XML in body of post

I am receiving XML in the body of the request into my service, but I am not able to access it. Should the XML come in through a FORM so that it can be retrieved ?

Any help is appreciated.


Can you elaborate your process of receiving the XML.

Is TN involved ? or Http directly ? or receiving via Email?


Hi, Nagendra.

You are correct. The XML should be posted as a <FORM> element. Something like <INPUT TYPE=TEXT NAME=variablename VALUE=“value of variable”> should work fine.

In your Flow, the name-value pairs will be parsed for you so that you can reference the variables by name. That is, variablename will be an Input variable to your Flow.

Good luck.


There are 2 accepted methods of having documents posted to WM…

  1. HTTP post with a mime type of text/html where the XML is in a name value pair. This has many advantages in that you can debug easier, the variable is available in the pipeline in plain text etc…

  2. HTTP post with a mime type of text/xml where the XML is in the body of the http request. This shows up in the pipe line as a node (document) and is not readily readable. However if you do a documentToRecord it will display as a record. and you can do your mappings as normal.

Most of our services are written so that it can accept input in either format. We had considerable heart burn dealing with multiple vendors and different methods of handling XML.

Hi! Brain,

I have a partner who would like to send the xml in the body of the request message stored in a variable other then $xmldata.
And also the content-type is set to “application/x-www-form-urlencoded”.

Partner needs to send the XML to our TN. Is their any way i can allow TN to recognize such data.

As i understand, In http post, it should have the XML encapsulated inside $xmldata or the content-type should be set to text/xml.

But this both is not possible in my case. As the partner can also not change its configuration due its own constraints.

Please suggest what could be the best possible way to make TN recognize the document. Or is it that we have no alternative.


Write an entry service that accepts inputs that match the names of the fields in the form. Have the partner submit the form to that service. In your service, simply pass the appropriate field to wm.tn:receive.

Hi! Rob,

I had already thought of this process. But my constraint is the partner can hit the TN directly but not to my own WM flow serivce due to security reason. We would like to have the partner hit the TN and then we route it to the flow service as needed. Our TN is, u can say accessible to outsiders.

I would appreciate ur feedback.


Hi Sandeep,

The standard wm.tn:receive service will not be able handle this request. However you can write your custom service which receives as input a contentStream and processes it. This will be able to handle any content type.

  • Rajesh Rao

TN isn’t set up to do this Sandip. If you can only expose the receive service and there’s no other way around it, you’ll have to write your own content handler (much like the built-in one that converts $xmldata to a node). There’s lots of docs out there about how to do this. Your client will have to set a different content-type header from the usual text/xml to trigger the new handler.

“…can hit the TN directly but not to my own WM flow serivce due to security reason.”

There is no additional security risk with going through a front-end service. Set the ACL for your service to be the same as wm.tn:receive. The additional security check that receive does (does the doc sender match the signed on user) will still be performed when your front-end service invokes wm.tn:receive.

Or is there something else that you’re concerned about security-wise?

Actually, TN is outside the firewall which is accessible but not the webMethods developer or my flow service.

Hope i could clarify.

I think there are some basics that we need to cover here.

Do you have two IS boxes deployed? One behind the firewall and one outside? Are you using reverse invoke?

TN is not a stand-alone component. It is basically a package, supplemented by a database, that runs within an Integration Server. You cannot have a TN without an IS.

Developer is not a run-time component. Using Developer you create services that are managed and run by IS. When a service is executed, it runs in IS, not Developer.

Your entry service will be available on the IS box that is outside the firewall. Thus, partners can post to your service just as easily as they can post to wm.tn:receive.

If there is only one IS/TN box, and it is outside the firewall, how is data flowing to get into the protected zone? If you have only one IS box, and it is outside the firewall, and it is accessing resources (database, etc.) inside the firewall, then you may have a security problem.

Does this help?

Asking your trading partners to send to a service other than TN receive is fairly normal practice. For flat file handling, it’s even the recommended method - see the Building Your Network document, appendix B, which describes using a gateway service. If you need to justify using another service to anyone else, pointing them to this webMethods document may help.

Just force your partner to make post direcly to your custom Flow service (set up ACL’s -mostly recommended)and this will help you the logic what ever you are trying to setup say (custom handler).

Skip’s advice sounds reasonable.

Some times things make forceable for mutual understanding between partners and their environment especially while transport process.

Thanks Rob,for the detail checklist.

Hi Guys

i have a question when the partner documents(xml) hits the Trading Networks what happens next can i convert it to any format from the TN or can i store some where in the data base directly.

thanx in adavance


Happy New Year everyone,

Burning question - how do I attach xml file to the http/https service? In the pipeline, I have a record with values and also xmldata file in xml format, so I can use either one…but how? I mapped xmldata to the data-string in the body of http service, but this does not work, because client is receiving xml file with the root tag corrupted…
The services manual is very vague and does not show any examples of how the http post arguments have to be set… Any help will be appreciated.

Best Regards

You mean how to send XML using pub.client:http?
What is the client that is receiving the HTTP message?

It sounds like the client is having a problem parsing the HTTP payload.

  1. Check the HTTP headers that you are setting. Your client probably needs a ContentType=text/xml and may need ContentType=text/xml;charset=UTF-8 assuming the bytes you are sending are UTF-8 and the XML prolog has no encoding entry or the entry defines UTF-8.

  2. Look at all the different “data” fields in the pub.client:http service. They are converted to an HTTP message in different ways. You may want to convert your XML string to bytes using whatever encoding you want and then send the bytes, so you are sure exactly what is in the payload.

  3. Get an HTTP sniffer/snooper and compare what is on the wire to what the client wants.