Previous – Dead Letter Channel | Index | Next – Channel Adapter

This week, we’ll study a pattern known as Guaranteed Delivery.

When do I use this pattern?

The Guaranteed Delivery pattern is used to ensure that the message is delivered to the receiver(s) even if the messaging system fails. This is achieved using persistence. When the sender sends the message, the message is stored in the persistence layer. Unless the message is stored, the message is not successful. Similarly, the message is not removed from the storage until it reaches the receiver.

As persistence is used, one should consider the performance impact before applying this pattern. For example, something like a quote request could skip guaranteed delivery. Whereas, order placement message could use the Guaranteed Delivery pattern.

Guaranteed Delivery in CPI

In CPI, this is a standard feature achieved using JMS Sender Adapter and JMS Receiver Adapter. For demonstration, we’ll send orders from OMS to the CPI and log the message.

Integration Flow – Get Order

Get Order

This flow exposes an HTTPS endpoint using HTTPS Sender Adapter and simply enqueues the incoming message using JMS Receiver Adapter.

Here, if the CPI is down, then the sender system will have to handle resending the message. If the message arrives in CPI and if the enqueueing is errored, then the message will not end successfully, and again the sender system will be able to resend the message. On the other hand, if the message is enqueued successfully, the sender system can rest assured that the message will reach the receiver.

Integration Flow – Process Order

Process Order

This flow picks up the message from the queue and logs the message body. The message will not be removed from the queue until the message is processed successfully. Therefore, the delivery to the receiver is guaranteed.

How Guaranteed is Guaranteed Delivery?

The Guarantee in Guaranteed Delivery is provided by the persistence used.

On the sender side, i.e., in JMS Receiver Adapter., the guarantee is limited by the expiration period. By default, the message put in the queue expires after 90 days. In other words, guaranteed delivery only lasts 90 days after the message has been put into the queue. On the flip side, it is important to set the expiry period to protect the middleware. If messages never expired and messages started piling up, the impact will be significant on the system.

On the receiver side, i.e., in JMS Sender Adapter, the guarantee is unlimited by definition. However, to protect the system from losing performance as a result of retrying indefinitely, the developer should control the maximum number of retries by use of SAPJMSRetries header. Similarly, an invalid message should be moved to Invalid Message Channel and the sender should be informed. The Guaranteed Delivery pattern only guarantees “delivery” and not the successful processing of the message.

Additionally, there are limitations on the guarantee such as the maximum capacity of a given queue, number of transactions. Mandy discussed these limitations in the blog Cloud Integration – JMS Resource and Size Limits.

In general, these limitations are generous, i.e., most scenarios should report 99.9% actual guarantee.

EIPinCPI Rating – 10/10

With the support of JMS, this pattern gets a full rating of 10 out of 10.

Conclusion

Guaranteed Delivery pattern refers to ensuring that the receiver receives the message even if the messaging system fails while processing the message. CPI supports this pattern through the implementation of JMS.

References/Further Readings

• Guaranteed Delivery Pattern in Enterprise Integration Patterns
• Mandy‘s blog on Cloud Integration – JMS Resource and Size Limits
• CPI Components
  • JMS Sender Adapter
  • JMS Receiver Adapter
  • HTTPS Sender Adapter

Hope this helps,
Bala

Previous – Dead Letter Channel | Index | Next – Channel Adapter