Geeks With Blogs
BizTalk SOA Evangelist BizTalk EDI MOSS VSTS SSAS and SSRS

1.      Introduction

2.      Intended Audience

 
 
 
 
Prevention is better than cure and the Best Practices document serves the similar purpose. This document is the detailed summary of all the practices and precautions you need to give due credit while developing your enterprise BizTalk Application.
All stake holders involved in the development activity including Project management team, Architect and review team, Development team, Test team.

 

Category
Technique
Reference
BizTalk configuration
Use separate Windows Groups for BizTalk Groups. Do not use a single a user for configuring all the features of the BizTalk. Please refer below link for configuration.
 
Better user management.
BizTalk configuration
Using a separate account to install/configure a BizTalk group and then after installation/configuration disable it.
Database Security.
It is good practice to have a BizTalk Setup user account in your domain that has required rights to do install and configuration of BizTalk and its databases. Use btsadmin to setup BizTalk, and disable later.  In end change owner of SQL jobs to another account.
 
 
Best Practices

 

Category
Technique
Reference
Design
Group the projects as per artifacts type.
It is a best to group the projects as per the kind of artifacts it contains. Schemas are broken into Internal, plus either External, Import and Export, or even separated by adapter: SQL, Oracle, etc. Orchestrations or Processes should be in one project.  Avoid using Transforms in Orchestrations.  Put maps in the Ports. Pipelines, if you need them, in a separate project.
Maps or Transforms in a project. 
Design
Promote only those properties that are required for routing or tracking. Use distinguished property for expression shape usage.
Performance
More processing required to find the promoted properties from the message. These properties are loaded in the memory, hence having a lot of them can put the system under extreme loads. Also, they are written to the database for tracking taking up disk space and more CPU cycles.
 
 
Overall Solution Architecture Review
 

 

Standard
Solution is organized in Visual Studio.NET and on disk in a standard fashion
Passwords are never stored in clear text
All references to explicit file paths are removed / minimized
All two-way services INTO BizTalk produce a response (either expected acknowledgement or controlled exception message)
Calls to request/response web services that take an exceptional amount of time to process are reengineered to use an “asynchronous callback” pattern
Exceptions are logged to an agreed upon location
Long-running processes have a way to inspect progress to date
Solution has been successfully tested with REAL data from source systems
Solution has been successfully tested while running under user accounts with permissions identical to the production environment
Messages are validated against their schema per use case requirements
Processes are designed to be loosely coupled and promote reuse where possible
 
 
Naming Standards Review
 

 

Standard
Visual Studio.NET solution name follows convention of:
[Company].[Dept].[Project]
Visual Studio.NET project name follows convention of:
[Company].[Dept].[Project].[Function]
Schema name follows convention of:
[RootNodeName]_[Format].xsd
Property schema name follows convention of:
[DescriptiveName]_PropSchema.xsd
XSLT map name follows convention of:
[Source Schema]_To_[Dest Schema].btm
Orchestration name follows convention of:
[Meaningful name with verb-noun pattern].odx
Pipeline name follows convention of:
Rcv_[Description].btp /
Snd_[Description].btp
Orchestration shape names match BizTalk Naming Standards document
Receive port name follow convention of:
[ApplicationName].Receive[Description]
Receive location name follows convention of:
[Receive port name].[Transport]
Send port name follows convention of:
[ApplicationName].Send[Description].[Transport]
 
Best Practices

 

Category
Technique
Reference
Schemas
Always Use Separate Internal and External Schemas
You should always transform messages you receive into your own canonical schema—regardless of how simple the schema is or who the source is. This can reduce the number of maps you need. Suppose you need to map three types of inbound messages to three types of outbound messages (perhaps not today, but maybe in the future). Applying this technique, you create a map to your canonical schema for each inbound schema and then a map from your canonical schema to each outbound schema. That’s only six maps to build and maintain, not nine.
 
Schemas
Always validate xml message against the standard schema.
Best Practice
 
Schema Review
 

 

Standard
Namespace choice consistent across schemas in project/name
Nodes have appropriate data types selected
Nodes have restrictions in place (e.g. field length, pattern matching)
Nodes have proper maxOccurs and minOccurs values
Node names are specific to function and clearly identify their contents
Auto-generated schemas (via adapters) have descriptive file names and “types”
Schemas are imported from other locations where appropriate to prevent duplication
Schemas that import other schemas have a “root reference” explicitly set
Clear reasons exist for the values promoted in the schema
Schema elements are distinguished appropriately
Schema successfully “validates” in Visual Studio.NET
Multiple different instance files successfully validate against the schema
 
Best Practices

 

Category
Technique
Reference
Transformation
Use Transformation on Receive and Send Ports when you have multiple partners sending multiple message formats and you need to convert these messages to a canonical format.
Business reason. If you embed the map in the schedule and the partner changes the format, not only do you have to rebuild the map, you have to rebuild the schedule to use the new version of the map.
Transformation
Use transformation in your orchestration schedule When you need to generate a new message in the schedule and use the modified (mapped) contents of an existing message as the base. When you want to map multiple parts of a message into one outbound message (this type of mapping cannot be done in receive / send port). There are performance gains which come from doing mappings in receive ports sometimes, but they are mostly around how many persisted messages your scenario generates and it is a bit complicated to explain.
Performance.
Transformation
Pure XSLT is much faster than XSLT which uses inline script or referenced assemblies.
Performance
Use xslt as much as possible in mapping.
Transformation
Use external XSLT or serializable classes in case of complex maps with 1000+ connections.
Maintainability.
Transformation
Do not use .NET objects directly inside the map. Use external assemblies instead.
Maintainability and Performance.
Transformation
To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly.
Performance.
The System.Policy.Security.Evidence object is often used in transforms and can consume a lot of memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.
 
Note:
 
Mapping Review
 

 

Standard
Destination schema has ALL elements defined with either an inbound link, functoid, or value.
Functoids are used correctly
Scripting functoid has limited inline code or XSLT.
Scripting functoid with inline code or XSLT is well commented
Database functoids are not used
Multiple “pages” are set up for complex maps
Conversion between data types is done in functoids (where necessary)
Map can be validated with no errors
Multiple different input instance files successfully validate against the map
 
 

 

Category
Technique
Reference
Orchestration
Eliminate orchestrations for messaging only patterns
When possible minimize the use of orchestrations to increase overall throughput and reduce the latency of business processes. If there is no need to run long running transactions and there is no need to invoke several systems for each request, then consider eliminating orchestrations and moving business logic to Receive and Send Ports to reduce the total amount of roundtrips to the BizTalkMsgBoxDb and decrease the latency due to database access. In this case, implement custom pipelines and reuse helper classes that were previously invoked from orchestrations. Use orchestrations only when strictly needed to implement design patterns as Scatter and Gather or Convoys.
Orchestration
Always Use Multi-Part Message Types
If your logical port and Receive/Send shape are using your multi-part message type, and you can easily change the underlying schema in the future without having to disconnect the port from the receive shape.
Orchestration
Optimize orchestration latency by reducing the number of persistence points.
Best practice
Orchestration
Minimize orchestration complexity to improve performance
Best practice
Orchestration
Use the Call Orchestration shape versus the Start Orchestration shape to improve performance
Best practice
Orchestration
Use XmlReader with XLANGMessage versus using XmlReader with XmlDocument to improve orchestration performance
Performance
Orchestration
minimizing the use of logical ports bound to physical ports
Performance
Orchestration
to extract or set properties used with business logic in an orchestration
If you are using a map to extract or set properties used with business logic in an orchestration, use distinguished fields or promoted properties. This practice should be followed because when extracting or setting values with a map the document is loaded into memory however when using distinguished fields or promoted properties, the orchestration engine accesses the message context and does not load the document into memory.
Orchestration
aggregate several fields into one field
If you are using a map to aggregate several fields into one field, use distinguished fields or promoted properties with an orchestration variable to accumulate the result set.
Orchestration
Use Orchestration Design Patterns when required
Performance and maintainability
Orchestration
Make appropriate use of .NET classes in orchestrations to maximize performance
Performance and maintainability
Orchestration
Orchestration Exception Handler Blocks
When using Orchestration exception Handler blocks, include all orchestration shapes in one or multiple scopes (non transactional scopes whenever possible) and create at least the following exception handler blocks:
  • An exception handler block for handling a generic System.Exception error.
  • An exception handler block for handling a general exception in order to catch and handle possible unmanaged errors, such as COM exceptions.
 
Orchestration
Always Try to Design Orchestrations with Direct-Bound Ports
You’ve got three Direct-Bound port types: Message Box Routing, Self-Correlating, and Orchestration-to-Orchestration (also called Partner Ports). Direct-Bound ports are self-configured, without sacrificing flexibility or performance. A handy benefit of Direct-Bound ports is that neither the developer nor the administrator needs to create corresponding physical ports in BizTalk Explorer or BizTalk Administration Console. So Direct-Bound ports yield orchestrations that are more self-contained, and therefore more reusable and easier to redeploy independently.
 
Orchestration
Publish Your External Schema, Not Your Orchestration
It provides loosely coupled mechanism for exposing the services. This buys you more freedom to change your orchestration without breaking the caller.
 
 
 
 
 
 
 
Orchestration Review

 

Standard
Each message and variable defined in the orchestration are used by the process
Transactions are used appropriately
All calls to external components are wrapped in an exception-handling Scope
No Expression shape contains an excessive amount of code that could alternately be included in an external component
The Parallel shape is used correctly
The Listen shape is not used in place of transaction timeouts
All Loops have clearly defined exit conditions
Where possible, message transformations are done at the “edges” (i.e. port configurations)
Calling one orchestration from another orchestration is done in a manner that supports upgrades
Correlation is configured appropriately
All messages are created in an efficient manner
The message is not “opened” in unnecessary locations
All variables are explicitly instantiated
No port operations are named the default “Operation_1″
Port Types are reused where possible
All Request/Response ports exposed as a web service are equipped with a SOAP fault message.
Orchestration has trace points inserted to enable debugging in later environments
Orchestration design patterns are used wherever possible
 
Business Rule Review

 

Standard
Business rule output tested for all variations of input
Conflict resolution scenarios are non-existent or limited
Long-term fact retrievers used for static facts
Business Rule vocabulary defined for complex rule sets
 
 

 

Category
Technique
Reference
 
 
 
 
 
 
 
 
 
Best Practices

 

Category
Technique
Reference
Administration
Do not enable Tracking for Ports and for orchestration.
Performance.
Deployment
Set the Assembly Key File with a Relative Path
This tip will help you check out the solution from version control and build it on a different box.
 
 
Deployment Package Review
 

 

Standard
“Destination Location” for each artifact uses “%BTAD_InstallDir%” token vs. hard coded file path
All supporting artifacts (e.g. helper components, web services, configuration files) are added as Resources
Binding file is NOT a resource if ports use transports with passwords
 
Configuration Review

 

Standard
Receive Port / Send Port tracking configurations appropriately set
 
Maps are applied on the Receive Port where appropriate
 
Send port retry interval set according to use case
 
Maps are applied on Send Port where appropriate
 
Send port does NOT have filter attached if connected to an orchestration
 
Subscriptions exist for every message processed by the application
 
 

 

Category
Technique
Reference
Performance
Monitor the size of databases and tables
 
Performance degrades on High Size of BizTalk databases. BizTalk Server takes a longer time than normal to process even a simple message flow scenario.
Performance
Enable tracking on BizTalk Server host
 
By default, tracking is enabled on the default host. BizTalk requires the Allow Host Tracking option be checked on a single HOST. When tracking is enabled, the Tracking Data Decode Service (TDDS) moves the tracking event data from the BizTalk Server Messagebox database to the BizTalk Server tracking database. If no BizTalk Server hosts are configured with the option to Allow Host Tracking or if the tracking host is stopped, then TDDS will not run and the TrackingData_x_x tables in the BizTalk Server Messagebox database will grow unchecked. Therefore, a dedicated BizTalk Server host should be configured with the option to Allow Host Tracking.
Performance
Use the correct BizTalk SQL Server Agent jobs
 
Execution of the BizTalk Server SQL Agent jobs are crucial for managing the BizTalk Server databases and for maintaining optimal performance.
Performance
Monitor and terminate suspended instances
 
Service instances can be suspended (resumable) or suspended (not resumable). These service instances may be Messaging, Orchestration, or Port. BizTalk Server 2009 accommodates termination and removal of these instances by using the Group Hub page in the BizTalk Server Administration Console or through the use of the Terminate.vbs script.
Performance
Monitor the performance counters of the PhysicalDisk performance object
 
BizTalk Server makes a large number of short, very quick transactions to SQL Server within one minute. If the SQL Server cannot sustain this activity, you may experience BizTalk Server performance issues. Monitor the Avg. Disk sec/Read, Avg. Disk sec/Transfer, and Avg. Disk sec/Write performance monitor counters in the PhysicalDisk performance object. The optimal value is less than 10 ms (milliseconds). A value of 20 ms or larger is considered poor performance.
 
Ensure all required BizTalk SQL Server Agent jobs are enabled and running
 
All the BizTalk SQL Server Agent jobs except the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job should be enabled and running successfully. Do not disable any other job.
 
Delete all unwanted data
 
If the databases have grown to become too large and if the data contained in the databases will not be required any longer, the preferred method is to delete the data.
 
 
 
 

 

Category
Technique
Reference
Performance
Optimize the BizTalk Registry for Web Services.
If your BizTalk orchestration is published as a Web service, you’ll definitely want to tweak some of the default ASP.NET parameters used by BizTalk. Below are the recommended settings.
 
Windows Registry Editor version 5.00
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BTSHOST\CLR Hosting]
“MaxIOThreads”=dword:00000064
“MaxWorkerThreads”=dword:00000064
“MinIOThreads”=dword:00000019
“MinWorkerThreads”=dword:00000019
 
 
Performance
Configure Parameters Used for Low Latency Performance Tuning
 
Please refer below link for more information.
 
 
Performance
Create separate hosts for orchestration, Receive and Send Ports
Creating separate hosts allows BizTalk to implement throttle mechanism and help it to load balance the incoming messages.
 
 
 
High Availability
Cluster the resources for high availability.
Clustering of MSDTC, SSO, Disk and BizTalk for High availability.
 
 
 
High Availability
Use database mirroring for BizTalk Server databases high availability.
Database mirroring of BizTalk databases helps to achieve the High Availability for Database servers and helps to recover from Failover scenarios.
 
 
 
 
1-      BizTalk Server Best Practices Analyzer V1.2
 
2-      Benchmark Wizard
 
 
 
1-      Windows Groups and User Accounts in BizTalk Server
 
2-      Installation Guide
3-      Microsoft BizTalk Server Performance Optimization Guide
 
4-      Best Practices for maintaining BizTalk Server Databases
 
5-      BizTalk Server Tips and Tricks
6-      How to maintain and troubleshoot BizTalk Server databases
 
7-      Optimizing Database performance
 
8-      BizTalk whitepapaers
 
 
10-   Optimizing Orchestration
 
11-   Schema Best Practices
 
12-   EAIPatterns

 

Posted on Saturday, May 14, 2011 6:19 PM BizTalk Concepts | Back to top

Copyright © BizTalkSOA | Powered by: GeeksWithBlogs.net