I would like to thank: – my MVP leads William Jansen and Jacqueline de Jong  – 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!

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

Saravana has been working with BizTalk Server since the first product release early in 2001, and has many years experience in architecture, design, and development of mission critical systems focusing mainly on Microsoft Technologies. He worked as one of the Lead BizTalk Server consultants in the National Health Service (NHS) project in UK for 3 years, one of the biggest public sector projects in the world and largest implementation of BizTalk Server 2004.
He is very passionate about upcoming Microsoft technologies. In year 2005 he won the Connected Systems Developer competition under MCP category for designing and building SQL Service Broker Management Studio 2005.
Currently, Saravana is an independent consultant focused solely on Microsoft based integration solutions using BizTalk Server. Microsoft published his white paper Understanding Design-Time Properties for Custom Pipeline Components in BizTalk Server.
Saravana is awarded "Most Valuable Professional (MVP)" for BizTalk Server every year since 2007. Finally Saravana owns and maintains the BizTalk 24*7 community site.

This is your chance to hear and meet one of the top international BizTalk community members. You can register here.

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.

BizTalk 360 tries to address some of the real challenges we face on a BizTalk environment, especially controlled environments like Production and Test environments. There are 3 core features I personally like about BizTalk 360

Governance/Auditing: This is such an invaluable addition to the tool, on a controlled environment it’s very important to know “who did what”. There were so many instances in the past, where we struggle to identify who stopped the host instance or who Unenlisted a send port etc. With BizTalk 360 we’ll know exactly who did that activity.

Fine Grained Authorization: This allows controlling the user’s access to the environment in a fine grained manner. It helps us reuse the environment by multiple departments/projects, without the fear of one interfering with other resources. We also don’t need to provide direct access for users to access the physical machines.

Topology: We got multiple environments with multiple configurations. In the past when we need to understand the network topology we either need to login to the server and work out BizTalk/SQL server configurations. But with BizTalk 360, it just dynamically plots the network diagram.

The great thing about it, there is a free version as well. The free developer version got pretty much all the essential things that will be useful for development purpose. The only downside I can see is, BizTalk 360 reached the market bit late. If this product was available 3 years ago, I’m pretty sure by this time every reasonable sized company would have got one. But late is better than never.

The commercial editions are also priced reasonably given the amount of functionality it got. I personally know Saravana Kumar, the fellow Microsoft BizTalk Server MVP who is one of the founders of BizTalk 360. I will hugely recommend anyone using Microsoft BizTalk Serer to take a look at BizTalk 360.

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

In the previous versions in some circumstances the provider (and PowerShell runtime) crashed when adding a new resource using the new-item cmdlet. This, among some other things, has now been fixed in release (v 1.2.0.1).

You can download the new version from here.

Thanks to Maxime for helping me fix this bug.

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!

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:

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

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.

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.

Op 2 december a.s. geef ik samen met Steef-Jan Wiggers een presentatie over BizTalk Server 2010.

Wil je weten wat er allemaal nieuw is in BizTalk 2010 kom dan naar de BTUG meeting op 2 december.

Naast onze presenatie zijn er nog twee andere presentaties:

- BizTalk 2010 en Trading Partner Management  (Richard Sargeant)
- Extended and Scalable integration through the cloud (Gijsbert in ’t Veld)

Note to international readers of my blog:
The above post is aimed at the Dutch community and therefor only published in Dutch language. Unless you want to learn Dutch you can safely ignore it (I realize that is probably true for all my posts).

Recently the book ‘Applied Architecture Patterns on the Microsoft Platform’ was released. The book is written by Richard Seroter, Stephen Thomas, Ewan Fairweather, Mike Sexton and Rama Ramani. Yossi Dahan is the technical reviewer. The book is published by Packt Publishing.

Shortly before the book was released, an event was held in Stockholm, Sweden. I was lucky enough to be able to attend. Three of the authors (Richard, Stephen and Ewan) did two long days of presentations. In the humorous and spirited presentations the chapters in the book were discussed accompanied by nice live demos.

I was already interested in this book because these authors are respected and known worldwide as BizTalk and Microsoft experts. After attending the event I was even more interested in reading the book.

A couple of weeks after the event I was contacted by the publisher. They asked me to read the book and write a review on my blog site. Below is my review:

During the last few years the Microsoft platform has evolved in two directions. Extension and enhancement of existing technologies and products has of course continued. A couple of new technologies and products including Windows AppFabric, Windows Azure AppFabric, and StreamInsight have been added to the stack. Architects have the important task of picking the right technology for their specific problem at hand from the broad landscape of technologies and products. Picking the right technology for a new project can be very challenging due to the number of architectural decisions that must be made. Wrong choices in this area can lead to big problems and high costs for companies.

How to pick the right technology or product from the Microsoft stack is exactly what this book is about. It must be said that the book does not try to be the ultimate reference guide with the right pointer for each possible scenario. Instead it equips the reader with the knowledge to decide which technical architecture is most appropriate.

The book can be roughly divided into three parts. The first part (chapter 1) creates an architectural decision framework. The decision framework is one of the tools used in the process of translating requirements into technical solutions.

The second part (chapters 2 through chapter 6) compromises the technology primers. The primers are an introduction to technologies and products used in the book. For each primer, typical use cases are described. There is also a sample solution included for each primer.

The third and final part (chapter 7 to chapter 19) contains the elaboration of a couple of fictitious cases. First, a company with a specific IT problem is introduced. Next, the decision framework from the first chapter is used to determine the best fitting architecture for the IT problem. Finally, the case is implemented in a downloadable sample solution.

In my view, books about architecture tend to be boring and hard to read. This book is absolutely not the case; I really enjoyed reading it. This book fills a gap in the Microsoft architecture guidance.

My favorite things about the book are:

· It provides a broad overview of the Microsoft product and technology stack. Newer technologies like Windows AppFabric and StreamInsight are included.

· The decision framework provides a useful tool for real world scenarios and helps in the design process of translating requirements into software.

· The extensive set of cases (12 chapters) is the main part of the book. It provides architectural information and reusable code that can be used as a starting point for real world scenarios.

This book is a must have for every Microsoft architect and developer.

Let’s start with some simple questions:

Question1:
What syntax do you need to use to access the filename of a message you received using the file adapter in an orchestration?

In an expression shape you use something like this:

myVariable = myMessage(File.ReceivedFileName);

Question 2:
Ok, that one was easy! Now the same question for the a message received using the FTP adapter?

Again in an expression shape use:

myVariable = myMessage(FTP.ReceivedFileName);

Question 3:
Ok, makes sense. So what do you need to do when you wan to set the filename for a message that you send out using the file adapter?

Easy, two steps needed:

1). Set the filename property in the send port to use the macro %SourceFileName%.
2). Set the context property in the orchestration to the filename you want to use, like this:

myMessage(FILE.ReceivedFileName) = “MyFileName.xml”;

The file adapter will replace the macro with the value of the context property.

Question 4:
Last question; Same question for the FTP adapter. How do you set the filename for a message that you want to send out using the ftp adapter?

myMessage(FTP.ReceivedFileName) = “MyFtpFileName.xml”;

Wrong!!!!!!!! you also need to use the same syntax as with the file adapter:

myMessage(FILE.ReceivedFileName) = “MyFtpFileName.xml”;

This is something I encountered during development last week. I think this is a little confusing. It took me a while to find out what happened here. Also, by searching the internet, if found out this seems to confuse more people.

I think the idea behind this is an attempt to make an orchestration adapter agnostic and to create an abstraction layer between the logical process (orchestration) and the adapters which are bound to a certain technology or protocol. So whether you use the file or FTP adapter it is always ‘FILE.ReceivedFileName’ you need to use. This idea is good but my remarks are:

- This works different for receive side which makes it a little inconsistent.
- The word ‘FILE’ is (at least in my head) directly connected to the file adapter. The abstraction would be more clear if some other term was used.

Confusing!

Dick Dijkstra en ik hebben een artikel geschreven over BizTalk en PowerShell. Het artikel is recent gepubliceerd in de gedrukte versie van TechNet magazine.

Het artikel is helaas nog niet online beschikbaar.

Note to international readers of my blog:
The above post is aimed at the Dutch community and therefor only published in Dutch language. Unless you want to learn Dutch you can safely ignore it (I realize that is probably true for all my posts).

This job is especially good news for those of us responsible for keeping BizTalk Server running and healthy.

The general idea behind the job is to check for errors and report that those errors exist in one of the message box databases, the management or the tracking database. A zombie message is an example of an error that will be detected. For a complete list of all the issues see the BizTalk 2010 help on this topic

The job consists of two steps. The first step is responsible for collecting error data from the different message box databases, the management database and the tracking database. The second step checks the collected data and raises an error if there is an issue in of the databases.

If any inconsistencies are found the job will fail and will write an error to the application event log. You can easily extend this by configuring other notifications for the job like e-mail, etc.

The job does not fix any issues it is just provides an alert mechanism. You can other tools like the BizTalk administration Console to fix any issues found.

When running the job on a healthy BizTalk server environment, the job succeeds:

Now I use the following non uniform sequential convoy orchestration to generate a zombie message:

I can easily do this by throwing in message 2 (destination receive shape 2) multiple times. The orchestration is only expecting one instance of message 2 which will lead to a zombie message. In the admin console this looks like this:

When running the job the second time I now see the following result:

The job history gives me more detailed information of what is wrong:

This information is also in the event log:

Some final considerations:

1. By default the job is scheduled to run once a week. You can of course change this schedule if you like.
2. This seems to be a heavy job in terms of SQL resource usage. Microsoft recommends to run the job during low traffic.
3. The will not detect if issues have already been reported. When the job runs for the second time and the issues have not been fixed they will be reported again.

I think this is a useful new feature in BizTalk Server 2010. I have seen many clients where issues in the BizTalk databases where not noticed for a long time.

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:

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:

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

Thanks to Imre Zolnai for triggering me to update it.

For more information see this link and this link.

There is also a FREE developer edition now, which is great news!

Today I found another one:

Seems like we will have to wait a couple of weeks more . Or maybe it will be available sooner on MSDN subscriptions? Who tells?

You can right click in the schema view and select ‘Hide property schemas’. It is obvious that after enabling it, the deployed property schemas are hidden from the view and you get an overview of only the ‘regular’ schemas.

I was not really shocked by this feature. To be honest I think it is not really useful (at least not for me). I was more fascinated by the fact that it appears there are still features I don’t know in the console while I work with it every day.

Did you know this feature? For readers that did not and who think it is not useless, see the screenshots below.

In BizTalk 2006 R2 Admin Console:

In BizTalk 2009 Admin Console:

In BizTalk 2010 (beta) Admin Console:

In BizTalk 2010 the Admin console now has a action pane which makes the feature more visible.

Anyone other “obscure” features that are not generally known?

The AppFabric Customer Advisory Team (CAT) (formerly known as BizTalk Rangers) opened a new blog. Their focus is not just on BizTalk Server but now also on Windows Server AppFabric, WCF, WF, AppFabric Caching and StreamInsight (CEP), etc.

Besides the mentioned blog there is also a CAT site. This contains information on other CATs as well. For a full description of the teams and all the relevant url’s see Richard’s post.

Very interesting stuff written by great experts; worth reading!

“BizTalk Server 2009 STD may be the best option; however, BizTalk Server 2009 STD is limited to five BizTalk applications”

For me reading the FAQ did not make things more clear. In fact I had two additional questions about the five application limit after reading. Besides that I also see questions around this topic pop up in the community regularly. So there are more people confused about this.

My questions are:

1). Is the five application limit a hard limit or is it "just" a licensing thing?
For example what if you have a hot deployment strategy where you want to deploy a new version of the fifth application. Obviously you un-deploy the old version as soon as possible but for a short period of time you need one application above the limit. Is this technically possible or is standard edition restricting this?

2). How about the “system” and default application? Are those included in the limit?
You get “BizTalk.System” and “BizTalk application 1” out of the box after configuring BizTalk. Do they count? In other words can I only install 3 additional applications? I personally almost set my own custom application as the default application and remove “BizTalk application 1”. Of course I don’t touch “BizTalk.System’ as it is the part of the BizTalk infrastructure. But what does that mean for the maximum number of applications?

The only way (for me) to find answers is to try out. Of course I never took the time to install standard edition which is why this was on my “to find out” list for far too long. Last week I stumbled across a standard edition (our system administrator accidentally installed Standard edition instead of developer edition on our development machines). I took this chance to get my answers.

The machine was clean and I started creating Application 1, Application 2, etc. While trying to create application 6 I got:

So, first answer: This is a hard limit. Second answer: No, “BizTalk.System” and “BizTalk application 1” are not included.

What if I delete “BizTalk application 1” (set another application to default first)? Can I create an additional application? The answer is: yes.

So as a reminder for myself and other people looking for this information:

BizTalk Standard has a hard limit of five applications. The out-of-the box (OOTB) applications “BizTalk.System” and “BizTalk Application 1” are not included meaning you can have five additional applications next to the OOTB applications.

Mainly for my own needs I moved the table to a place where I can easily find it. It is now a separate page accessible through the title bar of my blog. You can find it here.

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.

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

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

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.

Relevance view is a nice new feature that especially comes in very handy if you work with large schemas. It allows you to focus only on the relevant nodes for the links. Consider the following sample where I use the big EDI schema “EFACT_D98B_APERAK”. Imagine I want to concatenate two nodes in the source schema using a functoid. The first node is on top of the schema while the second node is on the bottom of the schema. (This concatenation probably does not make sense but that is because I don’t know much about EDI (and want to keep it that way )).

Without relevance view the complete link structure won’t fit on the screen. To be able to see how the nodes are linked we need to scroll up and down. This is the top half of the link:

We cannot see the bottom of the link and need to scroll down to it:

If we turn on relevance view all the non-relevant nodes are collapsed or coalesced so that we get a clear view of how the whole link goes from source to functoid to destination:

The mapper applies a couple of rules to either collapse a node or coalesce a node. If the node has no links it is collapsed. If a node or its child nodes have links groups of successive nodes are coalesced. Coalesced nodes are indicated by this icon:

By clicking the icon the nodes are expanded. The opposite icon is displayed to coalesce the nodes again:

You can toggle relevance view for the schema by pressing this button in the mapper ribbon:

As you can see you can toggle relevance view for the source and destination schema independently.

Another great feature in my top list of new mapper features.

In the next post we will be looking at ‘Suggestive Matching’.

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.

This is by far the coolest new feature. In complex mappings with big schemas it might be very hard to find the node in the destination schema to link to. With suggestive matching the mapper can help.

Say I want to map from the source element ‘Lastname’ to a corresponding element in the destination schema but imagine the schema is too big to easily find the destination node. This is how it works: I select the ‘Lastname’ element in the source schema right click and choose ‘Indicate matches’ from the context menu that appears:

The mapper automatically finds the most relevant nodes in the destination schema by doing a name match. It draws the suggested links on the map surface:

By using the arrow keys I can loop through the suggested nodes. If I have found the correct one I just press enter and the link is added for me:

For the small schema above this might seem like a little overkill but in big schemas that span outside the screen bounds these feature is absolutely very useful.

The next feature is about the optimized display of links.

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.

The mapper in BizTalk 2010 now has three different ways to display a link. The idea is that the readability of a map is enhanced by this feature, especially when we need to deal with big schemas with many links. Consider the following sample:

The links for which we can see both the source and destination element are displayed as normal lines (1). The links for which we only see one element (in this case the destination element) are dashed and grayed out (2). The links for which we cannot see both the source and destination element are displayed as thin grayed out lines (3).

Additionally the toolbar has a button that allows the developer to completely hide the links of type 3. This is the button:

If we press it, the links of type 3 are indeed hidden which further improves the readability:

The next post will be about ‘Highlighting selected objects’.

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.

Sometimes functoids and links are mixed up in the screen so that you cannot easily see to which elements they belong:

The highlighting selection feature will help you by emphasizing the select element, links and functoids. All the other links and functoids are grayed out. This is what happens when I select the ‘Lastname’ element in the source schema:

As you can see the relevant links and functoids are emphasized while the non-relevant are made opaque. This new feature will improve productive as it allows you to quickly see what is relevant for the piece of the map you’re currently work on.

This is also true for functoids selection. If I select the concatenate functoid for example all relevant links and functoids of that are emphasized:

If one the elements for your current selection is on another page in the map this is also shown. Let’s add another page to the map and also link the ‘Lastname’ field from there:

When I switch back to page 2 and select the ‘Lastname’ node again the mapper shows me that the other page also has link(s) from the same element. The mapper does this by showing a little icon in on the page tab:

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.

As you might now the grid area of the BizTalk mapper is a lot bigger than the area shown on the screen. In some cases you might have functoids somewhere on the grid area but not visible on the screen:

To get an idea of the complete link structure you had to manually scroll the grid up and down. In BizTalk 2010 this can be done automatically. This feature is called ‘auto scrolling’ and can be toggled using a button in the mapper ribbon:

If we press the button and select the relevant node the functoid is connected to (in this case the ‘Gender’ node) the relevant functoids are automatically brought into view:

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 previous versions of the mapper there was limited support for searching elements in the source or destination schema. The new mapper has extensive support for searching. Two great things of the new search are:

· Search happens instantly (while you type)

· You can define the scope of the search by setting search options. The search is not limited to elements in the schemas.

Searching is done by typing in the mapper ribbon:

You can even search within the content of functoids (when turned on). When I have two C# scripting functoids with the following code:

public string MyConcat(string param1, string param2)

{

return param1+param2;

}

public string MyConcat(string param3, string param4)

{

return param3+param4;

}

I can search for this code. When the mapper finds the searched string the functoids that contain the string are highlighted.

Searching for string ‘param’ highlights both the functoids:

Searching for string ‘param3’ highlights only the second functoid:

So what is the greatest new feature in BizTalk 2010? For me it is by far sizeable code window for expression shapes and message assignment shapes in the orchestration designer.

Although this seems like a small improvement it was many times requested and really makes the live of a BizTalk developer easier.

If you follow my blog you might know I wrote the expression maximizer utility a couple of months ago. This was actually a fun project for me to be able to join in the BizTalk tip contest on BizTalk gurus. I must admit though that I use it in my day to day development work.

I’m very excited that Microsoft has a similar feature out of the box. I gives me the same feeling when they added the browse button next for file ports in the admin console in BizTalk 2006 .

The expression window is now a standard visual studio window. This means you can for example dock it into the right pane:

But you can also use it in the normal way:

and resize it:

Zooming in the window is also possible. Handy if you need to do a demo:

Cool! Thank you Microsoft!

http://maxime-labelle.spaces.live.com/Blog/cns!D8D9369449D177DA!236.entry

Maxime added support for deploying vocabularies and policies to the PowerShell provider for BizTalk. In our opinion this is the easiest way to deploy BRE artefacts.

For now it is only available when you grab and build the latest sources. It will be included in the final 1.0 release of course.

Great work Maxime!

Untyped policies work great when tested directly in the Business Rules Composer interface or when executed from .Net code. Unfortunately I stumbled across a nice issue when I wanted to call the rules from an orchestration using the call rules shape.

In my first design of the orchestration I received a message of type System.Xml.XmlDocument. After that I used a call rules shape to execute the policy. Because this is an untyped policy it will only accept a message of System.Xml.XmlDocument as input.

Easy! Well, not exactly. While testing this orchestration I did not encounter an exception but found out my rule also did not fire. I enabled rule tracking and saw that my message was not asserted as a fact into the BRE. The tracked information was ‘fact not recognized’.

I tried some things to fix this without success. I ended up viewing the generated C# code for the orchestration and noticed a difference in the code generated for the call rules shape when using untyped and typed policies. For typed policies a new instance of Microsoft.RuleEngine.TypedXmlDocument is created  as a fact wrapper around the orchestration message. This TypedXmlDocument is then passed on to the BRE. For untyped policies this is different. There is no TypedXmlDocument created and the XmlDocument message is passed directly on to the BRE.

So in pseudo C# code, for a typed policy:

typedXDoc = new Microsoft.RuleEngine.TypedXmlDocument("MessageType”, (System.Xml.XmlDocument)orchestrationMessage);
policy.Execute(typedXDoc);

for an untyped policy the code looks like this:

policy.Execute((System.Xml.XmlDocument)orchestrationMessage);

The obvious difference between the two is that the first uses a ‘TypedXmlDocument’ instance to wrap the message. I expected the XLANG code generator to do the same for the untyped version but that is not the case. So what does this mean? Does this mean untyped policies are not supported? Or at least not in orchestrations? Is the only option to use code in an expression shape or helper class to execute untyped policies from within an orchestration?

Because I was completely stuck here I decided to ask BRE (and BizTalk) guru Charles Young for help. 

It turned out that I had to use the special ‘Any’ schema to solve this. As Charles explained to me there are two ways of working with untyped messages in BizTalk. One is the famous XmlDocument approach, the other one is the (undocumented) ‘Any’ schema.

One of the differences between the XmlDocument and ‘Any’ schema is that the latter is treated as a schema type by BizTalk. This means the XLANG code generator will wrap it inside a TypedXmlDocument for a rules call. This exactly like the way it works for a typed policy.

The only two things I had to do was change were the message type from ‘XmlDocument’ to ‘Any’ and accordingly the policy.

This is a picture of the revised orchestration.

The changes needed in the policy are described in a rewritten version of the original post. You can find it here.

A demo solution around this can be downloaded from here. It contains two orchestrations. One which uses the XMLDocument approach without the rules getting fired. The other using the Any approch with the rules getting fired. Remember to change to paths in the binding file before deploying.

Full credits for this solution go to Charles Young. Charles thanks for helping me out.

I this post I will use the exact same sample as in the previous post. These are the schemas used:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"

xmlns="http://UntypedBRE.FirstSchema"
targetNamespace='http://UntypedBRE.FirstSchema'

xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="FirstSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"
xmlns="http://UntypedBRE.SecondSchema"
targetNamespace='http://UntypedBRE.SecondSchema'
xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="SecondSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003"

xmlns="http://UntypedBRE.ThirdSchema"
targetNamespace='http://UntypedBRE.ThirdSchema'

xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="ThirdSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

In my sample policy I want to check the ‘FirstName’ element. If the value is equal to ‘John’ I want to fill the ‘IsJohn’ element with value ‘yes’. The policy (and single rule) should work for all the above schemas.

The problem is that mentioned schemas belong to a different namespace and have a different rood node, hence in BizTalk terms have a different message type. Because XML schemas facts in the BRE are by default tightly coupled to a specific schema the consequence is that those facts can only operate on a single type of message.

In order to make this generic you have to do the following:

1. Add one of the schemas to the Facts Explorer in the BRE

2. Make the schema general

As you can see the Document Type resembles the type of the schema I added. To make this generic I change this value to ‘Microsoft.XLANGs.BaseTypes.Any’. This will make sure that if I use a fact from this schema in a rule it will not be typed to this schema but will be generic:

3. Create the rule

In this step I create the rule. The facts will be filled in later.

4. Modify the XML facts

In the rule I need to evaluate the ‘FirstName’ fact and optionally set the ‘IsJohn’ fact. Because I want this to work on all schemas I need to define the facts in a generic way. If I click on the ‘FirstName’ fact I can see the xpath statements that point to this fact in the property pane:

The ‘Xpath Field’ and ‘Xpath Selector’ properties are directly referring to ‘FirstSchema’ root node and namespace. I change the values to make them generic also:

Note that I’m using ‘self::node()’ here. I described this trick before here.

Now the XML fact is no longer pointing to a specific namespace or root node. It just points to a ‘FirstName’ node somewhere in Xml message.

There are of course other possible values for ‘Xpath selector’ and ‘Xpath Field’ to solve this. It all depends on the schemas. If for example the facts you need all have the same parent node you can make the ‘Xpath selector’ select the parent node and the ‘Xpath Field’ select the ‘FirstName’ element.

I do the same for the fact I want to update in the action of the rule:

5. Complete the rule by adding the facts

Finally I can drag the XML facts from the Facts Explorer to my rule to complete the condition and create a new action. Like this:

You can see that the both the condition and the action are not referring (anymore) to any specific schema  but instead to any schema that has ‘FirstName’  and ‘IsJohn’  elements.

Testing the rule with instances from two different schemas shows that this works:

One thing to note about this is that the way I changed the xpath statements for the Xml facts comes with a performance penalty. Using things like ‘//*…….’.  will make the engine go through the whole xml tree which is less efficient then using the original full xpath statement. So if performance is a strict requirement be careful using techniques like these.

Another thing is that I do not check for the existence of the nodes first. The policy will crash when an message is processed that does not contain on of the nodes used in the rule.

I wanted to do the same after the release of SP1 for BizTalk server 2006 R2. Unfortunately it appears that the version number is not updated after applying the service pack. I double checked with some other people but they faced the same issue.

I already reported this issue to Microsoft and blogged about it for the beta release of the SP but it seems they did not fix it for the final release. It think it is a bad thing as you cannot easily determine which version and sp level is running based on the version number.

Anyway the latest version number table looks like this:

I will report the issue to Microsoft again. Although I double checked with some people I might be wrong here. Please let me know if you see different behavior.

In order to still be able to determine the version number in an easy way I wrote a PowerShell script. I have a post about it here.

You cannot just look at the version number anymore because it seems SP1 of BizTalk Server 2006 R2 does not update the version number. This means the version numbers for BizTalk 2006 R2 without and with service pack 1 applied are the same. See also my blog post here.

The script will detect any BizTalk version and service pack from 2004 and later. I have tested it on different environments with different BizTalk versions. Please let me know if it is not working

Below is the source, but you can also download it from here.

# Initialization of helper variables
# BizTalk version numbers
$versionBTS2004 = "3.0.4902.0"
$versionBTS2004SP1 = "3.0.6070.0"
$versionBTS2004SP2 = "3.0.7405.0"
$versionBTS2006 = "3.5.1602.0"
$versionBTS2006R2 = "3.6.1404.0"
$versionBTS2009 = "3.8.368.0"

# BizTalk version description
$descriptionBTS2004 = "BizTalk Server 2004"
$descriptionBTS2004SP1 = "BizTalk Server 2004 with service pack 1"
$descriptionBTS2004SP2 = "BizTalk Server 2004 with service pack 2"
$descriptionBTS2006 = "BizTalk Server 2006"
$descriptionBTS2006R2 = "BizTalk Server 2006 R2"
$descriptionBTS2006R2SP1 = "BizTalk Server 2006 R2 with service pack 1"
$descriptionBTS2009 = "BizTalk Server 2009"

# Registry paths
$bizTalkRegistryPath = "HKLM:\SOFTWARE\Microsoft\BizTalk Server"
$biztalk2006SP1UninstallRegistryPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft Biztalk Server 2006 R2 Service Pack 1 `[KB 974563`]'

$installedVersion = $null

# Check if BizTalk is installed:
if ((Test-Path $bizTalkRegistryPath) -eq $true)
{

# Set location to BizTalk registry key
Set-Location $bizTalkRegistryPath
$key = Get-ChildItem

# Get version number
$productVersion = $key.GetValue("ProductVersion")

switch ($productVersion)
{

$versionBTS2004 { $installedVersion = $descriptionBTS2004 }
$versionBTS2004SP1 { $installedVersion = $descriptionBTS2004SP1 }
$versionBTS2004SP2 { $installedVersion = $descriptionBTS2004SP2 }
$versionBTS2006 { $installedVersion = $versionBTS2006 }
$versionBTS2006R2
{
if ((Test-Path $biztalk2006SP1UninstallRegistryPath) -eq $false)
{
$installedVersion = $descriptionBTS2006R2
}
else
{
$installedVersion = $descriptionBTS2006R2SP1
}
}
$versionBTS2009 { $installedVersion = $descriptionBTS2009 }
}
}

if ($installedVersion -eq $null)
{
Write-Host "BizTalk Server is not installed on this machine."
Exit
}

Write-Host "BizTalk Server installation found on this machine."
Write-Host "Product version number: $productVersion"
Write-Host "Installed version: $installedVersion"

Although we will have this fixed in the 1.0 final release I decided to provide a hotfix right now for those who want to play with the beta and have a remote SQL server. This is major show stopper.

If you want to receive the hotfix please drop me an e-mail (see about page of my blog) and I will send you the fix and instructions a.s.a.p.

As an alternative you can download the latest sources from codeplex and compile them yourself.

The hotfix will also fix other reported issues:

- #3042
- #3170
- #3280
- #3390
- #3391
- #3393

When debugging BizTalk solutions you find yourself many times in a situation where you need to attach the Visual Studio debugger to the running BizTalk host instance. This is very easy to do. In Visual Studio you simply select ‘Debug’ then ‘Attach to Process’. From the dialog you select the ‘BTSNTSvc.exe’ process and finally click the ‘Attach’ button.

It gets a little more tricky when you have multiple host instances running on your development box. The dialog now shows all host instances and you need to pick the one running the artifact (pipeline component, orchestration, etc.) that you want to debug. The bad thing is that there is no readable name displayed and the only property that distinguishes between the instances is the PID (column: ID). So how do you know how to pick the correct one and go on debugging?

There are basically two approaches:

- You select all the ‘BTSNTSvc.exe’ process in order to attach the debugger to all of them.

- You use some tooling to find out the PID.

Although the first option works, it is not the best solution. Attaching to all processes takes more time and resources so it is better to just pick the right one.

Now this is nothing new and there have been a number of smart people that blogged about methods to find out the PID for a host instance. Samples are here and here.

In this post I want to show the PowerShell way of doing this.

When I use the ‘Get-ChildItems’ cmdlet on the host instances container PowerShell shows a list of ‘BTSHostInstance’ objects in the console:

Since the process id is not a property of the ‘BTSHostInstance’ object it is not shown in the list.

Fortunately the nice thing about PowerShell is that you can extend properties with extra members using the Add-Member cmdlet. In the script below I create a function that adds a a property containing the process id to every non isolated host.

function GetHostPID
{
    Get-ChildItem -Path 'Biztalk:\Platform Settings\Host Instances' | ForEach-Object {

        if ($_.HostType -ne 'Isolated')
        {
            [string]$a = (Get-WmiObject Win32_Process -filter "CommandLine Like '%$($_.HostName)%'").ProcessId
       
            $_ | Add-Member -MemberType NoteProperty -Name PID -Value $a
       
            Write-Output $_
              
        }
    } | Format-Table PID, Name, HostName, NTGroupName, RunningServer, HostType, ServiceState
}

When I execute the function I get a nice list similar to the list above but with the PID added to every row:

I can add this function to my function library so it loads automatically on startup and is always available in my PowerShell console.

Of course you can do this without the PowerShell provider for BizTalk and use WMI only. In that case it would be hard and require far more lines of code to get a nice formatted list like show above.

I’m really honored and excited. I would like to thank the people at Microsoft, community members and other people involved. Special thanks to fellow MVP Jan Eliasen (IMHO: the book will be great ) and codeplex powershell team members: Maxime and Michel.

No MVP logo? Well, I’m waiting for access to the MVP logo kit

Another option is that a new development team member has just started on a fresh development box and you want him to use the same host configuration that you have. There are a lot of other scenarios where you want to copy the configuration of your hosts and host instances to another machine.

A lot of great BizTalk people have already showed how this can be done in an automated way. Some samples are:

- VBScript and WMI
- Custom tool 1
- Custom tool 2

In this post I want to show you how this can be done using PowerShell and the PowerShell provider for BizTalk. So this is actually the next post in my series on more advanced things you can do with the provider.

I use a slightly different approach compared to the existing tools. I use a PowerShell script that can be executed on the source server. This is the server that already has the host configuration set up, for example a development server. The output of running this script is actually another PowerShell script that you can run on the destination server. This output scripts contains all necessary statements to create the hosts, corresponding host instances and settings.

This is how it works:

- execute the script
- the script prompts for the name and path of the output file:

- after a short while the script is finished and a PowerShell script is created. You can run this script on the destination server or send it to an administrator who will run it on another server.

This is the created script:

#Determine BizTalk root and switch to host container.
$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root
Join-Path $BizTalkRoot 'Platform Settings\Hosts' | Set-Location

$RunningServer = $Env:ComputerName
#Create hosts
#Create host 'ReceiveHost' and set properties.
New-Item -Path 'ReceiveHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'ReceiveHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'ReceiveHost' -Name Is32BitOnly -Value True

#Create host 'ProcessingHost' and set properties.
New-Item -Path 'ProcessingHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'ProcessingHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'ProcessingHost' -Name Is32BitOnly -Value True

#Create host 'SendHost' and set properties.
New-Item -Path 'SendHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'SendHost' -Name HostTracking -Value False
Set-ItemProperty -Path 'SendHost' -Name Is32BitOnly -Value False

#Create host 'TrackingHost' and set properties.
New-Item -Path 'TrackingHost' -HostType 'InProcess' -NtGroupName 'BizTalk Application Users' -AuthTrusted:$False
Set-ItemProperty -Path 'TrackingHost' -Name HostTracking -Value True
Set-ItemProperty -Path 'TrackingHost' -Name Is32BitOnly -Value False

#Switch to host instances container.
Join-Path $BizTalkRoot 'Platform Settings\Host Instances' | Set-Location

#Create host instances
#Create host instance 'Microsoft BizTalk Server ReceiveHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''ReceiveHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'ReceiveHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server ReceiveHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server ProcessingHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''ProcessingHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'ProcessingHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server ProcessingHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server SendHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''SendHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'SendHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server SendHost BTS2K9-DEV' -Name IsDisabled -Value False

#Create host instance 'Microsoft BizTalk Server TrackingHost BTS2K9-DEV' and set properties.
$Credential = $Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''TrackingHost''', '', '')
New-Item -Path 'hostinstance' -HostName 'TrackingHost' -RunningServer $RunningServer -Credentials $Credential
Set-ItemProperty -Path 'Microsoft BizTalk Server TrackingHost BTS2K9-DEV' -Name IsDisabled -Value False

There are a couple of things to mention about the generated script:

- This is by no means a script applicable for all situations and environments. The purpose is just to show the output script as a result of running the source script. The source script will probably need some modification to make it apply to your environment. For example the script does not take into account multi server configurations, etc.
- The output script will prompt for credentials for each host instance it will create. There are also ways to script this from source to destination. See for example here. In most cases hosts in different environments will run under different accounts which is why I choose to show a prompt each time.
- Also in this script the windows group for the host is kept the same for the destination environment. This might not be the case in your particular situation.

After running this script on the destination server I have a exact copy of my host environment on the source server.

The source script looks like this:

$ScriptFile = Read-Host 'Enter full path of script file:'</pre>
'#Determine BizTalk root and switch to host container.' | Out-File $ScriptFile
'$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root' | Out-File $ScriptFile -Append
'Join-Path $BizTalkRoot ''Platform Settings\Hosts'' | Set-Location' | Out-File $ScriptFile -Append
'' | Out-File $ScriptFile -Append

'$RunningServer = $Env:ComputerName' | Out-File $ScriptFile -Append

$BizTalkRoot = (get-psdrive -PsProvider BizTalk).Root
Join-Path $BizTalkRoot 'Platform Settings\Hosts' | Set-Location

'#Create hosts' | Out-File $ScriptFile -Append
$HostArray = @()
Get-ChildItem -Path . |  Foreach-Object {
    if (!$_.IsDefault -and $_.HostType -ne 'Isolated') {
   
        $HostArray += $_.Name
   
        "#Create host '$($_.Name)' and set properties." | Out-File $ScriptFile -Append
        "New-Item -Path '$($_.Name)' -HostType '$($_.HostType)' -NtGroupName '$($_.NtGroupName)' -AuthTrusted:`$$($_.AuthTrusted)" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name HostTracking -Value $($_.HostTracking)" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name Is32BitOnly -Value $($_.Is32BitOnly)" | Out-File $ScriptFile -Append
        '' | Out-File $ScriptFile -Append
                   
    }
}

'#Switch to host instances container.' | Out-File $ScriptFile -Append
'Join-Path $BizTalkRoot ''Platform Settings\Host Instances'' | Set-Location' | Out-File $ScriptFile -Append
'' | Out-File $ScriptFile -Append

Join-Path $BizTalkRoot 'Platform Settings\Host Instances' | Set-Location

'#Create host instances' | Out-File $ScriptFile -Append
Get-ChildItem -Path . |  Foreach-Object {
    if ($HostArray -contains $_.HostName) {
      
        "#Create host instance '$($_.Name)' and set properties." | Out-File $ScriptFile -Append
        "`$Credential = `$Host.UI.PromptForCredential('Host Instance user credentials', 'Please enter credentials for host instance ''$($_.HostName)''', '', '')" | Out-File $ScriptFile -Append
        "New-Item -Path 'hostinstance' -HostName '$($_.HostName)' -RunningServer `$RunningServer -Credentials `$Credential" | Out-File $ScriptFile -Append
        "Set-ItemProperty -Path '$($_.Name)' -Name IsDisabled -Value $($_.IsDisabled)" | Out-File $ScriptFile -Append
         '' | Out-File $ScriptFile -Append
       
    }
}

In the script I skip the default and isolated host. As with the generated output script this is just a sample and might not apply to your specific situation. The source script should be modified to confirm to your requirements and environment.

You can download the source script from here.

The other day one of my BizTalk buddies asked me if I knew a way to process different messages by the same policy in the Business Rules Engine (BRE). In other words is it possible to create some sort of generic policy that can process different types of messages?

In his scenario the schemas had some fields in common and he needed those fields to be evaluated and optionally set in a single BRE policy.

Of course you can make a policy that depends on different schemas and add rules for each schema. The bad thing about that is that you will get multiple copies of almost the same rule which might lead to a maintenance nightmare.

I created a small sample to show how this can be achieved in a single policy and single rule. Below are three very basic schemas I used in this sample:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="<a href="http://schemas.microsoft.com/BizTalk/2003">http://schemas.microsoft.com/BizTalk/2003</a>" xmlns="<a href="http://UntypedBRE.FirstSchema">http://UntypedBRE.FirstSchema</a>" targetNamespace="<a href="http://UntypedBRE.FirstSchema">http://UntypedBRE.FirstSchema</a>" xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>">
  <xs:element name="FirstSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="<a href="http://schemas.microsoft.com/BizTalk/2003">http://schemas.microsoft.com/BizTalk/2003</a>" xmlns="<a href="http://UntypedBRE.SecondSchema">http://UntypedBRE.SecondSchema</a>" targetNamespace="<a href="http://UntypedBRE.SecondSchema">http://UntypedBRE.SecondSchema</a>" xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>">
  <xs:element name="SecondSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="<a href="http://schemas.microsoft.com/BizTalk/2003">http://schemas.microsoft.com/BizTalk/2003</a>" xmlns="<a href="http://UntypedBRE.ThirdSchema">http://UntypedBRE.ThirdSchema</a>" targetNamespace="<a href="http://UntypedBRE.ThirdSchema">http://UntypedBRE.ThirdSchema</a>" xmlns:xs="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>">
  <xs:element name="ThirdSchema">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="xs:string" />
        <xs:element name="IsJohn" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

I my sample policy I want to check the ‘FirstName’ element. If the value is equal to ‘John’ I want to fill the ‘IsJohn’ element with value ‘yes’. The policy (and single rule) should work for all of the above schemas.

The problem is that mentioned schemas belong to a different namespace and have a different root node, hence in BizTalk terms have a different message type. Because XML schema facts in the BRE are by default tightly coupled to a specific schema the consequence is that those facts can only operate on single type of message.

In order to make this generic you have to do the following:

1. Add one of the schemas to the Facts Explorer in the BRE.

2. Make the schema ‘general’

As you can see the Document Type resembles the type of the schema I added. To make this generic I change this value to ‘System.Xml.XmlDocument’. This will make sure that if I use a fact from this schema in a rule it will not be typed to this schema but will be generic.

3. Create the rule

In this step I create rule. The facts will be filled in later.

4. Modify the XML facts.

In the rule I need to evaluate the ‘FirstName’ fact and optionally set the ‘IsJohn’ fact. Because I want this to work on all schemas I need to define the facts in a generic way. If I click on the ‘FirstName’ fact I can see the xpath statements that point to this fact in the property pane:

The ‘Xpath Field’ and ‘Xpath Selector’ properties are directly referring to ‘FirstSchema’ root node and namespace. I change the values to make them generic also:

Note that I’m using ‘self::node()’ here. I described this trick before here.

Now the XML fact is no longer pointing to a specific namespace or root node. It just points to a ‘FirstName’ node somewhere in a Xml document.

There are of course other possible values for ‘XPath Selector’ and ‘XPath Field’ to solve this. It all depends on the schemas. If for example the facts you need all have the same parent node you can make the ‘XPath selector’ select the parent node and the ‘XPath Field’ select the ‘FirstName’ element.

I do the same for the fact I want to update in the action of the rule:

5. Complete the rule by adding the facts.

Finally I can drag the XML facts from the Facts Explorer to my rule to complete the condition and create a new action. Like this:

You can see that the both the condition and the action are not referring (anymore) to any specific schema  but instead to any schema that has ‘FirstName’  and ‘IsJohn’  elements.

Testing the rule with instances from two different schemas shows that this works:

One thing to note about this is that the way I changed the xpath statements for the Xml facts comes with a performance penalty. Using things like ‘//*…….’.  will make the engine go through the whole xml tree which is less efficient then using the original full xpath statement. So if performance is a strict requirement be careful using techniques like these.

Another thing is that I do not check for the existence of the nodes first. The policy will crash when an message is processed that does not contain on of the nodes used in the rule.

The best way to for any application to support management and automation is to implement such functionality on top of Windows PowerShell. Windows PowerShell contains a comprehensive API which enables the implementation of Cmdlets or a Cmdlet provider and the implementation of custom hosts.

Cmdlets or a cmdlet provider
PowerShell has uniform syntax for working with commands working and container hierarchies. This is a great advantage for administrators as they only need to learn a single way of working to manage it all. By implementing cmdlets we can “translate” this PowerShell way of working in calls to an applications native management API.

This is exactly what we have done in the provider for BizTalk. Internally we call BizTalk management APIs like ExplorerOM to perform things like starting applications, exporting MSIs, etc.

A custom host
Besides implementing custom cmdlets you can also implement a custom PowerShell host. The host can be any sort of application as long as it implements the PowerShell host interfaces. It can be a Win32 app, a web app or a text console for example.

This is exactly what Microsoft has done in the most recent versions of Exchange server (2007 & 2010). Management is done using PowerShell. The graphical management console is a PowerShell host. Exchange can be managed using this GUI or for example using scripts or commands running in the command shell console that comes out of the box with PowerShell.

The diagram below shows this architecture:

Things get even more interesting since we have PowerShell 2.0. It has a new feature called remoting which allows for remote administration and automation. Remoting uses WinRm (Microsofts implementation of the WS-Management standard). Goods news is that WinRM is firewall friendly. It only uses http(s) for communication. Now the diagram looks like this:

Is this secure? Yes it is, both PowerShell and WinRM have been designed with focus on security. Both come out of the box with security enabled. Of course you still need to pay attention especially when exposing things outside the enterprise.

Back to BizTalk
For BizTalk we have a couple of options to remotely administer a BizTalk server. We can choose between: Remote Desktop, client installation of Admin console, custom web services for management tasks, etc. Of course all have their pros and cons. With PowerShell remoting we have a new additional option.

Below I’ll show a couple of screens to see how this works.

I used two virtual machines in this demo. I installed the following software on those machines:

Virtual machine 1 (name: BTS2K9-dev):

- Windows Server 2008 R2 (I know not supported for hosting BizTalk)
- SQL Server 2008
- BizTalk Server 2009
- PowerShell 2.0
- PowerShell provider for BizTalk 1.0 (beta)

Virtual machine 2 (name: Client):

- Windows Server 2008 R2
- PowerShell 2.0
- PowerShell provider for BizTalk 1.0 (beta)

The obvious but important thing to note here is that the only thing that I have installed on virtual machine 2 that is related to BizTalk is the provider. In other words I did NOT NEED ANYTHING from the BizTalk installation CD on this machine.

The first thing I needed to was to enable remoting in PowerShell. This very simple and only requires the execution of a single command ‘Enable-PSRemoting’.

Second thing I needed to do was to add the client to the list of trusted computers on the BizTalk box. This mainly needs to be done because I just wanted to communicate over http instead of https for this demo.

On the BizTalk Box the management console is shown. Note that the default host instance is stopped:

Back to the PowerShell console on the Client to do the following:

- Create a new remote session on the BizTalk Box.
- Add the PowerShell provider snap in to the session.
- Switch to the default BizTalk drive.
- Switch the location to the host instances.
- Start the default host instance.

Finally a check on the other box to see if the host instance is running to verify this has worked (need to refresh the admin console first):

As you can see in the screen shots this is really easy to do. In my opinion it is a great new, location transparent, firewall friendly, client only way of managing BizTalk Server.

The only thing left to be done is to rebuild the BizTalk Administration Console on top of Windows PowerShell.

I usually do a lot of tryouts and proof of concepts on my development box. In my urge to get things working I never spend too much time on descriptive application names. I also never clean up things after I’m done.

This will in inevitably lead to the following mess after a couple of weeks:

From time to time I feel the need to clean up this mess. I used to do this with the BizTalk Administration Console. I start on top of the list right click the application to first stop and then delete it. Then I go to the second, etc.

The problems start to arise when there are references between applications. If I delete an application that is referenced from another application I get the following warning:

I can still delete the application but the warning is annoying and takes time. The last thing I want is to lose too much time cleaning up

Things get even worse when there are assembly resources inside the application which are referred to by assembly resources in other applications. This time it is not a warning but a serious error preventing me from deleting the application.

This means I need to take this reference dependency tree into account and delete the “child” applications before their “parents”.

This all makes cleaning up my development box very annoying and time consuming which is probably why I keep postponing it in the first place.

You can nicely automate this procedure using a generic application removal script that uses the PowerShell provider for BizTalk. In the script I take advantage of the exception handling possibilities of PowerShell. I sort of do a “on error resume next”.

This is how the script works:

• - Build a list of all the applications and put them in a array variable.
• - Loop through the list and try to delete the application on top of the list.
• - When the deletion fails because of dependencies we catch, in PowerShell terms “trap”, the exception and shuffle the array a little bit so that the application that failed is moved to the bottom of the list.
• - We then continue with the application that is now on top of the list.
• - The loop will end when all the applications are removed.

This is the script:

Some details about the script:

In the fragment below we use the provider to get a list of all applications. We make sure exclude the system and default application because they cannot be deleted.

The second thing to show in detail is the error handling routine. The provider (or actually the BizTalk Management Classes library) throws an exception of type BtsException since the application is referenced and cannot be deleted. We catch this exception by using a trap statement. In the exception handler we do two things. First we make sure to set a variable in the main scope so that we know what to do with the array later. Either move the top item to the bottom or remove the top item. Second we use “continue;” to have the main routine continue with the next statement.

After running the script this is what the admin console shows:

Nice!!!!

The script can be downloaded from here

The setup (and source) can be downloaded from codeplex.

I hope BizTalk developers and administrators will find this a useful addition to their toolbox.

In the coming weeks we will provide more information on usage and show some tips.

Every time Microsoft releases a new version of BizTalk we are all very disappointed that they did not make the expression window resizable or at least bigger.

There are rumors that this is done to discourage developers to write a lot of code in those windows and move to external assemblies with helper classes instead.

Although I agree with that I still think it would be very nice to have a bigger window occasionally.

Like the “Orchestration Variable Retriever Functoid” this was on my “experimental things to do list” for a long time. I never had or took the chance to try it until BizTalk king Stephen W. Thomas announced his competition for the best BizTalk tip or trick.

Of course I want to join this competition so I started coding. Now that it is finished I must admit it has become quite a hack but it seems to work .

Anyway the “ExpressionMaximizer” will be my entry for the competition.

A quick walkthrough:

I have an orchestration with an expression shape containing a lot of code:

I double click the expression shape to open it (in normal mode):

With expression window still open I press CTRL+SHIFT+ALT+M (nice key combination ) and ……:

I have a big expression window where I can type many long lines of code!!!!

Everything is back to normal when you close the window and open it again.

Note that you first have to open the expression shape before pressing the key combination.

Want to try it yourself?
(description below is based on Visual Studio 2008)

- Download this zip file and extract it somewhere.
- Click ‘Tools’ –> ‘External Tools…’
- Press the ‘Add’ button
- Type a title, e.g. ‘Expression Window Maximizer’
- Fill in the command text box by browsing to the extracted ‘ExpressionMaximizer.exe’

- Press the ‘OK’ button
- Select ‘Tools’ –> ‘Customize…’
- Press the ‘Keyboard…’ button
- In the ‘Show commands containing:’ text box type ‘Tools.External’
- Select the correct ‘Tools.ExternalCommandX’ from the list. (You need to find out the correct entry by counting the external tools in the Tools menu).
- Click in the text box ‘Press shortcut keys:’ to set the focus to it.
- Press CTRL+ALT+SHIFT+M
- Click the ‘Assign’ button.

- Press the ‘Ok’ button.
- Press the ‘Close’ button.

I tried this on ‘Windows Server 2008 R2/VS2008′ and ‘Windows Server 2003 R2/VS2005’ without problems but I still take no responsibility for malformed windows or other disasters After all it is a big hack!

If you’re interested you can find the (VS2008) source code here.

There is also a link to a great presentation that they (Michel and Maxime) did at the French BizTalk User Group. The presentation is in the French language. For me that means I had to use the translation dictionary a lot .

Since then I received a lot of emails and comments from people that where unable to get the sample up and running. I must admit there are quite a lot manual steps to get from the downloadable source to a running BizTalk application.

This is why I updated the article. It has links to three downloads now:

• - the sources
• - installable MSI file
• - detailed setup instructions for the MSI file.

I hope this will make life easier for people who want to try it out.