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

About Ed Jones

Ed is a .NET and Integration architect for Avanade in the Twin Cities. Contact Ed

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: