often go hand in hand: it’s often either a business event triggering an interface or a business event following up on incoming interface data. For example: automatically creating pick orders and updating the related order statuses in the E-commerce frontend. In our aim for maximum comfort for both the business user as well as the system administrator, how can we automate this type of business events and interfaces in a combined way?
In this blog post I’ll boil the necessary standard AX ingredients into a configuration which allows you to reach this goal. I’ll also show you how to leverage this configuration to completely automate the following example flows:
- Flow 1: importing transactions from a (3rd party) sales channel, converting the transactions to sales orders and sending an acknowledgement to the channel that the order import was successful or unsuccessful.
- Flow 2: updating the on hand stock for the different channels and sending the stock levels to the sales channels.
- Flow 3: creating picking lists for the incoming orders and informing the sales channel on the ‘picking’ status.
When you have this running, it’s like simulating a factory with Lego: when your order pickers come in in the morning they’ll find the picking lists on the printer; the sales channels can work with the latest stock levels and order statuses and by leveraging role center your system administrator sits in his control room waiting for any exception to occur which requires intervention – Sounds almost like a real factory… right?
Below you find an overview of the example scenario for this blog post with the 3 flows mentioned – I highlighted the manual and automated tasks in blue/red respectively and painted processes and interfaces as solid lines/dotted lines respectively.
In this particular example, the (3rd party) sales channel has some specific requirements:
AX ingredients to automate
- It requires to receive an acknowledgement if sales order creation in AX was successful or not.
- It requires to receive stock updates at least every 5 minutes.
- It requires to receive information that the picking process for the items has started. This information is then available in the customer’s ‘My account’ section on the online store and is sent to the customer by SMS.
The ones of you with AX/Retail background will probably recognize how the different tasks in the example scenario can be supported by standard AX/Retail batch jobs:
- The interface flows 1A, 1C, 2B and 3B can be supported by Retail Distribution Schedules (Retail > Periodic > Data distribution > Distribution schedule), although they might have to be custom configured. The distribution schedules are to be configured as batch jobs.
- The transaction to sales order conversion can be supported by the Synchronize online orders batch job for E-commerce (Retail > Periodic > Synchronize online orders) or the Post statement batch job (Retail > Periodic > POS posting > Post statement) for POS. In this case we work with the Synchronize online orders batch job as in the example scenario we have to pick order placed at the online store.
- Creating pick orders can be automated in multiple ways but in this case we leverage the Picking workbench (Inventory management > Periodic > Picking workbench > Picking workbench).
Important to notice here on the side is that both the Synchronize online orders
batch job as well as the Picking workbench
will try to reserve items automatically, independent from the settings in the Accounts Receivable parameters (> General > Sales > Reservation
) which might be on Manual
. For this reason, and for the reason that picking will be tied to one specific point of time (for example 7AM), as opposed to the other batch tasks which will run periodically throughout the day, the 3 different ‘flows’ (combinations of business event and interface) are to be scheduled in their own frequency. This also provides the opportunity for an order manager to allocate additional on hand stock to fulfill open order requirements which failed to claim stock at import before the picking workbench runs automatically.
So… from helicopter perspective AX has a pretty good coverage, right? But we need to bundle the automated tasks in 3 groups which can be scheduled in their own frequency, instead of having to manage 7 batch jobs which are to be aligned in timing individually. How do we organize that?
Towards a solution
From the requirements stated above we can distill that we need the following configuration:
- 2 batch jobs for flow 1 and 2, to be scheduled periodically with high frequency (for example every 5 minutes)
- 1 batch job for flow 3, to be scheduled periodically with low frequency (once or twice a day at fixed points of time)
- Multiple batch tasks per batch job, to be run sequentially.
- Custom distribution schedules to support our interface flows, to be run as batch tasks. Assumption: we leverage standard AX/Retail CDX for interfacing, so we ship data in/out through the AX channel database for the sales channel.
Point 4 can be covered by defining new or updated Distribution schedules
supported by new or updated scheduler job
definitions. As an example for element 3A (Send pick status/information) of the example scenario above:
Points 1 and 2 are covered by the standard AX batch framework (System administration > Inquiries > Batch jobs > Batch jobs
) which offers the ability to define standard recurrence patterns. Example batch job for flow 3:
The difficulty in is point 3. For being able to schedule the batch jobs as separate batch tasks under the umbrella of one batch job, three things need to be arranged:
- Customization part 1: batch class adjustment. The respective business logic is to be enabled for running as a batch task. In AX 2012 R3 there are two main ways of developing batch classes:
- Through extending the RunBaseBatch framework: the ‘classical’ framework.
- Through extending the SysOperation framework: the framework introduced with AX 2012 which is recommended by Microsoft.
All current Retail batch jobs (my reference version: AX2012R3CU8) (still) rely on the RunBaseBatch framework. In this framework, batch classes can be enabled for running as batch tasks by setting the CanGoBatchJournal method to return TRUE – Here’s an example for the RetailCDXScheduleRunner which contains the business logic for running the Distribution schedules in batch:
Note: if this method is not added or returns FALSE, the batch class is simply not selectable as batch task under a batch job.
Note 2: you may have noticed that for some Retail batch jobs, Microsoft has added the CanGoBatchJournal
method in AX 2012 R3.
- Customization part 2: passing parameters to the batch task. As a batch class is sometimes built upon an existing form which is designed to pass parameters to the batch class (in the example above: a parameter which indicates which distribution schedule to run), it is not always possible to set the right parameters in the context of the batch job configuration form. See below for an example of this issue: the Distribution schedule form (Retail > Periodic > Data distribution > Distribution schedule) passes the selected distribution schedule as a parameter to the batch form when configuring a batch job. In the Batch tasks form (System administration > Inquiries > Batch jobs > View tasks; see figure below), this parameter cannot be set (only consulted). So in areas where the batch class parameterization relies on existing forms, some controls and business logic have to be added to enable the batch class to receive the right parameter values.
- Additional configuration. In our example scenario as described above, we have to enforce the tasks to run sequentially. But how? Standard AX provides some tools here:
- Batch task conditions. On the batch task we can configure AX to run task 2 after successfully finishing task 1. Here’s an example for our flow 3 above:
- Server configuration. When applying batch task conditions you’ll notice that some batch tasks (for example a Retail Distribution schedule) create subtasks which cannot be conditioned. So if Task 1 creates a subtask 1a, then task 2 could already start running in a separate (parallel) thread. Therefore, to force AX to run the main tasks sequentially, the number of threads on the batch Server configuration (System administration > Setup > System > Server configuration should be put down to 1 – Note that the number of threads indicates the number of tasks AX can potentially execute in parallel per batch job.
Note: the batch tasks which are to be enforced to run sequentially, need to be allocated to the batch server with Maximum batch threads = 1 setting specifically:
- Customization part 3. Even with the configuration under point 2 we are still not fully sure tasks will run sequentially. Some tasks are running in CIL (Common Intermediate Language) and cannot be checked for completion by AX; AX considers the tasks to be done when handed over to CIL and will use the thread for the next task. In other words: neither batch task conditions nor server configuration will work. In the example of task 1 being executed in CIL, the only thing I could think of was to implement a pause to make sure task 1 is finished before task 2 takes off. I’ve built this ‘pause’ in the form of a custom batch enabled class which allows me to set a number of seconds of pause before continuing to the next task – it’s not ideal, but with some testing it does its job perfectly. Here’s the code in the run method of the RunBaseBatch based pmoBatchPause class:
This business logic can then be used in the form of an additional batch task to pause the batch job for the number of seconds specified; here’s is an example for flow 1:
The cherry on the cake
Configuring the batch framework as described above adds another level of abstraction to the already powerful Retail CDX management framework in the Retail module. But when you top it off with a dedicated role center configuration, you can make a serious step towards Management by exception across the board. To stay with the example above, at business side you could implement an ‘exception cue’ for all orders which could not be directly fulfilled at import (flow 1A):
At IT management side you could implement an ‘exception cue’ for all (Retail) batch jobs errors. Clicking this cue will allow you to quickly descend into more details and solve the errors quickly and effectively:
I hope this has given you an impression on how you can create sets of interrelated automated tasks, whether having a business or integration background, to simplify the management of your complete solution and maximize comfort for your business and IT users.
Happy DAX’ing and happy holidays!
Het bericht Dynamics AX Retail: how to automate processes and interfaces in a combined way
verscheen eerst op Patrick Mouwen