1.6.4 Retrying tasks

You can retry a task from a failed step, or from the step after the failed step. The retried task will have the same task ID and inherit the property values of the failed task. The values of Service Share Properties are affected in the following ways:

Service Share Properties are assigned the property values that applied when the service was first executed
Shared built-in service properties are assigned the property values set as part of the retry operation

The schedule type of a retried task is immediate execution.

Important

You cannot retry a task if there is no failed step in the task or the task has been restored using the

restoresystem

command.

Information updated when a task is retried

The following information is not updated when a task is retried:: Task ID, task name, task description, input properties, schedule type, and start time

The following information is updated when a task is retried:

End time

The end time is updated when the retried task has ended.

Statuses in which tasks can be retried

Whether a task can be retried depends on the status of the task or step when it ended. The examples below explain circumstances in which tasks can and cannot be retried based on the task or step status.

When a task fails in a step that does not contain a Repeated Execution Plug-in: If you select Retry the Task From the Step After the Failed Step when retrying the task, the failed step enters Completed status and JP1/AO executes the task from the step after the failed step.

When a task fails in a step that contains a Repeated Execution Plug-in

If you select Retry the Task From the Failed Step when retrying the task, JP1/AO executes the task from the beginning of the Repeated Execution Plug-in.

If you select Retry the Task From the Step After the Failed Step, JP1/AO executes the task from the step after the failed step that contains the Repeated Execution Plug-in. At this point, the failed step that contains the Repeated Execution Plug-in enters Completed status, but the status of subordinate steps remain the same.

Depending on the subsequent-step execution condition assigned to the step that contains the Repeated Execution Plug-in, the step that contains the Repeated Execution Plug-in might enter Completed status even if a subordinate step has failed. In this case, you cannot retry the task from the step containing the Repeated Execution Plug-in.

When a step ends with a warning and the task fails: You cannot retry the task because there are no failed steps.

When a task fails at the last step: If you select Retry the Task From the Step After the Failed Step when retrying the task, the failed final step enters Completed status. Because this causes the task to end normally, you will be unable to retry the task.

When the setting that specifies whether to permit retry is changed before or after task execution: If you change the service setting that specifies whether to permit retry before or after executing the task, the setting that is in effect at task execution will be inherited. For example, if an attempt to execute a task for which retry is permitted does not succeed, the task can be retried even if, after the task is executed, the service setting is changed so that retry is no longer permitted.

Session behavior when retrying tasks

If processing fails in a subsequent step of a terminal connect plug-in, the session with the remote terminal is disconnected as soon as the task ends. This will cause processing of the terminal command plug-in to fail if you retry the task. In this scenario, re-execute the task instead of retrying it.

However, if the repeated execution flow contains both a terminal connect plug-in and a terminal command plug-in, retrying the Repeated Execution Plug-in causes the repeated execution flow to start from the beginning, and the session is re-established. In this scenario, the terminal command plug-in will be executed with an active session in place.

To Page Top