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.


 

SplitOptions.bmp


Comments (9)

  1. ericstott says:

    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.

  2. EdiBlog says:

    updating….

  3. klas_ericsson says:

    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

  4. EdiBlog says:

    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.

  5. EdiBlog says:

    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.

  6. klas_ericsson says:

    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

  7. ManojAg says:

    The KB article number for this fix is 956051.

    http://support.microsoft.com/kb/956051

  8. klas_ericsson says:

    I’ve installed this fix and set the processing mode to "Split Interchange as Transaction Sets – Suspend Interchange on Error" on the party, and verified that BizTalk resolves the test file to the correct party, hence using the processing mode above. However, I still get the same behavior when UNA is not present and but the segments are delimited both by ‘ and CRLF.

    The error I get from the EDI logging is:

    – "33: Invalid occurence outside message, package or group"

    followed by another post in the event log:

    – "A likely cause is invalid segment terminator due to missing Carriage Line and/or Line Feed seperators."

    As stated above, if I add UNA it works fine.

    I would be grateful for further instructions on how the above KB-fix can resolve this issue.

    Thanks,

    Klas Ericsson

  9. EdiBlog says:

    It will be better to report this behavior on MSDN Forum.

    http://social.msdn.microsoft.com/forums/en-US/biztalkediandas2/threads/