Document Processing
1. A partner sends a document, as follows:
The partner sends an XML document to the
Trading Networks wm.tn:receive service. The service reads the document into the pipeline. If coded to do so, the service places the name of the document type and processing rule to use for the document on variables in the pipeline.
The partner sends a flat file document to a document gateway service. The gateway service reads the document and places variables you specify (for example, SenderID, ReceiverID, DocumentID, and ConversationID) in the pipeline. If coded to do so, the gateway service places the name of the document type and processing rule to use for the document on variables in the pipeline, and places specified custom document attributes and their values in the pipeline. The gateway service then invokes the
wm.tn:receive service.
2. If Trading Networks does not find a document type name in the pipeline, it performs document recognition; that is, it compares the XML document to the criteria specified in enabled XML document types, or the flat file document to the criteria specified in enabled flat file document types. When it finds a match, Trading Networks creates a BizDocEnvelope from the document and places the BizDocEnvelope in the bizdoc variable in the pipeline. It then extracts the document attributes that are specified in the matching document type from the pipeline and adds them to the BizDocEnvelope, along with additional information required to route and process the document. The BizDocEnvelope represents a routeable Trading Networks transaction and conforms to the wm.tn.rec:BizDocEnvelope. The bizdoc variable adheres to the wm.tn.rec:BizDocEnvelope IS document type and is an instance of com.wm.app.tn.doc.BizDocEnvelope.
Trading Networks also places the sender and receiver variables in the pipeline. These variables contain the partners identified as the sender and receiver, respectively, in the document. The variables adhere to the wm.tn.rec:ProfileSummary IS document type and are instances of com.wm.app.tn.profile.ProfileSummary. To view the IS document type, open Software AG Designer and look in the WmTN package wm.tn.rec folder.
3. The next action depends on whether the pipeline contains a processing rule name and what the document type specifies, as follows:
If the document type specifies the use of a processing rule,
Trading Networks continues with step 4.
If the pipeline specifies a processing rule name,
Trading Networks skips to step 5.
If the pipeline does not contain a processing rule name, and the document type specifies to
not use a processing rule,
Trading Networks performs any pre-processing actions that are specified in the document type in the order they are listed in
Document Types.
Trading Networks then skips to step 7.
4. Trading Networks compares the document to the criteria specified in all enabled processing rules, as follows:
If the rule specifies this criterion... | Trading Networks does this... |
Sender, receiver, or both | Compares to the SenderID and ReceiverID system attributes in the document. If Trading Networks matches these SenderID and ReceiverID system attributes to a partner profile, it uses the corporation name and unit name specified in the profile as the name of the sender, the receiver, or both. Trading Networks compares the name of the partner to the partner or partners specified in the processing rule. |
Document type | Compares to the document type for the document. |
User status | Compares to the UserStatus system attribute for the document. |
Occurrence or non-occurrence of errors during document recognition | Checks for errors in the pipeline. |
Custom attributes | Compares to the attributes it extracted from the document. |
5. Trading Networks performs the pre-processing actions specified by the matching processing rule in the order they are listed in
Processing Rules.
6. Trading Networks performs the processing actions specified in the processing rule in the order they are listed below.
If this action is specified... | Trading Networks does this... |
Execute a Service | Processing depends on how you invoke the action, as follows: Synchronous: Invokes the service once, waits for the service to complete, and places the results in the pipeline. You can use the service results in output templates or other processing actions. If you do not use the Respond With action, Trading Networks returns the results of the service unmodified to the client that sent the document. If you do use that action, Trading Networks returns only the message you specify. Asynchronous: Invokes the service once and does not place the results in the pipeline. If there are subsequent processing actions, Trading Networks immediately performs them; if there are not, it returns to the caller that sent the document for processing. If you do not use the Respond With action, Trading Networks returns no information to the caller. If you do use that action, Trading Networks returns the message you specify. Service execution task: Invokes the service and uses reliable execution to retry the service if it fails. Trading Networks creates a service execution task to keep track of its attempts to execute the service. If Trading Networks retries the maximum number of times and the service is still unsuccessful, it updates the task status to FAILED. The processing and information returned to the caller are the same as for Asynchronous. |
Send an Alert Email | Sends the specified email to the specified person. |
Change User Status | |
Deliver Document By | Delivers the document to the receiver that is identified in the document using the delivery method you specified in the processing rule. |
Respond with | Returns the specified message to the caller that sent the document to be processed. |
7. If you extracted the ConversationID system attribute from the document, Trading Networks passes the document to the Process Engine for processing by a business process. If the Process Engine finds a running business process that uses the document’s conversation ID, it passes the document to the running process. If Process Engine does not find such a running business process, it searches for a process model whose first step waits for the document and starts a new instance of the process model. The Process Engine logs the status of business processes so you can view and monitor their progress.