Deployment, Monitoring, Administration Strategy for BizTalk Projects
1 Introduction
1.1 Key Definitions for Acronyms
1.2 Target audience
Target audiences for this document are:
- Teams involved in defining and developing BizTalk Server based solution
- Teams involved in implementing the BizTalk based Integration Architecture.
- Teams involved in maintaining the BizTalk Server based solution
2 Solution Deployment Best Practices
In order to deploy a successful solution built around BizTalk Server, it is important to follow a standardized approach. The following sections highlight the best practices that can be adopted in order to achieve this goal.
Deploying BizTalk Server 2004 based solutions is a multi-phased task that starts with you initially installing and configuring BizTalk Server. Next, you assess your critical assets and create a plan that implements a secure topology. Use this plan to configure your development, test, and deployment environments. Lastly, complete your deployment by putting your application or assembly into production.
The following sections highlight the best practices that can be adopted to deploy your application or assembly into environment.
2.1 Deployment Process
A Microsoft BizTalk Server 2004 (BizTalk) assembly is a Microsoft Windows Dynamic Link Libraries (.DLL) file that contains resource information, such as orchestrations, pipelines, schemas, and maps to be used in a BizTalk solution. The assembly also contains the version number, the culture, and public key tokens.
All project files (source code, configuration files, assemblies, setup wizards and dll) should be maintained in source safe
When you are ready to deploy assemblies, you will have completed these tasks:
- Get all the Project specific files from Visual Source Safe
- Create a BizTalk solution containing one or more BizTalk projects.
- Added all the necessary non-BizTalk Server items to it, such as HTML files, XML files, forms, and ASP pages.
- Built each BizTalk project in the BizTalk solution to create an assembly for that BizTalk project.
The following flowchart diagram shows all the steps involved in deploying assemblies from your development environment to your target environment, for a single server deployment and Multiple Server deployment [BizTalk Server Group ] sharing the same configuration database.
2.1.1 Standard Assembly Deployment
Follow the tasks in consecutive order in this table for your standard assembly deployment. Use the flowchart map following the Black arrow Line in conjunction with this table to help you identify your location in the process from the development environment to the target environment.
| Task (Deploying Assemblies (Standard)) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add constraints |
|
|
|
2.1.2 BTSInstaller Assembly Deployment
Follow the tasks in this table for your assembly deployment using BTSInstaller. Use the flowchart map following the Red arrow line in conjunction with this table to help you identify your location in the process from the development environment to the target environment.
| Task (Deploying Assemblies using BTSInstaller) |
|
2.2 BTSInstaller for Assembly Deployment
BTSInstaller utility is used to package BizTalk Server solutions into a Microsoft Installer (MSI) file. The solutions can include BizTalk assemblies, non-BizTalk assemblies, and binding files. You then distribute the MSI file to the appropriate target servers in a group. Target environments can be development, testing, staging, or production.
BTSInstaller enables:
- Package BizTalk assemblies, non-BizTalk assemblies, and binding files into an MSI file.
- Deploy BizTalk assemblies to the Configuration database in order of dependency.
- Import BizTalk binding files into the Configuration database.
- Install BizTalk and non-BizTalk assemblies to the global assembly cache (GAC).
This section discusses the procedures used to create the MSI file in the development environment, and the tasks to perform subsequently in the target environment.
2.2.1 Development Environment Tasks
After building Microsoft BizTalk Server solution and creating the assembly files, add a deployment project to package the assemblies and other required files into a Microsoft Installer (MSI) file for deployment to a new location. The name of project is BTSInstaller.VDProj, which is located in the
<Installation Path>\SDK\Utilities\BTSInstaller folder.
Complete the following steps, in the order given, to prepare for and create the MSI file:
Step 1: Adding the BTSInstaller Deployment Project
Step 2: Adding the BizTalk Projects to the Application Folder
Step 3: Excluding Unwanted BizTalk Assemblies
Step 4: Adding Binding Files
Step 5: Installing Non-BizTalk Assemblies to the GAC
Step 6: Creating the MSI File
2.2.1.1 Adding the BTSInstaller Deployment Project
To add a new deployment project
- Deploy the solution before adding it to the deployment project.
- Use BTSdeploy to export the bindings for your solution to an .xml file, and add that .xml file to the BTSInstaller project.
- From the product CD, copy the directory SDK\Utilities\BTSInstaller into solution directory.
- In Visual Studio .NET, in Solution Explorer, open BizTalk solution, right-click the solution node, point to Add, select Existing Project, and then double-click BTSInstaller.VDProj in the BTSInstaller directory.
- Select the BTSInstaller.VDProj project, and in the Properties window modify the Title, Manufacturer, and Product Name project properties as follows.
| Use this | To do this |
| Title | Type a title name. The title appears in the user interface (UI) of the MSI file, and on the Summary page of the Properties dialog box when you select the MSI file in Windows Explorer. |
| Manufacturer | Type the manufacturer name, which is the default directory you use within the Program Files directory when you install the MSI file on the target server. |
| Product Name | Type the product name, which is the default directory you use within the Manufacturer directory when you install the MSI file on the target server. |
2.2.1.2 Adding the BizTalk Projects to the Application Folder
It is must to add projects one-by-one in reverse order of dependency, going from most to least dependent.
To add the Biztalk projects to application folder, repeat the following steps until all the projects are added.
With the BTSInstaller project selected, on the View menu, point to Editor, and then click File System.
- Right-click the Application Folder, point to Add, and then click Project Output.
Note: As an alternative to using the Application Folder, you can install assemblies directly by pointing to Add and then clicking Assembly.
- Select the project with the most dependencies first, and then click OK.
Note: The file system entry for the Project Output <project name> represents all of the generated assemblies from that project.
Note: Assemblies referenced by the Project Output are included in the Application Folder contained in the MSI file.
The BTSInstaller project automatically includes all referenced assemblies, including assemblies that you installed as part of the BizTalk Server product.
If you want to install an assembly into the GAC instead of the Application Folder, do the following:
- In the File System Editor, select the assembly in the Application Folder.
- In the Properties window, click the ellipsis (…) for the Folder property, and select Global Assembly Cache Folder.
1. Excluding Unwanted BizTalk Assemblies
To reduce the size of the MSI file, exclude some of the BizTalk product files.
To exclude unwanted BizTalk assemblies from the MSI file
- Select all files listed in the Application folder except:
- Project outputs
- Non-BizTalk product assemblies referenced by project outputs
- Other custom assemblies and their dependencies
- dll
- dll
- xsd
- xml
- In the Property pane set Exclude to True.
All the files selected are excluded from the MSI file.
Note: If these files are not excluded, MSI file can be successfully installed on the target computer, but on un-installation, the MSI file will remove BizTalk product files that could result in an inoperative BizTalk Server environment. In the event that this occurs, use the Add/Remove programs option to repair BizTalk Server 2004 installation.
2.2.1.3 Adding Binding Files
To automatically configure the application during setup, add the binding files.
- Right-click the Application folder, point to Add, and then click File.
- Select the .xml file you want to export from the Deployment Wizard, and then click OK.
- Build the deployment project to generate the MSI file.
Use the generated MSI file to install the data to the target environment. After the data is installed, you should remove the MSI file. To do this you can run the Add/Remove programs option, select your application to uninstall, and then click Remove. The Add/Remove programs option removes the application.
Note: Remember to unenlist all orchestrations prior to uninstallation, because enlisted orchestrations cannot be undeployed.
2.2.1.4 Installing Non-BizTalk Assemblies to the GAC
Install any non-BizTalk assemblies you create to the global assembly cache (GAC) on the target computer
To install non-BizTalk assemblies to the GAC
- With the deployment project node selected in Solution Explorer, from the View menu, point to Editor, and then click File System Editor.
- Right-click the root node (File system on the target computer), click Add Special Folder, and then click Global Assembly Cache Folder in the drop-down list. This adds a new GAC folder to the tree on the left pane.
- Right-click the new GAC folder and add the assemblies that you want.
Note: Do not add BizTalk assemblies, because the deployment tool installs them during the current implementation of the custom action. As a result, BTSInstaller automatically adds assemblies to the GAC during installation and removes them from the GAC during uninstallation.
2.2.1.5 Creating the MSI File
To create the MSI file
- Select the deployment project in Solution Explorer, and from the View menu click Property Pages. In the Configuration Properties list, choose Build, and set Output file name.
- Right-click the BTSInstaller project node in Solution Explorer, and then click Build. BizTalk Server generates an MSI file in the default directory within the Program Files directory that contains the deployment project BTSInstaller.VDProj.
- Send the MSI file to the administrator of the target environment.
2.2.2 Target Environment Tasks
The target environment can be a test, staging, or production environment.
To copy the MSI file to a computer
- From each computer, or using Terminal Server, run the MSI file on each destination server. By default, you install the assemblies to each GAC, but not to the Configuration database.
Important: Deploy the assemblies to the Configuration database only once in a target environment.
- To deploy the assemblies to the Configuration database, you must run the MSI file with the following parameter on only one computer in the group:
MSIEXEC /i sample.msi DEPLOY=true
The MSI file deploys the assemblies to the Configuration database and processes any binding files that may exist.
- You can enlist and start the orchestrations on each computer at any time.
2.2.2.1 Log files
After the deployment, BizTalk Server creates log files for each BizTalk assembly and binding file that is added to the deployment project. These files reside in the target directory on the destination server. They have the following names:
- For the assemblies: <assemblyname>.log.htm and <assemblyname>.log.xml
- For the bindings: <bindingfile>.log.htm and <binding file>.log.xml
The files can be displayed in a Web browser.
BTSInstaller logs informational events in the Application log, with a source set to BizTalk Installer, for each deployed assembly and binding. It logs an additional error event with deployment errors.
2.3 Policies and Vocabularies Deployment
Use the Rule Engine Deployment Wizard to deploy or undeploy a Policy/Vocabulary. In the Rule Engine Deployment Wizard, when you try to deploy, only published policy versions are shown similarly for undeployment, only deployed policy versions are shown.
To Deploy a Policy/Vocabulary
- Publish the Policy/Vocabulary to Database from File
- Deploy Policy
You can only deploy to the rule store database that you are configured against. An attempt to deploy to a different DB will give an error.
2.4 BAM Infrastructure and Deployment
Information workers use Business Activity Monitoring to gain a real-time holistic view of business processes that span heterogeneous applications, regardless of the infrastructure implementation.
2.4.1 Automating BAM Deployment
A standard installation of the BizTalk Server comes with two utilities, bm.exe and BttDeploy.exe, to get a BAM services solution deployed quickly and easily. You can call these utilities from within a windows shell script to automate a BAM services solution deployment. Discussed below are the details of automating the deployment of all the components required within a BAM solution.
- Deploying the BAM Infrastructure: After the business analyst has defined the BAM view he wants, the system administrator uses the BAM management utility (BM.EXE), a command-line tool, to deploy the BAM infrastructure from the BAM Definition Workbook or the XML exported from the workbook. The BAM management utility dynamically creates the tables, triggers, DTS packages, and OLAP cubes necessary to support the BAM view.
This process can be automated by writing a windows shell script and executing it along with other deployments.
- Deploying the Tracking Profile: New tracking profiles are created or existing ones are modified to better manage and monitor a specific business process for your organization. You use the Tracking Profile Editor (TPE) to define the data that the business analyst requires. After the tracking profile has been created, it is usually deployed from within the Tracking Profile Editor itself so that the changes take affect and the data is collected. The Tracking Profile Editor is a developer tool, and thus you cannot use it to deploy tracking profiles in a production environment. In a production environment, it is recommended you use bttdeploy.exe command line utility from the administration computer to deploy tracking profiles. You can use this utility to automate the deployment procedure by incorporating its calls in a simple windows shell script executed with rest of the deployment.
2.5 Human Workflow Services and Deployment
Human Workflow Services (HWS) is a standard part of BizTalk Server 2004. HWS provides a workflow infrastructure built on the BizTalk Server 2004 engine. Information workers access the HWS infrastructure by using Web services, so it can be used by any client application. An HWS solution deployment requires following steps to be performed on the target system.
2.5.1 Automating HWS Deployment
Windows and .net technologies offer painless ways to automate the deployment procedure for almost any BizTalk solution; you can as easily automate a BizTalk HWS solution as well. For an HWS solution following are the components that need to be deployed on the target machine, you can automate their deployment procedure as discussed below.
Deploying and Registering Actions: As ‘Action’ is the notion used for an HWS orchestration, so you deploy the actions in the same way as any orchestration. Output assembly is packaged using the BTSInstaller which later can be used on each machine, in the deployment scenario, to get the actions installed. Deployment on the last machine gets the ‘Deploy’ flag set to true to make an entry to the configuration database as well. Later you can use the BTSDeploy.exe utility to import the binding information that creates and binds the actions to their appropriate ports. This can be done by adding a custom action to the BTSInstaller; alternatively you can achieve this using a simple windows shell script. After you deploy an HWS action and get it bound to all its logical ports, WMI does rest of the trick of enlisting and starting the action in your BizTalk host application followed by registering these actions with the HWS system for constraint creation. This WMI script can also be invoked as a custom action within the BTSInstaller package doing the action deployments.
Deploying the Activity Model: You create and manipulate activity models using the activity model designer API, which you can find in the Developer Tools that comes with the BizTalk installation. Once developed, an activity model can be added to the HWS Administration Console by simply using a windows shell script.
Deploying and Installing Fact Retrievers: As a BTSInstaller package has the provision of taking non-BizTalk assemblies to a target machine, you can use this feature to port the Fact Retriever’s output assembly from staging to production. Once the assemblies are deployed, HWS Administration console is used to install fact retrievers. In an automated deployment this can be done using a simple WMI script, using the BTSInstaller custom actions, you can set to execute with each execution of a BTSInstaller package doing the non-BizTalk assembly deployment.
Adding the Constraints: In general, you use the HWS Administration console to add, edit and delete constraints. WMI provided HWS classes can come in handy to automate this process. You can incorporate a simple WMI script, adding all required constraints to the HWS system, into the BTSInstaller package doing all the HWS deployments.
2.6 Assembly Deployment Security Best Practices
In order to run BizTalk pipelines, orchestrations, maps, schemas, receive and send adapter, you must deploy the assemblies that contain these objects in each computer that run them. It is recommended you follow these guidelines for deploying assemblies in your environment:
- Each computer has a global assembly cache (GAC), which contains the assemblies that one or more applications share. You must register the assemblies BizTalk uses in the GAC of every computer that uses the components within the assembly (that is, every computer that you selected to run a host instance of that particular host), and in the GAC of the administration computer from which you enlist the assembly components into the BizTalk Hosts.
- Ensure you have the Minimum Security User Rights to deploy assemblies
- You should ensure that only BizTalk administrators have access to the assemblies and binding files, as they may contain critical business data such as connectivity and configuration information.
- BizTalk administrators must ensure they trust the source of the assembly they deploy in the system. If they deploy assemblies with code you do not trust, they may expose the BizTalk Server environment to potential attacks.
- If you deploy assemblies through a network share, ensure the share containing the assembly has a strong discretionary access control list (DACL) so that only BizTalk administrators can read the assemblies from the share.
- Whenever you perform deployment operations, BizTalk Server needs to communicate to the Configuration database. You must ensure you open the appropriate ports on the firewall between the processing, services, and data domains
- If you point to a remote location for an assembly or binding file (the latter presenting the larger risk of clear text, sensitive data), you should consider the network between the target file’s source computer and the computer you are running deployment from. If the network between these two computers is not fully isolated from potential attackers, it is recommended to copy the target file to a removable media and physically transport it to the computer where you run the deployment tool.
- In order for BizTalk administrators to deploy an assembly from a network share, the BizTalk administrator must first change the security configuration of the .NET Framework configuration from local intranet to Full Trust.
- When you create a binding file, BizTalk Server removes the passwords from the file. You need to edit the binding file and add the password before you use it. It is recommended you mask or remove the password after you use the binding file.
2.7 Business Activity Monitoring Security Best Practices
With Business Activity Monitoring (BAM), information workers can have visibility into the business Process.
- Multiple users need access to live and archived data: salespeople, business managers, and others. These users must have domain accounts in the domain where the BAM Primary Import and BAM Analysis databases are (corporate domain), but their accounts do not have access to BizTalk resources.
- In order for users to access views of the BAM data, you must use the BAM Manager Utility (BM.exe) to grant the users permissions to the views, and the users must have SQL logins.
- In order to add users to roles that have access to the cubes in the BAM Analysis database, you must have an administration computer on the same domain as the BAM databases.
- The person administering BAM must be db_owner for the BAM Primary Import, Star Schema, and BAM Archive databases. They must also be an OLAP administrator for the BAM Analysis database.
- If you are deploying Excel workbooks (.xls), you need to have Excel on the administration computer. Before you deploy a workbook, open it and ensure the macro security is set to high, and that there are no warnings.
If there is no business need to distribute to the users BAM Excel workbooks that connect to the real data, it is recommended that you deploy the workbooks by using XML files. This would eliminate the need to install Excel on the admin
Related Posts
BizTalk Migration to Azure iPaaS- Why Should You Care?
Salesforce Integration using Microsoft BizTalk Server
Azure Logic Apps: 10 frequently used integration patterns in Logic Apps- Azure Logic Apps: Top 5 use cases and the road ahead of Microsoft integration
Elephant in the room: Managing 24/7 support for your EDI projects
Integration Practice: Solutions to 3 high-level challenges that Integation practice leads come across
