biztalk server development best practicesbiztalkusergroup.se/blogs/info/biztalk dev… · ppt...
TRANSCRIPT
BizTalk Server DevelopmentBest Practices
Brian Loesgen Principal SOA ArchitectMicrosoft Corporation
Alan SmithDeveloper, Trainer, Mentor, EvangelistKnowIT
Theme for this presentation…. Chronology of this presentation This is an interactive presentation, not a
multicast Audience participation is encouraged – AND
EXPECTED! You may have had experiences we have not,
we want to hear about them, and they could help others. Please share!
22
Agenda Infrastructure considerations:
Development environments Project structure Naming conventions Deployment Debugging Testing
Architectural Considerations Loose coupling Exception Management BAM Schema visibility Service-enablement
Administration Best Practices
Infrastructure Considerations
Development Environments
BizTalk is a *server* product, there is no “play” button in VS.NET for it
DO NOT use XP as a development environment Shared environments can be problematic
(other people stopping your services, consuming your messages, polluting your event log, etc)
Virtual machines are the way the experts do it Fully self-contained virtual machines are best
Capture messages from external systems like SAP so you can “spoof” them when disconnected
Project Structure: General
Assuming a local database, change the server name to “.”
Use relative paths Share a key between projects in an application Define and adopt a common folder structure,
something along the lines of: C:\projects\<client>\<application>\
Projects Documentation Deployment\Scripts Deployment\Bindings Etc…
Project Structure: Stratification For simple “one off” projects, it’s OK to put all artifacts into a single project For more complex projects, stratify projects by artifact type:
Schemas Maps Process Pipelines Helpers
Naming Conventions Naming conventions don’t really matter in your
isolated environment, but become absolutely critical when deployed to a share environment
Naming convention should be adhered to Newbies sometimes have issues renaming
artifacts as BizTalk uses the initial name for things like namespaces, be careful renaming and be aware of the points of impact
Deployment Deployment of a BizTalk solution does not have to be
difficult MSIs are *the* unit of deployment, use them! Creation of MSIs should be scripted using BTSTask,
yielding a highly-repeatable way to add resources to a BizTalk application and generate MSIs (sometimes it’s OK to use the UI)
Be kind to your infrastructure folks, use different binding files for different environments. You should NOT include production passwords of course, but accounts, URIs and machine names are usually OK; providing them could eliminate the risk of confusion/mis-configuration
Deployment NEVER deploy to production from Visual Studio (and
keep it off your production servers)! Remember that other resources can be packaged in
the BizTalk solution MSI, including: Business rules Virtual roots (eg: Web service receive locations) Helper classes that need to be GACed Support DLLs that may be required by an adapter (eg: SAP)
that can either go into the GAC or in the file system Post-processing scripts
Once I have my script to generate an MSI, it takes a couple of minutes to create a complete deployment package for a complex solution, and… it only takes a couple of minutes to install it in a target production environment
Debugging Get the SysInternals Debug View tool, write breadcrumbs for yourself
from an expression shape with System.Diagnostics.Trace.WriteLine The Best Practices Analyzer can be a great platform reviewer for you Spend time getting to know the BizTalk admin tool
Notice the orchestration debugger Notice the subscription viewer, look at some subscriptions, see what’s under
the covers
Testing Nunit is a great tool that can be used for
BizTalk solutions too BizUnit build on Nunit by adding additional
test steps From a purist standpoint, this is however
not really unit testing, it’s functional testing Profile your orchestrations to ensure code
coverage from the test
Architectural Considerations
Loose-coupling BizTalk is a pub/sub engine, use it!! Use direct-bound ports where possible
Decouples processes More extensible, new subscribers can be added post-deployment Promotes a services-oriented mindset
Filter options: Context properties (best choice as not bound by message type) Message content that has been promoted as promoted properties
Exception Management BizTalk solutions often span multiple
technologies, you need a unified exception handling mechanism
The ESB Guidance provides such a mechanism
An effective exception management strategy will simplify troubleshooting, and allow delegation of troubleshooting to non-administrators
BAM In most cases, operational metrics are very
important and useful as they can provide insights into solution performance
You have not properly implemented a solution if there is no visibility into the solution
BAM can be used for operational metrics (“show me order service failures over time”), as well as business metrics (“how many orders did we get?”)
You have BAM, use it!
Schema Visibility Define canonical schemas that are your
internal representation of data Generally, canonical schemas should not be
exposed to the outside world as this would complicate change. Instead, map to your canonical schema
Service-enablement By default, Windows 2003 Server is shipped
as a file server [HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\BTSSvc$BTSHOST\CLR Hosting] “MaxIOThreads”=dword:00000064 “MaxWorkerThreads”=dword:00000064 “MinIOThreads”=dword:00000019 “MinWorkerThreads”=dword:00000019
See http://msdn.microsoft.com/msdnmag/issues/07/05/BizTalk/default.aspx#S5 for proper usage!
Seek out knowledge Remember “teh Interweb”! ;) You are not
alone, there are many, many BizTalk resources out there that can help you
Did you know an SDK installed when you installed BizTalk? It’s true, take a look, lots of valuable samples
Online samples: http://msdn2.microsoft.com/en-us/biztalk/aa937647.aspx
Summary BizTalk is a development environment and platform, and as
such, encompasses a broad range of technologies BizTalk development does not need to be difficult BizTalk deployment does not need to be difficult Adherence to standards, and accepted best practices, will
greatly simplify development, troubleshooting and deployment of BizTalk solutions
Resources: Microsoft Home Pages
BizTalk Product Website: http://www.microsoft.com/biztalk/
BizTalk Server Developer Center: http://msdn.microsoft.com/biztalk/ BizTalk Server TechCenter on TechNet:http://www.microsoft.com/technet/prodtechnol/biztalk/ Microsoft SOA:http://www.microsoft.com/soa
Resources: Learning LinksBizTalk Server 2006 Tutorials: http://msdn2.microsoft.com/enus/library/aa560270.aspx
BizTalk Server Virtual Labs: http://msdn.microsoft.com/virtuallabs/biztalk/ BizTalk Beginner Training Roadmap (BizTalk Server Team Blog): http://blogs.msdn.com/biztalk_server_team_blog/archive/2006/03/21/556994.aspx
Learning BizTalk Server 2006 - BizTalk Server Developer Center: http://msdn2.microsoft.com/en-us/biztalk/aa937649.aspx
BizTalk Webcasts: http://msdn2.microsoft.com/en-us/biztalk/aa937645.aspx
Resources: ToolsBizTalk Server 2006 Best Practices Analyzer (BPA) : http://www.microsoft.com/downloads/details.aspx?familyid=dda047e3-408e-48ba-83f9-f397226cd6d4&displaylang=en
BizTalk Documenter: http://www.codeplex.com/BizTalkDocumenter BizUnit: http://www.codeplex.com/bizunit
BizTalk Pattern Wizard:http://www.codeplex.com/PatternWizard
BizTalk Orchestration Profiler:http://www.codeplex.com/BiztalkOrcProfiler
Resources: Blogs
BizTalk, WCF, WF, SOA, ESB aggregator: http://www.BizTalkBlogs.com
Bloggers Guide to BizTalk (archived posts, “best of”):http://bloggersguides.net/
Alan Smith’s blog:http://geekswithblogs.net/asmith/Default.aspx
Brian Loesgen’s blog: http://blog.BrianLoesgen.com
Resources: Books