When inserting XML inside a SOAP element, we are seeing unexpected encoding of special characters. Tracing through the flow, the xmldata string is properly encoded until it reaches the soapRPC service. However, once it reaches the soapRPC service and the message is assembled/sent, HTTP capture indicates that the intended XML data …

<datablock>
<myxmlpayload>AT&T</myxmlpayload>
</datablock>

… turns into …

<datablock>
<myXMLpayload>AT&T</myXMLpayload>
</datablock>

To be clear, this is not an issue with the documentToXMLString service (yes, encoding equals false). This appears to be an issue with the soapRPC service. Please let me know ASAP if anyone experienced a similar issue or has a possible resolution. Thanks!!!

In the documentToXMLString set enode=true for handling special characters.

As I said, the issue is that we don’t want it to encode special characters. Looking at the trace, the xmldata produced by documentToXMLString contains the correct result. However, once it passes through the soapRPC procedure, it contains the encoded special characters and the message is rejected by the receiving system.

Does anyone know why XML tags in a SOAP payload are encoded ( e.g. < turns into < ) in the soapRPC service? This is causing major issues for us and should be relatively easy to fix.

Could it be the SOAP service definition being interpreted by the soapRPC service and making the conversion? Can I override this definition?

Mark,

Since you haven’t gotten a response on this for a few days, just thought I’d offer another approach…

If you have the WSDL for the SOAP service you are trying to call, you can use it to generate a web service connector. I’ve used this to call .Net SOAP RPC services without any problems.

I appreciate the response. Turns out webMethods is encoding properly given the WSDL. The bottom line is that string datatypes should not be used to store complex types. Therefore, we’re pursuing a change of WSDL.

I’ve had the best results with using strings for the leaf nodes (elements) within a structure with any complexity needed. This is a lowest common denominator approach, but it avoids dealing with compatibility issues. I try to avoid recursive elements for now because of webMethods limitations at least as of 6.1. This can be a challenge for data structures like Bills of Materials.

To get the highest level of abstraction available, on the webMethods side, I use web service connectors. On the .Net side, I use web references. This eliminates the need for any logic to handle the underlying XML (i.e. serialize/deserialize) … I just access the document/object members.

Regards

One other item to consider, when you use Soap RPC you have very little control over how IS performs the mapping from XML to a IS document type. If you use document/literal web services you have to explicitly convert the soap request into a document type either in your flow service or in a custom soap processor.

While the document/literal style creates a bit more work in IS, it also allows you to operate more directly on the contents of the soap request to handle situations like this or to do value added things like process WS-Security tokens from the soap header.

Lately, I’ve been creating a single custom soap processor that handles processing the soap request in the way I want it to be done including creating document types from the payload, looking up the service to invoke using a method of my choosing and then invoking the service either on the same IS or a remote one. Takes a bit of work to get right, but makes adding doc/lit web services a snap from then on.

Mark

Dear Mark G. Kobe

I am not sure if this will solve the issue .Try encoding the XML message with these tags

<![cdata[>

We had similar issues while exchanging the messages with WebSphere .

Srini