Your SlideShare is downloading. ×
0
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
BizTalk deployment framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

BizTalk deployment framework

1,312

Published on

My last post on the BizTalk Deployment Framework contained screenshots from my slidedeck. I've updated this deck and stripped out the bits i can't share. …

My last post on the BizTalk Deployment Framework contained screenshots from my slidedeck. I've updated this deck and stripped out the bits i can't share.

See the additional information on each slide on: http://snefs.blogspot.nl/2013/09/biztalk-deployment-framework-things-to.html

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,312
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
53
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. BIZTALK DEPLOYMENT FRAMEWORK (BTDF) SANDER NEFS
  • 2. 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
  • 3. 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
  • 4. 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 essential General  1 .Net Solution is typically mapped to 1 BTDF Project which leads to an BizTalk Application
  • 5. BIZTALK DEPLOYMENT FRAMEWORK Usage
  • 6. HOW TO USE DESIGN TIME RUN TIME Deployment MSI Build Server VS.Net
  • 7. BIZTALK DEPLOYMENT FRAMEWORK Guidelines
  • 8. 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/
  • 9. 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/
  • 10. 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
  • 11. 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
  • 12. CONCEPTS • Deployment.btdfproj (xml config file) • Additional / Custom PropertyGroups per build type • ItemGroup (actual configuration of artefacts)
  • 13. DEDICATED BINDINGS (1-3) • Open the Settingsfile • Specify the Bindingsfile for the environment
  • 14. DEDICATED BINDINGS (2-3) • Add the BINDINGS in the Solution folder • Define to use the bindingsFileName from Excel as a property
  • 15. DEDICATED BINDINGS (3-3) • Add the BINDINGS in the BTDF ‘ItemGroup’ Additional files element
  • 16. 2 STEP DEPLOY/UNDEPLOY • Consider a multi-dependent solution with a ‘decoupled’canonical model
  • 17. UPDATING A REFERENCED APP • How to update the Common? • Replace common is not possible • Remove the dependencies delete apps • Versioning (complex & timeconsuming)
  • 18. UPDATING A REFERENCED APP(BTDF) • Redeploy based on already deployed environment • Most of the steps can easily be automated • Consistency in deployment
  • 19. BIZTALK DEPLOYMENT FRAMEWORK HelloWorld Application – suggested starting point
  • 20. 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
  • 21. GUIDELINES - I Choice: 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.
  • 22. GUIDELINES - II Choice: 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 ‘DeploymentTools’ 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">
  • 23. GUIDELINES - III Choice: 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

×