Process Engine

Basic scheduling (default)

By default Blueriq uses the basic scheduler for evaluating tasks and priorities. The evaluation is executed according to the configuration of the blueriq.timer.interval. This can be set to hourly (default), each minute or never. Each time the interval expires, the process engine starts evaluating all projects present on the Runtime that are using the Process Engine. Per project all cases are retrieved that contain timer tasks, automatic tasks, tasks with a expiration date or Priority Algorithms. When the evaluation leads to a match (meaning when the current time matches the proposed execution time), the task is executed. 

As a result, in a single-node or multi-node (clustered) environment when the interval expires, one of the nodes will start evaluating all projects which in turn will cause a peak load due to the increase CPU and memory consumption of that specific node.  

Advanced scheduling

When using the process engine in a clustered environment or when there are a lot of tasks being processed, the advanced scheduler is probably more suitable because this scheduler is able to schedule tasks in a precise manner. With the basic scheduler the evaluation takes place on a project level, case per case. The advanced scheduler evaluates and executes each task individually at a specific moment in time (unlike an interval). 

As a result, in a single-node or multi-node (clustered) environment each tasks will be handled individually and the nodes will handle a task one-by-one so no peak load will occur.

Jobs

This paragraph describes in detail the workings of the different jobs which are part of the Advanced Scheduler. 

Timer Job

Timer jobs are created for each timer task. When a timer task is created, a timer job is scheduled for it and executes the node processing. The process will continue from that point. 

If the current case is locked when the timer job executes, the job is rescheduled to execute every minute until the case is unlocked.

Expiration Job

Tasks that have an expiration timeout and a continuation point are considered to be Expiring Tasks. This information is placed into the timeout definition of the task.

For each Expiring Task an Expiration Job is created. This job is scheduled to execute at the moment in time when the Task should expire. This job sets the task status to expired and continues the process from the continuation point set in the timeout definition of the task.

If the current case is locked when the expiration job executes, the job is rescheduled to execute every minute until the case is unlocked.

Priority Reevaluation Job

For each task that has associated a priority algorithm a new Priority Reevaluation Job is created. This job is scheduled to execute according the the specific reevaluation time:

• Minute
• Hour
• Day
• Week
• Never

This job is relevant only if the task is still open.

Recovery Job

A pending task is a task that was started at a moment when the runtime unexpectedly stopped. The task that has the status started and is automatic has to be restarted as soon as the runtime is available again. 

For each task that has the status started and is automatic a recovery job is scheduled to restart it. 

This job is relevant only if the automatic task delegate is available on the process engine. If the delegate is missing at the job execution time, the task is rescheduled to execute again after one minute.

Considerations

The transactional boundary of the evaluation and execution done by the basic scheduler is a project. As a result, per project all cases are evaluated and all the tasks are executed the moment the timer interval expires. This will increase CPU and memory consumption. Also if something went wrong with executing one of the tasks within a project, the transaction will be rolled back (eq. case A has 5 timers tasks, if one of the timer tasks fails, all the other timer tasks will not be executed). Due to the fact that the advanced scheduler evaluates and executes each task individually, it has no impact on the other tasks when a specific task fails. Also, in a multi-node environment each task will be picked up one-by-one by one of the nodes so no peak load will occur.

On a business level there is another consideration to be made when switching to the advanced scheduler. When a project contains a lot of cases with tasks that will be matched in when the timer expires, evaluating this project could take a long time. If this evaluation takes more time than the value of the blueriq.timer.interval, the next interval will expire again which will start evaluating the same tasks again. Eventually this will lead to unexpected behaviour and performance loss. 

The same consideration holds for cases with many tasks that will be executed in the future. These tasks are constantly evaluated but will be skipped (because they don't match).