Issue with namespace prefixes in WSDL

Hi All,

I need some help in understanding the webservices. we got a wsdl from external trading partner. When we import the WSDL. It created the connector and all the docTypes that were created has ns1: in front of each document and each fields.

Now, we wrapped this WSDL in our IS service. The IS Service has inputs similar to the WSDL connector ( Means we’re just referencing to the documents created ). Here the next thing is we exposed our service as webService to another TradingPartner2.

Now, when the tradingPartner2 invokes our service. we’re receiving input data without ns1: infront. So, webMethods is not able to map.

What could be the cause for this issue. I cannot create a input document without ns1: because there are 1000’s of fields. So, we’re just using the same webservice inputs that we’re invoking from our IS service.

Any thoughts? Thanks in Advance!

I guess it should be simple…:slight_smile:

Attach your WSDL file in the post. Let me have a look at that once.

I think its default that ns1: will appear whenever there is namespace.

Here is the WSDL.

Again, when I run this webService in soapUI. I am getting proper results. When I look at the save pipeline, All the inputs have ns1: in front Whereas when the other trading partner is trying to invoke, the savepipeline do not have ns1: infront.

Thanks.,
TestWSDL.wsdl (16.6 KB)

The attached WSDL file has the namespace xmlns:dx=“http://fedex.com/ws/addressvalidation/v2 :slight_smile:

I am not sure whether you can re-write your WSDL (removing the namespace) not a good idea but if you think ns1: is causing the issue because the generated doc types has something like

docTypes:ValidateAddress_PortType_ValidateAddress_Input/tns:AddressValidationInput/AddressValidationInput/AddressToValidate/ns1:AddressId

Try using the below services to remove ns1: and just make it
docTypes:ValidateAddress_PortType_ValidateAddress_Input/tns:AddressValidationInput/AddressValidationInput/AddressToValidate/AddressId

WmPublic/pub.document:documentToXMLValues
WmPublic/pub.string:replace (Here search string=ns1: replace string=null
WmPublic/pub.document:XMLValuesToDocument

Map your document (results) with ns1 to the document without ns1. Doing this tradingPartner2 can invoke your flow service without ns1.

I hope this helps let me know your results.

1 Like

Hi Mahesh,

Thanks for the response, but the issue is that when TradingPartner2 is invoking our service. we’re receiving the input without ns1:.

Example: Input is defined as ns1:AddressID but we receive Input as AddressID.

So, Even if I try to search for ns1: , it will not make any difference. Also next thing is that I need to map this AddressID to the connector service which again has ns1:AddressID as its input.

So, its other way around. I need to add ns1: for each input tag I get from TradingPartner2.

The reason all you document types and fields in each docType contains the namespace prefix alias is because the elements in the WSDL are declared with the attribute form=qualified. To prevent the prefix alias from being added to each field in the docTypes, modify your WSDL before importing it into webMethods. Modify the value of the attribute from qualified to unqualified. Since the default value is unqualified, you could also simply just remove the attribute form=qualified if you wish. This would have the same effect as changing it to unqualified.

This modification should not cause problems and the services should work exactly the same…I think. And, you get rid of that ugly prefix alias in from of all you fields in the docTypes.

1 Like

Hi Dcova,

Thanks for your response. Yes. by making that attribute form=unqualified we can get rid of the ns1.

Regards,
Kumar.

Is the issue resolved?

Can you ask your partner 2 to add namespace ns1 if that is possible for them. If not we need to implement some logic in webMethods.

The desribed solution only works if there is only one namespace defined in the WSDL.

As soon as the datastructure uses multiple different namespaces the prefixes are required to distinguish which elments descriütion can be found in which namespace.

Regards,
Holger