Part of the xmlns disappears from the I.S. SOAP response


I’m trying to help a customer with an issue they are having with namespaces when using HTTP/SOAP calls to the Integration Server (v 6.5.) The high level problem is: part of the namespace disappears from the SOAP response.

Below is a snippet of one of WSDL they use when making the SOAP call to I.S. (from IBM Datapower appliance). When they receive the SOAP response from I.S. part of the namespace qualifier is missing.
For example, in the wsdl below, “bim” is missing in the response from “xmlsns:bim”, “ifx” is missing in the response from “xmlns:ifx”, “custprefix” is missing in the response from “xmlns:custprefix” (i.e. the text following the colon is not in the response message). I think you get the picture. This problem occurs through the response message.

Now I’m just started investigating the problem but I wanted to find out if anyone in the wmusers community has come across this problem (and hopefully have a solution). This problem is a very high priority for them (and now for me). There is a service request opened with wM Support on this problem and is currently being investigated by them and me. To get around the problem the customer’s webMethods developers came up with a work around. The problem with the work around is that it costs them a lot of extra time in development, testing and maintenance, and is putting one of their key projects at risk.

Note: the customer uses a custom SOAP processor instead of default and RPC.

Any feedback is appreciated!!

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

<wsdl:definitions xmlns:wsdl=“
xmlns:xsd=“XML Schema
xmlns:tns=“” name=“CUST_bsBranchInformationManagement” targetNamespace=“http:///”>
<xsd:schema xmlns:xsd=“htp://” targetNamespace=“http:// /EnterpriseManagementBusinessSupportAdministration/schemas/BranchInformationManagement/1” xmlns:bim=“http:// /EnterpriseManagementBusinessSupportAdministration/schemas/BranchInformationManagement/1”
xmlns:custprefix=“http:// /allcompetencies/schemas/allservices/1”>
<xsd:import namespace=“urn:ifxforum-org:XSD:1”/>
<xsd:import namespace=“http:// /allcompetencies/schemas/allservices/1”/>
<xsd:element name=“BranchSearchCriterias”>
<xsd:element ref=“ifx:BranchId”/>
<xsd:element ref=“custprefix:EffectiveDate” minOccurs=“0”/>

                    Note: there are 477 lines in total to this WSDL



Are they setting the namespace on the response? On the xmlDocumentToString, they should be setting the prefix/namespace association via the nsDecls parameter. That usually does the trick.

Can you post the SOAP Response the IS server is generating?

Hi Mark,

Thanks for the response. I’m just starting to look at their packages/services and will check out the xmlDocumentToString.

I’m still trying to get the SOAP request and response message from the customer.




This does not ring a bell. My projects have all used namespaces with prefixes.

There may be some confusion in that there are several equivalent ways of namespace qualifying an XML document. Just because a specific prefix is associated with a namespace definition in the WSDL does not mean the provider of the service has to return a response using those prefixes. The elements should be namespace-qualified using the namespace definition specified in the WSDL (actually in the types section of the WDSL or its imported schemas).

Hard to tell just from the WSDL fragment, but so far this doesn’t sound like a defect.

Mark C

Thanks Marc.

I have been doing some investigation into their services and my feeling is the response message is not being formatted correctly prior to running it through the documentToXMLString service.
As you know there are different ways to get the xmlns attribute into the response xml (setting nsDecls on input to doc-to-xml-string service or using @xmlns in the input document). The difference is that when using nsDecls, xmlns gets inserted into the top most element of the XML String, while @xmlns lets you specify where you want xmlns inserted in the XML String.

From what I can tell, the flexibility and capability exists within wM I.S. services to produce the required response. I haven’t proven if it’s a problem with wM or with a “flaw” in the coding.