Recently, I had the opportunity to help one of our company’s developers through some training exercises for BizTalk 2006 development. In that process I encountered what I considered to be a fantastic solution sample that I wanted to share with the BizTalk community should anyone be in a similar Trainer / Trainee situation or simply looking for a good example to demo to a technical audience regarding the power of BizTalk messaging and orchestrations. However, should the case be the former, you would be hard pressed to find a solution example that better illustrates to a developer who has a good handle on messaging but needs to be introduced to some of the more complex, advanced topics in Orchestration development.
In the circumstance I encountered, the developer was reviewing the use of envelope schemas for the purpose of dissecting composite messages into individual messages outside the context of an orchestration. He had also been working with developing header / trailer schemas against a complex (sequenced record) inbound Flatfile schema. In a very natural course of questioning, the developer asked “What if I wanted to take multiple messages and combine them into a single message”. This immediately made me think of the Aggregator sample provided in the Pipeline samples section of the BizTalk 2006 SDK. This sample came, in this case with the downloadable install from Microsoft for installation on Windows XP.
Overview of Sample
A brief overview of this sample goes as follows. An orchestration is provided that handles submission of inbound invoice messages in the form of Files with schemas and instances provided. This orchestration allows for multiple messages to be submitted at one time and combined into a composite messages based on a promoted property specifying (what we can assume would be a unique) identifier for the messages’ source company. The (4) sample file instances provided come from two source companies (Contoso and Northwind). Placement of these 4 sample file instances in a FILE receive location will result in two sent XML files that each combine 2 of the 4 inbound files, based again on this company unique identifier.
As noted, this is a superb example not only because of what it teaches a developer in training to do with disparate files that need to be constructed as a composite message but rather the aspects of BizTalk messaging and orchestration that the solution includes. While possibly already apparent to a seasoned BizTalk developer given the description (or experience with the sample), these include Correlations, Promoted Properties, Loops, Try Catch Blocks, Expressions, Variables (that incorporate a variety of aspects from BizTalk libraries), Complex Flat File Schemas, and the use of Envelopes (which if you recall was the original source cause of our review of this sample). I will review some of the applicability of these concepts / aspects in this sample:
Aggregate.odx defines 1 correlation type that accesses the promoted property of the inbound invoice schema making accessible our external company’s unique identifier (as mentioned before) – in this case in the form of a URI string. This type is incorporated into a correlation that relates both our initial activation message and any subsequent message for the same company in the form of an invoice. Until that next invoice message from the matching company is received our instance of the orchestration will remain in a state of dehydration. This becomes applicable for the specific purpose of creating composite messages when we start looking at loops but, again getting back to the applicability for training purposes, since the developer I was dealing with had such a good understanding of what he was seeking to accomplish in this case, it was very easy to make the jump to “When else might we want to utilize this type of in process suspension?”. The common example of process / approval was easily digested in this context.
Prior to this point, the developer in question, had been able to both quick and manually promote properties, but again, in the context of being able to now relate these multiple messages together in the form of a correlation, really began to understand where and why someone would want to use promoted properties. This was certainly one of those “ah-ha” moments we have all experienced in our development skills building process – very nice to observe.
Even in the absence of the training aspect of my description thus far, this sample provides a very strong of when and how to use loops in an orchestration. A loop while (MessageCount (a custom variable defined for the orchestration that is incremented as messages are added in composite to the aggregate message) is < 2) in this solution provides a minimum message count for incorporation into a composite message. In each pass through the loop, the received message (be it the initiator of the process a subsequent) is added to another custom variable defined as type SendPipelineInputMessages – a collection class defined within a subsection of the BizTalk libraries. This exposure and usage of BizTalk libraries classes, objects, methods, etc. was also a relative first for the developer in questions, at least a first at this level of understanding. We see another example of a loop within the catch section of the Try Catch Block of this orchestration as error properties are set on the errant message which is delivered to an alternate send port for handling (in this case by an orchestration that suspends that message’s processing).
Complex Flat File Schemas
Though the sample provides all of the associated schemas necessary for this sample, I actually had the developer in question rebuild the schema from an instance of the file using the flat-file wizard. With some help he had no problem dealing with the multiple sequence and variably delimited records. Further proof that this tool is a great addition to BizTalk 2006.
Envelopes in action were a great way to round out this experience for the trainee. He very easily understood why we would seek to group individual messages in some kind of packaged container – especially in this case since it was a composite message we were constructing. As part of the exercise, I asked him to do what the Envelopes sample asks the developer to do – basically promote an additional property on our inbound message that is incorporated into our outbound envelope schema. A completely successful exercise on the whole.
In summary I would reiterate that this is a fantastic sample for anyone looking to ramp up on BizTalk in a serious way. As with any of the samples available with BizTalk 2006 SDK, I would say it is best to take them entirely apart and entirely rebuild them in order to gain the full benefit. In doing so, I have seen first hand, developers really start to formalize in their own minds the power and potential benefits that come along with the platform.