How to survive the XmlDisassembler

The XmlDisassembler pipeline component in BizTalk Server basically does three things:

1. promoting properties (including the message type)
2. validating incoming documents (if turned on)
3. disassemble batches into body messages

Sometimes situations can occur where you want to process an envelope message but you don’t want to have it disassembled into separate body messages.

For example when receiving a message that contains a lot of data in the header of the envelope that is needed in the body of a message further on in the process. You then ideally want to use a map to copy over this header data into another message. If the port receiving this message uses the XmlDisassembler component the envelope will be processed and the header information is “gone”.

You can of course promote everything in the header to the context but that leads to a lot of data in the context. Besides that a considerable amount of code (distinguished fields and xpath statements in expression shapes) is needed to get the context properties into the message later on.

Another and, in my view, more elegant way to do this is by setting the value of a special property to true on the context of the envelope message before it is processed by the XmlDisassembler. The property is called ‘PromotePropertiesOnly’ and resides in the ‘http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties’ namespace.

A very simple pipeline component can be used to do this:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
pInMsg.Context.Promote("PromotePropertiesOnly",
"http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", true);

return pInMsg;
}

After setting this property will still have the functionality of the XmlDisassembler (like property promotion, setting the message type, etc.) but the debatching is skipped.

The property is available and can be used in all versions of BizTalk Server (2004, 2006 (R2), 2009 and 2010).

Replacing functoids in BizTalk 2009

A BizTalk developer recently learned me a great trick to replace funtoids in a map. It looks like a lot of BizTalkers, like me, are unaware of this handy feature.

When you accidentally used the wrong functoid in a map you can replace it by just dragging another functoid on top of it. The old functoid is replaced with the new one. The great part is that all the input and output parameters of the functoid are preserved.

The following video shows how to do this in BizTalk 2009:

BizTalk 2009 Mapper replacing functoids

I haven’t tried but this should also work in BizTalk 2006 (R2). I don’t know about BizTalk 2004.

When trying in BizTalk 2010 I was a little bit surprised to find out that this does not work. See video below:

BizTalk 2010 Mapper replacing functoids does not work

Fortunately there are many other productivity enhancements in the BizTalk 2010 mapper so I think I can live without this replace feature .

Mapping in BizTalk 2010: My favorite new features (overview)

The text below is based on the beta release of BizTalk 2010. It might not (completely) apply to the RTM release.

No doubt that, of all the new and changed BizTalk 2010 features, the enhancements to the BizTalk mapper are the most salient. For the current and previous BizTalk versions a lot of BizTalk developers do not use the mapper tool. Especially when transforming big XML messages they switch back to manually writing XSLT code.

In BizTalk 2010 Microsoft has tried to make the mapper tool more powerful and more user friendly. The future will tell if Microsoft succeeded in this and if more developers are willing to use the tool for their mappings. The questions is will they start dragging or drop the mapper again?

Besides making the mapper more suitable for big transformations I think Microsoft has another reason to put so much effort into enhancing it. In the future we will probably see a broader range of .Net developers use the tool for their transformations outside BizTalk. I think in the future Microsoft will position it as the general tool to do XML or maybe even object transformations.

Anyway, in my view Microsoft did a very good job. In the following blog posts (which I will publish in the coming days) I will show my favorite and most useful new mapper features. Those are:

· Intelligent Linking (part 1)
· Functoid Intellisense (part 2)
· Relevance View (part 3)
· Suggestive Matching (part 4)
· Optimized Display of links (part 5)
· Highlighting selected objects (part 6)
· Bringing selected objects in view (part 7)
· Search support (part 8 )

I wonder what you think about the new mapper and what your favorite new features are. So please feel free to comment.

Mapping in BizTalk 2010: My favorite new features (part 2) – Functoid Intellisense

The text below is based on the beta release of BizTalk 2010. It might not (completely) apply to the RTM release.

This blog post is part of a series of blog posts about my favorite new features in the BizTalk 2010 mapping tool. You can find an overview here.

Functoid intellisense is a visual improvement which shows the developer when a functoid has not been properly configured. Before BizTalk 2010 the only way to find out that a functoid was not fully configured was at compile time or even worse at run time.  With BizTalk 2010 this is different.

When we drag for example an ‘Equal’ functoid to the map this is what happens:

The functoid has an icon that shows that there is something wrong with the functoid configuration. When I hover over the functoid I’m presented a tooltip that shows me what is wrong:

Opening the properties for the functoid also shows me that the second input parameter has not been defined: (Also note the nice layout of the functoid properties window)

side note:

Besides the nice layout of the functoid properties window is also resizable now. In case of the scripting functoid the inputs and script dialogs are now unified in one single dialog. This also allows you to resize the scripting functoid code window (GREAT !!!). Furthermore you can choose to import code from a text file and set a specific script type as the default.

When I set the second parameter to a constant value and connect the output to the destination schema, there are no more icons which tells me the functoid is configured properly:

I think this feature is great because it shows in an early stage (during development) that there is something wrong with the map. This is absolutely a time safer.

The next post in this series will be about ‘Relevance View’.

Mapping in BizTalk 2010: My favorite new features (part 1) – Intelligent Linking

The text below is based on the beta release of BizTalk 2010. It might not (completely) apply to the RTM release.

This blog post is part of a series of blog posts about my favorite new features in the BizTalk 2010 mapping tool. You can find an overview here.

In this first post we are going to look at a new feature called ‘Intelligent linking’. When you define your schemas and add new nodes to the schema you can choose between different types of nodes. Intelligent linking only applies to nodes that you set to type ‘Record’ in the schema editor. In other words it applies only to nodes that can contain other nodes.

Intelligent linking allows you to choose the type of link for records when mapped from source to destination. The mapper will automatically show a context menu from which a link option can be selected. The context menu will only show up if we map from record to record.

In the following map (where the source schema is the same as the destination schema) the ‘Person’ node is of type ‘Record’:

When we drag the source ‘Person’ to the destination ‘Person’ the context menu automatically appears:

As shown by the context menu we have the following options to choose from:

· Direct Link
· Link by Structure
· Link by Name
· Mass Copy

Direct link will create a link from record to record. Link by structure will look at structure of the child nodes below the ‘Person’ node and will try to link them by looking at the structure or hierarchy of the nodes. Link by Name will as the name indicates look at the name of the child nodes to try to link them to the destination child with the same name. When you select the last option ‘Mass Copy’, the mapper will automatically insert a mass copy functoid and link the source to the destination:

Now if you have experience with previous BizTalk versions you might say this feature is not new. That is absolutely true. The feature was already present in previous versions of BizTalk. You could drag from source record to destination record and while holding the shift key you could do a mapping for the child nodes. The main improvement is in the usability of the feature. In the previous versions you had to go the properties of the grid/map and change the ‘AutoLink By’ property there. The bad thing was that you had to remember to set the property to the correct value before dragging a link. In other words the property was map based. Although this is still available in BizTalk 2010 we can now more easily use this feature because of the automatic popup. The property is now link based. Besides that you could only choose between the values ‘Structure’ or ‘Node Name’ for the property while you can now also choose the ‘Mass Copy’ option.

A great new feature which will dramatically improve development speed when working with big transformations where you need a lot of links.

In the next post we will be looking at ‘Functoid Intellisense’.