XI adds SAP headers to SOAP response

[Former Member]

Hi

There is a simple case where XI receives a SOAP request from an external system. Based on information in CRM a Business Process creates the answer/response and when it is send back to the SOAP client ... there are strange elements in SOAP header from http://sap.com/xi/XI/Message/30 namespace. The worse thing is that some of these header elements have SOAP:mustUnderstand="1"

What's the point? Why should external systems care about some vendor-specific headers?

So the question is: is there a way to make SOAP adapter to not add these elements (ReliableMessaging, HopList, Diagnostic, Main) into response header when it is sent back to the client?

[former_member391604]

Hi Heiko,

An easy way to manipulate SOAP header fields without having to use an adapter module or change existing interface and mapping definitions is to use the "Do Not Use SOAP Envelope" option and add an additional XSLT mapping as a second mapping step in the inteface mapping.

The XSLT mapping could be as simple as this

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

<xsl:template match="/">

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Header>

<!Put your header mappings here>

</soap:Header>

<soap:Body>

<xsl:copy-of select="/"/>

</soap:Body>

</soap:Envelope>

</xsl:template>

</xsl:stylesheet>

Put the XSL file in a zip file and upload as an Imported Archive.

In all your Interface mappings you add the XSLT mapping you just created as a second mappingstep.

rgds Johan Göthberg

[stefan_grube]

That should not happen.

Which parameters have a set in the SOAP sender channel?

Regards

Stefan

[Former Member]

The sender SOAP channel has the following options checked:

• Keep headers

• Use encoded headers

• Use Query String

We need to use the keep headers as there are some other header elements. But we manipulate with these using a Java module that has been added to the channel.

I am not sure about other options.

An example shorter unwanted element. The most terrible thing is that mustUndesrtand is true. God knows why :S

<sap:ReliableMessaging xmlns:sap="http://sap.com/xi/XI/Message/30" SOAP:mustUnderstand="1">
  <sap:QualityOfService>BestEffort</sap:QualityOfService>
</sap:ReliableMessaging>

Thanks for any ideas

[stefan_grube]

The meaning of 'keep headers' is different, as you want to use it.

You need to use the SOAP adapter in no-SOAP mode. That means, you check the parameter 'Do Not Use SOAP Envelope

' (all other parameters are unchecked) and deal with the SOAP envelope in the mapping.

Check this document for further information:

https://websmp207.sap-ag.de/~sapdownload/011000358700002953992006E/HowToUseSOAPAdapter.pdf

Regards

Stefan

[Former Member]

Hi

Thanks for the reply.

Actually I am not trying to make use oh the keep headers parameter. It works as it should. Strange thing is that XI expects every SOAP client to be a SAP system. Frustrating isn't it?

Ok. I was thinking about No-soap option also. This would mean:

• importing SOAP-ENV and SOAP-ENC namespace element into XI

• changing all existing message types

• (the most important) reimplementing by click-and-point all mappings. Can you suggest a way how to do this without the need to reimplement all mappings?

If I change a higher level item in the message then all mapping rules for lower level elements are lost. And as creating the no-soap message deal with the highest level possible then nothing of my mappings remain. And I have a good hundred of them.

So any suggestions?

[stefan_grube]

When you really need entries in your SOAP header (maybe you check that point first) there is no other way to do this in mapping.

When you do not want to recreate your mappings, you can add a second mapping step with a simple XSLT mapping wich just adds or removes the SOAP envelope and leaves the rest of the message. (This can be done with the XSLT copy function).

Regards

Stefan

[Former Member]

Hi

> When you do not want to recreate your mappings, you

> can add a second mapping step with a simple XSLT

> mapping wich just adds or removes the SOAP envelope

> and leaves the rest of the message. (This can be done

> with the XSLT copy function).

Could You be more specific? You mean in interface mapping there should be such a second mapping? An example or something similar?

Sounds interesting and promising...