Version 22.0.8473

• Retry and Resend
  • Retry
  • Resend
• Error Routing
  • Routing to Notify Connectors
• Global Alerts

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 paths in the flow allow for custom processing of files that trigger errors within a connector, and global alerts can be configured to notify a system administrator when errors are thrown within the application.

Retry and Resend

Many connectors can be configured with Retry and Resend settings in the Automation tab for the connector. These settings govern how the connector will respond 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 (e.g. a firewall prevents a connection to the server), permissions issues (e.g. the server does not allow access to the destination resource), and application-level processing errors (e.g. 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 will wait for the Retry Interval to elapse, then try sending/uploading the file again. It will continue this process until Max Attempts is exhausted. Only once the Retries are exhausted will the connector throw an error.

The Max Attempts value includes the original attempt to send/upload, so setting this value to 1 will ensure that a failed send is not Retried. Setting this field to a non-positive value will instruct 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 will ‘swallow’ these errors unless they persist through the entire Retry process. This minimizes downtime for non-critical failures and prevents unnecessary error alerts from being distributed.

Resend

Connectors only support Resend functionality if they implement protocols with built-in acknowledgments (e.g. AS2, AS4). A Resend is triggered when a connector sends a message that should be acknowledged, but does not receive an acknowledgment within 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 (async) has been exhausted. If the Resend attempts have been 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 in the Transaction Log, and errors related to more general application resources are logged in the Application Log.

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, and can be viewed 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 will be 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 if a specific connector is unable to send/upload/process a file. Configure a Notify Connector with the target email for the system administrator, and then use the Error Path to connect the connector where the error occurs to the Notify Connector.

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

Notify Connectors use SMTP settings configured in the Advanced tab of the Profiles 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.

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