Adeptia Connect has a recovery feature to automatically recover process flows, which are not executed completely due to Connect Server Kernel shutdown.

Connect Server Kernel shutdown can occur due to following reasons:

• System is shutdown
• Kernel is stopped

When Kernel restarts, all incomplete process flows that are recoverable are recovered.

This page contains the following information:

How recovery works

During execution of a process flow, at every checkpoint BPM Server stores the current state of the process flow in a recovery file. There is one recovery file for each execution of a process flow. These recovery files are stored in a recovery folder defined in the property abpm.recovery.repository.root. If kernel goes down during execution of process flow, recovery file will have the state of the process flow till the last checkpoint. If no checkpoint is reached, no recovery file is created and the process flow can never be recovered after failure. In the recovery file only state of the process flow is saved. Intermediate data of the process flows are stored in the repository folder. Once system is restarted and if recovery is enabled, BPM Server looks for the state of the uncompleted process flow in the recovery file, picks up the intermediate data from the repository file and resumes the process flow.

The recovery file, remains in the recovery folder unless the process flow execution is completed. The recovery of process flows cannot be completed if intermediate data are not available in repository folder. Intermediate data gets deleted automatically by Data Cleanup or user can delete it manually to free disk space. Click here for more details.

Even if recovery is not enabled, the recovery files created during execution of the process flows are stored in the recovery folder. In this case recovery of the uncompleted process flows are not done. Later on if you want to recover those process flows, you need to enable recovery and restart the kernel. After Kernel is restarted, the uncompleted process flows are recovered.

Enabling recovery

By default recovery is disabled. To enable the recovery, change the value of the property abpm.transaction.recovery.enable from no to yes.

Perform the following steps to enable this property:

1. Click Account > Settings.
2. Expand the Server Node Settings in the left panel.
3. Select the server node.
4. Click Edit.
5. Expand Process Flow > Recovery.
6. Set the value for the abpm.transaction.recovery.enable property to yes.
7. Click Save.
8. To reload the configuration, click Reload Configuration link.
   A confirmation message is displayed that the configuration has been reloaded.
9. Restart the Connect Server.

If Queue Processor is enabled, Queue Processor does the recovery. The property abpm.transaction.recovery.enable will not have any effect on recovery process. Queue processor tracks all the jobs (request for execution of process flows). If jobs are not completed in previous run, then queue processor will recover them automatically. Click here to know more about Queue Processor.

Shutting down Quartz scheduler

Quartz scheduler plays an important part in the recovery of services and in case of an emergency kernel shutdown. As the name suggests, scheduler keeps a track of all the events, services, and process flows that are running or will run in future. As a part of the recovery process, now when your kernel shuts down, the quartz scheduler will carry out the following tasks before it shuts itself down:

• Execute all the events that are currently running
• Save the state of the scheduler

Recoverable Process Flows

You can make a process flow as recoverable process flow using one of the following options:

• Enabling Implicit Recovery
• Using Checkpoints

Enabling Implicit Recovery

Implicit Recovery is a unique feature which means that the execution state of the process flow is recovered automatically in case the process flow is not executed completely due to some reasons. Now, when the kernel restarts, the process flow resumes execution from the point where it leaves.

• Only, Synchronous activities are implicitly recoverable in the process flow. If asynchronous activities are used in process flow, they are made recoverable explicitly using check points. To know how to add checkpoint, refer to the section Using Actions in Process Flow.
• Actions such as Delay, Put Context Var do not have Implicit Recovery Implementation.
  Implicit recovery is supported for any level of parent-child relationship in the process flow. For a recoverable parent process flow, all its child process flows are implicitly made recoverable irrespective of whether the child process flow is configured as recoverable or not. 

Using Checkpoints

Process flows, which have checkpoints, are recoverable. Checkpoint is an action which can be used in a process flow during it creation. There can be any number of checkpoints in a process flow. Checkpoints should not be used after an asynchronous activity which is generating a source stream. Otherwise after recovery the source stream generated by asynchronous activity will not available for the target activity which will be consuming this stream. To know how to add checkpoint, refer to the section Using Actions in Process Flow.