Stop job step

Stop job step

The Stop Job step terminates a job to halt further processing. It is commonly used when an error occurs in the business logic, making it unnecessary to continue execution.

You can configure the Stop Job step to mark the job as either Failed or Successful, based on your business requirements.

Example: Stop Job Step

This recipe searches for attachments in ServiceNow, uploads the file to Google Drive, and then stops the execution.

Figure: Stop job

The Stop Job with Error step can be added when a job encounters a failure. If the file is not found, the job will be marked as failed.

Figure: Stop job with error

Handling Errors with Control Statements

The Handle Errors control statement allows you to monitor actions for errors, similar to the try/catch mechanism in programming. When an error occurs, you can:

• Retry the actions – Useful for temporary issues such as network failures.

• Implement corrective measures – For example, sending email notifications, logging error details, or rolling back operations by deleting partially created records.

This control statement consists of two key blocks:

• Monitor Block – Contains the actions to be monitored. If all actions execute successfully, the Error Block is skipped.

• Error Block – Executes only if an action in the Monitor Block fails. This block can be configured to:

  • Retry the monitored actions a specified number of times with defined intervals.

  • Execute alternative actions if all retries fail.

Example: Monitoring Errors Block

In this example, the recipe attempts to update a Jira issue's status based on an incident. If an error occurs during the update, a comment is added to the Jira issue to log the failure.

Figure: Test Recipe

In this Recipe, the Monitor block checks for errors while updating a Jira issue. If the Jira key is missing, an incident is created, and the system attempts to update the corresponding Jira issue. Error handling ensures that any failures during the update are logged by adding a comment in Jira.

Example: Monitor Errors Block

This recipe attempts to update the status of a Jira issue based on an incident created in Apex. If an error occurs, a comment is added to Jira to log the failure.

In this recipe, the Monitor block detects errors during the Jira issue update. If a Jira key is missing, an incident is created, and the system tries to update the associated Jira issue. Error handling ensures that any failures in updating the Jira issue are captured by adding a comment in Jira.

Auto-Retry

When utilizing the Error block, you can configure Integration Hub to automatically retry failed actions within the Monitor block. By default, failed actions are not retried. To enable automatic retries, you must manually configure the auto-retry setting.

Figure: Monitor block

Integration Hub enables you to configure up to three retry attempts and specify a time interval between retries, ranging from one to ten seconds. Additionally, you can define a condition that must be satisfied before Integration Hub retries the actions within the Monitor block.

Figure: Monitor block with retry action

Auto-Retry Mechanism

If the actions within the Monitor block are prone to temporary failures—such as network disruptions or timeout issues—enabling auto-retry allows the recipe to attempt the steps again. Integration Hub will continue retrying until the actions succeed or the maximum limit of three attempts is reached.

On-Error Datapills

When a Handle Errors block is added to a recipe, Integration Hub generates error-specific datapills. These datapills enable customized error handling based on details such as error type, message, and source, including the recipe step, action, or application.

The following datapills can be used to define error-handling steps:

#