Skip to Content
Author's profile photo Dominic Beckbauer

Working with HTTP-Input in SAP Cloud Platform Integration Flows and How to Test These Flows with Postman

In this blog entry, I would like to show you the basics of creating a HTTP-Input for your iFlow and how to send data for testing with the tool Postman.

Http-Inputs accept standard http requests as an input to trigger an Integration Flow in SAP Cloud Platform Integration.

You can use http-inputs in production, if the service that triggers your iFlow uses standard http-requests or you can use it to test your integration flows, sending headers and a body payload to your flow.

Tests can be carried out using the software Postman. This software provides many options of sending different http-requests to your flow to simulate input that might come from your system.


Postman: I use the tool Postman to trigger the input element of the integration flow. (See:

SAP Cloud Platform Integration Tenant: Of course you need an instance of the Cloud Platform Integration with a user and password that has the right authorization to create iFlows. You need to be familiar with the basics of creating an iFlow.

Creating your Integration Flow

We need a HTTP Input Element and an End-Message Element. What you do in-between depends on your Flow. In this case I use a XML Validator to check the body message, make a small mapping and use a script for debugging. For this blog entry, only the HTTP Input is relevant and furthermore there needs to be a Message-End element.

Configuring your Integration Flow

HTTP Input


This is the URL extension with which you can address your flow. In this case it is:

If you set a * as wildcard, you can extend your url-path and read it out of the header variables.

You can find XXXXX and YYY in the URL of your SAP Platform integration account. YYY can be eu1 or us1 for example, depending of the region of your tenant.


You can set Client Certificate or User Role (Basic Auth) here. In this case we use Basic Auth.

User Role

This is the role that the user needs to connect to the Flow. You can assign roles in the SCP Member area of your tenant ( -> choose your location and tenant —> Security -> Authorizations -> Groups: Assign Role ESBMessaging.send to app <your-tenant>iflmap and finally assign your S-User)

General settings

Allowed Headers

In the general settings of your iFlow (just click somewhere in the white space next to your iFlow to see the settings), you will find the option “Allowed Headers”. If you want to send header variables to your iFlow inside your HTTP-Request and use them, you have to specify them here (separated with | ). Alternatively you can set * to bypass all. Be aware that you will find your Basic Auth token in the iFlow in this case. This might be a big security issue.

Using Data and Variables in the Integration Flow

In general it can be said that header variables of the request becomes header variables of the iFlow message and the body payload becomes the message body. Although there are some other interesting variables that get filled:

Header Variable Description
CamelHttpMethod The request method (GET, POST, PUT…)
CamelHttpPath The part of the Uri that comes after your defined path. If you defined the address as /HTTPDemo/*, you get what stands instead of the * in your URL. You have to set * that you are allowed to extend the URL.
CamelHttpQuery Variables from the URL (?var1=val1&var2=val2)
CamelHttpUri The URI after the domain (/http/yourdefinedpath
CamelHttpUrl The full URL that was used to trigger the flow


You can get access to these header variables with ${header.<nameofvariable>} for example in the Content Modifier element.

Header variables that are send in the http-request and should be used in the iFlow must be allowed (See: Configuring your Integration Flow -> General Settings -> Allowed Headers). The cookies that are send with the request might be one header variable too (“cookie”).

Testing your Integration Flow with Postman

You need to install Postman from

Create a new Request and fill in the following fields:


Depending on your Request. If you want to provide a payload you can use POST. Otherwise you can use GET. If you set a flag on “CSRF Protected” in the configuration of your Integration Flow, you have to use a GET Request to get your XCSRF Token first. With the token as a header variable, you can use POST messages after that (See: Testing your Integration Flow with Postman -> XCSRF-Token)


Fill in the URL of your integration Flow (See: Configuring your Integration Flow -> Address)


Authentication (Certificate Based Authentication / Basic)

In this example we use basic authentication. This means we have to add a header variable. Postman does this by itself if you click on Authorization and input username and password of your SAP Cloud Platform user.

For me, I use my business mail and my Platform Integration password. The same that I use to login. Of course you should only use that for testing and not for productive use.

Be aware if you decide to accept all header variables (see “Configuring your Integration Flow -> General Settings -> Allowed Headers”), that your basic auth token is a header variable in your iFlow. You need to delete it, otherwise people, who have access to the traces of your flow could copy it. Additionally it might be sent in the output as a header variable (for example, if you have a http output in your flow)


(For Post Requests) Fill in the Data Type of your body payload (not for GET Requests because you don’t have a body Payload). Postman does this itself if you use the dropdown in the Body section.


If you secured your HTTP-Input with XCSRF-Protection, you have to add the XCSRF-Token here. You send a GET Request to the Base URL of your Flow and set the Header XCSRF-Token: Fetch. In the response header, you find the requested Token that you can include in your Request Header instead of “Fetch” (For exampleà XCSRF-Token: 6kn3jr8uvkggF7oG3ih_SQ==). See the screenshot below as example.

The token is valid for a specific time.


Fill in your payload here. Be careful that the content-type is set properly. Use the raw option to copy and paste input from another source.

Send the request

Your Request should look similar to this:

You can now use Send to test it (I have, of course, changed my Basic Auth Token J ). You will see the response in the part of the window under your request. Similar to the request, you can explore the Header and Body of your response.

Questions and Answers

Do you have a groovy script for me to test my input from postman in the iFlow?

I use


import java.util.HashMap;

def Message processData(Message message) {


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

def map = message.getHeaders();

def mapProp = message.getProperties();


if(!map.containsKey(“subject”) ) {


} else {

message.setHeader(“subject”,map.get(“subject”) + ” “);


message.setBody(“BODY:\r\n” + body + “–ENDBODY\r\n\r\nHEADERS:\r\n” + map.toString()  + “–ENDHEADERS\r\n\r\nPROPERTIES:\r\n” +  mapProp.toString());

return message;


in a Script Element in the iFlow. It fills all header and property variables in the body of the message together with the original body.

What happens with my header variables?

They become header variables of the messages in the iFlow. Make sure that you allowed the header variables you need (See: Configuring your Integration Flow -> General Settings -> Allowed Headers)

What happens with my Http-Request-Body?

This will become the Payload of the messages in your iFlow.

What do I have to be aware of when using Basic Authentication?

If you allowed all Headers in your iFlow, you will find your Token in the iFlow. This might be a security issue.

What is my response message?

The message payload of the iFlow becomes the body and the header variables become the header variables of your response.

Do I have to copy and paste the XCSRF-Token from my fetch-get request to my post requests all the time?

If you set XCSRF Protection in the HTTP Input settings of your iFlow, yes. But if you use environment variables in Postman you can add a small script to the Test area of your request:

pm.environment.set(“X-CSRF-Token”, postman.getResponseHeader(“X-CSRF-Token”));

It fills the X-CSRF-Token variable (you have to create it first in the environment you use) with the token you get from the request. You can use this in another request then as variable

Are there any other tricks when using Postman?

Yes; use variables inside Environments. For example for URLs, XCSRF-Token and Authentication.



Feel free to leave comments and I will try to answer any questions of you.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Martin Pankraz
      Martin Pankraz

      Nice Write-up Dominic! I really like the fetch-mechanism.

      Author's profile photo Dominic Beckbauer
      Dominic Beckbauer
      Blog Post Author

      Hi Martin,

      thank you for the reply. Indeed you can do some pretty nice things with the scripting engine and variables that I used in the fetch mechanism. You can find more informations in the Postman API description:


      Author's profile photo Alex Silva
      Alex Silva

      Great post!


      Author's profile photo Alice Van Ommen
      Alice Van Ommen

      This works perfectly, nice!

      Just a thought:  It would be great if we could actually see this Posted test message as well in SCP/HCI monitoring...or maybe that is possible somehow?


      Author's profile photo Dominic Beckbauer
      Dominic Beckbauer
      Blog Post Author

      Hello Alice,

      I think you have two options here:

      If it is just for debugging, you can enable the trace option:

      Than you can see the message that you have sent going through your flow in the "Monitor Message Processing". Be aware that the trace is only saved for 15 minutes. Not too long but it is very usefull for debugging.

      The second option is to put a script in the beginning of your flow. This can be used to log the incoming message.

      You need sth like:

      def messageLog = messageLogFactory.getMessageLog(message);
      def body = message.getBody(java.lang.String);
      messageLog.setStringProperty(“Logging”, “Attachment”)
      messageLog.addAttachmentAsString(“ResponsePayload”, body, “text/xml”);

      This is than more persistent. Also look at my script in the blog post to enrich the body with the header variables to get the whole message.

      Does this help you?

      Best regards


      Author's profile photo Alice Van Ommen
      Alice Van Ommen

      Hi Dominic,  sounds like good options.

      I am trying the second one, but Cloud Integration (Groovy Script>Processing) is giving me errors on the extentions I try when trying to upload the (notepad) script  (.java, .js etc).  Do you have a tip?




      Author's profile photo Dominic Beckbauer
      Dominic Beckbauer
      Blog Post Author

      Hi alice,


      try *.groovy 🙂 The best is probably to create the script in the WebIDE

      Than copy and paste your code and save.

      Does this help you?

      Author's profile photo Alice Van Ommen
      Alice Van Ommen

      Excellent, thanks!


      Author's profile photo Rajesh PS
      Rajesh PS

      Dominic Beckbauer


      I wanted to check regards X-dynaTrace in http header generated and sent to consumer application. Though headers are disabled at SAP CPI end due to this invalid chars the message is failed to consume at end application.

      Flow looks like SAP CPI -> EMP (kafka) -> Consumer app(.NET)