I have a couple of questions regarding Ttrading Networks 6.1:
I have a flow that performs the following:
file poller detects new file existence
flow service gets the ffdata stream, sets the TN_parms parameters and calls TN through wm.tn:routeFlatFile
TN identifies the related TN doc type and the processing rule matching this specific doc type instance (sender/receiver/doctype/user status criterion) which invokes another flow service
Flow service performs getContentPart from the Bizdoc, uses FFSchema to translate the BizDoc contents into an IS Document, maps this Document to a pivot IData document.
Now I want my Flow Service (4.) to post the pivot back to Trading Networks for further processing (routing, mapping to target structure, sending out). I tried the following on my pivot document:
recordToBizDoc
routeBizDoc
But this does not work. get the document into Trading Networks but in the Transaction Analysis console I can see an empty Bizdoc contents.
Also TN considers my pivot BizDoc as a flat file document (as it succeeds in matching it against a TN FlatFile Doc Type): I checked with a “savePipelineToFile” call in my flow service after the “recordtoBizDoc” call, and I noticed that my pivot BizDoc still contains the original FlatFile properties (TN_parms $contentType, $receiveSvc, $encodingType properties) and BizDoc content (see below):
<array>
<record>
<value>ffdata</value>
<value>application/x-wmflatfile; UTF8</value>
<number>0</number>
<byte></byte>
<number>0</number>
<null>
<null>
<idatacodable>
<value>false</value>
</idatacodable>
</record>
</array>
So I am not quite clear as to how I am supposed to send my Document back to Trading Networks and what kind of TN Doc Type should I create to get this data (only XML and FlatFile seem to exist) ?
Should I translate my document back into a flatfile through pivot schema and then use routeFlatFile ?
Should I map my pivot document to an XML String then XML node and then use routeXML ?
The TN DocType recognition is based on my TN_parms values for the flat file. If I route a Bizdoc to TN, what can I use to identify the TN doc type? Similarly if I use XML, my XML would not contain things such as ReceiverID, SenderID as the data is sent through email to the partner so how to identify the TN doc type if only the xml fields are available?
You’ll want to use routeXML in the TN package to get the data back into TN. However, be careful with the processing rules that you do not create an endless loop.
For this, you will want something in the document that you can key on, like a status field for the document recognition to use to pick which service to send it to.
Also, it is possible to just leave the document in TN, and change the user status. Then, you can have another service scan for tn docs with the specified status and invoke processing.
Thanks for your answer, I’ll try your suggestions.
I am still curious to understand what is the purpose of this routeBizDoc function, what is the appropriate use case for it ?
Another question: the next step in my process is to produce an XLS file out of the pivot and email it to my partner. Now I can use the HSSF OpenSource libraries to build my Excel file but how do I get TN to deliver it to my partner?
It seems that I can invoke my flow service from TN to :
build the Excel File from the pivot doc contained within the BizDoc
add the Excel file to the Bizdoc as byte (addContentPart)
post the BizDoc to TN (as FlatFile?)
TN can then email it to the partner using my own custom delivery service
Another way is you can built a (csv) flatfile Schema out of pivot and after mapping and transformation to FF then route it to TN as a flatfile docType and extract the content from bizdoc and email it to the trading partner either using custom delivery service(pub.client:smtp)or TN Email Delivery Method option listed in the ProcessingRule/Actions tab.
You may need to clean the pipeline before submitting your pivot document to TN. What may be happening is the TN_parms variable is still there and so TN doesn’t actually look at the pivot doc itself–it uses the TN_parms from the original submission.
Your approach is sound. You just need to be fairly agressive with cleaning up what I refer to as “pipeline litter” – TN is one of the worst litterbugs (though it has gotten better). Or call routeBizDoc/routeXML/receive using a scope to limit the pipeline.
As Rob mentioned abouve about using of Scope,you can try to implement this and so that whole pipeline info will not be used when routing the document to TN.
what you do is just wrap up the node under a temp record and set this record on the scope property which is in the pipeline/properties tab on the routeXML/receive service.