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

  • Anonymous
    December 17, 2005
    The comment has been removed
  • Anonymous
    December 19, 2005
    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.
  • Anonymous
    January 16, 2006
    The comment has been removed