I am sending a xml doc to TN. But the content-type is set to “application/x-www-form-urlencoded” and the xml is stored in a variable other than $xmldata.
I know that if i set the content-type as text/xml and store the xml in the variable as $xmldata, i would be able to extract the content easily. But due to constraint at my side, it is not possible to change those.
When i send the XML with above mentioned content-type set , i receive the data in my TN. Under the content, the data is in bytes. This selects the default rule and receives it in TN. I am interested to add a doc type and processing rule for this. As the data is received in bytes, i would appreciate what could be the way to write the selection criteria in doc type. When i choose the document in the transaction analysis screen, under the content, i see it as mentioned as “application/x-wmidatabin”. My actual XML lies in a variable say in “temp”.
—“When i send the XML with above mentioned content-type set , i receive the data in my TN. Under the content, the data is in bytes.”—
This above message shows that your xml in TN is not recognizing properly,and showing bytes in content area and that leads to default processing rule.
Make sure xml with proper encoding and appropriate content type.
If you use routeXML or receive service and sending it from developer
the TN Params will show up content-type “application/x-wmidatabin” and content “null” in the pipeline ,even though xml process sucessfully to TN,so ignore these variables and no need to set them explicitly before sending xml to TN.
As recommended in several posts–you should create a custom entry service for your partner to post to. This will give you an opportunity to perform any tweaking to the data that is needed to successfully submit the doc to TN. In this case, you’d call bytesToString, with the proper character encoding (probably ISO-8859-1) and then pass the resulting string to wm.tn:receive. Posting directly to TN has a variety of issues, almost all of which you seem to be running into.
thanx for your input. I understand i have been put in variety of issues and i had post many requests, just for the reason that i am trying to hit the TN directly and not via a custom flow service.
I think i have to make sure that, for non-xml documents or with a different content-type, hitting the custom flow service is THE solution.
No worries about the number of posts. Thats what these forums are for.
IMO, a custom service is the right way to go for all posts, not just non-XML. This is the approach we follow for our IS/TN integration projects with each of the clients we work with. Keep in mind that the entry service isn’t a replacement for wm.tn:receive, but rather it simply front-ends receive, giving you a spot to perform any special handling that may be need before turning the doc over to the TN services. It also provides an opportunity to perform additional error checking/reporting.
