EDI Processing Modes in BTS2006 R2
Today we will discuss EDI processing options supported on the Receive Side.
EDI Receive Side enables BizTalk to 'receive' and process EDI encoded documents. R2 delivers a EDI Receive Pipeline which includes DASM to parse and validate the interchange and also generate appropriate Acknowledgements (e.g., TA1, 997 or CONTRL)
The EDI Receive Pipeline supports three processing modes and the selections are enabled at Party Level via controls in Party/EDI Properties on the BizTalk Server 2006 Admin Console, the three options are listed below.
- Generate Transaction Set XML, Aka De-batching: This is the traditional processing model wherein the incoming Interchange/Group is split into individual Transaction Set XML and generates ‘multiple’ Transaction Set XML per Interchange – one for each ‘valid’ Transaction Set.
- Generate Interchange XML – Suspend Interchange on Error: One Interchange XML is generated for the entire incoming EDI Interchange. On encountering error the Interchange is suspended. In this processing mode the interchange structure is always preserved.
- Preserve Interchange XML – Suspend Transaction Set on Error: One Interchange XML is generated for the entire incoming EDI Interchange. On encountering error the erroneous Transaction Set is suspended. In this processing mode the interchange structure may not be preserved.
The flow diagram in Figure 1 (also available as attachment with the blog) along with the verbiage elaborates on the processing options.
The Figure is a flow diagram illustrating processes for configuring translation of EDI Interchange files to XML representation(s).
- At 100, a user may configure, the way to translate incoming Interchange files.
- At 110, a user may decide whether to generate a single XML representation for the entire Interchange file received, or to generate multiple XML representations, one for each Transaction Set of the Interchange.
- If the user wants to Split Interchange is selected, then configuration option 120 is enabled. Within this option, user may choose to either suspend the invalid Transactions sets while splitting the interchange(160) or to suspend the entire interchange if even one Transaction Set is invalid (170)
- At 130, user option will produce a single representation can be advantageous when order of the transaction sets is important. For instance, where breaking up the Interchange into individual XML representations for each Transaction Set would lose the ordering of the Transaction Sets, it may be beneficial to translate the interchange to a single XML representation that maintains the structure of the EDI Interchange. If this option to Preserve Interchange is selected (130), then a user may additionally choose to configure how to handle errors.
- For instance, if a user chooses to suspend messages with errors via configuration option 140, then one XML representation is generated for the Interchange while dropping any Transaction Sets with errors.
- Option 150 in turn avails the user the option to configure the system to produce no XML if any of the Transaction Sets of the Interchange are invalid, or include bad data. Option 150 might be appropriate where all transaction sets are critical, or lose information when separated.
In summary, the Receive Side thus provides the ability to preserve an ‘entire’ Interchange per the incoming sequence, the ability to drop erroneous transaction sets and regenerate the interchange while updating footer totals and the ability to control this behavior via configuration options in the Trading Partner Manager Console.
