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

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)

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?

Thanks!
Deepan

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.

-Senthil

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).

Thanks
Deepan

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.

-Senthil

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.

Also did you set the Content-Type=text/xml while posting it and what is the input type you are using?

HTH,
RMG

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.

OK keep the forum posted:

Are they sending direct to TN receive or invoking a customer service in turn routes to TN?

OK keep the forum posted:

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.

Though i have reason to suspect customer might not have set Content-Type to text/xml

Yes it could please check with the customer on this and determine next:

822 vars should work same as 6.5 posting…

Hi Deepan,

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.

mit freundlichen Grüßen / with kind regards

Thomas

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.

Thomas

9.0 will be coming in FY13…and you will say 10

If not 11…

Thanks Thomas:

What for?

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

I am sure you brought this to the attention of product support?

Are you not satisfied with Coherence default clustering?..Do you have terracotta licensing?

Just curious:

HTH,
RMG

coherence is not supported on VM I believe, one of the reasons SAG support recommended Terracotta; yes we do have license for Terracotta for IS clustering.

Regards
Deepan

Got u…Thanks for the update:

-update for the issue with http requests–
customer was sending XML as URL encoded which was not recognised by 82 IS, customer agreed to change in their side to remove the url encoding and test went ok.
other way we could resolve this is write a custom content handling service, extract the xml string from contentStream then decode the url encoding to get the xml string.

Strange, that same request was accepted in 65 but not in 82, may be we missed some server settings or parameters??

Nope…but they shouldn’t be changing simple/standard stuff:

Nope…but they shouldn’t be changing simple/standard stuff:

What URL encoding?

I have no chance to look at how customer is sending data. however this is my observation

1. The xml sent by customer is URL encoded - %3C for <, %3E for < etc…
2. This request when sent to 65 server it is recognised and IS places “node” in the service pipeline
3. When sent to 82 server, this is not recognised and we get “contentStream” in pipeline; when converted to string, we get the URL encoded XML.

I wish nothing changed in the standard stuff; still wondering any settings or other parameters causing this.

Make sure they set the content-type=text/xml while sending HTTP post string data…If not ask for more details on their methods:

As far I know no standard settings changed the receiving style: