Like posting the Sender, Receiver values explicitly to TN using TN_parms in flat file, can we post it for XML documents also?

In one of our xml business document, we don`t have Sender, Receiver values in the strucutre. We pick-up the files from Source FTP location and post to TN for continue the further processing. During posting the xml document to TN, we want to pass the Sender/Receiver value explicitly for recognition of the document and to start the business process.

No its not possible for XML doc types…TN expects sender/receiver id’s from the XML data itself for extraction/document recognition.So you need to include some place holder for the sender/receiver values in the xml structure itself for TN doc extraction.

HTH,
RMg

Hi,
I was thinking about this (Not tried it). What happens if you treat the xml doc as a FlatFile. Post it as application:x-wmflatfile to tn/receive with TN_Parms explicitly filled out with Sender/Receiver that are set in TN (ExternalIDs)???

When you post as xml data, you provide the XQL for sender/receiver extraction and identification. If you post as FF, you will not need it and it may work.

Anil

As a continuation from my previous post, you can actually try using service wm.tn.doc.ff.routeFlatFile which takes ffdata (as a stream) and TN_Parms as input arguments. I would do the following to try and see if it works, in a quick and dirty service -

1. Read xml file using pub.file.getFile as a stream.
2. Call wm.tn.doc.ff.routeFlatFile service with ffdata populated from previous step and TN_parms hardcoded to your sender/receiver/Doctype/attribute values.

Make sure TN_parms/$content_type to text/plain.

Hope that helps,
Anil

With XML TN document you can try the below approach.

1. In TN, do not assign any schema or IS document to validate the structure (limitation of the approach) for the doc type.
2. Get the internal IDs of the sender and receiver you want to pass explicitly.
3. Get the id of the document (use wm.tn.doctype:list. Filter the list based on Typename, which you give as the name of the doc when created and get the id).
4. Use wm.tn.doc:createNewEnvelope. Pass the doc id, sender and receiver internal ids.
5. Convert the xml into bytes (stringToByes).
6. Use wm.tn.doc:addContentPart service and pass the bytes that you have got from XML.
7. Now bizdoc is ready. Invoke wm.tn:submit to send the doc to TN.

Using this approach you can send any arbitrary data into TN.

Cheers
Guna

Guna,

Is it a one time task above to process the XML with explicit sender/receiver or every time we route the XML’s for that particular sender/receiver all the above flow steps needed to be executed?

HTH,
RMG

Hi RMG,
Ideally the above steps to be executed every time we send the XML doc to TN for a set of sender and receiver. The reason is, as you know that the partner internal IDs and TN doc internal id change when ever we deploy to other systems (From D to Q and P).

To avoid some of the steps above (getting internal ids for partners and tn doc), we can get the sender and receivers internal ids, TN doc type id when these are created in a new system after deployment, put them in a configuration file and retrieve from there. But this is tedious and error prone.

Ideally the above approach is most suitable to send non-xml and non-ff data to TN (like PDFs, txt files etc from client apps) using a TN xml doc as a wrapper.

Cheers
Guna

I would discourage the direct use of internal IDs, whether hard-coded in a service or stored in a config file. Use external IDs and lookup the internal IDs using the appropriate TN service, just like TN recognize does. Internal IDs shouldn’t change when migrating, but that’s another topic for another thread.

Another approach is to wrap the XML document within a local XML envelope (defined by your local IS/TN) within your gateway service. That envelope would have fields for sender, receiver, doc type, or anything else you’d like. Then TN can do normal XML recognition.

The downside to this approach is that the processing service would need to de-envelope to get the “real” document.

If you have just one partner for this doc type, you can hard-set the sender and/or receiver in the TN Doc type by using a custom service on the SenderID (or ReceiverID) attribute extraction. I wrote a service that has a string input of ‘arg’ (it seems at least in 6.1 you MUST use ‘arg’ and not something else like ‘setDUNS’) and an output of a string list ‘newValues’. The service does nothing but call getInternalID with the ‘arg’ as the id and hard-set “DUNS” as the idType. I map the returned partnerID into the first newValues. That will cause TN to set the sender to that partner. It is a way to hard-set the sender or receiver based on the document type, using a set-input value into your generic service from the TN Document Attribute Extraction. Hope that makes sense…