You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

Scheduling is an important part when working with processes. When modelling a process it is possible to create all kinds of tasks such as timer tasks, automatic tasks and tasks that expire after a period of time. It is also possible to model Priority Algorithms which gives you the possibility to present the tasks to the users in the correct order of the urgency of the task. To make sure these functionalities are correctly processed, a scheduling mechanism lies at the heart of the Blueriq Process Engine.

We distinguish two types of schedulers namely Basic and Advanced. Choosing the right scheduler that suits your needs depends on the business demands and the number of cases and tasks being processed. The paragraphs below describe the workings of both schedulers and the considerations when choosing the appropriate one.  

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 upgrading from the basic to the advanced scheduler, please refer to the Scheduler migration guide

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.

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). 

 

  • No labels