This article explains what you have to consider when dealing with asynchronous messaging in SAP Integration Suite – Cloud Integration (f.k.a. CPI).
If you come from SAP PI/PO, you might be used to the concept of staging (and logging): Staging defines, at which point of the processing a message is being persisted. Automatically. Just by selecting from a drop-down menu. It is important to know and to decide, when this is happening during your message processing. In PO this is typically
- before routing (BI/VI),
- after routing and before mapping (MS),
- after mapping (AM).
For receiver and interface split integrations this is also important to consider:
A message will be splitted by receiver and then by interface (if applicable) and each message will be persisted individually.
Modeling this in SAP Cloud Integration will require your decision, IF you want to accept messages asynchronously or if you process them synchronously without the need of thinking about queuing. There are good reasons to process messages asynchronously, by accepting a message (maybe after performing checks on structure/format/content) and then making sure it will reach the target. We have published an article on asynchronous messaging best practices, however here´s the general ruleset:
YOU have to decide, WHERE you buffer/queue the messages, from which position the RETRY will take place
Some adapters provide built-in queuing, such as XI or AS2. Also, an SFTP Sender adapter will keep the file at the source and delete/move/mark the message only if the integration flow message completed successfully.
For most cases you can use a simple JMS-based queuing. Any error situation AFTER the JMS queuing will push back/keep the message within the queue and perform a RETRY:
If an error occurs in the first integration process, the error is pushed back to the sender (you might catch the error with an exception subprocess and complete the message successfully and send back a HTTP 400/500 to the sender with a description).
If an error occurs in the second integration process, e.g. during mapping or outbound connectivity, the message is KEPT in the JMS queue and a RETRY takes place (you can also trigger the retry manually from the JMS queue and/or you might want to add a circuit breaker by checking the number of retry attempts and finish the processing after a while, see header SAPJMSRetries).
Now, if you have a split to multiple receivers, you need to wisely choose where you add the JMS queues. If you use only one, it might happen that one receiver is processing the message and another can not be reached. In this case, a RETRY would call BOTH receivers AGAIN (with each retry attempt).
If this is acceptable, this might be an option to go for, however a more “PO-like” version would look like this:
Of course you can separate each Integration Process into an individual Integration Flow.
Now you understand the overall concept. It should be clear, how you can buffer/queue messages at any time during the processing of a message in an integration flow (or across).
Last Update: 2. Jul 2024
