Skip to Content
Technical Articles

The Curious Case of the Unexpected Headers

Updated June 25th, 2019: The scriptFile and scriptFileType headers mentioned below are no longer left behind by the Script step. The variable and data store headers are still returned to outside callers, though.

TL;DR: Some integration flow steps leave behind headers, that contain information about the internals of the integration flow. If you don’t want to leak that information to the outside world, you need to actively remove the headers in question.

The other day, I hooked up an HTTPS sender channel to a simple Cloud Integration integration flow to do some testing. The integration flow reads a variable and executes a Groovy script. Not very exciting at all, it must be said, but it nevertheless led to a finding, that was curious indeed.

When I called the integration flow’s endpoint in Postman, I noticed something unexpected in the HTTP response headers: The name of the Groovy script, and the name and contents of the variable. Here are the headers in question:

  • scriptFilescript1.groovy
  • scriptFileTypegroovy
  • MyVariableTesting123
  • SapDataStoreIdMyVariable

(The variable is called MyVariable, and it contains the string Testing123.)

I proceeded to remove all steps except the script step and the Content Modifier step, that reads the variable. I did this in order to make sure, that those two steps had in fact added the headers of their own accord. This turned out to be the case. Now, why these headers are left behind, is less clear at the moment. They might be implementation artifacts, that are not cleaned up.

Further investigation showed, that reading from (Get step) and writing to (Write step) a data store also results in the SapDataStoreId header being added. In those cases, the header contains the ID of the data store entry.

Is this a problem? Probably not in most cases, but Cloud Integration developers should be aware, that these headers can possibly leak information, that we do not expect an outside party to be able to view. Particularly variables and data store entry IDs can potentially contain sensitive information, that should not leave the Cloud Integration tenant.

Fortunately, we can remove these headers, but we need to do so actively. Keep in mind that the Headers tab of the Content Modifier step is not only used to add headers, but also to remove them. In this example, the SapDataStoreId header is removed:

For more detail on how to remove headers, please see this blog post by Praveen Tirumareddy.

If you have noticed other unexpected headers added by integration flow steps, please comment below, and I’ll update this blog post with your discoveries (and attribute them to you, of course).

In case you are interested in more Victorian-era sleuthing, I highly recommend the original Sherlock Holmes books by Arthur Conan Doyle, or the classic Granada Television series featuring the wonderful Jeremy Brett as Holmes.

My fellow SAP Mentor Eng Swee Yeoh provides additional insight into these curious headers in his comment below. Eng Swee’s research shows, that they are indeed used by Cloud Integration internally, and then not cleaned up afterwards.

In addition, Eng Swee’s results indicate that the script step uses a third header: functionName. I tried setting this header before a Script step, and the script engine does indeed try to execute a function, whose name matches the value of this header. This means that if you happen to have an unrelated header named functionName in your integration flow, any subsequent Script steps will very likely fail.

Interestingly, the functionName header is not returned to the caller. Eng Swee’s code snippet below shows how this particular header is actively removed.

You must be Logged on to comment or reply to a post.
  • Hi Morten


    I agree with Jelena – what an exquisitely designed blog post! ?


    Regarding these headers, I can elaborate further based on my own findings using an example of a Groovy script step.


    The graphical based integration flow generates an underlying Camel Spring DSL route that is used during runtime by the Apache Camel framework. When using a Groovy script step, the following steps are generated in the Spring DSL.

    From item (1), you can see that the Camel exchange headers are populated with the scriptFile and scriptFileType details.

    Subsequently it executes a bean method in (2). This processing happens in class which extracts the value from the exchange headers to determine the script that needs to be dynamically executed during runtime.


    Similarly, you can deep dive into other modelling steps to see how these variables are generated and used. Note that the steps in the Spring DSL also corresponds to what you can see in the recent enhancements to the message processing log viewer.


    I do agree that such headers should not have left the system, so it would have been better to use exchange properties rather than exchange headers.



    Eng Swee

      • Hi Morten


        Regarding the functionName header, even when it is set in the Groovy step of the integration flow, it seems that the response header is not populated with the value.


        Upon further inspection of the above said bean method, it looks like there are some lines of code at the end of the method that clears off those value from the header.


        This brings up the question - why are the other headers not cleared off?



        Eng Swee


  • Hi Morten,


    These unwanted/extra header values may cause your Odata API to fail with 'Bad Request (400) error'. Cleaning them before making any external call is always a good idea.