How To Package and Deploy BizTalk 2006 Applications

Packaging and deploying your BizTalk applications has been made significantly easier in BizTalk Server 2006, and I wanted to show the steps necessary in this post.

My first step, of course, was to build a working BizTalk solution. It’s a simple scenario where I pick up an “order” file, process it through an orchestration which uses a Business Rule, and then plop it back out on the file system. I then built and deployed the solution to my local BizTalk Server from within Visual Studio.NET 2005. I then created the necessary receive location and send ports using the BizTalk Explorer in Visual Studio.NET. Finally, I bound my orchestration to the recently created send and receive ports.

The next step is to build the application in the BizTalk Administration Console. Now, within the BizTalk project properties in Visual Studio.NET, you can pre-select which application to target. If you didn’t do that, you can just create a new application in the Admin Console, and then move the related BizTalk artifacts (e.g. schema, orchestration, ports, rules) into it. Then we want to make sure the application actually works, so I started it up, dropped my file, and bam!, there it was.

Now, we need to export the binding file so that we’ll have options for configuration when packaging and deploying. So, you can right-click your application from the BizTalk Admin Console, select Export and choose Bindings … You’re then asked where you’d like to drop the binding file out to. These binding files contain all the necessary configuration information for your application. Because I want to be able to use the same MSI package for any target environment, I’m going to create another binding file. So, I copied my exported binding, opened it up, and changed the file pick up and drop locations to reflect the production file system configuration. I renamed this one as PRODUCTION.

If I go back to my application in the Admin Console, and click the Resources folder, I can see all the various files (besides the standard BizTalk artifacts) that I want to include in the application. Here I can right-click, and choose to add a resource. If I point to the two binding files, BizTalk automatically sees they are of type System.BizTalk.BizTalkBinding. And then look, I can specify the target environment for each binding file! So I could potentially include binding files for all my target environments (test, staging, production) in a single MSI.

Now we right-click the application and choose to Export an MSI which causes the MSI wizard to pop up. You get asked what to call the application and where to put the finished package. After finishing the wizard, you’ve got a MSI package ready to go. My next step was to stop and then delete the BizTalk application from the Admin Console. Deleting the application actually removed the assembly from the database, deleted send and receive ports/locations, and removed my business rule. So in essence, it actually deleted all remnants of the deployed application.

Double-clicking my MSI package installs all the binary files to my machine, but does NOT configure the application. After running the MSI, the wizard tells you to import the MSI into the BizTalk Admin Console for configuration. So, on the Applications folder in the Admin Console I choose to import an application and point to the MSI package. Now, it asks me which binding file (i.e. which target environment) should be used. Neat stuff. After completing the import, my assemblies are again registered in my BizTalk database, my ports are alive, and the business rule has been re-published.

The very last step is to restart the application and make sure everything works. So, I can click on the application and select Start which then asks me which things to start up. I choose everything, so that the orchestration will be enlisted and started, the business rule will be deployed and my host will be started up. I go ahead and drop my file again, and everything processes as it did before.

Naturally this process can also be done in an unattended fashion since you aren’t expected to walk through an MSI wizard on every machine in your farm. But, it’s important to understand the steps necessary to accurately deploy your applications. I think we’ve made it significantly easier to package these applications and really reduced the opportunity for human error.

Comments (3)

  1. Benjy says:

    Richard, Interesting article. Do you know if the behavior of BTS 2006 is consistent across deploys-undeploy-modify-redeploy etc and better than BTS2004? . Im currently using BTS2004 and very often when i need to deploy changes, i cant get the existing stuff out smoothly. I have batch files that stop orchs and ports etc but they dont always work. Orchs seem to get stuck in memory especially if custom pipeline components are used and theres a lot of manual work. For the next project, im recommending BTS2006 but i need to be sure theres a more consistent story. Any thoughts?

  2. Good question. It’ll prompt a follow-up post today or tomorrow where I try and redploy the package on top of an existing, running app to see what happens.

  3. Ron Phillips says:

    Nice paper, Richard! The new MSBUILD stuff is exciting, and its an easy transition for those of us already accustomed to building NAnt-driven deploys.

    You might want to mention handling of sensitive information in binding files, like logins. I assume this gets obscured, just as with binding files in BT2004. It would really be nice to have some one-way encryption method for distributing these, or at the least something similar to the spreadsheet Colestock implemented in his deployment framework.

    As for the previous poster’s question, I suspect a race condition: if you have a script that stops an orchestration and unenlists, you need a delay put in after every step. Thus you put in a pause to make sure running instances are killed before you unenlist, and that before you undeploy the assembly, etc.

Skip to main content