One of my most enduring projects has been the design and implementation of a custom PowerShell Provider for BizTalk Server.

For over a year and a half now, I have been participating in the design and implementation of architectures using BizTalk Server. During that time, I have always been frustrated with the relative lack of tools and support for automation of the platform. Having known about Windows PoweShell from some time I decided, on a suggestion of one of my fellow architect (and BizTalk MVP), to tackle this issue and come up with a solution.

The result of this work in progress is the PowerShell BizTalk Provider !

History

Ironically, it's only after having completed the first version that I became aware of a similar initiative. I must admit that I was a bit defeated, having spent the bigger part of the previous months to polish the version in order to be able to publish it. But Randal and I quickly decided to join forces.

Randal is great to work with and has been instrumental in funelling the work and focus of this project. He is also very active and writes on our progress on hist blog. With Michel, we are very proud of what we've done. I certainly hope to be able to provide additional and complementary contributions about the project here also, of course.

Since we produced the first alpha release back in april, there has been a small but consistent following from various sources. The project is very active currently and we are in the process of finalising our first beta version suitable for use in a real-world environment. We recently gave some publicity to the provider, so if you are interested and would like to know more, please check out the presentation^[fr] we made at the French BizTalk User Group.

Architecture

The architecture of the provider consists in two main components:

• The BizTalk Management Automation layer is a façade over the numerous and heterogeneous libraries supporting the automation of a BizTalk group. This layer serves several purposes.

  First, it helps unify the various technologies one need to use in order to effectively program against a BizTalk group. For instance, you can use the Microsoft.BizTalk.ExplorerOM assembly to start and stop applications and otherwise manipulate receive and send ports. But if you need to programmatically create a new BizTalk host or host instance, your only choice is to resort to using WMI. And if you want to export your BizTalk application to a Windows Installer package, you need to make use of yet another assembly. And on, and on.

  Of course, another purpose of this layer is to actually provide a strong foundation to build some great tools that target the BizTalk programming model. Although the boundary between dynamic and static languages is increasingly becoming somewhat fuzzy, the scenarios for using scripts versus statically compiled programs do not completely overlap. If you need a more long-term solution than what scripts can provide, you may want to create a full blown .net application or library to accomodate your needs. It is our aim that the Biztalk Management Automation layer serves this purpose.

• The BizTalk PowerShell Provider itself acts as a virtual drive and allows for navigating the hierarchy of Biztalk artifacts. We have tried to model the hierarchical store after the BizTalk Server Administration Console MMC SnapIn to make it easy for administrators and developers to familiarise themselves with the provider.

  In addition, the provider comes with a set of useful CmdLets that help perform the most common administrative tasks.

Project

Of course, there is still a lot to do. We need to add an extensive documentation, in the form of online help resources as well as articles and tutorials. That's partly what this blog is for.

The project is currently hosted on CodePlex and you can download it directly from there. If you would like to contribute, please drop me a line.