Troubleshooting Ultra Pipeline Tasks

On this Page


The common issues you might encounter with Ultra Pipelines Tasks include:

  • Ultra Tasks become disabled. Ultra Task configuration includes a setting for the maximum number of times a Pipeline can fail to start before the Snaplex disables the Ultra Task. During development or troubleshooting, you might want to disable this feature or increase the number. 

  • A Pipeline will not start. A pipeline processes a document multiple times. If the FeedMaster does not receive an acknowledgment that a document was processed, it can be retried. By default, the document may be retried up to five times. You can change this in Snaplex configuration as described below in Configuring Snaplex Retries.

  • Unhandled errors. To troubleshoot errors and failures in an Ultra Pipeline it is a good practice to implement error and exception handling as described below. When the Pipeline handles errors and exceptions, the Snaplex will not automatically disable the Ultra Task.

Configuring Snaplex Retries

You can change the maximum number of allowed retries for document processing failures in Snaplex Node Properties. To do so, open the Snaplex Create or Snaplex Update dialog and follow these steps:

  1. Select the Node Properties tab.

  2. In the Global Properties field, add the Key ultra.max_redelivery_count.

  3. For Value, indicate the number of times the Snaplex should try reprocessing documents. 

Error and Exception Handling

Use error handling to avoid failures, disabling of the Ultra Pipeline or a service disruption. You can add Error handling to Ultra Pipelines by following these guidelines:

Error Views

Add an error view to all crucial endpoint application Snaps in the pipeline to return a response with custom error messages (code and HTTP status code). Doing so notifies you of errors in the document processing of Ultra Pipelines. For example, the Mapper Snap used in the pipeline below allows customizing information for error content when the REST Post Snap fails.

Error Code Standard

You can adopt standard HTTP response codes and messages to indicate the success or failure of a request, returning specific error responses at different stages of the pipeline. For example, invalid headers result in HTTP response status code 401, and an invalid version results in 406.

“response codes”: [{
“400”: {
“error code”: “4000”,
“error message”: “Malformed request body or missing a required parameter”
}, {
“401”: {
“error code”: “4010”,
“error message”: “No valid session key or credentials provided”


Maximum Tries

By default, if the first run of an Ultra Pipeline fails, SnapLogic attempts to run it for a total of five times. However, you can configure the number of times you want Ultra Tasks from a specific Snaplex to run by configuring the maximum number of allowed retries for an Ultra task. To do so, modify the following parameter in Global Properties in Snaplex Update: ultra.max_redelivery_count to indicate the number of times you want a failed Ultra Task to run. 

Error Handling in Asynchronous Ultra Tasks

Ultra Pipelines require a Document type output in the Error Pipeline. The following pipeline provides an example of an error pipeline set up for error handling in asynchronous Ultra Tasks.

Ultra Pipelines require a Document type output in the Error Pipeline.

The following Ultra Pipeline provides an example of this design:


The following describes the setup for each Mapper Snap.
In the first branch, the first Mapper (Map - Build Pipeline…) specifies the runtime records to pull the errors from.

The subsequent Mapper Snap (Map Error Records) lists which errors to pass.

Then, the error messages are copied and sent to a specified email address and log in one branch, while in the original branch, a Mapper Snap (Map REST - Reply) defines the REST response.

We add a JSON Formatter (Status Output) after the Mapper with the HTTP status code format.

The final Mapper outputs the response as a document.


You can download this sample pipeline to reuse for your Ultra Pipeline:

  File Modified

File zErr_Pipeline_Notification_REST_2024_01_04.slp

Jan 05, 2024 by John Brinckwirth