Sdílet prostřednictvím

EDI Processing Modes in BTS2006 R2

  • Článek

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.

 

SplitOptions.bmp

Comments

  • Anonymous
    November 13, 2008
    Can this article be updated to include the fourth option? http://support.microsoft.com/KB/956051 Also the KB Article states there are only 3 options, which should be changed to 4 options.

  • Anonymous
    November 17, 2008
    updating....

  • Anonymous
    March 18, 2009
    Hi, Perhaps not the correct post, but: I’m receiving EDIFACT documents without UNA in BizTalk Server 2006 R2. They use ‘ (0×27) as segment terminator. If records ALSO are separated with CRLF (0×0D 0×0A) I can’t get BizTalk to parse these correctly.

  1. With UNA included (UNA:+.? ‘) it works fine.
  2. Without UNA it works if I remove all occurrencies of CRLF. I need to specify that BizTalk should expect ‘ + CRLF as segment terminator on the EdiReceive pipeline property “EfactDelimiters”. Is this possible, or is there another way to configure it? I would expect it to be, since you can specify exactly this behavior on the send side. I would not like to have to ask external parties to include UNA since this is optional. Thanks, Klas Ericsson

  • Anonymous
    March 18, 2009
    This issue has been fixed in BTS 2009. If there is any reason you cannot move to BTS 2009, please approach Microsoft support for a hotfix and the product group would take it up accordingly for BTS 2006 R2.

  • Anonymous
    March 18, 2009
    This issue has been fixed in BTS 2009. If there is any reason you cannot move to BTS 2009, please approach Microsoft support for a hotfix and the product group would take it up accordingly for BTS 2006 R2.

  • Anonymous
    March 23, 2009
    Hi, Thanks for the information. Eventhough we will eventually move to BizTalk 2009, we are in need of a solution to this problem in our existing installations based on BTS 2006 R2. Microsoft Support asked for the article number relating to this issue in order to be able to give us a hotfix. Is there a registered issue so that I could supply the KB9*-number to Microsoft Support? Thanks, Klas Ericsson

  • Anonymous
    March 23, 2009
    The KB article number for this fix is 956051. http://support.microsoft.com/kb/956051

  • Anonymous
    March 23, 2009
    The comment has been removed

  • Anonymous
    March 24, 2009
    It will be better to report this behavior on MSDN Forum. http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/