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]\Pipeline 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” • Developer’s 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/undeploying 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. So…What 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 • Doesn’t 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 • Doesn’t 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 group…you Install on every server in the group (where relevant hosts are instantiated!)

27. What’s 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 doesn’t act as “scoping” mechanism with respect to names of ports, etc. – those must be unique in the group. • Log history of deployment success/failure