Wondering if you’re getting the right salary?
Nigel Frank is organizing its yearly salary survey for Dynamics professionals.

You’ll get a copy of the results for free if you take part in the survey, and you can also win some prizes.

Just click the banner to take part in the survey.

I am tasked with doing data migration for a project that is about to go live. One of the things that have to be converted are item groups (InventItemGroup) and their linked dimensions (InventItemGroupForm).

Importing the InventItemGroup table is easy, but InventItemGroupForm is a little bit trickier.
There is a job below that shows how to fill in the LedgerDimension field on the InventItemGroupForm table. I’m not saying I completely understand the new dimension framework, but this method worked for me, and I hope it helps you when you have to do the same thing.

You will notice that you won’t be able to import the InventItemGroupForm table with the excel add-on. You’ll have to use a custom job (or make you own import framework like I did).

This white paper can help too: Implementing the Account and Financial Dimensions Framework (White paper)

Comments with ideas / insights / improvements are welcome as always.

Hi everyone,

Together with some colleagues, I will be attending the Technical Conference in Nice next week.
I’m very exited, as this is a first for me (but hopefully not last).

I will bring you the news when I get back.
See you there!

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.

Here’s a list of af few reasons why I think it is important to fix those best practice errors :-).

Improved performance
Many best practices have an influence on performance. For example, it is best practice to set the property CreateRecIdIndex to True on tables with Created/Modified DateTime fields. If you don’t, this will have an adverse effect on the performance of those tables.
Another example is that if you adhere to the best practices concerning the construction of classes and the use of batch classes, it will be much easier to improve performance by enabling batch multi-threading.

Improved readability of code
When all developers follow best practices about formatting of code, the code will be more readable and easier to understand. Avoiding dead code and removing unused variables will also make the code less confusing.

Developers learn
There are a lot of handy things you can learn by solving best practice deviations. Adding fields to field groups for example is a great way to avoid customizations to forms. And by figuring out what configuration is needed on a menu item, you learn about what effect configuration keys have on you solution.

Improved security
Adding security and configuration keys is vital to good security. When ignoring best practices, an unauthorized user might cause a big mess that you’ll have to clean up.

Certified for Dynamics AX
Making sure your solution is best practice deviation free goes a long way towards passing the Software Solution Test.

Better user experience
Some best practices have to do with labels, help texts, descriptions for batch task, etc. If you ignore those, it will be more difficult for the user to understand the solution you created.

Exception handling can be quite confusing in Dynamics AX, so I wanted to share some quick facts about try/catch and transactions.

The general rule is that exceptions are caught in the outer most catch, where the ttslevel is 0. This means that if you put a transaction around a try/catch, your exceptions will not be caught.
The following two jobs demonstrate that:

Transaction inside try/catch:

Output:

Error an error
Info error caught

Try/catch inside transaction:

Output:

Error an error

As you can see, the error is not caught when the transaction is around the try catch.

However, there are two exceptions to this rule.
The following code demonstrates that UpdateConflict and DupplicateKeyException can be caught inside a transaction.

Output:

Info Info can only be caught outside of the transaction
Info Warning can only be caught outside of the transaction
Info Deadlock can only be caught outside of the transaction
Info Error can only be caught outside of the transaction
Info Internal can only be caught outside of the transaction
Info Break can only be caught outside of the transaction
Info DDEerror can only be caught outside of the transaction
Info Sequence can only be caught outside of the transaction
Info Numeric can only be caught outside of the transaction
Info CLRError can only be caught outside of the transaction
Info CodeAccessSecurity can only be caught outside of the transaction
Warning UpdateConflict can be caught inside transaction
Warning UpdateConflict can alse be caught outside of the transaction
Info UpdateConflictNotRecovered can only be caught outside of the transaction
Warning DuplicateKeyException can be caught inside transaction
Warning DuplicateKeyException can alse be caught outside of the transaction
Info DuplicateKeyExceptionNotRecovered can only be caught outside of the transaction
Info Timeout can only be caught outside of the transaction
Info PassClrObjectAcrossTiers can only be caught outside of the transaction

It is also noteworthy that, when you enter a catch block, there has been a implicit ttsabort, so the transaction has been rolled back. However this is not true for UpdateConflict and DuplicateKeyException when they were caught inside a transaction.