Sometimes batches are sent with common header information related to messages in the batch. This information is useful for routing purposes whereas the information is also useful for processing the messages. This information may or may not be useful to other client application or processes other than the process which is processing the message. Sometimes the header is preserved if the header is needed sometimes it is stripped off from the batch.

Thinking and implementing in terms of BizTalk we have to consider the disassembler component properties specially the preserve header property. I have seen a lot of BizTalkers getting in trouble with the header information and they have no idea where the header goes once they specify the header schema and the document schema property in the disassembler component.

Following is the input flat file which I have used as an example. It contains two items for body schema and two items in the header schema. We will mainly focus on the header items and how to extract them separately and access them in a meaningful way.

First thing you notice and should implement is to set the preserve header property to true. With this the header schema value is promoted to the message context and it can be extracted in the orchestration. In the figure below you can also see two other properties HeaderValue1 and HeaderValue2 in the expression editor. These values are much more useful than just extracting the raw header schema value. The raw header value can be extracted by the XNORM.FlatFileHeaderDocument context property of the message.

Now to extract the fields separately from the header you have to create a property schema. In my case I have defined two header fields (HeaderField1 and HeaderField2).

After creating the property fields make sure to change the Property Schema Base property to MessageContextPropertyBase for each of the header fields.

Next step is to promote these fields from the header schema as shown below.

Now when the project is built and deployed we test the solution by placing the input file in the input folder. What we expect is the two header values in the variables which are written in the event log along with the raw header XML which you can see below.

In this way we can use the header values in a more meaningful way and even if we need we can route the message based on the header values. If you could see the output file the header items would be stripped off from the batch.

You can download this sample from the box.net widget available on the right of the page.

In integration it is a very common task to receive different messages from different locations process them individually and produce a result in the form of a single consolidated message. This task is performed by an aggregator. In the aggregator a Singleton orchestration with sequential or parallel convoys is implemented. There are variations in the collection of input messages i.e. it can be a parallel convoy or a sequential convoy with different or same message types.

You can read more about Aggregator Enterprise integration pattern here.

While implementing the aggregator orchestration you need to ensure that the single instance of the orchestration receives the convoy of messages. There can be two types of convoys.

Sequential Convoy

In sequential convoy all the types of messages are received in an ordered sequence. The first receive shape initializes the correlation set while the other receive shapes follow the correlation set. You can have the first receive shape’s activate property to true and set the initialize correlation property. While the other receive shapes will have the follow correlation set property set and activate property false.

Parallel Convoy

In the parallel convoy the messages arriving are not in a sequence and their sequence does not matter but the processing should be started when all the three messages are received. Configuring the parallel convoy is straight forward. Just drag the parallel shape and add the receive shapes in the parallel shape branches. If the parallel shape is the first shape in the orchestration then each parallel receive shape must have activate property to true and initialize the correlation set otherwise follow the correlation set initialized by any first receive shape or send shape.

In my example I have used a sequential convoy and used a transform shape to aggregate all the three messages into a single message and then send this message through the file port.

In many business processes we receive a consolidated group of messages containing multiple messages inside it and we call it a batch. It is a common task to debatch each single message from the batch and process it separately. We can then transform or route these messages for further processing.

This would be really common for people working on BizTalk for some time however on the MSDN forums I still find beginners running into problems with debatching and using xpaths. I had this in mind to have a blog post explaining debatching, however I have explained debatching quite a time on the forums. Guess from now on I will be redirecting them to this post.

This is an overview of the debatching orchestration.

The orchestration works in the following steps.

1- First we count the number of items to debatch in the original message. We assign the count into an integer variable and use a count function in the xpath. Remember to copy the xpath of the repeating record node from the message schema.

2- Then we extract each message and assign it in the message of type single message. You have to create a new schema that would define the single message in the batch and in the construct shape assign the Nth message from the batch to the single message. I have used the position function in the xpath and specified the index throught the loop count variable which is incrementing by 1 in the loop.

Share this:

Like this:

Site collections are a logical container for a hierarchy of sites which gives the scope for administrative previlages, authentication and authorization, design and restore and backup operations to the sites in the collection.

The motivation for creating site collection with respect to administrative previlages is that the sites hierarchy within the site collection will have the same administrative rights. For e.g. the IT department guy gives administrative previlages to the Business person for Business Department site collection. The business person as an administrator can create and assign roles, users and groups to access sites. Also authorize the users against the content in the sites such as documents, lists and libraries. Hence for the sales department the administrative previlages will be to the person in sales department for the sales department site collection. Therefore isolating administrative previlages among site collections.

The second motivation for creating site collections is authentication and authorization for users and groups. The users as a member of one site collection are independent of the other site collection. A user in one site collection has to do nothing with authorization on content of other site collection. Even if that user is an administrator of one site collection and has authorization over all site hierarchy content withiin its own site collection by default it will not have any previlage on sites in the other site collection.

The third motivation for creating site lists would be the restore and backup operations that can be scheduled for site collections.

The fourth motivation for creating site collections are site elements and custom queries. The WSS object model provides the means to create custom queries that span all the lists within the site collection. Users can also create various custom site elements that can be used accros the site collections.