Retry levels and retry pattern overview

A primary function of the store and forward service (SFS) is to attempt to redeliver a message when delivery of a message fails.

Retries are performed in the following situations:
  • The destination is not available (for example, if your trading partner's server is down)
  • The destination is unreachable (for example, if the URL or port is invalid)
  • An SSL failure occurred
  • A certificate issue occurred (for example, if the certificate is invalid)
Restriction: If the data is transmitted and the data transfer is broken, retry is not performed.
Therefore, delivery of a message might fail under two scenarios:
  • The target service (AS4, or web services) terminates unexpectedly or is restarted.
  • The final destination is not available.
If the target service is not available, SFS tries to invoke the target service based on the configuration (SFS_target_service_lookup_number_of_retries and SFS_target_service_lookup_retry_interval) in the SystemConfigurationSYSLoader.properties file.

If the destination is not available, SFS attempts to redeliver the message based on transport and destination retry configuration. If message delivery fails even after the allowed number of retransmission attempts for the store and forward service (SFS) is exhausted, the message is purged from the SFS repository, and a notification is sent to the business application.

Retry configuration

SFS attempts to redeliver the message according to the retry configuration. In AS4 Microservice, a retry involves the following two levels:
  • Transport retry
  • Destination retry

Transport retry

Transport retries are made to resolve transient failures in the network over which delivery is attempted. It is a low-level retry and is included in all destination level retries. The following parameters must be specified in the retry policy for a transport retry:
  • Number of Server Retries - Number of server or transport retries
  • Server Retry Interval - Time interval for server retry

Destination retry

Destination retries are specific to a particular destination. A destination retry must be configured in the retry policy and associated to a destination. A destination retry is a high-level retry and includes a transport retry. The destination retry interval is longer in duration than the transport retry interval. The intention is to allow sufficient time to correct the transient problem that is causing delivery failure. The following parameters must be specified in the retry policy for a destination retry:
  • Number of destination retries - Number of destination retries
  • Destination retry interval - Time interval for destination retry

Message delivery retry pattern

Each destination retry involves the configured number of transport retries. For example, if two destination retries are configured at an interval of 30 minutes, and two transport intervals are configured at an interval of 5 minutes, the retry pattern is as follows:
Table 1. Message delivery retry pattern
Delivery attempt Time Retry level Status
First delivery attempt 1:00 PM N/A Failed
First delivery retry 1:30 PM Destination Failed
Second delivery retry 1:35 PM Transport Failed
Third delivery retry 1:40 PM Transport Failed
Fourth delivery retry 2:10 PM Destination Failed
Fifth delivery retry 2:15 PM Transport Failed
Sixth delivery retry 2:20 PM Transport Failed
The delivery of the message is failed and appropriately logged.
Note: If a destination retry is set to 0, no retry happens, even if the transport retry is set to the minimum value, 1.

Retry scenario

A retry scenario where organization A is trying to send a message to a trading partner over AS4 is explained in this section.

Retry configuration for the retry policy that is associated with the specified destination is as follows:
  • Number of Server Retries - 2
  • Server Retry Interval - 5 seconds
  • Number of destination retries - 2
  • Destination retry interval - 30 seconds
  • Auto-Queue Settings - auto-queue is enabled
    Note: If auto queue is enabled in the retry policy and if a message cannot be delivered to a destination after all the retries are exhausted, the HTTPS or MDN destination is disabled. The reason is to stop the store and forward service from sending messages to the destination that is down. In this case, you must enable the destination by selecting the Enable destination check box in the HTTPS or MDN destination configuration user interface.

Target service: AS4

  1. The target service (AS4) receives the message, processes the metadata, and uses the AS4 outbound exchange profile to deliver the message. The target service sends a request to the destination configured in the destination profile of the outbound exchange profile, but gets a connection refused response.
  2. The target service throws a RetryException and invokes the retry service.
  3. The retry service invokes the scheduler to schedule a retry.
  4. Destination level retry, attempt 1:
    1. The scheduler waits for the specified time interval (30 seconds), and fires a trigger to invoke the retry handler.
    2. The retry handler sends the message that is stored in the store service to the target service.
    3. The target service sends a request to the destination, but gets a connection refused response.
  5. Transport level retry, attempt 1:
    1. The scheduler waits for the specified transport retry interval time (5 seconds), and fires a trigger to invoke the retry handler.
    2. The retry handler sends the message that is stored in the store service to the target service.
    3. The target service sends a request to the destination, but gets a connection refused response.
  6. Transport level retry, attempt 2:
    1. The scheduler waits for the specified transport retry interval time (5 seconds), and fires a trigger to invoke the retry handler.
    2. The retry handler sends the message that is stored in the store service to the target service.
    3. The target service sends a request to the destination, but gets a connection refused response.
The steps are repeated until the number of retries is exhausted. If the message is delivered during any attempt, further retries are not triggered. The total number of retries that happen for the configuration specified in the scenario are:
  • Transport level retry - 4
  • Destination level retry - 2