Currently we send BizDoc to partner by invoking wm.tn:receive service.
However, we don’t plan to use TN on our side while the partner still uses TN to accept msg from us.
We cannot use tn services or BizDoc.
So, I was thinking we could use pub.client:http service and provide the url to invoke wm.tn:receive.
The receive service takes a node and TNParams as input.
I tried converting BizDoc into string and to node and map it to the tn:receive’s node argument.
I got 200 http response, but the body content had “Bad Request” message.
What xml format (before converting to node) does the tn:receive expect in order to successfully process the request?
What i am saying applies to all service invocations, not just tn:receive. tn:receive expects a node (or ffdata or edidata) and an optional TN_Params document.
To invoke a service with a node as input, just put the XML data into your HTTP request and send it. If you want to pass TN_Params as well, you will have to resort to use multipart encoding (cf some article about content-type=multipart/related;boundary=“xyz” on the WEB. I am not sure, if it is possible to send in an IData (content-type to use, encoding etc), which would be would become your TN_Params, maybe someone else can help.
Probably your best option is it to create a whopper service, that has a simple interface, which in turn calls tn:receive for you.
There is an article in the Knowledge Center about not exposing wm.tn:receive directly. I’d recommend that you encourage your partner to follow its advice.
“I tried converting BizDoc into string and to node and map it to the tn:receive’s…”
If you’re planning to not use TN then I’d suggest to not try to attempt to “convert” a bizdoc to the XML string (there is a service to get the payload of a biz doc, but since you’re not going to be using TN, it is immaterial). It’s a dead-end for you.
Just focus on creating the XML string in the usual manner and send it to the partner service using the HTTP service as rmg and Thomas suggest. Be sure to set the content-type header as rmg points out.
I wouldn’t mess with trying the multi-part approach. You don’t (or shouldn’t) need to do that.
Again, since you’re not going to be using TN on your side, don’t work to try to “convert” the bizdoc to an XML string. And I wouldn’t try to set TN_parms. That’s something that your partner should not be exposing to outsiders.
But if you insist on going down a path that you indicated you’re going to abandon, then call wm.tn.doc:getDeliveryContent. If the bizdoc was created from an XML submission, then the delivery content will the byte array of the XML doc. Pass that to data/bytes and set the content-type header to the value returned from getDeliveryContent.
When you switch to not using TN, then simply create the IS document that is needed, then pass that to pub.client:http in the document input. Or use pub.xml:documentToXMLString and pass that to data/string. Add the key “content-type” with a value of “text/xml” to the headers.
In other words, pretend you have no idea that your partner is using TN. Treat them as though they are a plain ol’ server that accepts XML posts.
