Introduction
A change on the case can be initiated in different ways, for example by a user performing a task, or a message event that is being sent to the case. After such a change, the new state will be stored in the database, and nothing happens until the next change. When you actually want the case to change at a certain moment, there is a mechanism to make sure that it can.
Deadlines make sure certain tasks can appear after some deadline is past, or tasks are no longer available. Also, some automatic task can become relevant after a deadline has past. A set of important deadlines during a case can be bundled in a timeline. In the current way, this can be modelled by the Business Engineer when needed.
The concept of scheduling something at a certain point in time is a timer, which can be set in the process module of a case. A timer on its own will not do anything other than trigger a following process flow. It is customary to keep the actual deadlines declarative, since it would also be triggered when someone performs another action on the case, and the deadline happens to be past already. This way the actual timer would only be needed to trigger a full process evaluation at a certain time, where the re-evaluated case could lead to the resulting action (for example, a task precondition is evaluated to FALSE, an automatic task becomes relevant, etc. ). Keeping the deadlines declarative makes it easy to shift any values when the dates change which they were based on, and can also be disabled/enabled in your case according to your logic.
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 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 during the last case evaluation. The timer is only necessary for when it needs to change somewhere in the future.
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.
A timer is Required in a 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 - Determine the value of the deadline in the implementation
Make sure that the implementation model determines the right value of the deadline. In most cases the deadline is based on data from the dossier (in my example the date of departure of the trip, together with the fact whether the trip has been approved or not). If the trip is not approved, and the date of departure is soon, the priority must be higher.
The priority determination is also dependent on the same value, so it will react when the deadline is passed.
Make sure this deadline is mapped to the process. And the deadline will be set when appropriate.
Step 3 - Checking the timers in the DCM-Maintenance-APP
All scheduled timers are set in the Case-Engine, and can be viewed in the DCM-Maintenance-APP. A timer is set as a "task element" in the tasks table, and can also be seen from the "scheduled events" tab in the Case Overview. In this example the deadline "samenstellen":
Future state
In a future state (DCM-Zone) we want to skip the timers. You are able to model a timeline (a set of deadlines that may be relevant to each other), and set each deadline individually as a scheduled event. This way you only have to model deadlines and the effect of the deadlines in the Case Implementation, and the Case-Engine will make sure the events are set at the relevant time. Each deadline either means the Case is re-evaluated, or a specific flow is triggered (leading to a Case re-evaluation afterwards).
Overview
Content Tools