HL7/ebXML Slow Retry

ebXML Retries


According to ebXML Message Service Specification Version 2.0 a MSH (Message Service Handler) will perform multiple retries to send a message if it(sender) does not receive an Acknowledgement from the receiving MSH. The number of retries is one of parameters used by the sending MSH to confirm that a message is sent reliably.

According to ebMS2.0

Ø The Retries parameter is an integer value specifying the maximum number of times a Sending MSH SHOULD attempt to redeliver an unacknowledged message using the same Communications protocol

Ø 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.

From the second bullet point it is clear about what ebMS2.0 suggests us to do.

According to the classic Enterprise Integration Patterns "messaging" ensures that message will be guaranteely delivered but does not guarantee when it will be delivered. If the infrastructure supporting the conversation between sender and receiver is down for considerable time the sender will ensure that the receiver gets the message when the infrastructure is back. However when the message is delivered the context of the message may not be valid anymore. Generally systems implement message expiration that is if they receive a message which is quite old they discard the message and the “oldness” of the message usually is implementation specific. In some cases the messaging middleware implements the message expiration policy where it specifies how long a particular message type will live or when it will expire. The expired messages are written into dead letter queues for service management activities.

But ebMS2.0 does not specifically talk about what to do after the number of reties expire other than letting the layers above the messaging layer know of the failure to deliver the message. It also does not talk of the slow retry mode (or is it called long retry mode?) or about message expiration at all except for the number of retries as per the contract property.

In one of the large HL7V3.0 implementation where ebXML is implemented for asynchronous messaging it was recommended that systems use HL7 retry mode when sender MSH retries expire without an ACK being received from the receiver. In this particular implementation the system provider suggested that all systems which communicate with a particular sender should implement the “Slow retry” as exponential retry behavior that is, after each ebXML request sequence has failed, the Sender must retry with an increasing time interval. This might run into a problem for outages of longer duration as the persistent duration of the message might expire if at all the message has been received by the receiver but the acknowledgment has not reached the sender from the receiver.

According to ebMS2.0 persistent duration is a parameter which is defined as the minimum length of time data expressed as "duration" from a reliably sent message is kept in persistent storage by a Receiving MHS node. If the persistent duration has passed since the message was first sent, the Sending MSH SHOULD NOT resend the message with the same ebXML MessageId though the HL7 Message Id should be the same.

If response is not returned even after ebXML retries and “slow retry” there is no other way other than handling the problem manually. In case of Multi-Hop using a intermediary slow retry is not suggested at all it has to be handled manually as Multi-Hop do not conform to eith SEF or RIF(See my post on HL7 Forms of Operation)