ReliableAsynchronous Not So Reliable? Here's Why


The SysOperation framework has four basic modes, what Microsoft calls Execution Modes.  Their desirability depends on the situation, of which I'll try to explain briefly.

  • Synchronous - This is similar to running a long process on the client.  It will lock the client session if the processing takes longer than a few seconds, and the user won't be able to do anything until it is completed.
  • Asynchronous - To run a service asynchronously, the service class must have a Service node in the AOT, be a part of the AxClient service group, and the service group must be re-deployed thereafter for the change to take affect.  If this isn't done, the service will default to Synchronous which will lock the client session.
  • ReliableAsynchronous - The default mode if none is selected. When the processing begins, it creates two asynchronous threads - the first on the batch server and another on the client to poll the batch server to get the infolog when it is completed. When the batch job is completed, it is removed but leaves traceability in Batch Job History.
  • ScheduledBatch - This is akin to checking the batch tab, but the user does not get a choice.  Even if they did not select to run it on batch, it will. And, it will leave the job in the Batch table in an 'Ended' state when it is complete.

In many casses, ReliableAsync is the most desireable option.  The user can kick off a job, and can go about their daily tasks in other modules. The job executes "reliably" on the batch server, so even if the user's client session were to die unexpectedly, the job will complete as long as the AOS is alive.  

Now, some of us are finding that rapid execution of these jobs can lead to unpredictable results.  Due to the nature of it, it kicks off two simultaneous threads of which run in tandem.  In some cases, the batch job is not yet completed inserting when the polling mechanism looks for the batch, as a fellow Dynamics AX architect Alex mentions in his blog post

We also have found, that the SysOperationServiceController.afterOperation() method is executed twice for ReliableAsync, once for the client thread and once for the server/batch (Synchronous) thread.  When the operation works as desired, and displays the infolog result to the user the order of execution is FIRST Synchronous and then ReliableAsynchronous.  You can put an info(strfmt('%1',_executionMode)); in that method to see which are getting hit first. 

In some cases, the ReliableAsync execution mode will hit first, and the batch job is either not yet complete (no infolog) OR it is already completed and has been deleted as is normal for this execution mode.  In that case, I force the process to look up the batch job history record and pull that infolog in stead.

For our users, this makes the process more "reliable" as they are guaranteed an infolog result from their job ( which is posting movement journals, kind of important in this case ).  

I hope this helps you make the ReliableAsync option more reliable for your staff. Of course, if you don't want to modify the core SysOperationServiceController, you can override the afterOperation method in a custom controller like we have done above.