BizTalk Server 2010 unleashed book

22 September 2011

Back in the days when I was working with BizTalk 2004 I always had the book
‘Microsoft BizTalk Server 2004 Unleashed‘ close by on my desk.
Later on, when BizTalk 2006 was released the same was the case for the book ‘Professional BizTalk Server 2006‘.

It is not my intention to fail other good BizTalk books, but in my view the
above mentioned books are the BizTalk bibles that every developer must have.

Good news is that such a bible is now also available for BizTalk Server 2010.
Yesterday, I received a copy from Jan Eliasen (one of the authors). The book is
called ‘BizTalk Server 2010 unleashed’.

I helped Jan out by reviewing his chapters while he was in the process of
writing. Currently I have only read his chapters but I can still say the book
looks very promising.

In my view this is the book that every BizTalk 2010 developer needs on his
desk! It is writing by BizTalk experts: Brian Loesgen, Charles Young, Jan
Eliasen, Scott Colestock, Anush Kumar and Jon Flanders.

So to all the authors: thanks for delivering a new version of the BizTalk
bible to the community 🙂


Warning – Cannot resolve the ‘schemaLocation’ attribute

17 June 2011

I always take compiler warnings seriously and at least investigate them before releasing.

In one of the solutions I work on I consequently received the warning  ‘Cannot resolve the ‘schemaLocation’ attribute’. This solution contains a BizTalk project with a lot of schemas. For each schema multiple occurrences of this warning where reported. This lead to a long list of warnings.

Although this is a warning and it didn’t seem to bother anything at run-time I didn’t like the excessive list of warnings.

It turned out that the BizTalk compiler is quite strict in the way the imports are defined for schemas in other assemblies. We have schema types defined in schemas in other assemblies. We reference those assemblies and use the types in the schemas. Something like this:

<xs:import namespace="http://biztalk_server_project1.myschematypes" schemaLocation="BizTalk_Server_Project1.MySchemaTypes" />

As you can see we had the ‘namespace’ before the ‘schemaLocation’ attribute in the import statement. We manually added the import statements and didn’t bother about the sequence of those attributes. However it seems the BizTalk compiler wants the imports to be defined as:

<xs:import schemaLocation="BizTalk_Server_Project1.MySchemaTypes" namespace="http://biztalk_server_project1.myschematypes" />

This also the sequence used when you import a schema in the BizTalk schema editor.

After putting all the ‘schemaLocation’ attributes before the ‘namespace’ attributes the warnings were gone.

Not a showstopper but still worth mentioning in my view.


How to survive the XmlDisassembler

22 April 2011

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).


BizTalk Server MVP 2011

1 January 2011

Great start of 2011 for me. Today I received an e-mail from Microsoft telling me that I’ve been re-awarded the MVP title.

This is the second time for me. The first year has been an awesome experience. The title gave me the opportunity to do great things and meet inspiring and very skilled people.

I would like to thank:
– my MVP leads William Jansen and Gaby Lieuw 
– Ed Hickey and all other Microsoft employees involved
– people at Aviva Solutions
– and finally many thanks to Ivanka for her support and patience

I’m looking forward to another great year!

Happy new year everyone!


Visual 2010 BizTalk project woes

18 November 2010

I sometimes find myself in a situation where I need to make direct modifications to the XML code of an orchestration, map or pipeline. In Visual Studio you can do this easily by opening the file with the non default editor (right click orchestration file, ‘Open With…’ and ‘XML (Text) Editor’).

I encounter very strange behavior for the different file types (orchestrations, maps, pipelines) after I opened them in the Visual Studio 2010 XML editor. For schema files the behavior is as expected. For the other file types it looks like the default editor binding is missing after opening the file in the XML editor.

Orchestrations:

Steps to reproduce:
– right click orchestration (.odx) file in solution explorer
– choose ‘Open With…’
– choose ‘XML (Text) Editor’
– close the orchestration (save is not necessary)
– open the orchestration with the default editor (double click)

Results:
The orchestration opens but displays a very strange screen. It looks like a mix between the orchestration and the code behind:

image

Besides this there are the context menu for the specific orchestration has changed. Two options are added:

image

Maps:

Steps to reproduce:
– right click map (.btm) file in solution explorer
– choose ‘Open With…’
– choose ‘XML (Text) Editor’
– close the map (save is not necessary)
– open the map with the default editor (double click)

Results:
In this case the map opens with the correct mapper editor but there are also two extra options added to the context menu as is the case with orchestrations.

Pipelines:

Steps to reproduce:
– right click pipeline (.btp) file in solution explorer
– choose ‘Open With…’
– choose ‘XML (Text) Editor’
– close the pipeline (save is not necessary)
– open the pipeline with the default editor (double click)

Results:
For pipelines Visual Studio opens the XML representation when double clicking. It seems as if the default editor has changed.

image

This is very annoying. Is it just me? Do you have this too at your development box?

Workaround:
The workarounds I found are:
– Choose ‘Open with…’ and pick the default editor from the list.
– Open the BizTalk project (.btproj) with notepad and remove the ‘<subType>’  xml nodes for every file. After open the project again in Visual Studio it is fixed (until you open the file with the XML editor again).

I’m using BizTalk 2010 RTM (developer edition), Visual Studio 2010 Ultimate. Do you have this too?

I raised this issue on the Microsoft connect site.