Introduction
With Microsoft Dynamics NAV 4.0 we had a job scheduling mechanism available in the Service Management module. The purpose for the job scheduler in Microsoft Dynamics NAV 4.0 is to give the possibility for scheduling tasks and their recurrence.

In Microsoft Dynamics NAV 5.0 the Job Queue was introduced. The Job Queue is primarily made for Outlook Integration, but has been extended to also include the previous job scheduling mechanism from Microsoft Dynamics NAV 4.0. The purpose of the Job Queue is to provide a mechanism for data processing on a server.

Job Queue Concept

The new Job Queue in Microsoft Dynamics NAV 5.0 is build over the following concept:

The Job Queues Entry table is where users or processes can enter a request for execution of a report or a codeunit. The Server (NAS) will look periodically into the Job Queue Entry table to see if there is a Job to execute.

The NAS will when it finds a Job Queue Entry, read it, delete it from the table (unless it is a recurring job) and then start running the requested job (report or codeunit).

 When the report or codeunit finishes, the NAS will write a ‘response’ into the Job Queue Response table. In case the calling process has requested this (as is the case for the Outlook integration). The NAS will also insert a record into the Job Queue Log Entry table to record that it has processed a Job (this is not shown on the drawing).

Security

The Microsoft Dynamics NAV permission system determines whether a user has access to run the specified object or not. The permission system will also check if the user has access to the data accessed by the specified object.

Important Note: If permissions are copied from the demo data, users will have permissions to run all objects. Access for each user will in this case only be limited by permissions for data. The job queue will however use the NAS for executing the objects. The NAS is defined as a specific user with specific permissions in Microsoft Dynamics NAV. This means that the objects executed from the Job Queue will be executed with the permissions of the NAS-user. To prevent the situation where access to data and objects are not based on the user permissions and instead of being based on the NAS-user permissions we have introduced an extra requirement for objects to be run via the Job Queue; The user must have explicit permission to run the object that is requested to be run – even if the user has been given the usual default ‘all objects’. In other words, if the user needs to run report 1 via the job queue, the user must have explicit rights to run report 1.

When to Use

If a codeunit have done some processing and generated a result it must be possible to pass the result back to the user or process. This is where it is beneficial to provide a Job Queue Entry record as a parameter to the codeunit being called.

The Job Queue Entry record has a number of fields whose only purpose is to carry parameters into and out of the codeunit. These fields are copied to the Job Queue Response record. This also means that codeunits that are to be run via the job queue must be specified with the Job Queue Entry record as parameter in the OnRun trigger. Actually this provides one extra level of security, as this prevents users from running random codeunits via the Job Queue. If the user needs to pass on parameters to a report, the only way to do so is by wrapping the report execution into a codeunit which then parses the input parameters and enters them into the reports before executing it.

Follow this link for how to setup

Follow this link for usage example

Martin Nielander
Program Manager

This posting is provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.