Mastering Background Processes in D365 F&O: Understanding the SysOperation Framework
Mastering Background Processes in D365 F&O: Understanding the SysOperation Framework
.png)
🚀 Mastering Background Processes in D365 F&O: Understanding the SysOperation Framework
If you work with Microsoft Dynamics 365 Finance and Operations (D365 F&O), you know that running long-running processes or complex operations efficiently is key. That’s where the SysOperation Framework comes into play—it's the modern, robust architecture for creating batch jobs and service-based operations using X++.
The SysOperation Framework has replaced the RunBase and RunBaseBatch classes.
Why SysOperation Matters
The brilliance of SysOperation is its fundamental design principle: separating the business logic from the user interface (UI). This separation isn't just neat; it makes your custom processes significantly more:
Scalable: Operations can run reliably in the background, even across large datasets.
Testable: Logic can be tested independently of the UI.
Flexible: The same core logic can be executed either interactively (by a user) or as a scheduled batch job.
The Three Core Components
The SysOperation framework is built around three primary classes that work together seamlessly:
Data Contract Class: Think of this as the input form. This class defines the parameters (the 'data contract') that the user or system needs to provide to the operation. It's how your code knows what to process.
Service Class: This is the engine—it contains the actual business logic (the X++ code) that performs the work. This is where the core operation is executed, totally separate from how the user interacts with it.
Controller Class: This acts as the manager. The Controller determines how the process will run—whether immediately as an interactive operation or submitted to the batch framework to be run later. It manages the execution flow from start to finish.
By cleanly separating these concerns, the SysOperation Framework ensures your custom operations in D365 F&O are powerful, stable, and ready for enterprise-level use!
1. Data Contract Class
A class with the [DataContractAttribute] that holds the parameters needed for the operation. Each property that needs to be passed to the process is defined using [DataMemberAttribute].
For example, say we want to create a data contract for customer account. We create the method below as follows:
[DataContractAttribute]
public class CustTestLoopContract
{
CustAccount custAccount; // parameter property - cust account
[DataMemberAttribute("Cust Account")]
public CustAccount parmCustAccount(CustAccount _custAccount = CustAccount)
{
custAccount = _custAccount;
return custAccount;
}
}
2. Service class: A class that extends SysOperationServiceBase and contains the core business logic for the operation. This is where the work is performed.
Imagine a code snippet that loops from the CustTrans table using the Customer account specified in the parameters (Data contract). Notice that the data contract is passed as a parameter to the process method, and it is used to access a data member, in this case, "Cust Account".
public class CustTestLoopService extends SysOperationServiceBase
{ // extends the SysOperationServiceBase class
public void process(CustTestLoopContract _dataContract)
{ // method where the operation is performed by the class
CustTrans custTrans;
while select custTrans where custTrans.AccountNum == _dataContract.parmCustAccount()
{
info(strFmt("%1",custTrans.AccountNum));
}
}
}
3. Controller class: A class (often extending SysOperationServiceController) that orchestrates the process, connecting the data contract to the service class and handling the execution mode. It can be used to create user dialogs or to run the operation as a batch job.
The controller class, more often than not, should have 4 methods overridden:
- New method: overrides the new method of the superclass (SysOperationServiceController) by specifying the method of the Service class to run and the execution mode.
- Default Caption: The caption of the batch job.
- Construct: Instantiate the class with the execution mode.
- Main method: The method that the menu item would run.
public class CustTestLoopController extends SysOperationServiceController
{
protected void new()
{
super(classStr(CustTestLoopService),
methodStr(GCustTestLoopService, process),
SysOperationExecutionMode::Synchronous);
}
public ClassDescription defaultCaption()
{
return "A test batch to loop customer trans";
}
public static CustTestLoopController construct(SysOperationExecutionMode _executionmode = SysOperationExecutionMode::Synchronous)
{
CustTestLoopController controller = new CustTestLoopController();
controller.parmExecutionMode(_executionmode);
return Controller;
}
public static void main(Args _args)
{
CustTestLoopController controller;
controller = CustTestLoopController::construct();
controller.parmArgs(_args);
controller.startOperation();
}
}
Finally, you need a menu item, preferably an action menu item pointing to the controller class. Once a user clicks on it, the dialog pops up with parameters (Cust account) and the batch processing option for background processing. This frees up the UI to be used for other processes, while the other processes completes in the background.
In the next blog post. I will talk about how to use a query and Automatic UI builder. Automatic UI builder gives the flexibility to manipulate the parameters control.
.png)
.png)
Comments
Post a Comment