I am using webMethods Integration Server v 6.1 SP1 w/ Fix 54, 55 & 61.
I created a custom SOAP processor. I am going to publish data from the SOAP request to my broker. The problem I am having is that I can’t extract XML data from the SOAP request my processor is receiving. I am using pub.soap.utils.getBody to get a node from the soapDataRequest without a problem. When I use pub.xml.queryXMLNode using body as input, I get unexpected results.
I used tracePipeline to see what is available. Here is my server log:
My guess is the processing instruction (<?xml version=“1.0” encoding=“utf-8” standalone=“yes”?>), is causing my problem. I don’t know why XML data starts displaying as < > instead of <>.
I might be able to transfor the XML coming into my SOAP processor since data is originating from an application within my enterprise. I think the vendor offers the ability to transform XLM data using XSLT.
Can someone offer a debugging technique to get me over the hump on this one?
Writing my thoughts on this thread has been good therapy. I have been stuck on this for half a day, and I have my answer.
I save the soapRequestData and soapResponseData objects as Strings by doing a savePipelineToFile.
I created a copy of my custom processor and restored the pipeline from file. From there, I do a getBody and queryXMLNode. The result of my query, a String, is then transformed to an XML node using xmlStringToXMLNode. I do a second query that allows me to query the data starting with the second XML processing instruction.
I believe Mark Carlson has posted something similar in the past, but I couldn’t apply the ideas until the proverbial lightbulb went on.
Looks like the “postxml” element contains a single element called “xml” which contains a blob of encoded xml. Can you extract the contents of the postxml\xml element in an string that could be the input to service to convert it to a document?
If you have control over the application generating the soap message, I would strongly suggest that they not send URL encoded xml blobs in a soap message. That may be easy for them, but is pretty non-standard. You can make it work if you have to, but it’s pretty ugly.
An easier debugging technique is to just create a test driver for your custom soap processor. The test driver builds the soap message either starting from a document type or from an example soap message using pub.soap.utils:stringToSoapData.
After building the soapData object, just invoke your custom soap processor service mapping to that service’s soapRequestData object input parameter. That will allow you to trace the execution starting in your test driver and stepping into your custom soap processor service.
do a pub.xml:xmlNodeToDocument->pub.xml:documentToXMLString->pub.xml:xmlStringToXMLNode after the pub.soap.utils.getBody and then you can start using the output Node of the pub.xml:xmlStringToXMLNode service to do a pub.xml.queryXMLNode .
.