What if all posting routines in Microsoft Dynamics NAV could be scheduled to a more sufficient time of the day?
The example in this blog shows how the job queue functionality can be used to allow background posting of sales orders.
In this example the sales order will contain creation of a new field that indicates if the sales order has been scheduled for posting or not. A filter is also introduced, so that the user doesn’t see Sales Orders that are scheduled for posting. We will also create a Job Queue entry for every sales order and thereby handle every sales order independently. Another possibility could be to add functionality that could handle all scheduled sales orders at one go.
The example also includes some error handling – meaning that if the job queue for some reason can’t post the Sales order, the status is changed to failed, and the Sales Order will reappear on the list of Sales orders the user will have to handle.
To provide an overview, the modified (and the new) objects are listed here:
Note that we introduce space for an error message (in case of Posting Error). The error text could be made available as a ‘lookup’ value in the status field.
We need to make the sales orders that are scheduled for posting in the job queue disappear from the view in form 42. Note also, that we have made the Job Queue Status field visible on the form.
When the user presses Post or F11, codeunit 81 is called directly with the Sales Header record as parameter. So let’s modify codeunit 81:
Note that when inserting the JobQueueEntry, it’s primarily the User ID field that is filled other fields are filled with default values. Note also that we specify the job queue to run a codeunit “Sales Order Post via Job Queue”, which is new and created for this example. The sales order to be posted is specified using the GETPOSITION function and entered into the Parameter String field of the Job Queue Entry. The Job Queue Entry record has several parameter fields that can be used in various situations.
Note that a codeunit that is being run by the job queue has to have the Job Queue Entry record as parameter. And as described in the last section, you also need to explicitly give the users permission to run codeunit 9000 – unless they are specified as ‘SUPER’.
Some codeunits display some kind of progress indicators using the dialog. When executing code on a NAS, no GUI operations are allowed. Hence, all updates of the progress dialog window in codeunit 80 needs to be wrapped with a IF GUIALLOWED THEN...
The default security setup in NAV relies entirely on restrictions on data access. By default all users have access to all forms, codeunits, reports etc. except the data, they process or show. Since the Job Queue mechanism has no way of sensing what data will be affected by running e.g. codeunit 9000 (that then runs codeunit 80 that runs codeunit 12 …) we have chosen to require specific execution permission to codeunits and report that are going to be run by the job queue.
And that’s it. Now go on and post the sales order and see what happens.
I would like to add a special thanks to Rikke Lassen and Bardur Knudsen for making this blog a reality.
Martin NielanderProgram Manager