The key objects of the framework are :
• Service: Developers should not add the business logic in controller classes, which violates the Single responsibility principle. The programmers made a way to separate the operation i.e. create a service class. The Service class extends from the SysOperationServiceBase class and contains the business logic for the batch operation . This class should contain all the business logic. When constructing your controller, indicate which class holds the operation that the controller will trigger.
• Data Contract: Data contract class is the model class use to define attributes for batch operations. These attributes are provided by the user, in a dialog. A DataContractAttribute attribute is needed for the class and the properties methods requires a DataMemberAttribute attribute. It’s nothing more than a model class with a few attributes in it. You can extend theSysOperationDataContractBase base class to define our labels, groups, sizes and types of parameters.
• Controller: Controller class extends from the SysOperationServiceController class, which will give you all of the methods you need. It is the class that orchestrates the whole operation. The controller class holds information about the operation, such as: when it should show a progress form, when it should show the dialog, and its execution mode – asynchronous or not.
• UI Builder: The UI builder class is an optional class for the SysOperation framework, which acts like the view part of the pattern. Use it if to add extra behavior to the dialog that AX constructs dynamically. If you are happy with the Ax dialog AX shows when you run your operation, then you don't need this class. UI Builder class extends from SysOperationAutomaticUIBuilder class and is used for adding custom behavior to dialog / dialog fields dynamically constructed by the SysOperation framework. It will provide you a set of methods to work with the dialog’s design, but more usually add extra behavior, or customize a lookup inside the postBuild method.
