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 all,

**Last update - 26/02/2020**

I did this proof of concept in the LITE plan of SAP EM product that was Deprecated by SAP but the functionalities still valid for DEFAULT plan.

** End of update details **

I'm here again to give you more information about how to use asynchronous patterns with SAP CPI - Neo and SAP EM - Foundry - SAP Cloud platforms.

On my previous blog - SAP EM Blog - I was presenting to you some functionalities and integration patterns - publish-subscribe (queue) - for an asynchronous message.

The integration it's simple using POSTMAN with SAP CPI and SAP EM, I will not present here the whole configuration because it's something that you can check on previous blogs and also on SAP EM Help:

The diagram below it's exactly what I produce.

Integration Diagram:

Description of the scenario:

The integration it's simple using POSTMAN post the message to the ENDPOINT generated on SAP CPI and CPI flow will be responsible for management or messaging (point-to-point(Queue) or publish-subscribe (Topic)) the SAP EM.

Integration Scenario SAP CPI:

The integration scenario contains the objects:

  • Sender

  • Content Modifier

  • Request-Response

  • Groovy script 

  • Router

  • Request-Response

  • Request-Response

  • End of Event.

Integration Process CPI:

The diagram it's just POC proposal and I know that it's missing the exceptions for HTTP call's, no worries.

Tired until now?

Don't be because now I will explain you each step inside the SAP CPI Product to make this scenario not only works but also provide rich detail of steps and calls to SAP EM and support your integration with patterns of the asynchronous message with the new message broker from SAP.

Ps.: SAP CPI also contains native JMS for queue proposal but with feel queues, more queues you must pay additional amount.


So let's rock ?

1 ) Postman:

End point: https://{your_SAP_CPI_NEO}/http/SAP_EM/QueueProcess

Body: XML File routing the message for each action must do - Management or Messaging. This body will be not the data that will be inserted on the queue, it will be the response call for Token from SAP EM. I don't enhance more the scenario because of test proposal, but you can make content modifier before the first synchronous call to keep the body also - Camel: Variable / ${in.body} - and another one to receive the return of groovy just the head and set the body of next content modifier with the real body.


2 ) Content Modifier: Get the action

  • Get the content and use to send a message to Manage Queue or Messaging Queue but the body (XML message) will be deleted on the next step.

  • XPath to extract the value that will be used on Router.

  • Tip: The content modifier does not parse type JSON, for that you can create a content modifier plus JSON to XML function before the content modifier because in this case you are sending XML and you can use Type Xpath.

3 ) Request-Response:

  • Synchronous Function from CPI using HTTP adapter to make the first connection with SAP EM to retriever the TOKEN that will be used for authentication on next steps (Management Queue).


3 ) Groovy script:

  • Parsing the JSON and extract the value from name {access_token} and set the header for the next call that will be based on the value got on the first content Modifier.

Code below:

import java.util.HashMap;
import groovy.json.*;

def Message processData(Message message) {

//Retrieve message body
def body = message.getBody(java.lang.String) as String;

//Instantiate JSON Parser
def parser = new JsonSlurper().parseText(body)

//Retrieve message log
def messageLog = messageLogFactory.getMessageLog(message);

//Retrieve properties
def props = message.getProperties();

//Retrieve access_token from JSON message
def access_token = parser.access_token;

//Adding Authorization parameter to the message header
message.setHeader("Authorization", "Bearer " + access_token.toString());
message.setHeader("x-qos", '0');
message.setHeader("Content-Type", "application/json");

return message;

  • With this code as you see the body will be the response of SAP EM system, basically this JSON code below:

{"access_token": "TOKEN"  ,"token_type": "bearer","expires_in": 007,"scope": "James Bond","jti": "England"}

5) Router:

  • Based on the value from the XML sent via POSTMAN, the router will check where to go - Management (Just check the queues registered on the SAP EM) or Messaging, in this case, I'm testing only the asynchronous pattern point-to-point(Queue).


5) Management or Messaging queue:

  • Router did check on the value of tag Management of the XML sent via Postman:

XML File:


6) Management Queue:

  • The SAP EM Help you can check how you must build the endpoint of the message together with the endpoint provide on the JSON file when you generate the instance, in this case the end point here is:



7) Messaging Queue:

  • The SAP EM Help you can check how you must build the endpoint of the message together with the endpoint provide on the JSON file when you generate the instance, in this case the end point here is:


8) End process.

So just to remind you that until now I just explain you all steps and needs to make the call and to end.

Let's real rock and roll now?

OK, I got you and it's time for that, I will present below without much detail because I already explain you all steps above:

Posting message to SAP CPI - HTTPS with the tag MANAGEMENT with value 1, it means in the routing of integration scenario we will go to check what is the queues registered on SAP EM.

The endpoint used from SAP CPI:


Check the image below the response:

So let's insert on the queue "name": "SCN_BLOG_EMwithCPI".

I really hope you enjoy this experience and different style to provide good information for you about the new message broker of SAP.

Kind Regards,



Ricardo Viana.


Labels in this area