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.
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.