Skip to Content

Reading the SOAP header when a web service is consumed seems to be an easy task. Nothing could be further from the truth in my case. It really took some time to realize. That is the reason for this blog, to share my thoughts, problems and insides with the community.

System

We use a SAP PI 7.11 SP11 system to realize this scenario.

Context and requirement

It all starts with the requirement to know who consumed a web service and to store that information on the SAP back end system. It means that a user ID must be provided within the SOAP call, but the requirement is not to put this in the message body, but dynamically in the SOAP header.

The input message could look like this

BLOG -- 1.jpg

What preceded it were a blog and the follow-up.

*** Important remark     Please note that this blog is based on Service Interfaces containing only 1 operation.

                                          Currently, it does not work with multiple operations within 1 service interface.

                                See Open items and doubts section below.

Configuration

The input structure looks like this

DT_input

     Name

The output structure looks like this

DT_output

     UserID

     Name

The objective is to fill the UserID field with the value of the AuditUser field within the SOAP header. To accomplish this, an XSLT mapping will be used. No other mappings are being used within the Operation Mapping step.

This is the XSLT mapping I used:

<?xml version=”1.0″ encoding=”UTF-8″?>

<xsl:stylesheet version=”1.0″ xmlns:xsl=http://www.w3.org/1999/XSL/Transform xmlns:ns1=”namespace”>

  <xsl:template match=”/”>

            <ns1:DT_output>

                  <UserID><xsl:value-of select=”*/*/AuditUser”/></UserID>

                  <Name><xsl:value-of  select=”*/*/DT_input/Name”/></Name>     

</ns1:DT_output>

  </xsl:template>

</xsl:stylesheet>

Concerning the Integration Directory, a sender SOAP adapter is used and the option Do Not Use SOAP Envelope is enabled.

Also, I added nosoap=true in the URL in soapUI, to allow sending messages in no soap mode. In that case, the SAP PI system puts the complete message in the payload.

After successful tests, I still have some doubts and things I want to clarify…

Open points and doubts

  • What about multi-operation Service Interfaces? I already started with a thread on this topic. I also created a new thread.
  • For testing purposes, I use soapUI, but for real scenarios, Microsoft Visual Studio will be used. What about enabling the no soap mode there? Check out this thread.
  • What about the SAP Enterprise Service explorer for Microsoft.NET, compatible with Microsoft Visual Studio 2012 and 2013? Is there any? For MS Visual Studio 2008, I know there is one.

Once these open points and doubts are cleared out, I will update this blog to have everything in 1 place.

[UPDATE]


Just a tip to quickly test/modify an XSLT mapping and immediately see the result: go to XSLT Tutorial and click on the button try it yourself.

On the left side of the screen, put the XML structure entering the SAP PI or PO system. And on the right side of the screen, put your XSLT mapping code.

Press the button Edit and Click me and see the conversion result at the bottom of the screen.

Special thanks go to Antonio Sanz for helping me out with the XSLT mapping and the scenario.

To report this post you need to login first.

8 Comments

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

  1. Stefan Bosshard

    Dimitri, nice blog – thanks for sharing.

    Do you know, if there is a possibility to access SOAP Header (outside of DynamicConfiguration) within a adapter modul?

    Regards

    Stefan

    (0) 
    1. Dimitri Sannen Post author

      Hi Stefan,

      Use a XSLT mapping. Works fine and you can do whatever you want.

      We now use it and it is very flexible.

      Also, in case of a synchronous scenario, we use it to build up the SOAP header again.

      Kind regards,

      Dimitri

      (0) 
  2. Prajwal Kumar

    Hi Dimitri,

    I have used the option ‘Do not use Soap Envelope’ and used XSLT mapping to read the header values. But got the error “Interface Determination did not yield any actual interface“. Do we need to construct the whole structure (Header + Body) as a new Data Type in PI, to make it work (or) is there any work around to eliminate this error.

    Thanks,

    Prajwal

    (0) 
    1. Sebastian Simon

      Hi Prajwal,

      That typically happens when PO can’t detect the message type from a root tag of the message. As you sat “Do not use SOAP Envelope” the complete SOAP message will be passed into PO.

      Might help if you pass more information how your scenario is constructed.

      There’s different ways to solve that.

      Option A:

      In an Integrated Configuration you might just remove the Software component in the sender side tab and activate it again. It won’t check strictly the message type versus the interface then.

      Option B:

      Use a generic SOAP envelope schema as sender interface

      http://schemas.xmlsoap.org/soap/envelope/

      Hope that helps

                  Sebastian

      (0) 
      1. Prajwal Kumar

        Hi Sebastian,

        Thanks a ton for the reply.

        With option A, when I remove the SC in the sender side tab, I’m seeing that my Receiver Interface(and the op mapping) is being deleted once I save the ICO and getting the error “Specify at least one receiver” and I’m unable to select my op mapping again with this setting as it is not showing my op mapping in the search criteris in the ICO.

        Coming to my scenario, mine is a SOAP to PROXY (Sync) scenario, where in I need to read some of the custom header values from SOAP and pass it on to the PROXY structure. I checked the SOAP Envelope option and wrote an XSLT mapping. My request of OP mapping contains XSLT(1st argument) and normal graphical mapping(2nd argument which maps xslt response to the CRM message type).

        Please let me know if you need any more details.

        Thanks,

        Prajwal

        (0) 
        1. Sebastian Simon

          Hi Prajwal,

          I just tried it again with an ICO where i used this. The “trick” with removing the Software component seems to only work if you don’t use “Operation-Specific” Type of Receiver Determination.

          I configured the whole ICO (with Software component Version), saved it and then went into edit mode and removed the Software component verison, then saved and ignored the popup 😉

          Option B should work in any case.

          Hope that helps

                       Sebastian

          (0) 

Leave a Reply