BIZTALK DEPLOYMENT FRAMEWORK (BTDF)

SANDER NEFS

CLASSIC DEPLOYMENT VS BTDF

MSI• Pro

• Commonly known by BizTalk developers

• Cons

• Manual deployment / package creation of (non) BizTalk artefacts

• Custom scripts required for a lot of tasks

• No Automated deployment / logging scripts required

• No standard approach to handle multiple server deployment / bindings / redeploy / full server install etc

BTDF• Pro

• Components already developed, available Highly customizable / flexible

• Automated package creation of (all) artefacts, generated Wix MSI

• Lot’s of online resources / documentation on- and offline available

• Cons

• Learning curve to fully use capabilities

BTDF FEATURES

• Actively maintained / supported!

• Support for BizTalk Server 2006, 2006 R2, 2009, 2010 and 2013 and BizTalk ESB Toolkit 2.x on both 32- and 64-bit Windows

• Integration with Visual Studio 2005/2008/2010/2012 menus, toolbars and output window, plus

• Templated bindings file processing that automatically targets multiple runtime environments from a single bindings file

• Extensibility through user-defined MSBuild targets and tasks (e.g. Database deployment)

• Support for deployment of various BizTalk artifacts including:

• Messaging bindings / Orchestrations / Schemas / Maps / Pipelines / Custom components (DLL's) / Custom pipeline components / Custom functoids / Rules / and vocabularies / IIS virtual directories / Single Sign-On (SSO) applications / BAM activities / ESB Toolkit itineraries / Configuration settings infrastructure including user-friendly settings management spreadsheet,

• Full and Fast deployment modes to reduce development cycle time

• Automated packaging of entire application into standard Windows Installer MSI file

• Automated restart of one or more BizTalk host instances and IIS or selected AppPools

• Automatic addition of BizTalk application references

• Automation of the entire BizTalk application deployment and update processes

• Support for Windows XP, Vista and 7 and Windows Server 2003 through 2008 R2

• IntelliSense and Add New Project wizard

• NET API for settings access at runtime and custom ESB Resolver

• Detailed logging for informational and troubleshooting purposes

• Enables use of un-encoded XML for adapter and port configurations in binding files, allowing easy manual editing

• Single deployment script serves both development workstations and servers

• Easily customizable installation wizard for server deployments

• Support for side-by-side deployment of multiple versions of a single application

• Deployment verification via NUnit unit testing tool

• Integrated deployment of Log4Net for runtime event logging

• Automated configuration of BizTalk runtime settings including debugging features and .NET assemblyto-

• AppDomain mappings

• Automatic creation/cleanup and NTFS permission assignment of FILE adapter physical paths

• Automatic deployment of debugging PDB files to the Global Assembly Cache (GAC)

• Infinite extensibility through open-source license

CONSIDERATIONS

ADMINISTRATOR• BizTalk Administrator must

learn a new way of deployment / administration!

• Full deploy of all projects can be scripted (undeploy, deploy) fairly easy

DEVELOPER• Deployment is not based on Xml

config .Config instead of user setting in VS.Net project file (if it deploys on my machine…it does on yours…)

• .BTDF projects are not a known type in VS.Net, add the files manually in the solution

• Alignment of procedures with Administrator is essentialGeneral

1 .Net Solution is typically mapped to 1 BTDF Project which leads to an BizTalk Application

BIZTALK DEPLOYMENT FRAMEWORK

Usage

HOW TO USE

DESIGN TIME RUN TIME

Deployment

MSI

Build Server

VS.Net

BIZTALK DEPLOYMENT FRAMEWORK

Guidelines

HOW TO USE (BIZTALK 2013)

• Install the 5.1 beta 2 (latest at this moment)

• Open the BizTalk solution

• Create a new project ‘Deployment’

• Select the items to be part of the deployment

• Tick ‘Only write values different from default’

http://www.tfabraham.com/BTDFDocs/V5_0/

HOW TO USE (BIZTALK 2013)

• Nothing is shown?

• Create a ‘Deployment’ folder

• Add the items

• Important files

• Deployment.btdfproj

• Configuration

• SettingsFileGenerator.xml (excel file)

• Contains all the settings

http://www.tfabraham.com/BTDFDocs/V5_0/

CONCEPTS

• SettingsFileGenerator

• Configure settings per environment

• Settings are stored in SSO

• MasterBindings

• Bindings are modified with macro’s (e.g. URI), the URI is dynamically set based on the selected environment

• Approach: No Masterbindings Each environment will have a ‘dedicated bindings’ file

• MSBuild is used to perform the actions (all settings can be overridden

CONCEPTS

• Deployment.btdfproj (xml config file)• PropertyGroup (1) with solution name / BTS application name

• Settings per artefact type (deploy maps, schemas etc)

• PropertyGroup (2) with MSI file name guid etc

CONCEPTS

• Deployment.btdfproj (xml config file)• Additional / Custom PropertyGroups per build type

• ItemGroup (actual configuration of artefacts)

DEDICATED BINDINGS (1-3)

• Open the Settingsfile

• Specify the Bindingsfile for the environment

DEDICATED BINDINGS (2-3)

• Add the BINDINGS in the Solution folder

• Define to use the bindingsFileName from Excel as a property

DEDICATED BINDINGS (3-3)

• Add the BINDINGS in the BTDF

‘ItemGroup’ \ Additional files element

2 STEP DEPLOY/UNDEPLOY

• Consider a multi-dependent solution with a ‘decoupled’canonical model

UPDATING A REFERENCED APP

• How to update the Common?

• Replace common is not possible

• Remove the dependencies delete apps

• Versioning (complex & timeconsuming)

UPDATING A REFERENCED APP(BTDF)

• Redeploy based on already deployed environment

• Most of the steps can easily be automated

• Consistency in deployment

BIZTALK DEPLOYMENT FRAMEWORK

HelloWorld Application – suggested starting point

LAB: ‘HELLOWORLD’

• Install the 5.+ BTDF version on your environment

• Start the tutorial:

• ‘Create a Deployment Project for the HelloWorld Application’

• Goals

• Learn to use the Deployment Framework for BizTalk's Add New Project wizard

• Customize a Deployment Framework project file in the Visual Studio editor using IntelliSense

• Configure an XML bindings file for use with the Deployment Framework project

• Deploy the application as a developer using the Deployment Framework's Visual Studio integration

• Build a Deployment Framework MSI for deployment to a BizTalk server

• Deploy the MSI to the local machine as if it were a BizTalk server

GUIDELINES - IChoice: Disable starting of ports etc

<StartApplicationOnDeploy>False</StartApplicationOnDeploy>

<StartReferencedApplicationsOnDeploy>False</StartReferencedApplicationsOnDeploy>

<EnableAllReceiveLocationsOnDeploy>False</EnableAllReceiveLocationsOnDeploy>

Rationale: Starting applications is useful on dev/test not on accp/prod)

Note: These settings are part of the ‘standard’ settings, which to my knowledge cannot be overwritten, therefore you should choose the safest option.

Choice: Always use masterbindings

Rationale: Standardisation, in all application you will use, there will be some ports that use masterbindings. If this is used from the start all projects will have the same structure. In most of the case you will end up using them.

Choice: Do not use XmlEscape

Rationale: Xml Escape will modify the binding file (by unescaping the file using a adapterXpaths.txt file in the BTDF folder), the configuration .txt file does not include all possible xml escaped values such as WCF adapter settings, inflicting manual changes…which means customizations…which i do not favor.

Additionally this is a hassle when using Send ports filters and making modifications, as you have to manually change the exported bindings from XmlEscaped to unescaped…..not really ideal.

  Choice: SkipIIS/Host instance restart (include in manual)

Rationale: If (this needs to be though over) you have multiple applications, it’s likely that it’s not usefull to restart IIS/Host instances as this would be done for each application.

 

GUIDELINES - IIChoice: Use SSO - Settingfiles

Rationale: Standardisation - All settings that are required in your application should be stored in SSO, the BTDF can retrieve them in various components

Choice: Use project name <Deployment> instead of <projectname>.deployment

Rationale: Standardisation, this makes it very easy to script deployments when multiple applications are used

Choice: Only configure values that are overwritten

Rationale: This prevents very long configuration files. In most project the defaults are suitable, and once a settings is required (due to a project type) adding the setting is fairly easy.

Choice: Create folder in Project ‘Deployment\Tools’ and add all tools

Rationale: Once the BTDF project has been created, you need to add all files such as (bindings, settingsfile generator, tools etc), this allows you to add this to TFS which enables co-developers to quickly build the project  

Choice: Change the toolsversion (only after error: SDC 2006 error)

Rationale: If you receive an error on SDC Task (when using FILE tasks)

Original configuration

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Installer" ToolsVersion="4.0">

New configuration

     <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Deploy">

GUIDELINES - IIIChoice: Do I need the BTDF?

Rationale: Yes , I think in most scenarios you do, you must wonder if the learning curve for a newbie is worth the advantage. For example, a POC which lasts for a couple of days, the learning curve might not be useful.

Choice: We will need to define each project if there is more than 1 project of the same type

Rationale: the deployment framework assumes certain naming conventions and allows you to have a short .BTDF project file (only deviations needs to be specified), however, if you have multiple projects, you need to specify them all! (1 project .Schemas would mean no config, an additional project ‘External.Schemas’ would mean we need to define both Schemas projects in an ItemGroup

Feature requests

· Undeploy ESB itineraries

· Ability (or documentation how) to overwrite default settings (using parameters) such as;

‘StartApplicationOnDeploy’

- Do not GAC pipelinecomponents