AMQP defines four terminal delivery states for message transfers that can occur after completion of the transfer: accepted, rejected, released and modified.

The accepted terminal delivery state indicates that the destination node has accepted the transfer.

The following table illustrates how the accepted delivery state is mapped to Universal Messaging server (Sender) communicating with an AMQP subscriber (Receiver):

Description: When UM receives a disposition frame without a local and remote state, it responds by accepting the delivery, disposing using the source's default outcome and advancing the link.

Description: When UM receives a disposition frame with a remote state of accepted but already settled, no further action is taken.

Description: When UM receives a link attachment the link address is examined and the destination node verified. Following that an asynchronous UM native sub is queued. Finally when the UM server has completed the subscription, the delivery is accepted and settled. This is equivalent to a UM regular subscribe.

Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability NONE and ReceiverSettleMode.FIRST, it accepts and settles it with no further action. This is equivalent to a UM reliable subscriber (no durability, no ACKs).

Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability CONFIGURATION (NON PERSISTENT) or UNSETTLED_STATE (PERSISTENT) and ReceiverSettleMode.FIRST, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE) is queued with the mapped fields. Finally when the UM server has completed the ACK, the delivery is accepted and settled. This is equivalent to a UM durable subscriber ACK.

Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability NONE and ReceiverSettleMode.FIRST, it accepts and settles it with no further action. This is equivalent to a UM reliable subscriber (no durability, no ACKs).

Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability CONFIGURATION or UNSETTLED_STATE and ReceiverSettleMode.FIRST, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE) is queued with the mapped fields. Finally when the UM server has completed the ACK, the delivery is accepted and settled. This is equivalent to a UM durable subscriber ACK.

Description: When UM receives an unsettled disposition frame with a remote state of transactional, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that it updates internal data structures in the sender session context. This is equivalent to a UM transactional durable subscriber ACK.

When UM receives a disposition frame without a local and remote state, it responds by accepting the delivery, disposing using the source's default outcome and advancing the link.

The following table illustrates how the accepted delivery state is mapped to a Universal Messaging server (Receiver) communicating with an AMQP publisher (Sender):

Description: When UM receives a partial delivery, it rejects it with an amqp:not-implemented error and settles, as multi frame transfers are not currently supported in UM. We have plans to add support for this in a future release of the product.

Description: When UM receives a non-partial delivery it tries to examine and transform its contents using the configured UM transformer. If the result of this operation is null, the delivery is rejected with an amqp:precondition-failed error and settled. This is unexpected outcome which indicates that an unexpected error occurred during transformation.

Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is SETTLED, no further action is taken. This is directly equivalent to a UM reliable publisher.

Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is UNSETTLED, it will accept it and advance the link. This is equivalent to a UM reliable publisher with a response from the server but no transactions.

Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is MIXED, it will accept it and advance the link ONLY if it is not already settled. This is equivalent to a UM reliable publisher with a response from the server for some publisher controlled transfers and no transactions involved.

Description: When UM receives a non-partial delivery transactional delivery, it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM TX native publish request is queued. Finally, when the UM server has processed the native TX publish request, it will accept it with a transaction state set to the TX ID and advance the link ONLY if it is not already settled. If it is already settled, no further action will be taken. This is equivalent to a UM TX publisher .

The rejected terminal delivery state indicates that the destination node has rejected the transfer.

The following table illustrates how the rejected delivery state is mapped to Universal Messaging server (Sender) communicating with an AMQP subscriber (Receiver):

As discussed in the accepted state mappings, an AMQP subscriber with these settings is mapped to an asynchronous UM native subscription. When the UM server has completed processing the subscription request and an error has occurred the delivery is rejected and settled as follows:

In addition to the above rejections applying for all subscriptions and accepted state mappings, an AMQP subscriber with these settings is mapped to an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE). When the UM server has completed processing the ACK, and an error has occurred the delivery is rejected and settled as follows:

The following table illustrates how the rejected delivery state is mapped to a Universal Messaging server (Receiver) communicating with an AMQP publisher (Sender):

Description: When UM receives a partial delivery, it rejects it and settles it, as multi frame transfers are not currently supported in UM. We have plans to add support for this in a future release of the product.

Description: As discussed in the accepted state mappings, an AMQP publisher with these settings is mapped to an asynchronous UM native publish getting queued. When the UM server has completed processing the native publish, and an error has occurred the delivery is rejected and settled as follows:

Description: As discussed in the accepted state mappings, a transactional AMQP publisher with these settings is mapped to an asynchronous UM TX native publish request getting queued. When the UM server has completed processing the native TX publish request, and an error has occurred, the delivery is rejected and settled as follows:

The released terminal delivery state indicates that the destination node no longer knows anything about the transfer, expecting redelivery.

NOTE: In Universal Messaging Link no explicit use of the released state is performed as it is internally handled by the Apache Qpid™ Proton-J protocol engine. See https://qpid.apache.org/proton/index.html for related information.

The modified terminal delivery state indicates that the destination node no longer knows anything about the transfer, expecting redelivery but only after modification by the sender.

NOTE: In Universal Messaging Link no explicit use of the modified state is performed as it is internally handled by the Apache Qpid™ Proton-J protocol engine. See https://qpid.apache.org/proton/index.html for related information.