BizTalk Messages

Every application needs management. Ideally an application should provide two ways of management. First an administrator needs a (graphical) console to be able to do single or ad-hoc actions like changing configuration, responding to error conditions, etc. Second there should be a way for an administrator to create and run scripts. Scripts allow administrators to store a set of repetitive tasks in a container (called a script) in order to be able to easily do the same action over and over again. This is also called automation.

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.

This is the first in a series of posts where I want to show some more advanced scripts and things you can do with the PowerShell provider for BizTalk.

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

For people interested in both PowerShell and BizTalk, I just finished a getting started guide to introduce the basics of the PowerShell provider for BizTalk (version 1.0 beta). The guide can be downloaded from here.

After a couple of months of hard work (mainly in the evenings ) we are very proud to announce the beta release of the PowerShell provider for BizTalk.

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.