Troubleshoot Ultra Tasks

The common issues you might encounter with Ultra 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 does 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 a pipeline invoked by an Ultra Task, 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.

Configure 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:

Select the Node Properties tab.
In the Global Properties field, add the Key ultra.max_redelivery_count.
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 Task or a service disruption. You can add Error handling to pipelines invoked by Ultra Tasks 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. 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”
}
}]
}]

Note: Maximum Tries: By default, if the first run of a pipeline invoked by an Ultra Task 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 Tasks 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:

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. Async Mapper Snap

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

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

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

The final Mapper gives the response output as a document.

You can Download the pipeline to reuse for your Ultra Pipeline.