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.
