wM IS 7.1.2 server issue - Handling XML Messages

[hari_ngs]

I am facing a strange issue in wM 7.1.2 :

I am posting a SOAP message to my flow service using SOAPUI. The SOAP:Header has which are qualified with the namespace prefix “asa”.

When I am receiving the message using “getHeaderElement” using a document called “Header” to cast the output in the way I want. The “Header” document has the namespace prefix of “HDRDOC1” corresponding to the namespace represented by “asa”.

But when I am printing the output of “getHeaderElement” using “debugLog”, I find that webMethods has converted the “asa” namespace prefix for certain elements in the message header correctly to “HDRDOC1” . But some elements having “asa” has been converted to the prefix “ser-root” ( which I have not specified at all anywhere - not sure where it is coming from).

Please let me know what the issue is !

[DevNull43]

Take a look to getHeaderElement service documentation, you can map namespace name with localname.

Also take into account this known issue documented in [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuite7/readme/IntegrationServer_7-1-2_readme.pdf[/url]

1-1VFN9Q
A SOAP Header that is sent in the SOAP request is not decoded properly.
When decoding the SOAPHeader and converting it to an IS document type, the SOAP coders do not work
correctly if the header contains a top-level simple type element with a name that matches the local name of
the header QName. In this situation, the coders generate an empty body and the data is not present in the IS
document. This issue affects both the “SOAPHeaders in the pipeline” feature and the
pub.soap.handler:getHeaderElement service.
To work around this issue, ensure that any SOAPHeaders to be processed by service-based header handlers,
or used with the “SOAPHeaders in the pipeline” feature, do not contain any top-level simple type elements
with a name matching the localname of the SOAPHeader.

I managed to have nightmares with webservices

Hope this helps.

[hari_ngs]

Thanks…that was helpful. I got it fixed by removing the changing the name of the top-level element to one different from the localname of the SOAPHeader