Page History
| Excerpt | ||
|---|---|---|
| ||
How to handle a timeline in DCM, concerning dates that are important, and the Case-Engine should come into action |
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 at a certain point gets to react.
...
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. )
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.
...
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.
...
| 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 -
...
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).
Step 3 - Receive the Message Event in the Case Process
Future state
We are aware of the number of steps needed to process a message event. In the future we are aiming to make this much easier for the Business Engineer.
Overview
Content Tools