How to Turn On ESB 2.0 Tracing...

If you're building a BizTalk ESB 2.0 Solution, there will come a time where you need to use custom traces and the built in ESB 2.0 Traces to help debug and track what is going on.

The way to turn on tracing for ESB 2.0 is to create a Trace Source, set the TraceSwitch to "Verbose" for the Trace Source and configure a trace listener to record the traces. That's all.

Below are the steps to do what was just mentioned:

1) Open the BizTalk Configuration file
BTSNTSVC.exe.config

2) Modify the file to contain to contain a "< system.diagnostics >" section inside the "< configuration >" element. (Verify one does not already exists because two diagnostic sections will cause the BizTalk Host instance to fail)
< system.diagnostics >

3) Inside the Diagnostics section add a source with the name: "BizTalk ESB Toolkit 2.0" (Make sure that this source does not conflict with any other sources otherwise your BizTalk Host Instance won't start.) The ESB 2.0 Toolkit is hardcoded to check for this source name before logging any details.
< sources >
< source name="BizTalk ESB Toolkit 2.0" />
< sources >

4) Inside the Diagnostics section also add a Trace Switch with the name of "BizTalkESBToolkit" sets its value to "4" or "Verbose". This trace switch is used to determine when to log or write traces, only if the value is Verbose.
< switches >
< add name="BizTalkESBToolkit20" value="4" />
</switches >

5) Add a Trace listener. If you don't already have a trace listener configured, add 1 of the many Trace listeners that come out of the box with the .Net framework: (Default, EventLog, TextWriter, Console, Text, etc.) When using the EventLogTraceListener, the initializeData attribute must be set to the source of the Tracing Event. In this case it is the "BizTalk ESB Toolkit 2.0" source.
<trace autoflush="true" indentsize="4" >
<listeners >
<add name="myListener" type="System.Diagnostics.EventLogTraceListener" initializeData="BizTalk ESB Toolkit 2.0" />
</listeners>
</trace>

Complete View of the BizTalk Configureation File

6) Restart BizTalk Host Instance and Wahlah!!!

ESB 2.0 Toolkit Traces

Controlling where Maps are processed with BizTalk ESB 2.0
(Canonical Messaging Pattern)

While implementing some ESB patterns, my team and I at Tellago were tasked with purposely running a map after the message gets published to the Message Box. Which brings up the topic of this post. If you want to control where in the processing steps a map is transformed, let's say on the receiving side, or on the sending side, we can do this with the "Routing Slip" pattern for ESB aka Itineraries.

Before I get into how this is done, let me explain why you may need to do so. One reason could be you simply want to follow a Canonical Message Exchange Pattern. Where Endpoint specific messages are transformed into a common canonicalized format. A formart in which you control and process. After processing, you may need to transform the message back into an endpoint specific format that only the endpoint understands.

The way in which we accomplished this was to apply a Transformation service before after the publishing to the Message box. In ESB 2.0 itinerary design, a Transformation step is applied before the off ramp extender and another is applied after, which the post transformation step having its container set to the Send Port/Send Off Ramp as outlined in the following Itinerary design:



This design allows for a message to come into BizTalk using one format, then transformed into a canonical format, processed and routed to a subscribing endpoint. At which point in time the message gets published to the message box. Any subscribing endpoint would then receive a copy of this message and could further process the routing slip steps. How this works is that the Itinerary is promoted into the Message context for each message copy. You can also do other forms of processing, such as normal BizTalk processing like orchestrations or other send ports.

In order to continue processing the itinerary steps after the Off ramp extender, all you need is a component that understands the itinerary that can be found inside the message context. This could be a send port with a send pipeline which contains an ESB Dispatcher component. To process the steps inside a custom orchestration, use the ESB Itinerary Utility classes to get the current step. In anycase this pattern allows for multiple steps to occur after the message is published to the message box.


Happy ESB'ng

Using the latest BRE Deployed Policy with ESB BRE Resolver...

Quick note, over the weekend I noticed that when you select a version number for a rule within the BRE Resolver inside an itinerary, it uses the specified version of a policy. If you want to allow the BRE Resolver to utilize the latest deployed version, leave the version number blank.




A colleague of mine Leandro Diaz Guerra verfied this, where he states:
"I just wanted everyone to know that you can configure the itinerary BRE Resolver for both transformation & routing services leaving policy version empty, and it will automatically run the rules with the latest deployed version, just like the Itinerary Selector in the ItinerarySelect receive pipeline."

ESB – BRE – BTS 2009 – Breaking Changes to be aware of…


While the new BTS 2009 has major improvements in its support for TFS, MS Build within it’s project structure, there was a breaking change to the Business Rule Engine Composer Schema Import process. In BizTalk Server 2004, and 2006, when importing a BizTalk Schema into the Business Rule composer, you had to be aware of the fact that the Composer did not get the Document Type property assigned correctly.

When importing the schema you had to verify the value of this property matched the fully qualified name of the .Net Schema class type.




If it did not, you must manually type it in. For BizTalk Server 2006 R2, this process was *sort of* fixed.

The way the R2 import process works is that the BRE Composer searches for a BizTalk Project file within the same directory of the Schema file. If it finds one, the import process opens the BizTalk project file, which is nothing more than an xml file, and looks for the Files section until it matches the schema name and pulls the Document Type property value from the Namespace and Root node name.

Well obviously BizTalk Server 2009 changed its project (Xml File structure) design to match MS Build project file formats, hence the support for TFS. The New format uses MS Build Item Groups, which are pointers to file locations for a Project setting.

The Business Rule Composer was not updated to refresh where the Document Type property value is pulled from, thus causing the Business Rule policies not to execute properly when using BizTalk Server 2009 and ESB 2.0.

By the way, the R2 version of the project structure still works, so theorectically, if you add a CData section to the 2009 project structure and add the Files ->Include->File sections as outlined above, then the Document Type will be pulled correctly.

So the point is- remember to manually edit the Document Type in the Business Rule Composer when using with BizTalk Server 2009 and ESB.