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?

Joykola,

can you let us know after converting the bizdoc to node to which data argument you are mapping the node in pub.client:http service?

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.

Thomas

You can send $xmldata or xmlstring/bytes/stream with headers/content-type =“text/xml” to the tn:receive via http that should work fine.

Did you try with the above settings above?

HTH,
RMG

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.

data/bytes

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

Hi RMG,

maybe you know: How do you send in $xmldata and an IDoc for TN_Parameters using http?

Thomas

I will try the Multi-Part option. Thanks guys.

I was never tried TN_Params thing but suggested to map the either data/string or send as a argument ($xmldata) with content-type

Where do you see the empty body in the TN transactions page receiving end?

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.

YES…as Rob said multi-part option is of no use for this and try with above logic and you can see the light end of the tunnel

Good idea