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.
Deadlines make sure certain tasks can appear after some deadline is past, of 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. )
How to model a Deadline in the Case-Engine
Step 1 - Create a REST interface to retrieve messages
Step 2 - Send an actual Message Event to the right case
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