I am using HTTP to send an XML document to a trading partner. In the HTTP response, they are providing me with a submission ID stored in XML. The logical way to recognize the document is to swap the sender & receiver from my original submit to TN.
There are many different services to send data to TN.
What is the best service to use?
Chris,
wm.tn:receive is the best service to use if an external Trading Partner is submitting data to TN.if you are submitting from within the flow service, then it would be routeXml.
ramesh.
Thanks for the answer, ramesh.
My response document will not contain sender id or receiver id. This is OK since I know who I sent the HTTP request to.
How do I use info that is already in pipeline so TN can recognize sender Id and receiver Id? Neither routeXML or receive take input parameter of sender Id/receiver Id.
Do I need to create a new BizDocEnvelope and map the sender Id and receiver Id from my initial HTTP request?
Chris,
Use the standard routeXML service for submiting XML document to TN (map input node).
HTH,
RMG
My real challenge here is to have TN recognize the sender id and receiver id.
When I send the XML data to TN, it appears as the correct document type. However, the data in the file does not contain any data that will identify the sender or the receiver.
This will not be a problem since I am initiating the HTTP session w/ my trading partner. Because I initiate it, I know who the sender and receiver are.
Is there any way to hardcode the sender/receiver info for TN? I know you can do this with flat files by using the TN_parms document. How do I do it when the data is XML?
So you cannot add any custom fields(sender/receiver)placeholder in your XML document,so that TN will recognize accordingly.
For XML documents you have to specify the sender/receiver/doctype for recognizing every document for processing.
HTH,
RMG
Chris,
For all intents and purposes, Sender/Receiver IDs are required in TN (technically not required, but…). Since you’re generating the data, you might as well just add the sender/receiver info w/in the XML. The beauty of XML is that you’re free to add tags w/o breaking things on the receiving end (unless they really strictly validate the XML). Going with the additional tags route gives you a lot more flexibility in dealing with the docs in TN. You’ll be able to do resubmission, submit through TN Web, submit to TN through FTP, etc.
Chris,
Do you agree with the custom tags to include in your xml for recognizing in TN,so that life becomes simpler even it will not break things as told above and my post.
Ofcourse this all depends if you external partner allows to add the custom routing tags unless they dont strictly validate the structure ignoring the sender/receiver parts.
HTH,
RMG
This is data that is coming to us from a trading partner (Application Service Provider to be exact).
I am sure adding custom tags will upset auditors. It definitely would make life easier for me.
Put the response in an “envelope.”
Define a new structure that you control.
Have a header to hold the sender, receiver and other control information. Use data from the doc that was sent/the pipeline to set these fields.
Have a body field/structurre that holds the response unchanged.
Submit the doc to TN and process away.
If you really, really can’t get your anal-retentive ASP to allow adding custom tags, worry not. All’s not lost.
First, identify two tags whose values will not change – One each for Sender and Receiver ID.
Then, for “My Enterprise” and Trading Partner’s profile, add the values as “External IDs”. Select an “External ID Type” that you’re not using i.e. “User Defined 3”. Personally, I prefer to create custom “External ID Type” like “ASP Assigned” so that it’s clear what the value is for.
Lastly, for the DocType’s attribute, extract sender/receiver ID, and set Transformation -> Built-In -> and select the “External ID Type” that you’ve chosen.
All this, of course, assumes that your ASP’s format is not used for any other trading partners (which is normally the case anyway, as any standard EDI/B2B formats worth its salt will have sender/receiver clearly identified).
Hope this makes sense to you.
You could always use recognize and preroute perhaps?
Using recognize gives you the bizdoc and that could be updated to place in the Trading Partners prior to processing it.
Also, if you don’t require this http response to go anywhere external to wM, you could attach it to the outbound document as another piece, similar to how EDIINT documents have payload body parts.
It would be a simple enough thing to then write a query over those.
TRJ