I had to spend a few hours today to dig into the batching features of BT2010 (I don’t think 2013 is much different, but don’t know about earlier releases).
Built-In Convoy-Style Orchestration
So basically, there is a sequential convoy style orchestration that can be started, runs continuously, waiting on a receive to feed it more messages, and can spit out a batch occasionally (we will discuss what causes the batch to be created shortly).
The following shows the batching orchestration running in the Group Hub / Running Instances.
Now, how do we start this orchestration, how do we stop it, and what causes the batched EDI files to be emitted?
Setting up the Agreement
I’m not going to cover BizTalk EDI from the very beginning, that would be another blog and a much longer one. So I’m assuming you have already created some EDI files, and now you need to batch them, and thus you are already familiar with the Party/Agreements.
In the agreement, there is a “link” or item on the left called “Batch Configuration”. From there, you can click “New Batch” and fill out the screen. At first, I didn’t realize the screen was scrollable, so I didn’t see that about 70% of the options were not visible until one scrolls down. So here is a screen shot of the “Batch Configuration” full expanded in length. (I already clicked “New Batch” and entered some basic dummy data.)
You set up the Filter to some Receive Location that you have created. You will drop the files you want to batch there.
When you click the “Start” button at the top, an orchestration will start running within a few seconds (the length of time might be dependent on your SQL polling interval BatchControlMessageRecvLoc, I’m still a little fuzzy on that).
Where do the batched EDI message go?
Per the walkthrough (link at the top), you create a SendPort with the following filters:
- On the first line of the grid, select EDI.DestinationPartyName for Property, == for Operator, the name you selected for the party to send the batch to for Value, and And for Group by.
- On the second line, select EDI.ToBeBatched for Property, == for Operator, and False for Value, and And for Group by.
- On the third line, select EDI.BatchName for Property, == for Operator, and the name of the batch for Value. (Batch1 in my screen shot above).
When do the batch file get released (created)?
Back in the “Batch Configuration” (the tall screen above), there is a section called “Release”. You can select four options:
2. Maximum number of transaction sets in group or interchange
3. Maximum number of characterrs in interchange
4. External release trigger.
(You could have different batches, with different release mechanism.)
Use the schedule to release a file every 30 minute, every hour, every day, etc…
Here are samples of the schedule options:
I think the other option, the max number of transactions and characters, is fairly self explanatory.
The last option, “External release trigger”, is a little more interesting. It is explained in detail on MDSN here. The concept might be that you want to send a batch of EDI files based on some other factor. Imagine for example that someone clicks a “Send” button on a web page. That web page you would then be the “external trigger” that would cause a batched EDI file to be emitted.
In summary, the “external release trigger” involves creating a ReceiveLocation with the
BatchControlMessageRecvPipeline Pipeline, then dropping a file like the one below in that Receive Location. In the above example I made up, the “Send” button from the web page would create this XML and write the file in the BizTalk pickup directory tied to the appropriate Receive Location.
I hope this is a good summary. I believe that if you have read this, then reading the MSDN articles and walk throughs will make a lot more sense, and you will get your EDI batching up and working faster. Please comment below if you found this helpful, or if you see any corrections or improvements.
So the “Start” button at the top of the Batch Configuration starts the orchestration. What if you want to quiesce your BizTalk system? As usual, just stopping the host instances should to that. If you need to redeploy your application, you would have to stop the orchestration; the question then is whether the last messages in the orchestration all get batched into one final file. What if your trading partner just wanted one file per day? Might be some logic you have to add here. If I find answers, I will update the blog.