Failed Outbound exchanges should be retried

A previous RFE requested a solution to retry outbound AS4 one way push exchange where the failure was caused by a HTTP 30xm 40x or 50x error.  This was implemented and is working well. This has saved us considerable time and expense by not requiring the execution of daily reconciliations to identify initiated exchanges that have failed to deliver successfully.  Further refinement of our configured RETRY POLICY or the Conformance Policy configurations has also reduced the number of outbound failures that are not automatically retried.

However, it has been identified that there are other scenarions where IBM B2B Advanced Communications does not attempt to retry failed outbound AS4 One way push exchanges.  This issue was raised under support case  TS011023954  Created on  Oct 25, 2022 12:28 GMT+10.

On Oct 18, 2023, 15:28, the support team finally responded with the following - 

"... 

     -Had a discussion in our meeting , explained following

      Delivery retry can happen on two cases . 1. on socket timeout error 2. customer configured http error codes where retry exception thrown. However in this particular scenario           "java.io.IOException" there is no retry possible in the code and transaction is failed . This is as per design.

      -Please raise a ER if you need retry to be done for "java.io.IOException" t

..."

As an ebMS/AS4 gateway administrator I want to see all failed exchanges retried regardless of the reason for failure - the lack of a receipt is a key indicator of failure.  

As per previous comments, Failed outbound messages are only identified after exhaustive manual reconciliations across various messages types and patterns.  This takes operational support staff at least 1 hour every business day to complete the reconciliations and then additional time to actually take action to restart/replay/resend any identified messages.

The solution to retry failed exchange by restarting/replaying from within B2Bi is not a valid solution because, time still needs to be expended to identify the failed exchanges.

The business impact is that the Precision Administration Gateway is failing to meet message SLA with reportable breaches occurring regularly - perticularly where messages fail outside business hours.

It would be ideal if these failed message scenarios could be identified and leverage the Conformance Policy "no receipt received" message retry approach.