Outbound EDI batching in BizTalk Server 2009

INTRODUCTION

EDI Batching can be done out of the box in BizTalk 2009: There is the built-in batching orchestrations within BizTalk 2009 which can be started within the application “BizTalk EDI Application” and managed within the configuration of your party. More information about how this method works, together with a walkthrough, can be found here.

Note that the link will give you a step by step guideline for BizTalk 2006 R2, but should work for BizTalk 2009 as well. The only difference, as far as I can see, seems to be that the batching configuration within BizTalk 2006 R2 is separated between X12 and EDIFACT and for BizTalk 2009, you can configure it within the same dialog box (Parties > EDI Properties).

Screenshot:


Image: EDI Batching settings dialog in BizTalk 2009

PROS & CONS

For most companies the built-in batching solution within the party configuration will be sufficient: You can let the batch subscribe to your messages and your EDI messages will be batched one by one and will be released depending on the release criteria that you have set.

As you can see from the screenshot, these criteria can be scheduled (in a timely manner), based on the number of group segments or transactions sets within the interchange or by an external release trigger.

One important thing that I found while testing this method is that the batching orchestrations will only accept EDI messages which are considered to be “complete”. Otherwise you would get an error from the batching orchestration “71: Transaction Set or Group Control Number Mismatch”.
This is because the orchestration logic tries to assemble your EDI message, but cannot find the UNH and UNT segments within the message instance.
If you have just created the EDI message instance from a map for example, this is not filled in by default. You would first need to execute the EdiSend pipeline on your message to do this.

This built-in batching method should be quite easy to use if your release mechanism requirement is one of the available release criteria. However, I don’t see how you would easily determine the order of your messages in your outgoing interchange.

It also becomes complex when you need to be able to build parallel batches, initialized by different source messages.

AN ALTERNATIVE BATCHING METHOD

And off course, this is where this alternative batching method comes in…
First, I wish to thank my colleague Carl Batisse for providing me a glimpse to this solution: thank you Carl!

This alternative method is using a batch schema that is mainly used for validating instances of interchanges. However, it can also be used to reverse the process and thus create interchanges from the Xml you created.

The EDIFACT batch schema can be found in the BizTalk 2009 folder in the location:
<BizTalk_Installation>\XSD_Schema\EDI\Edifact_BatchSchema.xsd”
For X12, one would use the “X12_BatchSchema.xsd” file.

In my example, I will only use the EDIFACT schema, which looks like this:


Image: Edifact_BatchSchema.xsd

To validate an interchange against this batch schema, add it to your project together with the EDIFACT schemas that it will contain. If you run the “Validate Instance” on the batch schema, each EDI schema included in your project will be tested against your instance.

If you want to generate an instance of the schema, the batch schema will contain 3 transaction sets of all of the EDI schemas in your project, which is handy!

The result of the generated instance clearly shows you how the schema works. In my example I have added the the EDIFACT schemas for DESADV and IFCSUM and the batch schema to my project:


Image: Edifact_BatchSchema.xsd generated instance for DESADV and IFCSUM

You can clearly see the UNA, UNB and UNZ records and in between those, you can see that there is one “TransactionSetGroup” and “TransactionSet” record for each transaction set in the interchange. The DocType attribute defines the type of EDI message that is contained within the transaction set.

The attribute at root level “DelimiterSetSerializedData” contains the decimal representation of the characters used for delimiting, just as the UNA segment. The UNA segment can also be filled in with the actual characters instead of the decimal representation, but the notations cannot be mixed.

This means that you can simply map to this batch schema (with XSLT for example, which will be handier in this case). If you, for example, need to have multiple IFCSUM transaction sets within your interchange, you can provide a “xsl:for-each” loop containing the transaction set details.

After the mapping, you would simply let loose the EDI assembler on your instance and the EDI would be created… or not?

Now here comes the tricky part about the use of this schema… it will not allow you to continue without presetting the UNB and UNZ (on interchange level) and UNH and UNT (on transaction set level) segments. The EdiSend pipeline for example will not do this for you. Instead, in this case, it would provide you with a nice error message again.

So BizTalk will not handle the interchange control number and transaction set control numbers for you and this is a bit of a downside to this solution. This means that you would need to store the last used interchange and transaction set control numbers somewhere. This could be a database for example.

Specific nodes to fill in (EDIFACT)

At interchange level:

UNA, UNB1 (syntax version), UNB2 (sender identifiers), UNB3 (receiver identifiers), UNB4 (interchange date and time, depending on UNB1 version), UNB5 (interchange control number), UNZ1 (number of messages in the interchange) and UNZ2 (copy of UNB5).

At transaction set level:

UNH1 (transaction set control number), UNH2 (transaction set type and version), UNT1 (transaction set segment counter), UNT2 (copy of UNH1).

The transaction set segment counter can be a little tricky, because you would need to count the segments in your XSLT. The EDI assembler will however correct this value if it happens to be filled in incorrectly. It will however show you a warning in the event log, which can be ignored.

Pieter Vandenheede, CODit