ESB Toolkit Best Practices
I’ve been trying to put together a document of BizTalk best practices and have found a number of sources with a lot of great ideas. I’ll share what I’ve discovered at some point, but for now here’s one of my favorites.
It’s from Stott Creations regarding the ESB Toolkit. Below is a list taken directly from the article. Please read the full article (http://esb.stottcreations.com/biztalk-esb-toolkit-2-1-and-real-world-best-practices/) for more details:
Top 5 List of BizTalk Real-World Best Practices
| Best Practice |
Benefits and Explanation |
| In design, use the ESB Toolkit as the starting point – but not the endpoint. |
The ESB portal as delivered is to expose the capabilities of the ESB toolkit data and their relationships but is not a production grade site as-is. |
| Just Enough Logging (JEL) – scale back logging post-go live to sane levels. Do not enable tracking for ports and orchestrations, and minimize the tracking of MsgBody. Do enable tracking on Biztalk server hosts. |
Logging every message is demanding on database and storage resources, and over time becomes less valuable. After deployment, administrators and users only care if BizTalk is running and if they have the ability to drill in on errors. As a general rule, the greater the amount of logging, the less said logging is used. Minimize and target the tracking and logging you actually need. |
| Avoid complex deployment scenarios using shared custom core libraries |
As a rule of thumb, always exhaust all possible scenarios using out-of-the-box (OOTB) components to solve an issue before moving to custom code. Most scenarios can be accomplished by leveraging the samples provided, at the very least as a starting point. Shy away from starting from scratch. This also eases deployment and maintenance (no custom core components means nothing in the config files. Everything can be deployed in a comprehensive package) |
| Write tightly focused, small components |
This promotes solid designs and reusability. Break up development in small units of work and string these solutions together in the itinerary. |
| Your endpoints should always be resolved/configured via BRE over UDDI |
Power users often want to change endpoints and map types; the BRE as a resolver engine is the most powerful and flexible engine available. Comparatively UDDI both lacks intelligence and is has a complex interface configuration. |
Advertisements
