Receipts are another integral aspect of the BizTalk Framework.Your business model might require receipts for the documents it sends to your trading partners, whether it be for auditing purposes, implementing subsequent business logic, or otherwise. BizTalk Server 2000 provides several ways to implement receipts, and also provides extensibility to allow you to implement receipts for your own custom data formats.
The process of transmitting and receiving receipts involves configuration for both the source and destination systems. An overview of the process is shown in Figure 6.5, and the steps are outlined here:
1. A business document is submitted to BizTalk Server at the source organization.
2. A channel on the source system accepts the document, and performs any configured document validation and/or transformation steps. This channel should be configured to "expect receipt."The channel then forwards the document to the associated messaging port that is configured to send the document to the destination organization. No special configuration is necessary here to enable the receipt.
3. A channel at the destination organization receives the transmitted document and begins interpreting it. This channel must be configured to "generate a receipt" and point to a related receipt channel. After passing on the receipt generation request to the receipt channel, ordinary document processing resumes.
4. The associated messaging port on the destination system handles the document. No special configuration is necessary on this messaging port to enable receipt processing, since the receipt processing is initially handled by the channel.
5. Information from the document headers is provided by the destination channel that originally received the document and is passed to the receipt channel.
6. The receipt channel uses the "BizTalk Canonical Receipt" document definition to interpret the incoming receipt information. This document definition contains information necessary for the destination organization to properly route the receipt document, and for the source organization to properly correlate the receipt with the original document. The channel can optionally map this to another outgoing document definition, provided that a suitable handler of that definition resides on the source system. Finally, the associated messaging port packages the receipt document and returns it to the source organization.
7. The source organization receives the receipt document and it is interpreted by an appropriate parser, based on a document definition appropriate for the receipt. Included parsers are the X.12 and EDIFACT parsers.
Figure 6.5 Overview of Receipt Processing
Figure 6.5 Overview of Receipt Processing
Configuration of channels and ports for receipt processing can be simplified by considering several basic rules. Channels that process outbound documents and require receipts should have their Expect receipt property set. Channels that receive inbound documents and want to send a receipt should have their Generate receipt property set. Finally, a receipt channel exists solely for the purpose of generating receipts.The destination of a messaging port bound to a receipt channel must match the source of the original document for which a receipt is requested. That is, the receipt must be sent back to the organization that sent the original document.
There are two main alternatives to generating and accepting receipts: channel processing and reliable messaging processing. Channel processing is designed primarily for X.12 and EDIFACT document formats, which include document routing information in their headers. This source and destination information includes the organization identifier type and value, enabling each system to uniquely identify both the source and destination. Also, a unique ID for the document itself is passed in the header, allowing the source and destination systems to agree on exactly which original document a particular receipt is associated with. Because receipt generation and acceptance are commonplace with EDIFACT and X.12 document exchange, parsers for these formats are included with BizTalk Server 2000.You can create additional parsers on your own, however, by implementing the IBizTalkParserComponent interface in C++. A custom parser is responsible for converting the instance document to an XML representation and routing it to an appropriate channel for subsequent processing.
Was this article helpful?