Page History
...
How to model a Deadline in the Case-Engine
One example of a timed event could be changing the priority of a Case at a certain point in time. In my example, the priority is a metadata field, with a derived value on what the priority should be at any point in time.
This makes sure that whenever the case is being stored, the right priority will be determined and stored as well. In the implementation there is a rule for determining the priority. Below a part of the decision table.
We must make sure that after the deadline has passed, this rule is triggered again, which might lead to a different value of the priority.
Step 1
...
- Timer sub-process in the Case-Engine
The Case-Engine could come into action at a certain point in time (in the future), by adding a timer to the process-module. You can do this by adding a sub-process to any process, containing a timer.
After the timer has evaluated to TRUE (meaning the time has passed), the timer-node flows to the next point. In my example it just needs to re-evaluate the case. An automatic task will be scheduled doing just that. Make sure the "reevaluation event" is set to "On domain change", making sure the date sent from the implementation is always set to the timer, also when it changes.
This sub-process can be added to the phase where the deadline is relevant. In my example in the "Samenstellen" phase. Add this timer as an ad-hoc sub-proces.
As a precondition, make sure the deadline is relevant (for example the deadline is set), and the deadline has not already passed. This makes sure the deadline is always a KNOWN date set in the future.
Another advantage of using the ad-hoc sub process construction, is possible migrations. When timers are no longer needed in the model, just model the precondition to FALSE. After a process-evaluation (for example using a migration message event + automatic task), all timers will be cancelled, after which you can delete the timer sub process from the model.
| Note |
|---|
Note that a deadline is only relevant when set in the future. if the deadline is past, the last process-evaluation already made sure the resulting preconditions are true, so in this example, the priority will already have been set to high. The timer is only necessary for when it needs to change somewhere in the future. |
| Note |
|---|
A timer which has an UNKNOWN date, or date in the past, will always result to TRUE right away. So when the precondition is set to TRUE, is might result in a looping situation where the case is re-evaluated repeatedly. |
| Note |
|---|
A timer is Required in a sub-process. So when a timer node is set directly in the phase, it will keep waiting in this phase until the timer is passed. Even though the milestone might already have evaluated to TRUE. The precondition on the sub-process makes sure timers are cancelled when they are no longer relevant. |
Step 2 - Send an actual Message Event to the right case
...
Overview
Content Tools