Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 reactthat it can.

Deadlines make sure certain tasks can appear after some deadline is past, of 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

...

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 during the last case evaluation. The timer is only necessary for when it needs to change somewhere in the future.

...

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.

...