The following problem arose during an integration test. This change has been confirmed to fix the issue:
I've got the a setup where 'my' Jentrata MSH is communicating with a 3rd part MSH. When an acknowledgement is sent, and fails, a subsequence retry from the original sender is not handled according to the ebMS spec.
The sequence of messages is as follows:
// 3rd party sends a ebXML order message over HTTPS, which is receive and stored by Jentrata
1) 3P --(Order ebXML)--> Me
// My MSH creates an Asynch Acknowledgement message and tries to send it but this fails
2) 3P X<-(Asynch Ack ebXML)-- Me
// After the CPA's retry period, the sender resends the order message
3) 3P --(Order ebXML)--> Me
// My Jentrata MSH detects this as a previously handled message and does not send an acknowledgement.
According to the ebMS spec Jentrata should send the same Ack message again but Jentrata does not comply with this spec and doesn't send anything in response to the retry by the 3P.
The rules applying to the non-receipt of an anticipated Acknowledgment due to the loss of either the
application message or the Acknowledgment Message are as follows:
• The Sending MSH MUST resend the original message if an Acknowledgment Message has been requestedbut has not been received and the following are true:
• At least the time specified in the RetryInterval parameter has passed since the message was last sent,
• The message has been resent less than the number of times specified in the Retries parameter.
• If the Sending MSH does not receive an Acknowledgment Message after the maximum number of retries, the Sending MSH SHALL notify the application and/or system administrator function of the failure to receive an Acknowledgment Message (see also section 4.2.3.2.4 concerning treatment of errors).
• If the Sending MSH detects a communications protocol error, the Sending MSH MUST resend the messageusing the same algorithm as if it has not received an Acknowledgment Message. "
The following problem arose during an integration test. This change has been confirmed to fix the issue:
I've got the a setup where 'my' Jentrata MSH is communicating with a 3rd part MSH. When an acknowledgement is sent, and fails, a subsequence retry from the original sender is not handled according to the ebMS spec.
The sequence of messages is as follows:
// 3rd party sends a ebXML order message over HTTPS, which is receive and stored by Jentrata 1) 3P --(Order ebXML)--> Me // My MSH creates an Asynch Acknowledgement message and tries to send it but this fails 2) 3P X<-(Asynch Ack ebXML)-- Me // After the CPA's retry period, the sender resends the order message 3) 3P --(Order ebXML)--> Me // My Jentrata MSH detects this as a previously handled message and does not send an acknowledgement.
According to the ebMS spec Jentrata should send the same Ack message again but Jentrata does not comply with this spec and doesn't send anything in response to the retry by the 3P.
from Para 6.5.4 Resending Lost Application Messages [ https://www.oasis-open.org/committees/download.php/272/ebMS_v2_0.pdf]
The rules applying to the non-receipt of an anticipated Acknowledgment due to the loss of either the application message or the Acknowledgment Message are as follows: • The Sending MSH MUST resend the original message if an Acknowledgment Message has been requestedbut has not been received and the following are true: • At least the time specified in the RetryInterval parameter has passed since the message was last sent, • The message has been resent less than the number of times specified in the Retries parameter. • If the Sending MSH does not receive an Acknowledgment Message after the maximum number of retries, the Sending MSH SHALL notify the application and/or system administrator function of the failure to receive an Acknowledgment Message (see also section 4.2.3.2.4 concerning treatment of errors). • If the Sending MSH detects a communications protocol error, the Sending MSH MUST resend the messageusing the same algorithm as if it has not received an Acknowledgment Message. "