This is the third and final part in my series of posts about SysOperation (at least for now). You can find part 1 here and part 2 here.

I will demonstrate how to override methods on the dialog (in this case modified()), and how to read and set properties of controls.

For the sake of this demo, we will add a checkbox to the dialog that will allow us to set the enabled property of the date control.
It should look like this:

1. Modify the data contract

We will need to modify the data contract so a checkbox is displayed on the dialog that we can use to enable or disable the date control.

Add this variable to the class declaration of the KlForCustTesterDataContract class:

Then add this method to that same data contract

There’s nothing new here, we already did all of this in part 1

2. Extending SysOperationAutomaticUIBuilder

We will extend the SysOperationAutomaticUIBuilder class so we can override methods and properties of controls on our dialog.

First, create a new class, KlForCustTesterUIBuilder:

Things we will need in this class are:

1. a variable for the date control
2. a variable for the new checkbox control
3. our data contract

So we add these variables to the class declaration:

2.1 Adding the override method

We will first write the method that will override the modified of the checkbox control. Simply add a new method to the KlForCustTesterUIBuilder class:

The code above sets the enabled method on the dialogFieldTransDate object based on the value property of dialogFieldAllowModifyDate object, or alternatively, the _checkBoxControl variable.
As you may remember, we declared the DialogField variables in the class declaration. Of course we will still have to initialize these variables , and that’s what we’ll do when overriding the postBuild method.

2.2 Overwriting the postBuild method

Next, we need to override the postBuild method on our KlForCustTesterUIBuilder class. This method will be called after the dialog is created, so it is a good place to put our logic.

Override the method:

Next, let’s add some code to this method, starting with the code that retrieves the data contract object, which is pretty easy:

Next, we retrieve the DialogField objects:

In the code above, the bindInfo() method returns an object of type SysOperationUIBindInfo. This contains information about which dialog controls the data members are bound to. By providing a reference to the parmTransDate and parmAllowModifyDate member when calling the getDialogField() method, we get the dialog control that is associated with each member.

Next, we will register the method we want to override:

As you can see, we can use the registerOverrideMethod() method to override methods on dialog. This is a huge improvement over overriding methods on dialogs in 2009. We simply point to the method we want to override (FormCheckBoxControl.modified) and the method the needs to be executed (KlForCustTesterUIBuilder.allowModifyDateModified).

Finally, we initialize the value of the enabled property, and the complete method will look like this:

3. One more attribute

Now, we’ve created the UIBuilder class, but we still have to link it to our data contract. That’s what the SysOperationContractProcessingAttribute attribute is for.

To link the UIBuilder class to the data contract, open the classDeclaration method of the KlForCustTesterDataContract class, and add the SysOperationContractProcessingAttribute:

4. Testing!

But wait (you already know what I’m going to say right), first click the Generate Incremental CIL button to generate CIL.

Right click the KlForCustTesterServiceController menu item we created on day 2, and choose open. You should see this dialog:

When you check the checkbox, you should see that the date field is enabled.

Download the XPO for part 3 here.

That concludes my blog posts about SysOperation, I hope you like it, and I’m looking forward to your feedback.
Have fun making batches!

In part 1, we created a nice batch using data contracts, service operation and the SysOperationServiceController class.

Today, we will place our menu item on the Customers form, so we can process the customer that is selected in the grid. It will look like this:

A thing that is still missing though, is a way to work with the Args that are passed when a menu item is executed. We want to be able to set the query on our data contract before showing the batch dialog. We might also want to have a default value in some fields, for example, the date should be today’s date every time we launch the dialog.
We can do all of that by extending the SysOperationServiceController class.

So let’s do that!

Create a new class that extends SysOperationServiceController

Now let’s create a method that constructs an instance of this class based on the Args object

Above is the basic code that should be in your construct method. However, this doesn’t do anything more than the SysOperationServiceController already does, so let’s add the logic that sets the date to today’s date.

As you can see, the Data Contract is fetched using the getDataContractObject() method. This will also unpack any values that were packed before, just like a normal RunBase would.
Setting the date is a simple as setting the parm method on the data contract.

Now let’s add the logic that creates the correct query by adding a range based on the record in the Args variable.

There you go. Now we need to make a main method that uses this construct method, and starts the operation:

We also need to create a new menu item. Right click you project – New – Menu Item.
Enter the following properties:

ObjectType: Class
Object: KlForCustTesterServiceController
Parameters: KlForCustTesterDataService.testCustomer

Next, add the menu item to the CustTable form:

Finally before testing, click the Generate Incremental CIL button to generate CIL.

Right click the CustTable form and click Open. This will open the Customers form. Switch to the grid view (Ctrl + Shift + G), and select a record. Then click the button we just added.

Note: a bug (or something I do wrong?) I found is that the query values that are displayed on the dialog seem to be “lagging”. The wrong values are shown, but when you click ok, the correct values are used, unless you click the select button.
This can be fixed by adding this line before returning the controller object:

KlForCustTesterServiceController.queryChanged("_klForCustTesterDataContract.parmQuery", query);

This is probably not a nice way to do this, so I’ll look into it, and let you know.

When you click Ok on the dialog, you should see that only the customer you’ve selected will be processed. You will also see that the date has been set to today’s date, just like we wanted.

Download the XPO for part 2 here.

This is part 1 of a series of 3 blog posts where I demonstrate how to create batch classes using the SysOperation classes (Read the introduction here)

We are going to create a batch that looks like this:

And we are going to do that without creating a RunBaseBatch class!

Note: Just to be clear: the batch class won’t actually do anything useful, everything is just for demo purposes.

Okay, let’s start!

1. Data Contract

First, we will create a data contract. The data contract contains data members that represent the fields that will be available on the dialog.

Let’s create a new class, KlForCustTesterDataContract:

The string DataContractAttribute indicates that this class is a Data Contract. The square brackets [] indicate that this string is an attribute (You can read more about attributes on MSDN).

Next, let’s add Data Members to this contract by first declaring them in the class declaration

We add a string field, a date field, and a query. We still need to create parm methods for these variables.

This is just a simple string field, nothing special here except for the DataMemberAttribute attribute that indicates that this method is da data member.

The date field is of type TransDate, so we’ll give it a nicer label by using the SysOperationLabelAttribute attribute to specify the label used.
Also note that, when two attributes are specified, the are separated by a comma (,).

We will also add a query, so we can loop all customers. As you can see, we can specify the query by using the AifQueryTypeAttribute. The query KlForCustomers is just a query in the AOT with CustTable as a datasource (see xpo file at the end).

Next, we add two helper methods that are not Data Members, so we can easily set and get the query variable.

To get the query:

To set the query:

2. Service class and operation

Next, let’s create a service class called KlForCustTesterDataService.

Right click the class, click properties, and set the run on property to server.

Adding a service operation to this service class is as simple as adding a method. As you can see, the SysEntryPointAttribute attribute indicates that this is a service operation, and our data contract is used as an argument.

Of course, this method needs some demo functionality, so let’s add that:

3. Service

Right click your project, and choose New - Service. Give this service the same name as the service class, KlForCustTesterDataService.
In the properties of this node, set the class property to KlForCustTesterDataService
Expand the node of your service, then right click on the Operations node.
Click Add operation and check the add checkbox next to the method we’ve created, and click OK.

4. Menu item

All we need to do now is create a menu item so we can start our dialog.
Do this by right clicking your project – New - Menu item. Name it KlForCustTesterDataService.

Enter the following properties:
ObjectType: Class
Object: SysOperationServiceController
Parameters: KlForCustTesterDataService.testCustomer

As you can see, we don’t link directly to our service class, in stead, the class SysOperationServiceController will be used, and will know what service operation to start because it is specified in the parameters property. More about these controller class in part 2 of this series.

5. Run it!

But wait, we still have to do one small thing: compile our X++ into the common intermediate language (CIL). Don’t worry, it’s easy. Just click the Generate Incremental CIL button in the toolbar (this might take a while).

After CIL was generated, right click the menu item and click Open. You should see your batch class. As you can see, all fields from the datacontract are displayed, and a select button was automatically generated so you can modify the query.

Output when run in batch:

In part 2, we will take a closer look at the SysOperationServiceController class. See you tomorrow.

Download the XPO for part 1 here.

Dynamics AX 2012 introduces a new way for creating batches, without using the RunBaseBatch class. The SysOperation* classes are part of the Business Operation Framework, and can be used to create these batches.

Some documentation is already available on MSDN about the BOF and the SysOpertation classes, but I was still confused when creating such a batch class. That is why in the next 3 days, I will cover the basics on how to create these batches, so you don’t have to figure it all out on your own.

I hope to get some feedback too, because not everything is crystal clear to me either :-).

But anyway, this is what you can expect in the next 3 days:

Day 1 (link)
A demonstration on how to create Data Contract classes and Service Operations. You will also learn how to use attributes like DataContractAttribute and DataMemberAttribute, and at the end, we will already have a working batch class.

Day 2 (link)
We will take a closer look at the SysOperationServiceController class, and will be creating our own controller. This will allow us to set properties on our Data Contract based on Args. This is useful when you batch is started by a button on a form that is linked to a datasource.

Day 3 (link)
To make a fully functional batch, we need to be able to overwrite methods on our dialog field like lookup and modified. We also want to be able to change the properties of these fields, like enabling or disabling them. That’s just what the SysOperationAutomaticUIBuilder class is for, and we’ll look into that.

The code below contains a try/catch that I use a lot when developing batch jobs, especially multithreaded ones.
It deals with frequently occurring exceptions that, in some cases, can be easily solved by retrying:

• Deadlocks
• Update conflicts
• Duplicate key conflicts

Duplicate key conflicts are more rare than update conflicts, but I’ve seen them pop up under heavy load on InventDim records.

Introduction

Normally, when you schedule your RunBaseBatch class as a batch job, it will create one task.
You can check this under Basic – Periodic – Batch Job when you have scheduled a batch job.
In a diagram, it looks like this:

This batch task will execute everything on one batch session on one batch server.

But in AX 2009, your batch group can be added to multiple AOS server, and an AOS server can process multiple tasks simultaneously. So how can we use this to speed up our batch job?

We do it by splitting up our task in multiple smaller ones, which are then distributed over multiple batch sessions (threads) and over multiple AOS servers.

Like this:

Example

In this example, I will loop all my customers, and simulate a process that runs for 3 seconds by using the sleep() function.

Note: download the .xpo file below.

Single thread

1. KlForUpdateCustomers: A class that contains my business logic I want to execute
2. KlForUpdateCustomersSingleTheadBatch: A class that extends RunBaseBatch and makes calls to KlForUpdateCustomers

KlForUpdateCustomers
This class contains this in its run method (see xpo file for other methods):

KlForUpdateCustomersSingleTheadBatch
This class is our batch class so it extends RunBaseBatch. It has a queryRun, and has this run method:

It loops all customers, and makes a call to the class we created earlier for each customer. To keep it simple, I did not add exception handling to this example.

When we run this in batch, a single batch task is created in the batch job that runs for about 3 minutes (according to the batch job screen).

Multithread

1. KlForUpdateCustomers: the business logic class we created earlier and we can reuse
2. KlForUpdateCustomersMultiThreadBatch: The class that represents the batch job and will create batch tasks
3. KlForUpdateCustomersMultiThreadTask: The class that represents one batch task and makes calls to KlForUpdateCustomers

KlForUpdateCustomers
This class is the same as before and processes one customer (CustTable record).

KlForUpdateCustomersMultiThreadTask
This class extends RunBaseBatch and represents one of the many batch tasks we will be creating. In this example it processes one CustTable record, so a task will be created for each CustTable record.

The run method looks like this:

KlForUpdateCustomersMultiThreadBatch
This is our batch job class, and this is where the real magic happens. This class will create multiple instances of KlForUpdateCustomersMultiThreadTask and add them as a task to our job at run time.

This is how the run method looks:

As you can see, for each custTable record, we create a new task. When the batch job doesn’t run in batch, we process it as we otherwise would using one session.

In the batch tasks screen (Basic – Inquiries – Batch Job – (select you batch job) – View Tasks), you can clearly see what happens.

First, the status is waiting, and one task has been created.

Then, when the batch job is executing, we can see that multiple tasks have been added to our batch job.

We can also see that it processes 8 tasks at the same time! This is bacause the maximum number of batch threads is set to 8 on the batch server schedule tab of the Server configuration screen (Administration – Setup – Server configuration).

Finally, we can see that the job has ended, and that all runtime tasks have been moved to the batch job history:

You can view the history and the log of this batch job:

Notice how the executing time has gone from 3 minutes to 1 minute according to the batch job screen.

Alternatively, you could use a queryrun in you batch tasks class too. You could for example create a batch group per customer group if that makes more sense to you. The ‘per record’ approach is just an example, just do what makes the most sense in your situation. Sometimes it is better if the runtime tasks have a bit more to do, to counter the overload of creating the tasks.

Conclusion

Spread the word :-).

Download the XPO file by clicking here.

Update 2011/02/11:
There were two errors in the example:
This line:

Has been replaced with:

And this line:

Has been replaced with:

Todo on my part: update the XPO.

Here are two jobs to run inbound and outbound messages manually, so you don’t have to wait for the batches to pick them up.

Inbound:

Outbound:

Ofcourse, you can put this code in classes, or combine them so they are executed together. Because inbound messages can trigger outbound messages, it’s better to process the inbound messages before the outbound messages.

A possible use for this is when monitoring batch jobs.
Tested using AX 2009, XP Pro.