Some time ago, with a client using BizTalk 2006 and Covast Accelerator 2006, we suddenly had the following issue popping up in their event log:

There was a failure executing the send pipeline: "Covast.BizTalk.Pipeline.EDI.CovastEDISendPipeline, Covast.BizTalk.Pipeline.EDI.Default, Version=5.0.0.0, Culture=neutral, PublicKeyToken=68bef120a46b49ad" Source: "Covast EDI Assembler" Send Port: "sp_MySendPort" URI: "D:\BTS2006\DumpLocation\%MessageID%.edi" Reason: Message translation failed: (2217) Unknown error (-2217)

The source of the problem was Covast.
Somehow, it was no longer able to perform valid assembling and disassembling (both were failing).

After a lot of digging and research I finally came to the "Covast EDI Accelerator 2006 Reports" screens, hidden deep within the BizTalk Administration Console HAT :-)

When you double click the interchange which was in error, you saw the following error:

The format of the document has not been configured

Finally, this led me to the source of the problem.

Someone at the client fiddled around with one particular ASC file trying to add some extra segments to the schema to accompany a change in one of their flows. No harm done, but unfortunately when re-generating the XSD, he also regenerated the SYNTAX schema and deployed.

The result was that there were now 2 SYNTAX schemas deployed within BizTalk and Covast doesn't know how to handle that.
Reverting back to the old version of the flow fixed the error and after that we just removed the SYNTAX schema from the project, rebuilt and deployed and now it worked.

Reason for posting this is that at the time, neither search engine could come up with a decent answer, so hopefully someone benefits from this post.

Let us know in any case!

Pieter

Introduction

EDI interchange batching is the process of creating an EDI file or interchange which contains multiple EDI transaction sets. Creating this interchange is called “EDI batching”.

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