Common BizTalk Deployment Issues & Solutions
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.