Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Trading Networks Built-In Services Reference | Core Services | Summary of Elements in this Folder | wm.tn:receive
 
wm.tn:receive
Receives a document that Trading Networks is to recognize and process. This service recognizes the type of document and submits it to Trading Networks to perform business document exchange.
Important:
Although Trading Networks can process documents of any supported EDI standard, it cannot properly process a mixture of TRADACOMS and non-TRADACOMS documents in a single submission. If the first inbound document is a TRADACOMS document, Trading Networks considers any subsequent non-TRADACOMS documents to be of the Unknown document type. Similarly, if the first inbound document is a non-TRADACOMS document, Trading Networks considers any subsequent TRADACOMS documents to be of the Unknown document type.
This service ensures that the sender of the document matches the current user. If you are sending documents from within processing rules or services and this identify check fails, see wm.tn.doc.xml:routeXml.
Input Parameters
node
Object (required for XML documents; not applicable for flat file documents and EDI documents) A document to process (must be an instance of com.wm.lang.xml.Document). The typical way to get an XML document into the pipeline is by posting an XML document to Integration Server.
Note:
You can add flat file documents or EDI documents in the pipeline by adding them as an Object with the name ffdata and edidata, respectively.
TN_parms
Document (optional) An IS document (IData object) that you can use to provide parameters that govern how Trading Networks recognizes and processes a document. TN_parms is primarily used for flat file processing.
The document gateway service adds hints to TN_parms that Trading Networks uses when performing document recognition for a flat file document. For information about using hints in a document gateway service, see webMethods Trading Networks Administrator’s Guide.
For both XML and flat files, optionally add the following fields:
*TN_parms/DoctypeID or TN_parms/DoctypeName to identify the TN document type to use, thus bypassing document recognition and eliminating the overhead of searching for the TN document type. If you specify both variables, DoctypeID is used.
*TN_parms/DoctypeID is a string that identifies the internal identifier of the TN document type. To determine the identifier use wm.tn.doctype:list. Using DoctypeID rather than DoctypeName is more stable because the internal identifier cannot be changed.
*TN_parms/DoctypeName is a string that identifies the name of the TN document type. Be sure to use the exact combination of upper- and lowercase letters.
*TN_parms/processingRuleID or TN_parms/processingRuleName to identify the processing rule to use, thus bypassing the processing rule lookup and eliminating the overhead of searching for a processing rule. If you specify both variables, processingRuleID is used.
*TN_parms/processingRuleID is a string that identifies the internal identifier of the processing rule. To determine the identifier use the wm.tn.route:list service. Using processingRuleID rather than processingRuleName is more stable because the internal identifier cannot be changed.
*TN_parms/processingRuleName is a string that identifies the name of the processing rule. Be sure to use the exact combination of upper- and lowercase letters.
*TN_parms/$bypassRouting to indicate whether Trading Networks should use a processing rule to process the document. Set the value of $bypassRouting to one of the following strings:
*true to disable processing rule routing. Disable the processing rule routing, for example, if a business process handles the document. When processing rule routing is disabled, Trading Networks performs the pre-processing actions identified in the TN document type; however, it does not search for a processing rule, nor perform any processing rule actions.
*false to enable processing rule routing. Default. When processing rule routing is enabled, Trading Networks searches for a processing rule or uses the rule identified by TN_parms/processingRuleID or TN_parms/processingRuleName and performs the actions defined in the processing rule.
Output Parameters
bizdoc
Document (optional) The document that Trading Networks received (i.e. the document passed in the node input variable) formatted as an IS document (IData object). For the structure of bizdoc, see wm.tn.rec:BizDocEnvelope.
sender
Document (optional) The profile summary for the sender of the document. For the structure of sender, see wm.tn.rec:ProfileSummary.
receiver
Document (optional) The profile summary for the receiver of the received document. For the structure of receiver, see wm.tn.rec:ProfileSummary.
TN_parms
Document (optional) An IS document (IData object) that provides hints that Trading Networks uses when performing document recognition for a flat file document. For information about document gateway services hints, see webMethods Trading Networks Administrator’s Guide.
flags
Document (optional) Flags that specify the pre-processing actions for the document. If specified, the service uses the persist? flag to determine whether to save the document. The flags must be an instance of com.wm.app.tn.route.PreProcessingFlags.
Usage Notes
*This service returns after Trading Networks completes processing for the document that is, after Trading Networks executes the pre-processing and processing actions for the document. If the processing actions instruct Trading Networks to execute a service asynchronously, the asynchronously invoked service may not be complete.
*If you are invoking this service to process documents for other components that use Trading Networks, for example webMethods Module for EDI, see the documentation for that component to determine how to submit documents to Trading Networks.
*If you invoke Core Services directly, by default none of the output parameters appear in the pipeline. To include output parameters in the pipeline, do the following:
*To include all of the service's output parameters in the pipeline (as well as the input parameter's node object), include the Trading Networks parameter clearTNObjects in the TN_parms parameter and set it to false as follows:
clearTNObjects=false
*To clear the pipeline of only some output parameters, specify the parameter clearKeys in the TN_parms parameter, and set the value as a comma-separated list of those parameters. For example, if the service is receiving an XML document, to clear the pipeline of node, bizdoc, sender, and receiver for this service, specify:
clearKeys=node,bizdoc,sender,receiver
If the service is receiving a flat file document, to clear the pipeline of ffdata, bizdoc, sender, and receiver for this service, specify:
clearKeys=ffdata,bizdoc,sender,receiver
If the service is receiving an EDI document, to clear the pipeline of edidata, bizdoc, sender, and receiver for this service, specify:
clearKeys=edidata,bizdoc,sender,receiver
*If you are invoking this service from a Java program, in addition to returning bizdoc, sender, and receiver as IS documents (IData objects), the service returns bizdoc as an instance of com.wm.app.tn.doc.BizDocEnvelope and the returned sender and receiver as instances of com.wm.app.tn.profile.ProfileSummary.
*The TN_parms/$bypassRouting variable takes precedent over the Processing Rule Routing settings within the TN document type. For example, if the $bypassRouting variable is set to true to disable processing rule routing, but the TN document type Processing Rule Routing settings enable processing rule routing, the $bypassRouting variable takes precedent and Trading Networks will bypass processing rule routing.