Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
Hello folks,

Everything its ok with messaging/event broker?

Basically in this blog, I will present a similar solution of the - SAP CPI – Retry JMS and Open Incident – ServiceNow and once again with the brilliant blog of mandy.krimmel – Cloud Integration – Connecting to Messaging Systems using the AMQP Adapter.

In the past I already present to you with two blogs the SAP Enterprise Messaging - The message broker to pubsub events from S4/HANA, you can check both blogs about this service under the SAP Cloud Platform.

  1. SAP CPI - EM and CPI for asynchronous patterns

  2. SAP EM – Message Broker for Events S4

When I published those blogs the AMQP protocol adapter was not in place, so I demonstrated the functionalities of SAP EM via API Restful with POSTMAN.

The Solace it's a private messaging broker that supports many different protocols and others, you can get more information and even create a PubSub+ instance for free during 30 days.

I tested solace with HTTPS Restful and AMQP protocols and I will present for you only with SAP AMQP new channel available for CPI.

Open API's & Protocols supported by Solace:

Why you don't use the JMS Protocol?

Because the JMS Channel on SAP CPI it's only for internal queues mechanism.

Solace PubSub+ Instance:

First integration diagram:

The first diagram the SAP sender system sending the XML message but the receiver system it's off and the exception raises a publish in the Event Broker Solace Queue mechanism.

Second interface diagram:

The second diagram presents the read data from Queue from Solace Event Broker to SAP CPI, retry mechanism to send the message to the receiver system and in case of fail the CPI writes in another queue for controlling.

Third interface diagram:

The third diagram it's processed to read the queue and in case of still offline the receiver system, the SAP CPI calls the ServiceNow API or sends an e-mail.

This is just a sample, I will not show the e-mail process in this blog.

First Integration Flow:

Integration Flow Description:

  • Sender

  • Exception flow

  • Sender

  • Content Modifier

  • Content Modifier – Response HTTPs

  • End of Event/Exception.

  • Receiver

I already explain in the previous blogs the steps, it's the same just with the different receiver channel AMQP and different Replay Error Message (Content Modifier).

Configuration AMQP Channel - Server Details:


Authentication - Simple Authentication and Security Layer (SASL).

Processing detail:

You must input the queue in Solace that will write the message (publish-subscribe).

Second Integration Flow:

The second integration flow process the message from JMS (read), try to send and retry in case of fail with the third party system and in case of fail of retry mechanism the incident will be created in ServiceNow – Incident Management Platform.

Integration Flow and description:

  • Sender – AMQP - Solace

  • Router - Retry Mechanism

  • Receiver

  • Router - Retry Mechanism

This integration flow basically reads the message from AMQP Sender Channel, makes a retry mechanism based in the header expression for "JMS" - ${header.JMSXDeliveryCount} > '5'

What is the problem to use only this header parameter available for different JMS internal mechanisms of SAP CPI where we can use the expression - ${header.SAPJMSRetries} > '5'.

Question mark?

Basically, this is a very simple parameter based in MS, so the retry mechanism will work but in less than 10 seconds so this is not a good retry mechanism because always you must contact the external Solace team to proceed with manual retry.

Retry duration:

How to solve this problem?

In my proof of concept, I design a groovy script to split between the retry mechanisms counter based on expression ${header.JMSXDeliveryCount} > '5'In the case of the internal JMS queue mechanism of SAP CPI the parameter ${header.SAPJMSRetries} > '5' 

Integration Flow and description:

  • Sender – AMQP - Solace

  • Groovy Script - Sleep

  • Router - Retry Mechanism

  • Receiver

  • AMQP Sender Channel

Configuration of Sender channel - The connection details it's posted above - Here just add the queue name that must read the data.

  • Groovy Script - Sleep

Groovy Script Detail - I understand the this groovy can produce some kind of performance issue in the SAP CPI platform but this was just proof of concept, if you have another better idea, please share.
import java.util.HashMap;
def Message processData(Message message) {
def body = message.getBody();
return message;


Retry duration with the groovy script - sleep 120000 - 2 min:

Third Integration Flow:

The very similar flow of the previous blog - SAP CPI – Retry JMS and Open Incident – ServiceNow you can check the details there, the difference from the previous blog, in case I also use the retry local integration process running under the expression - ${header.JMSXDeliveryCount} > '5' without sleep in this case because the second integration flow it's responsible for automatic retry after 2 minutes.

  • AMQP Sender Channel

Configuration of Sender channel - The connection details it's posted above - Here just add the queue name that must read the data.

Test the integration Postman:

SAP CPI endpoint: https://<tenant> here endpoint)

Post - Request-Replay:

Service Now Incident Management after many tests:

Description details with a queue that Solace Team must check and retry:

After the incident opens the Solace team will be contacted and retry the message based in the configuration setup.

Solace Panel:

I really hope that you enjoy it and also that you start to think about event brokers and cloud solutions.

If you get something better for the "sleep" mechanism, please write down.

Kind Regards,

1 Comment
0 Kudos
Hello Viana,

Thank you for sharing this great content!


Luciano Silva

Labels in this area