Sysoperation VS RunBase

 

What is the Sysoperation framework how it is different from the runbase framework?

In Microsoft Dynamics AX 2012 & D365FO, the SysOperation system supplanted the RunBase system to bolster the group preparing usefulness. Going forward, the SysOperation system is prescribed for composing custom trade rationale that requires clump handling usefulness, over the censured RunBase framework. The RunBase system characterizes coding designs that actualize these necessities. The SysOperation system gives base executions for numerous of the designs characterized by the RunBase system. Another incredible thing is SysOperation system streamlined the pack / unload of factors that were extra work within the RunBase system, taking advantage of the Traits highlight presented with AX 2012 & D365FO.

SysOperation framework allows application logic to be written in a way that supports running operations interactively or via the Microsoft Dynamics AX & D365FO batch server. It implements the MVC (Model–View–Controller) design pattern, with the isolation of Parameters (Model), Dialog (View), and Service (Controller), for the code that’s executed.

The key objects of the framework are defined below:

Service:

The service class extends from the SysOperationServiceBase class and contains the business logic for the batch operation. Developers often tend to add the business logic in controller classes, which violates the Single responsibility principle.

Data Contract: 

Data contract class is the model class defining attributes needed for batch operations. These attributes are provided by the user, in a dialog. DataContractAttribute attribute is needed for the class and the properties methods require the DataMemberAttribute attribute.

Controller: 

Controller class extends from the SysOperationServiceController class. It holds information about the batch operation like execution mode, show dialog or progress bar etc. and directs the batch operation.

UI Builder: 

UI Builder class extends from SysOperationAutomaticUIBuilder class and is used for adding custom behavior to dialog/dialog fields dynamically constructed by the SysOperation framework.

D365FO Batch Job retries

 

Enable automatic retries on batch jobs

In the April/May released, Microsoft introduces the feature to retry the batch job, In the past, if the Finance and Operations apps experience any kind of loss of connection to Microsoft SQL Server, then all batch jobs that are running fail, and the reason is, on Azure if the connection is lost then the recovery is almost impossible.

So, Microsoft introduces an Interface class that will batch to reset itself in case of connection loss or failure.

How you can implement it in your code?

Here is an example if you are using the "RunBaseBatch" class in your batch Job.

class TestBatchJob extends RunBaseBatch implements BatchRetryable

{

    [Wrappable(true), Replaceable(true)] // Change to meet your customizability requirements

    public boolean isRetryable() // Use final if you want to prevent overriding

    {

        return true; 

    }

}

 Here is an example if you are using the "SysOperationServiceController" class in your batch Job.

class TestBatchJob extends SysOperationServiceController implements BatchRetryable

{

    [Wrappable(true), Replaceable(true)] // Change to meet your customizability requirements

    public boolean isRetryable() // Use final if you want to prevent overriding

    {

        return true;

    }

}

Important

If you designing a multithreading job and adding the runtime task, then you should implement this interface on both the main controller and the task controller.

If you want to disable the retry of the batch job then add your class in the 

Batch class configuration overrides 

Overrides setup