Namespace prefix in SOAP Elements causes problems in XI

[Former Member]

Hi guys,

I'm using code generated by NW Developer Studio for use inside Portal components acting as a web service consumer. The problem is that the code generated includes a namespace prefix for each element in the body of the message, but XI doesn't like the namespace prefixes and throws back a DeliveryException.

The SOAP message created by the generated NWDS code is:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wn3="http://www.w3.org/1999/XMLSchema" xmlns:wn2="http://www.w3.org/2000/10/XMLSchema" xmlns:wn1="http://www.w3.org/2001/XMLSchema" xmlns:wn0="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wn4="http://allieddomecq.com/poc" xmlns:tns="http://allieddomecq.com/poc">

<SOAP-ENV:Body>

<wn4:PortalSOAP_MT_Request>

<wn4:CustomerIdentifier>0001000064</wn4:CustomerIdentifier>

<wn4:SalesOrganization>ES50</wn4:SalesOrganization>

<wn4:SystemIdentifier>R3D</wn4:SystemIdentifier>

</wn4:PortalSOAP_MT_Request>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The problem is the "wn4" prefixes on the CustomerIdentifier, SalesOrganization, and SystemIdentifier tags. When we send the soap request from XML Spy without the prefixes, the response comes back OK with the expected data.

I've had a very good look around the generated code - the serializers for creating the soap request - but could not find what exactly might be changed to leave off the prefixes.

Alternatively, is there something I could ask our XI consultant to do, to make his component accept the request with the redundant prefixes in the tags?

Many thanks for any advice/help,

Laura

[stefan_grube]

What exactly is the error, when you send the message? The namespaces should not lead to any trouble.

Where do you send the message to? Do you use mapping?

Regards

Stefan

[Former Member]

Thanks for all of your replies. Our XI consultant Ajit Thomas solved this one as follows:

"The SOAP call that comes in defines the elements of the Data Type with an explicit namespace definition eg:

<ns:CustomerRecord xmlns:ns="http://company.com">

<ns:CustomerNumber> </ns:CustomerNumber>

<ns:CustomerDetails> </ns:CustomerDetails>

</ns:CustomerRecord>

And wasn't recognised by the XI mapping tool. To get around this problem, I created an external definition which contains these explicit namespace definitions, and used that instead of the DT we created in XI. The mapping now works correctly."

[Former Member]

I'm facing the same issue with SOAP in NWDS adding prefix without namespace in my request and XI complaining.

Is there any other way to solve this problem ?

Thx,

mejj

[Former Member]

> And wasn't recognised by the XI mapping tool. To get

> around this problem, I created an external definition

> which contains these explicit namespace definitions,

> and used that instead of the DT we created in XI.

> The mapping now works correctly."

I've the same problem and I solved it with Lauras work around. But I didn't like this solution. I define interfaces and create a service, I generate a WSDL with the Integration Builder (configuration) and after that I have to re-import my own WSDL in Integration Builder (design). Isn't a little bit strange?

[Former Member]

Hi Laura,

you have to realize that the two documents

<ns:CustomerRecord xmlns:ns="http://company.com">

<ns:CustomerNumber> </ns:CustomerNumber>

<ns:CustomerDetails> </ns:CustomerDetails>

</ns:CustomerRecord>

and

<ns:CustomerRecord xmlns:ns="http://company.com">

<CustomerNumber> </CustomerNumber>

<CustomerDetails> </CustomerDetails>

</ns:CustomerRecord>

from an XMl point of view have totally fifferent structure. Thus, a mapping which is able to deal with the first structure will fail for the second and vice versa.

Surely, both structures somehow can carry the same information, but they do this with different languages (Maybe you can compare this to the fact, that you may deliver the same information in English or in German language).

When you model the structure in Integration Repository using datatypes and message types (what I think you did), you will always get a structure that looks like the second one. This is just a convention (like the convention that all information in this forum should be presented in English). When defining a message mapping for this structure it also relies on this fact and thus will not understand the other kind of document.

External Definitions are more flexible. They are also able to understand structures that are modelled the other way. This greater flexibility is due to the fact that External Definitions were designed to understand structures that come from an external world where different conventionts might be used.

To come to a conclusion: If the structure you have to deal with has been defined externally then it is not intended that you model it inside the Integration Builder using datatypes and message types. In this case the external source should provide a description of the message as XSD, WSDL, or DTD. You upload this as External Definition, and everything works fine.

If you have designed the structure yourself, you can model it with datatypes and message types. But then you will always get a structure which looks like the second one. In this case you should make sure that all other participants in the game also stick to that structure. Then everything will be fine, too.

Greetings Stephan

[Former Member]

HI Laura,

try adding the below to the SOAP Envelope (after the last namespace, before tag closes)

elementFormDefault="qualified"

Hope this helps

Regards

Vishnu

[Former Member]

Hi,

I suppose the problem is with the XML namespace of the MI and not with the prefixes (w4:).

So in the sender SOAP adapter communication channel, in the <b>default XI parameters</b>, specify the name of the <i>Interface name and Interface namespace</i> to which data is being sent.

Hope this helps.

Cheers,

Siva Maranani

[Former Member]

Hi Vishnu,

Unfortunately this does not solve the problem for us, when editing the soap envelope in XML spy.

Anyway it would be preferable to change the Java serializers generated by NW Developer Studio, which then creates the soap envelope.

Thanks for your reply,

Laura

Message was edited by: Laura Re