RestartEvent Activity

The RestartEvent activity allows restart of any workflow if the workflow was previously suspended. Attempts to restart a workflow which was not suspended is illegal though not prohibited.

Additionally, if workflow is suspended in HandleProtocolMessaging activity, restart is not allowed as the restart would lead to incorrect synchronization.

The activity accepts an EventID as input to provide flexibility of determining which event to restart. Best practice for a child workflow to execute is to use GetAssocEventsSummary activity to find the parent event of the event to restart. You can also determine the event ID using customizations or by explicitly passing the event ID as input to the workflow.

The restart activity can initiate the event restart only if

  1. The event is a valid event ID.
  2. The event is not complete, that is event status is not ERROR, CANCELLED or SUCCESS.
  3. The status of the process associated with the event is not CANCELLED, COMPLETED or SUCCESS.
  4. The process is not already executing.
  5. The process is not executing and lock can be obtained. Normally, if a process is not executing, it can be locked. However certain application failures (complete cluster failure) may leave the process locked. In this case, a manual intervention is needed to correct the process state and then restart it from UI. In case of such an abnormal failure, the locked processes can be checked by looking up table PROCESS (STATUS=WAIT_TASK).

The activity handles exceptions as follows:

  • If the event (or more precisely, the associated process) is still running, process can be not locked and restarted. Process must be locked before it can be restarted. The restart will be attempted again for a specified retry count, if retry count is more than 1. Activity will sleep for specified interval between restart attempts. Default retry count is 3 and sleep interval is 10000 milliseconds.
  • If there is an exception during restart, activity will throw an exception. If there is any error transition specified in the workflow, error transition will be invoked.
  • If a) and c) is the case, the output InitiatedEventID is null. Otherwise InitiatedEventIDis set as the event which was restarted.

The RestartEvent activity works in tandem with the Suspend activity. See the supplied samples wfin26catsourcev5_suspend_sample.xml and wfin26producteditapprovalv3_restart_sample.xml under $MQ_HOME/ common/standard/samples/workflow. Following is an example of the use case which includes this activity.

  • Import is initiated with "Split/ Approval Required".
  • Import batch is saved and depending on the action to be taken record add, edit or delete workflows are initiated using SpawnWorkflow activity. Immediately after import the workflows are initiated, import workflow suspends using Suspend activity.
  • Each of the workflow goes through processing and reaches an end state. When end state is reached, event status is updated to SUCCESS or ERROR, and a subflow is initiated to check for restart.
  • The subflow first obtains the summary of all events spawned. Based on the summary, restart can be initiated.
    RestartEvent Activity Process