I have a problem converting a SOAP message into a webMethods document.
Below is a snippet of the XML: soapenv:Body
<ns1:addNumbersRequest xmlns:ns1=“urn:web.text.service” soapenv:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”> <ns1:numbers xsi:type=“xsd:string”>1|2|3</ns1:numbers>
</ns1:addNumbersRequest>
</soapenv:Body>
Using the above xml, the document generated is malformed.
However when I convert the line: <ns1:numbers xsi:type=“xsd:string”>1|2|3</ns1:numbers>
to 1|2|3 The result will be OK.
Please see doc.jpg(correct) and doc2.jpg (malformed)Any idea how to get the conversion working without changing XML data?
It’s not “malformed.” The conversion is working properly. The numbers data with the xsi:type attribute is being represented properly with an attribute field and a body field.
I agree with Rob, that the resulting doc is not “malformed”.
Your example seems a bit odd to me. First, if you are using a document / literal style of SOAP message, you don’t typically see the encoding information (e.g. xsi:type=“string”) in the request message. On the other hand, if you are using rpc / encoded you would not need to work directly with the soap request to extract its payload as this is done for you by the IS soap-rpc processor.
Second, if you had used the pub.soap.utils:getBody built-in service to get the body of the soap request as an IS node object, then you could have simply converted that to a document using pub.xml:xmlNodeToDocument without needing to work with the XML string.
So, the generated doc is correct, but your test is confusing.
my webMethods Integration Server (SOAP server) is receiving SOAP messages from 2 different clients: another webMethods (using connector) and another middleware product. And yes, I have used the getBody and xmlNodeToDocument to extract the argument from the SOAP message itself.
The XML below is the SOAP message I receive from a webMethods connector: soapenv:Body
<ns1:addNumbersRequest xmlns:ns1=“urn:web.text.service” soapenv:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”> 1|2|3
</ns1:addNumbersRequest>
</soapenv:Body>
I do not have any problems executing the SOAP server service using the SOAP message above, as webMethods connector does not generate "xsi:type=“string”. The document generated from the SOAP message above would be like doc.jpg (please see attachment)
However, the other middleware product produces the following SOAP message: soapenv:Body
<ns1:addNumbersRequest xmlns:ns1=“urn:web.text.service” soapenv:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”> <ns1:numbers xsi:type=“xsd:string”>1|2|3</ns1:numbers>
</ns1:addNumbersRequest>
</soapenv:Body>
And using this SOAP message, webMethods fails to execute, since the xmlNodeToDocument generates a document that is different from the document generated from the first SOAP message. The document generated for this SOAP message is doc2.jpg (please see attachment)
By right, webMethods should be able to execute both SOAP message without any problems. When I write the SOAP service in POJO, I do not have any problems in processing both SOAP messages (a.k.a. they are treated as the same request)
What should I do in webMethods to be able to accept both SOAP messages and process them without errors?
Currently, I need to create 2 separate services: one to accomodate the connector SOAP client and another to accomodate the SOAP message being passed by another middleware product.
Messages 1 and 2 are semantically equivalent. If you populate the xmlns parameter with the correct namespace and a prefix of your chosing you can process either. You may find it easier to use pub.xml:queryXMLNode rather than pub.xml:xmlNodeToDocument.
I’ll repeat my question. Are you using exposing your IS service as SOAP-RPC or SOAP document / literal. If the former, then the endpoint URL should be http://hostname:port/soap/rpc and you will not manipulate the soap request directly.
I am using SOAP document. So, I need to acquire the argument manually. Do you have a sample SOAP service in webMethods that could accept both SOAP messages?
If you use pub.xml:queryXMLNode and populate its nsDecls parameter with the namespace “urn:web.text.service” and a prefix of “ns1”, you should be able to use the same XQL query string to extract the “numbers” variable whether it is prefixed or not. See attached screenshot that shows and example that correctly parses both soap requests.
Did you create the WSDL that these two SOAP clients are using to generate the code that creates these two messages? Perhaps there is something in the wsdl:types section that is causing the type encoding information to be added to the second example or maybe its just an old version of a tool. If you created an XML schema to describe your input (request) message, but that schema does not specify the “xsi:type” attribute, then the input message in the second example is invalid and would fail XML validation.
The other middleware that I use as the SOAP client is not using the WSDL (yea I declare it myself in XML). The middleware only provides a way to define the WSDL if using X-Fire technology. Or, if using AXIS, I need to retrieve the WSDL on the fly from a flow service, which I think is impossible. Normal web service would be able to generate the WSDL by appending the ?WSDL at the end of the url address. Btw, thanks for your sample. It helps me to do a work around:)
Well, if you place your WSDL in the \pub folder of an IS package, you can access it via a URL although not with the “?WSDL” URL parameter. BTW, IS 7.1 will support hosted WSDL’s when it releases later this year.
If you are declaring the XML, seems like you should be able to remove the type encoding attributes from the soap request.
