If you’re familiar with AX AOS topology, and you’re a global organization, you already know the pain point that is Time zone in AX 2012. The system is designed to host multi-company, multi-currency, and multi-time zone, however not all functionality in the system is time zone aware. One of those major sets of functionality is the SysOperation framework.
The SysOp framework is the new means by which developers can access the underlying batch framework. I’ve posted on the many benefits available by using the SysOp framework over the RunBaseBatch legacy methodology, and a fellow DAX blogger Tommy Skaue has posted more in depth about the inner workings of Batch processing. He graciously is sharing this info-graphic with the world, of which is below:
You’ll see in many of the steps, an AOS is involved. Now, an AX AOS can only have a single default Time zone, and that is whatever the underlying Windows Server operating system time zone setting happens to be. This setting can have major impact on how date fields are calculated throughout the system. There are many simple “date” fields ( vs UTC DateTime ), such as any derivative of TransDate EDT. Even some UTC calculations use the DateTimeUtil::GetSystemDateTime().
This can be a huge problem if say your users are executing a batch process based in Singapore, while the AOS that actually ends up executing that task is in the United States. There is risk of backwards or forward dating, depending on your time zone sweep.
Of course, you can setup time zone based Batch Groups:
In these batch groups, you could place AOS servers that are configured for the appropriate time zones, and train your users to use the correct batch group.
Unfortunately, in some cases the SysOperation framework won’t ask you what batch group to use. This is called ReliableAsynchronous mode. Because it executes without a batch tab on the dialog, it has to use a batch group that will guaranteed always exist in every AX installation, which is the “Empty Batch Group”:
If you place all of your AOS in this group, you’ll have extremely unpredictable date generation occur. If you place no AOS in this group, nothing will process for ReliableAsync tasks.
What would be nice, is if the system would instead determine a default batch group, based on a User Session. This would help with processing time sensitive tasks and documents appropriately. I’d like to demonstrate a potential approach.
First, let’s add the ability to set a default batch group per AX Cluster:
This is adding a BatchGroup field to the SysClusterConfig table, as well as the related form pictured above. Simple enough.
Now, let’s make a small modification to the SysOperationController base class, and determine a more appropriate batch server based on a user session:
The above example gathers the name of the AOS from the current session. It then finds the SysServerConfig entry based on this name. From there, we can determine the Cluster that AOS is configured and capture the default Batch Group. Of course, if nothing is found or it is null, we use the regular system setting to maintain continuity.
Only thing that remains is to override the new() method to call this logic:
Oh the joys of global organizations! =)