Tallan's Technology Blog

Tallan's Top Technologists Share Their Thoughts on Today's Technology Challenges

Common BizTalk Deployment Issues & Solutions

Leo Wang

Deploying BizTalk application is a challenging task, which requires some special knowledge beyond desktop or web application deployment. In this blog, I will discuss some very common deployment issues and their solutions.

I usually choose manually deploy BizTalk application to other computers due to the time constraint to write automation script. A typical deployment cycle consists of three steps. First, prepare BizTalk application for deployment. I usually deploy BizTalk application to my local BizTalk server, then test it to ensure it works properly. I will check the value of Application Name of the project property pages to ensure it is specified properly. If the application name is not defined, it will be deployed to the default BizTalk application, BizTalk Application 1. Once it’s up and running, I will add some resource files to the application such as binding file for a target environment. Second, export BizTalk application. BizTalk Deployment Wizard is an excellent tool to export BizTalk application to an MSI file. Finally, import BizTalk application. I use BizTalk Administration Console to import the BizTalk application. If the previous version of the same application is deployment, I will uninstall and delete the previous BizTalk application before importing.

Above procedure seems to be simple. Especially, in the second step the BizTalk Deployment Wizard tool greatly simplifies the deployment process by creating an MSI file in matter of a few minutes. For any real world BizTalk application, however, we still need to pay attention to some common “minor” things to save us hours to troubleshoot deployment problems.

#1 Forgot to register artifacts

One of unique characteristics of BizTalk application development is that BizTalk artifacts including .Net assembly need to be registered in the BizTalk management database in the deployment time. This is why simply copying assembly dlls into GAC wouldn’t guarantee the application will run. In the runtime, BizTalk server will read the metadata from the database instead of using reflection in order to improve performance.

#2 MSI didn’t install assemblies into GAC

Did you ever wonder why MSI didn’t install your assembly into GAC? In order to install assemblies into GAC, the assemblies must be marked for a specific action such as file import, file install or add resource before exporting BizTalk application to an MSI.

 #3 Do not use binding file effectively

Manually creating settings such as send/receive ports is tedious and error-prone. Binding file provides a mechanism to simplify this process. We can export settings from our development environment, then modify it and import it to another machine. If the BizTalk application exists in the target machine, we can export a binding file from the target machine, for example, change the database connection string and/or assembly versions , then add it into the local BizTalk application before exporting. Alternatively, we can store all binding files into the source control system.

#4 Forgot to configure the security data

The exported binding file usually doesn’t include some sensitive data due to security concerns. For example, database connection password, POP3 password etc. When testing our BizTalk application, we can find the SQL adapter throw an exception, which indicates the database connection failure. In this case, we can either manually to specify the password or modify the binding file.

#5 Do not understand the difference between Import and install MSI

Although exported MSI could be installed just like any MSI files, it’s not common practice for BizTalk server in that installation doesn’t register artifact into BizTalk management database. Instead, we should import BizTalk MSI using BizTalk Server Administration console tool. The import process will add metadata into the database and copy files.

#6 Forgot to start host

Orchestration assemblies need to be loaded at runtime. Once we redeploy them, we need to stop and start BizTalk host.

Many applications could have their own deployment requirement. For instance, deploy policy and/or modify rules. It’s always a good idea to document the BizTalk deployment process for a particular application. Ultimately, we would like to see our BizTalk application deployment is a repeatable and quick process. Automation would be the answer only if we have time to create scripts or we have a deployment framework to allow us to create such scripts quickly.

Tags: BizTalk,

2 Comments. Leave new

[…]  As I discussed in my previous blog, manually deploying BizTalk application is error-prone. For every BizTalk application, developing a script to automate deployment process is absolutely necessary. One of recent projects I’m working on requires to import and deploy policies with multiple rulesets and vocabularies. BTSTask , a command line tool from Microsoft, can be used to accomplish this task. […]

Suppose two production server is running one in 01 and another is in 02 server. we have deployed application in one server .How host instances will work for both server. Please provide information in details. like if we open receive port for one server than in which server the new message will come. Same with send ports.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>