March 24, 2015

Dynamics AX 2012 SysOperation framework quick overview

The information in this post is based on Dynamics AX 2012 R3. It may or may not be valid for other versions.

This post is just meant as a quick overview and cheat sheet. If you are new to the SysOperation framework, I strongly suggest that you read Microsoft’s white paper on the subject as well. The information here may be useful if you just need a quick brush up on the different classes involved in developing operations with this framework.

There are variations, but when I use the framework I typically implement three classes:

  • Data contract
  • Service
  • Controller

Data contract

The data contract holds the data members needed for your operation. It can be compared to the typical CurrentList macro defined in the RunBase framework, but implemented as a class instead. There is no super class for data contracts, instead it makes use of the DataContractAttribute attribute, like so:

[DataContractAttribute]
class MyDataContract
{
    ItemId itemId;
}

In this example, the itemId is a data member. You need to implement a parm method for each data member and tag it with the DataMemberAttribute so the framework knows what it is. This enables the framework to automatically build the dialog for you.

[DataMemberAttribute]
public ItemId parmItemId(ItemId _itemId = itemId)
{
    ;

    itemId = _itemId;
    return itemId;
}

Service

The service class is the class that contains the actual business logic. It is not concerned with showing dialogs, batch processing or anything of the sort – that is the responsibility of the controller class. By separating this, you are more likely to design your code well and make more reusable code.

Like the data contract class, the service class does not need to inherit from anything in particular. The method that starts the operation (i.e. runs the business logic) must take an object of your data member class as input, though. For example:

class MyService
{
}

with a method called run:

public void run(MyDataContract _dataContract)
{
    // run business logic here
}

Controller

The controller class handles the execution and batch processing of your operation. It also makes sure that the code is executed in CIL for maximum performance. The controller class typically inherits from the SysOperationServiceController class, although there are other options as well.

class MyController extends SysOperationServiceController
{
}

The constructor of the super class takes a class name, method name and (optionally) execution mode as parameters. The class and method names should be the name of your service class and the method that should be run on it. So, you might implement your controller’s construct method like this:

public static MyController construct()
{
    ;

    return new MyController(classStr(MyService), methodStr(MyService, run));
}

Then the main method of the MyController class can be as simple as

public static void main(Args _args)
{
    ;

    MyController::construct().startOperation();
}

And you’re basically done. The above is obviously a very simple example and the framework contains a plethora of other options and possibilities, but this serves as a quick overview if you need a brush up when you haven’t used the framework for a while.

facebooktwittergoogle_plusredditpinterestlinkedintumblrmail

Posted by Mikkel

I am a senior Dynamics AX developer by day and an open source/free-as-in-speech software enthusiast by night. In addition to many technology-related topics, my main interests are physical exercise, healthy cooking, heavy metal music and spending quality time with my girlfriend.

View more posts from this author