Introduction

EOIO was a long awaited functionality that every Integration consultant was waiting for in SAP CI. We had this in SAP PO where we would use it to preserve the order of messages. Messages using EOIO were stored in a FIFO queue that ensured the messages that arrive first in the middleware is also the first to leave. The order was ensured even in case of outages on the receiver system and the middleware would continue to retry the failed messages in the context of FIFO.

Solution

SAP has recently released JMS Adapter Adapter version 1.4, that has the Exclusive mode which ensures that the message order is preserved.

Both JMS Sender and Receiver adapters have a new option now – Access type – Exclusive / Non-Exclusive

For normal scenarios where the Order in which the messages are processed doesn’t matter it’s highly recommended to use non-exclusive setting in Access Type. Using “Exclusive” as Access type will enforce EOIO and takes away the option of parallel processing which ultimately means that as soon as the receiver system is up messages will get processed one by one and not parallelly.

Let’s dive in to the POC now.

Here we have a integration process that has this message which is split into 5 individual messages and will be sent to a EOIO JMS Queue

Content Modifier has the following message

We are splitting this and sending individual Message nodes to the JMS Queue, Parallel processing is unchecked in the splitter

The Integration process runs and creates 5 messages in the JMS Queue

Now SAP CI iflow will automatically retry these as the receiver systems URL is a dummy URL which doesn’t exist

As expected only the very first message gets Retried and none of the other messages in the queue are picked up.

This is a very welcome update from SAP. This will bridge the gap between SAP PO and SAP CI where consultants had to design workarounds to implement EOIO.

IntroductionEOIO was a long awaited functionality that every Integration consultant was waiting for in SAP CI. We had this in SAP PO where we would use it to preserve the order of messages. Messages using EOIO were stored in a FIFO queue that ensured the messages that arrive first in the middleware is also the first to leave. The order was ensured even in case of outages on the receiver system and the middleware would continue to retry the failed messages in the context of FIFO.SolutionSAP has recently released JMS Adapter Adapter version 1.4, that has the Exclusive mode which ensures that the message order is preserved.Both JMS Sender and Receiver adapters have a new option now – Access type – Exclusive / Non-Exclusive For normal scenarios where the Order in which the messages are processed doesn’t matter it’s highly recommended to use non-exclusive setting in Access Type. Using “Exclusive” as Access type will enforce EOIO and takes away the option of parallel processing which ultimately means that as soon as the receiver system is up messages will get processed one by one and not parallelly. Let’s dive in to the POC now.Here we have a integration process that has this message which is split into 5 individual messages and will be sent to a EOIO JMS Queue Content Modifier has the following message<Root>
<Message>
<id>1</id>
</Message>
<Message>
<id>2</id>
</Message>
<Message>
<id>3</id>
</Message>
<Message>
<id>4</id>
</Message>
<Message>
<id>5</id>
</Message>
</Root> We are splitting this and sending individual Message nodes to the JMS Queue, Parallel processing is unchecked in the splitter The Integration process runs and creates 5 messages in the JMS Queue Now SAP CI iflow will automatically retry these as the receiver systems URL is a dummy URL which doesn’t existAs expected only the very first message gets Retried and none of the other messages in the queue are picked up. This is a very welcome update from SAP. This will bridge the gap between SAP PO and SAP CI where consultants had to design workarounds to implement EOIO. Read More Technology Blogs by Members articles