9. Fail-safe

Introduction

This chapter describes the default behavior of the process engine on how to prevent loss of data. It also describes the functionality a functional administrator has to restore a case that is broken. This chapter doesn't describe how to model a process, but should give a better understanding on how the process engine will behave in certain scenario's.

The requirement for a fail-safe solution is that data should never get lost, so that decision making and processing business functions are always done on correct data.
Data can get lost during a transaction. A transaction can fail because of an error in a model, because the database is off line, because a case is locked, because a service cannot be delivered. There are a lot of reasons something can go wrong which will interrupt a transaction.

To guarantee the quality of data the application needs to meet the following requirements:

• Incidents may never crash the application
• Incidents must be registered
• Incidents are traceable
• Incidents must be recovered to be able to continue case handling

Task Behavior

To get a better understanding of the scenarios described on this page it is necessary to understand task behavior in the runtime.

What could happen?

To get a better understanding on the behavior of the process engine it is best to set out a few scenarios based on a simple model. Even within this simple model a lot can happen to disrupt a case.

Here is an example of a simple process model:

Main process
The main process consists of 2 phases (sub-processes).

The process model for Phase 1	The process model for Phase 2
Phase 1 consists of 2 tasks. Task 1 is started manually. Task 1 will create a case lock. Task 2 is triggered by a timer. Task 5 is triggered by a message event. Task 6 is started manually. Task 1 needs to be finished before task 6 is applicable. Task 6 also creates a case lock.	Phase 2 consists of 1 task. Task 3 is started manually and creates a case lock. Task 3 can only be started after Phase 1 has finished. Task 4 is an automated task and is triggered by a message event.

List of scenarios:

Default Scenario, no disruption

• The case has been initiated.
• Task 1 has the status 'open'. All the other tasks are not available.
• Task 1 is being executed.
• Task 1 gets the status 'started'.
• The case is locked.
• The wait node starts evaluating it's expression when Phase 1 was activated, so at the moment phase 1 is activated.
• Task 1 is finished.
• Task 1 gets the status 'completed'.
• The case lock is lifted.
• Task 6 gets the status 'open'.
• Task 6 is being executed and gets the status 'started'.
• Task 6 is finished.
• Task 6 gets the status 'completed'.
• The case continues to Phase 2.
• The timer in Phase 1 is canceled, because phase 1 has ended.
• Task 3 gets the status 'open'.
• Task 3 is being executed.
• Task 3 gets the status 'started'.
• The case is locked.
• Task 3 is finished.
• Task 3 gets the status 'completed'
• The case lock is lifted.
• The condition node is valuated 'True'.
• Phase 2 is finished.
• The main process ends.

Timer expires during a case lock and phase 1 ends

• The case has been initiated.
• Task 1 has the status 'open'. All the other tasks are not available.
• Task 1 is being executed and finished.
• Task 6 gets the status 'open'
• Task 6 is being executed and gets the status 'started'.
• The case is locked.
• The wait node starts evaluating it's expression when Phase 1 was activated, so at the moment phase 1 is activated.
• The timer expires and wants to triggers Task 2.

• The case is still locked.

• Instead of failing to trigger Task 2, the trigger is being delayed.  (new behavior since 9.6)

• Task 6 is being finished.

• Task 6 gets the status 'completed'.
• The case lock is removed.
• The process now has the following sequence:
  1. Ending phase 1, because this is the event that happens when finishing Task 6.
  2. Executing the delayed trigger and setting Task 2 to status 'open'.
• The process will handle the sequence descending and starting with 1.
• Phase 1 will be ended.
• The delayed trigger of Task 2 is canceled because the process has ended Phase 1. (If Task 2 would have gotten status 'open' and it was required then Phase 2 would not be able to handle Task 3. This is also new behavior since 9.6).

Error in an automated task and finishing a case

• The case has been initiated.
• Task 1 has the status 'open'. All the other tasks are not available.
• Task 1 is being executed. The wait node starts evaluating.
• Task 1 is finished and get the status 'completed'.
• Task 6 is processed.
• Phase 1 is ended. The wait node is canceled.
• Phase 2 is started.
• Task 3 gets the status 'open'.
• A specific message for this case instance has been sent to this process. (new behavior since 9.6)
• The message is stored with this case. (new behavior since 9.6)
• The message event triggers Task 4.
• Task 4 is being executed.
• Task 4 gets status 'started'.
• The execution of task 4 fails because of an error in the model.
• The case cannot continue, the error needs to be fixed first.
• After the error in the models have been fixed and published the status of Task 4 is still 'started'.
• With an API it is possible to restore the status of a task back to 'open'. (new functionality since 9.6)
• Task 4 has the status 'open' again.
• Task 4 is finished and gets the status 'completed'.
• The condition node is evaluated 'True'.
• Phase 2 ends.
• The main process ends.
• The specific messages stored for this case instance is deleted. (new functionality since 9.6)
• All process related entries are deleted.

Message to case during a case lock

• The case has been initiated.
• Task 1 has the status 'open'. All the other tasks are not available.
• Task 1 is being executed. The wait node starts evaluating.
• Task 1 is finished and get the status 'completed'.
• Task 6 is processed.
• Phase 1 is ended. The wait node is canceled.
• Task 3 gets the status 'open'.
• Task 3 is being executed.
• Task 3 gets the status 'started'.
• The case is locked.
• A specific message has been sent to this process.
• The message is stored. (new behavior since 9.6)

• Instead of failing to trigger Task 4, handling the message is being delayed. (new behavior since 9.6)

• Task 3 is being finished.

• Task 3 gets the status 'completed'.
• The case lock is removed.
• The process now has the following sequence:
  1. Valuating the condition node.
  2. Executing the delayed message and setting the automated Task 4 to status 'open'.
• The process will handle the sequence descending and starting with 1.
• The condition node is valuated 'False'.
• The delayed message is being handled and triggers Task 4. (This is new behavior since 9.6).
• Task 4 gets the status 'open'
• Because task 4 is an automated task, it is being executed and gets the status 'started'
• Task 4 is being finished.
• Task 4 get the status 'completed'.
• The condition node is evaluated 'True'
• Phase 2 ends.
• The main process ends.

A combination of event handling during a case lock

• The case has been initiated.
• Task 1 has the status 'open'. All the other tasks are not available.
• Task 1 is being executed.
• Task 1 has gets the status 'started'.
• The case is locked.
• The wait node starts evaluating it's expression when Phase 1 was activated, so at the moment phase 1 is activated.
• A message is caught by this case instance and wants to trigger Task 5.
• The message is stored. (This is new behavior since 9.6)
• Because the case is locked, the message event is delayed. (This is new behavior since 9.6)
• The timer expires and wants to triggers Task 2.
• Because the case is locked, the timer event is delayed. (This is new behavior since 9.6)
• Task 1 is finished.
• Task 1 gets the status 'completed'.
• The case lock is lifted.
• The process now has the following sequence:
  1. Process the exit event of task 1, and set Task 6 to status 'open'.
  2. Executing the delayed message event and setting the ad hoc Task 5 to status 'open'.
  3. Executing the delayed timer event and setting the ad hoc Task 2 to status 'open'.
• The process will handle the sequence descending and starting with 1.
• Task 6 gets the status 'open'.
• Task 5 gets the status 'open'.
• Task 2 gets the status 'open'.
• At this moment there are 3 tasks available in the work list.
• If a task is required, then the tasks have to be executed before phase 1 can be ended.

List of behavior that is new since release 9.6 

• All messages are stored in a new table in the process database: EVENTS
• During a case lock, events are delayed. Events consist of timer nodes and messages. These delayed events are temporarily stored in a reference table: DELAYEDEVENTS. After processing a delayed event, the entry in the DELAYEDEVENTS table is deleted.
• Ending a case will delete all messages stored specific for the deleted case instance.
• A rest API has been added to retrieve information about the process:
  • Get a list of cases.
  • Get a list of tasks.
  • Get information for a single case.
• A rest API has been added to influence the process:
  • Restore a task status back to 'open', so that the task can be performed again.
  • Publish a timer event manually, so that the triggered task can be executed again.
  • Re-sent a stored message, so that the process can be continued with the correct data.

Rest API

For more detailed information about the methods of the rest API go this page.