Error Handling

Version 23.4.8839


Error Handling


Connectors in CData Arc can be configured to flexibly respond to errors that occur during file processing. Retry and Resend settings allow connectors to endure temporary connection issues without interrupting the automated data flow. Error Routing in the flow allows for custom processing of files that trigger errors in a connector, and you can configure Global Alerts to notify a system administrator when errors are thrown in the application.

Video Resources

Watch this short video for an introduction to how Arc simplifies error handling.

Retry and Resend

Many connectors can be configured with retry and resend settings on the Automation tab for the connector. These settings govern how the connector responds to a failure to send or upload a file to a remote destination.

Retry

A Retry is triggered when an Arc connector attempts to send or upload a file to a remote server, and the server does not indicate that it successfully received the file. This includes a wide range of potential issues, like basic connectivity problems (for example, a firewall that prevents a connection to the server), permissions issues (for example, the server does not allow access to the destination resource), and application-level processing errors (for example, an AS2 partner’s system cannot match the incoming request to a configured AS2 profile).

Connectors that support retry logic have Retry Interval and Max Attempts configuration fields. When a retry is triggered, the connector waits for the Retry Interval to elapse, then tries sending or uploading the file again. It continues this process until Max Attempts is exhausted. Only once the retries are exhausted does the connector throw an error.

The Max Attempts value includes the original attempt to send or upload, so setting this value to 1 ensures that a failed send is not retried. Setting this field to a non-positive value instructs the connector to retry indefinitely instead of throwing an error.

Utilizing retry logic helps Arc tolerate temporary network conditions that interfere with data transmission. If a partner’s server temporarily goes down, or if network conditions are temporarily unstable, the application ‘swallows’ these errors unless they persist through the entire retry process. This minimizes downtime for non-critical failures and prevents unnecessary error alerts.

Resend

Connectors only support Resend functionality if they implement protocols with built-in acknowledgments (for example AS2 and AS4). A resend is triggered when a connector sends a message that should be acknowledged, but does not receive an acknowledgment in the configured Resend Interval.

Instead of throwing an error, the connector attempts to send the message again. This process repeats until the connector receives the expected acknowledgement or until the Max Attempts has been exhausted. When the resend attempts are exhausted, the connector throws an error.

Error Routing

When a connector encounters a problem sending, uploading, or processing a file, and any available retries and resends have been exhausted, the connector throws an error. Errors specific to a file transaction are logged on the Transactions tab, and errors related to more general application resources are logged on the Application tab.

The file that caused the error is routed through the flow according to the Error Path. Error paths are represented by a red dotted line that is separate from the blue flow path. Error paths are hidden by default, but you can see them by right-clicking a connector and selecting Show Error Path:

Once the error path is visible, drag the red dot to the left side of another connector (just like the blue flow path) to configure the error path. Files that cause an error are routed to the connector that is connected via the error path. Files that do not cause an error are unaffected by the error path.

Routing to Notify Connectors

Notify connectors are commonly used with error paths. This setup is useful if a system administrator needs to be notified when a connector is unable to send, upload, or process a file. Configure a Notify connector with the target email for the system administrator, then use the error path to connect the connector where the error occurs to the Notify connector.

Once configured, emails containing information about the file that raised an error are automatically sent to the specified recipient.

Note: Notify connectors use SMTP settings configured on the Alerts tab of the Settings page to send emails.

Global Alerts

In addition to routing specific error-causing files with error paths, Arc also supports a global error alert system.

The Alerts tab of the Settings page contains settings for enabling global alerts. Enabling global alerts is functionally equivalent to connecting each connector in the flow to a shared Notify connector via the error path described above.

Once enabled, any errors thrown by the connectors in the flow automatically generate an outgoing email (and/or a Windows Event) with information pertaining to the error.