This article introduces the new C/AL functions in Microsoft Dynamics NAV, with particular emphasis on Task Scheduler.
Originally published in Q3 2017 NAVUG Magazine
Task Scheduler is the new platform engine that runs Jobs Queues. Before, all of the Job Queues were handled in AL and were either started through NAS or directly from the client. The AL approach had loopy logic for each Job Queue awaiting new jobs to arrive, keeping sessions open for a long time.
The problem was when something out of AL expected behavior failed, like a network outage making a SQL error, then the error would shut down the queue, requiring it to be restarted.
The new implementation supports restart of jobs, tolerance for transient errors, amount of parallelism including distribution between multiple NST, and more.
You can also simply continue to use Job Queue entries in Madeira (now Microsoft Dynamics 365 for Finance and Operations, Business Edition) since the Job Queues now run on the new engine. The old NAS is only there if people upgrade and still need the feature until they have upgraded the application.
The trick is that the system now knows who created the task and then also knows that the task should be run with that User’s permissions. The existing Job Queue functionality has been modified so it runs on top of this new mechanism and consequently, it doesn’t need the Job Queue table for anything.
Categories are still supported, but the execution mechanism will make sure that only one job with a certain category is executed at the same time. Priorities are not supported; for now, it’s first-in, first-out.
In the server configuration, you will notice that a new tab has arrived. Task Scheduler allows you to turn the feature on or off for a specific NST and how many concurrent tasks can be executed. What this means is that you can now configure one NST to serve Users and another one for background jobs. The default configuration is that the feature is turned on, and you don’t need to configure any job queues to make background jobs work. Also, it doesn’t keep any threads alive on the server when there is nothing to do. In case of server restart, the background execution will just resume automatically after a few minutes as the NSTs may need to synchronize and figure out who should run an aborted job. Use categories for serializing certain jobs, e.g. posting jobs to avoid lock timeouts (and deadlocks). When a job is started, it checks if it has a category code. If so, it checks if there is any other job running right now with the same category. If so, the job will reschedule itself for some seconds later.
The task scheduler enables you to control when certain operations or processes (in other words, tasks) are run. A task is a code unit or report that is scheduled to run at a date and time. Tasks run in a background session between the Microsoft Dynamics NAV server instance and database. Behind the scenes, the task scheduler is used by the job queue to process job queue entries that are created and managed from the clients.
To set up a task, create a code unit that contains the logic that you want to schedule. You can create a second code unit (referred to as a failure code unit) that contains the logic to handle the task if an error occurs for any reason. Once you have the code units, you can add C/AL code to the application that calls the CREATETASK function to schedule a task to run the code units.
The CREATETASK function can also specify the earliest date to run the task and whether the task is in the ready state.
A task can fail under the following conditions:
- The company cannot be opened.
- An SQL connection or transient error occurred with the database.
- The Microsoft Dynamics NAV server instance restarted while
the task was run.
You can view these errors in the event log of the computer that is running the Microsoft Dynamics NAV server instance. When an error occurs, the Microsoft Dynamics NAV server instance will rerun the task according to the following retry flow:
- Two minutes after the first failure.
- Four minutes after the second failure.
- Fifteen minutes after the third failure and any subsequent failures up to a max of 10 times after which the task is cancelled.