We have recently upgraded our server from version 6.2 to version 8.2.2 and after that there are problems with one of our customers posting xml data to our servers.
The service exposed customer is a wrapper to wm.tn.doc.xml:routeXml; receives an XML via http post and routes the document to TN. in 6.5 it was working perfectly and in 8.2 it stopped working (only for this specific customer and customer confirmed no changes at their end; the same request routed to 6.5 server works fine).
When we checked the pipeline in 6.5; we can see the below list of variables placed in pipeline of the service for the http request
$xmldata ------> String with the complete XML string
$xmldataList —> StringList with complete XML string in position 0
node ------> XML node (Our service processes the node and ignores the rest)
In 8.2 there is no data available in pipeline most of the time. or sometimes a httpContentStream which when we try to restore it does not work.
Have any one faced this kind of issue with 8.2.2.
Any changes to http request handling behaviour in 8.2 vs 6.5?
Hi Deepan,
It can either be “$xmldata” or “string” in 8.2 as well… No difference has happened with the signatures…
But remember, $xmldata will have the data as xml node format… which means, you will have to use xmlNodeToDocument service to convert it to IS doc… I think this node object acts as a stream hence u r not able to save it in pipeline… Map $xmldata to node input in above service and try converting it to IS document.
Hi Senthil,
Thanks for your reply; however as i mentioned in 6.5 we can see the below placed in pipeline by the server 1. $xmldata ------> String with the complete XML string 2. $xmldataList —> StringList with complete XML string in position 0 3. node ------> XML node (Our service processes the node and ignores the rest)
however we do not see any data being placed into pipeline in 8.2.2
I suppose we can save the pipeline containing streams using pub.flow.savePipeline (in memory).
No… You cannot save this stream in file or in memory… If you still want to see the content, use streamToString service, and then invoke savePipelineToFile service… Later disable all the steps, and keep restorePipelineFromFile service, or directly check the file in the filesystem.
ok. the problem is not with saving pipeline (it could be posted as stream/bytes). this what my pipeline looks if restore in 6.5.
[ATTACH=CONFIG]872[/ATTACH]
however i do not see any data being placed in pipeline for the same service in 8.2.2. so document gets routed to TN. I suspect a change in behaviour with respect to http request handling in 8.2.2; any pointers would be helpful.
You may want to read the section “Submitting and Receiving XML via HTTP” in the Developer Users Guide and the documentation of the server parameter watt.server.http.xmlFormat in the Adminstering Integration Server document. Watch out for the new xmlFormat argument you can put into the URL. The way I understand it, is that at least as of version 8.2SP1, you can get only one of the three: node, xmlStream or xmlBytes.
Hi RMG, We receive this xml from one of our customer; content-type is set to text/xml. At this moment i’m not sure of input type or the program being used to post. we are waiting for some additional information from customer.
They send to a wrapper service which in turn invokes TN service to route the document to TN.
Also the other thing i have noted just before; when we receive the request from the customer the pipeline has variable contentStream with com.wm.net.HttpInputStream as value (in MWS monitor).
Though i have reason to suspect customer might not have set Content-Type to text/xml; the same requests works very well in 6.5 server which gets node in pipeline.
If the request works in 6.5 i would expect it to get processed in 8.2.2 as well. Am i overlooking something here?
I have verified the server setting as suggested by Thomas earlier, it is set to node (watt.server.http.xmlFormat=node) and all other customer requests are processed well.
Looks like you should get out a http sniffer. TCPMON from apache.org is the Tool of Choice. To use ist, you must either convince the Client to send requests to a different port or to tell the server to release it’s port and use a different one. TCPMON will then work as plumbing between the two ports and will nicely display whats being sent and received. You even have the chance to edit a recorded request and to resend it. I always have this one in my toolbox. Please keep us posted how this resolves.
I think you cannot expect compatibility of buggy behaviour.
Nothing that comes to my mind. But i would expect some porting effort going from 6.5 to 8.2.2 and skipping 2 major releases: 7 and 8.0. It’s my personal opinion that 8.2 should have been called 9.0.
at this moment we chose to fall back to 6.5, not because of this issue but for other stability issues around terracotta clustering…
we plan to do some more tests and will update the forum in some point with solution / root cause.
thanks for all your support and information
