Welcome to the Twin Cities BizTalk User Group

1
Welcome to the Twin Cities BizTalk User Group

• November 2005

2
Thank You

• Thanks to Digineer for sponsoring today's BizTalk
  User Group Meeting

3
Automatic BizTalk 2004 Application Deployments

• Scott Colestock
• Trace Ventures, LLC
• blog www.traceofthought.net

4
Agenda

• What are the elements of a BizTalk deployment?
• What makes it complicated?
• What are my options for getting the work done?
• What can I do with the BizTalk Deployment
  Framework (www.traceofthought.net)
• How does the deployment world change with BT2006?

5
Elements of a BizTalk Application Deployment

• Deliver metadata to BizTalk Management Database
• Schemas, Maps, Pipelines, Orchestrations
  assemblies all interrogated
• BTSDeploy.exe / BizTalk Deployment Wizard
• One time per BizTalk group
• Lee Graber analogous to regsvr32.exe
• Deliver assemblies to the GAC
• All assemblies containing schemas, maps,
  pipelines, orchestrations
• All .NET components you will call

6
Elements of a BizTalk Application Deployment (2)

• Deliver Binding Files
• Define physical ports (Send Port Groups/Send
  Ports, Receive Ports/Receive Locations)
• Associate orchestrations with host definitions
• Tie logical orchestration ports to physical ports
• Tie orchestration roles to parties
• Ancillary components
• Custom functoids to BtsInstallDir\Developer
  Tools\Mapper Extensions
• Custom pipeline components to BtsInstallDir\Pipe
  line Components

7
Elements of a BizTalk Application Deployment (3)

• Virtual directories / App pools
• BTSHttpReceive.dll or SOAP proxy
• Appropriate permissions
• Vocabulary Policies
• File drop / pickup directories ( perms)
• SSO Affiliate applications
• MSI for packaging delivering

8
Complications

• Dependency tree
• .NET dependencies via references
• BizTalk dependencies via call/start orchestration
  shapes, schema usage, etc.
• Least dependent assemblies must be deployed first
• Most dependent assemblies must be undeployed
  first
• To replace an assembly that is depended upon,
  all the dependents must be undeployed first
• (See Flanders blog for table of exceptions to
  the rule masteringbiztalk.com)

9
Direct Dependencies among BizTalk 2004 Components
10
Implications of Dependency Web

• Developers edit/build/deploy/debug cycle can be
  tricky and error prone
• Updating a pipeline component means undeploying a
  pipeline
• And all send/receive ports that use it
• Updating a pipeline might mean stopping/undeployin
  g an orchestration
• Updating a schema might mean undeploying several
  pipelines, orchestrations, and transforms

11
Implications of Dependency Web (2)

• Background All BizTalk components (except
  send/receive port definitions) are .Net
  assemblies
• Packaging components for a BizTalk 2004 project
  according to their type turns out to be good
  design
• BizTalkSample.Components.dll
• BizTalkSample.Schemas.dll
• BizTalkSample.Transforms.dll
• BizTalkSample.Pipelines.dll
• BizTalkSample.Orchestrations.dll
• BizTalkSample.PipelineComponents.dll
• Why? If these assets are grouped in assemblies
  arbitrarily, managing the dependencies becomes
  much more complex. Monolithic assemblies make
  reuse operations difficult.

12
Complications (2)

• Binding file act as a layer of indirection
• Contain references to queue names, ftp locations,
  directory/UNC locations, SOAP endpoints, email
  addresses
• These all vary by physical environment!
• But a binding file contains too much other
  structure information to make it safe for
  operations team to edit
• Most shops want binding files version controlled
  part of release management strategy

13
SoWhat do we want?

• Solution to deploy all of the components of a
  BizTalk solution to all the appropriate places
• Assemblies, IIS resources, permissions,
  directories, bindings, policies, etc.
• Manage away the complexities
• Dependency tree issues
• Environment-relative configuration
• Makes developer life easier QA/Production
  deployments repeatable

14
What are my options?

• Option 1 See BTSInstaller in BizTalk docs
• Addresses delivering assemblies in MSI
• Deploying metadata to BizTalk management database
• Some holes virtual directory management, SSO
  affiliate apps, rule engine components,
  environment-relative config
• Doesnt address developer pain
• Option 2 See BTS2004BatchFileDeployment.zip at
  http//www.gotdotnet.com/team/wsservers/bts2004
• Shows how to adapt admin scripts provided in
  \sdk\samples\admin
• Doesnt cover everything good place to start if
  rolling your own

15
Option 3 Deployment Framework for BizTalk
(traceofthought.net)

• Q What is it?
• A A set of scripts and utilities for deploying
  BizTalk solutions both on developer workstations
  and into server environments, including MSI
  packaging and environment-specific configuration.

16
Components of Deployment Framework

• BizTalkDeploymentInclude.nant
• NAnt include file to use with your projects
• Manages dependency tree coordinates deployments
• Used for workstations and servers

17
Components of Deployment Framework (2)
Utilities to

• Enlist/Unenlist/Start/Stop orchestrations and
  ports
• Preprocess xml binding files (or other xml files)
• Provide basic UI for managing environment-relative
  config
• Configure IIS vdirs, app pools, web extensions
• Selectively restart BizTalk host instances
• Create affiliate applications import
  configuration data
• Deploy policies / vocabularies
• Provide automatic MSI generation

18
Developer Experience with the Deployment Framework
19
What is required to use the Deployment Framework?

• Get full sample from www.traceofthought.net
• Run the sample
• Spend some time with the documentation
• Install NAnt according to docs
• Follow naming conventions for solution name,
  project names, directory names for ease of use
• Get core zip file for Deployment Framework from
  same location
• Expand core zip on top of your projects current
  directory structure
• What do you get?
• DeployTools/DeployResults/EnvironmentSettings
• WiXSetup directory
• Create a YourProject.sln.deploy.build file

20
Environment Relative Configuration

• Lots of elements of BizTalk binding files (or any
  xml config file!) can vary by physical
  environment
• Having operations staff manage large xml files
  can be tricky needle in haystack
• Adapter configuration is escaped xml
• We would like to extract out what varies into
  simple name/value pair management with simple UI
• (Demo)

21
Building MSIs

• Once you have all your scripts working in
  development
• All aspects of setup are being communicated
  efficiently among developers
• Why not use for the server?
• Only a subset of NAnt deployed - no services, no
  file associations for nant
• Small additional nant file required
• Redistribution directory created (to look like
  server image) WiX MSI auto generated
• (Demo)

22
Why NAnt ?

• Dependencies among BizTalk components are
  certainly no more complex than build dependencies
  for other types of software
• Tools such as MAKE/NMAKE and Ant/NAnt have always
  managed these dependencies well
• Background They allow for the natural expression
  of dependencies, such that the complete
  dependency tree is worked out by the tool

23
NAnt Background

• NAnt is the .Net version of Ant, an open-source
  build tool that expresses all of the
  functionality of a traditional MAKE tool using
  Xml
• .while adding substantial functionality!
• NAnt scripts are quite suitable for expressing
  deployment of BizTalk components
• Can be used with BTSDeploy.exe and a handful of
  WMI scripts or Explorer OM-driven custom tasks to
  control all aspects of deployment
• This includes tearing down the environment in
  the correct order so as to deploy new versions!
• This includes all assemblies, all send/receive
  ports, and all bindings

24
BizTalk 2006 Deployments

• Application concept represents grouping of
  assemblies and related resources
• You can manage and deploy at application-level
  granularity
• MSI generation (from the BizTalk Admin MMC!) is
  provided at the application level

25
BizTalk 2006 Deployments (2)

• Lifecycle
• Developer deploys assemblies within Visual
  Studio.
• Application name can be specified in project
  properties.
• Right-click solution select Deploy
• All dependency issues are managed for you
• Port definitions, additional assemblies (.net
  class libraries, custom functoids, pipeline
  components), virtual directories, pre/post
  scripts, policies, etc. are added as resources
  with the Admin MMC
• When ready, export Application as MSI (tweaking
  all physical bindings to match target environment
  for that MSI (including vdir security), or
  including variation of binding file for each)
• Import your MSI in target environment

26
MSI Details

• MSI itself appears to be prepared to deploy
  assemblies to the GAC and other file delivery
  tasks
• Work of deploying metadata to BizTalk is handled
  by the Import MSI Wizard
• Wizard allows you to declare other applications
  you reference(perhaps shared schemas and
  orchestrations, etc.)
• Introduces new dependency!
• Be extremely careful with this
• Any bindings requiring a password will have to be
  edited manually
• Starting ports/orchestrations is manual step
• You Import once per BizTalk groupyou Install on
  every server in the group (where relevant hosts
  are instantiated!)

27
Whats Missing?

• Ability to have single bindings file, with
  user-friendly merge mechanism
• Ability to supply custom UI to gather
  environment-specific credentials for IIS
  application pools, directory ACLs, etc. from
  operations personnel
• In an early beta, VS.NET only allowed undeploying
  if assemblies were in default application ?
• Application concept doesnt act as scoping
  mechanism with respect to names of ports, etc.
  those must be unique in the group.
• Log history of deployment success/failure