When a step of a job fails, the job is considered failed as well. To perform some clean-up actions before the job finally exits (such as logging or sending email notifications), you can create steps of type "error/success handling". The error/success handling steps allow you to protect the execution of one or more steps, referred to as a "protected block". The following diagram illustrates the structure of a protected block.
Structure of a protected block
When any of the steps within the protected block fail, error handlers control what happens before the job finally exits. Error handlers can be one of the following:
•On Success (runs if all steps in the protected block were successful)
•On Error (runs if any of the steps in the protected block were not successful)
•On Retry (this handler runs only if the protected block has the retry count option set to a value greater than 0; it runs if any of the steps in the protected block has failed and a retry is going to follow). For details, see the "Retry on error" section below.
•Always (runs regardless of whether the steps in the protected block were successful)
When the protected block finishes executing, FlowForce Server executes any defined handlers based on the outcome. For example, on the diagram shown above, the protected steps are Step A and Step B, and the error handling logic is as follows:
•If A fails, then A, C and E will be executed.
•If B fails, then A, B, C and E will be executed.
•If A and B are successful, then A, B, D and E will be executed.
In practice, it is not necessary (although it is possible) to define all three handler types for every job that you want to handle. The most common scenario is to define only On Error and Always handlers. For example, the image below illustrates a simple protected block with On Error and Always.
The first step runs a script from the C:\scripts directory by invoking the \system\shell\commandline function. The execution of this step is protected by two handlers: On Error and Always. The On Error handler will be triggered only if the execution of the first step fails. More specifically, if the first step fails, the error handling step sends an email that contains the ID of the failed job instance in the subject line. The Always handler is executed unconditionally, regardless of whether the first step was successful or not. This handler logs a message by running a script from the C:\scripts directory. For a more detailed worked example similar to the one illustrated above, see Adding Error Handling to a Job.
