Process Definitions: Process Status Tab

The Process Status tab lets you control restart behavior for Process Definitions and Chain Definitions that use Submit Frames. Restart behavior controls what happens when a process submitted as the result of a Submit Frame reaches the status Canceled, Completed, Error, Killed, and/or Unknown.

By default, if a process that is using a Submit Frame reaches one of these statuses, the Submit Frame will simply ignore that particular process instance and resubmit the process at the next time in the Submit Frame. By configuring this tab, you can change this behavior and potentially restart that process instance.

Note: When an instance of a process is restarted, a new instance of the process is created and all values are set according to the original instance.

Tip: To restart a specific recurrence using its original submit time, navigate to Monitor > Processes, then right-click any recurrence of the process in the choose Scheduling > Restart. In the pop-up window that displays, click Perform Restart on the recurrence.

The Process Status tab of the Process Definition editing pop-up window includes the following controls.

Field Description Default Value
Returncode Map To Completed

Lets you specify a comma-separated list of specific return codes that should be automatically mapped to Completed. By default, only 0 is mapped to Completed.

Note: If you specify a value here, and you want 0 to be mapped to Completed (as it would be by default), you must include 0 in the list.

Maximum Starts

The maximum number of restarts allowed for the process. The value is decremented after each restart. This means that a Maximum Restarts of 3 will restart the process 3 times and the total number of runs will be 4. It is only decremented when the system does a fully automatic restart. When an operator intervenes using an action on a Process Definition or an Operator Message, for example, then the value is reset to the value of the Process Definition.

On a Step, the initial run counts towards the value specified in Maximum Starts. However, on a Process Definitions, the initial run does not count towards the value specified in Maximum Starts.

100
Action
  • Continue Submit Frame: The restart will occur following the Submit Frame.

  • Default Behavior: The return code for this instance of the process is ignored. The instance is not restarted. The next instance of the process is submitted at the specified time.

  • Request Restart: When this option is selected, you can specify an Operator Message to send. Human intervention will be required to restart the process instance.

  • Restart: Restarts the process instance immediately.

  • Restart From Error: Restarts a Chain Process from the Step that reached status Error. This option is identical to Restart for non-Chain processes.

  • Restart No Resubmit: The process will be restarted, but the restarted process will not be resubmitted.

  • Stop Submit Frame: The Submit Frame is stopped.

Restart Delay The delay between the end of the process and the restart. 15s

The following table provides more detail about the Action field options.

Action Process Restarted? Submit Frame Obeyed?
Continue Submit Frame (Default behavior) No Yes
Stop Submit Frame No No
Request Restart Only if an Operator responds to the Operator Message Yes
Restart Yes Yes
Restart from Error Yes, from the Step that reached Error status. Yes
Restart No Resubmit Yes No

Note: Using the Completed status in combination with Restart from Error will restart from Error only if there was a process in status Error, and Continue if there was no process in status Error.

Note: When you configure a restart behavior on a Process Definition and call it from within a Chain, the restart behavior of the Process Definition will take effect inside the Chain.

Manual and Automatic Restarts

There are some differences between a manual restart and an automatic restart.

  • A manual restart uses the user who restarted the process. The restart is not counted towards the Maximum Starts value, and the restart is not affected by any values specified for Maximum Starts or Restart delay The Restart Count is reset when either the object on which it is set is restarted, or a parent object is restarted. Thus the Restart Count on a Step, for example, is not reset when you restart a call in the Step. When you restart the Step or any parent (such as the parent Chain), the counter on the newly created object (Step or Chain) is reset.
  • An automatic restart does not set the user, does update the restart count and is limited by the Maximum Starts value. Any Restart Counts on child objects will be reset in the newly created object.

Restart Behavior in Chain Definitions

A Chain Definition is a type of Process Definition, so the restart behavior described above also applies to Chain Definitions. In a restart, a new instance of the Chain process are created and the parameters of the top-level process are set according to those of the original. This is not a recursive operation. Call parameters mapped to the Chain will have the same values, but parameters that contain REL expressions will be reevaluated. Parameters on the Chain itself that contain REL expressions will not be reevaluated.

Restart Behavior of a Process Definition used in a Call

When you configure a restart behavior on a Process Definition and call it from within a Chain, the restart behavior of the Process Definition will take effect inside the Chain. The Step will wait until there are no more restarts.

Example

Assume that a process with restart behavior On Error Request Restart was submitted with a Submit Frame and a presubmit count of 3, and the first process has reached Completed.

The following figure illustrates the number of processes in this recurrence.

The following figure illustrates the process reaching Error. Note that in the figure, an Operator Message is waiting for a reply. As soon as the process reaches a final state, a new one is submitted.

The following figure illustrates the process being restarted.

The following figure illustrates the restarted process reaching Completed.

The following figure illustrates the restarted process reaching Error. Again, an Operator Message has been generated and is waiting for a reply.

See Also