My friend Carlos Medina has posted a BizTalk functoid that lets you get the value of a context property of a given message from inside a map when it is executed inside an orchestration context. It's a fairly obscure, ugly, unsupported hack  :-), but a cool piece of code nonetheless!

I've just uploaded a version of my Fix Encoding Pipeline Component I had written for BizTalk Server 2006 that has been retro-ported to BizTalk Server 2004.

The code is not exactly the same and it is not so pretty, but mostly because  the .NET Frramework 1.1 does not have functionality to enumerate supported encodings (not even half baked like v2.0), so I hardcoded a list of encodings for the dropdown, which I hope are supported :-).

Keep in mind you'll need to GAC the component in order for the custom UITypeEditor to work!. Enjoy.

BizTalk Server 2006 offers some tools that can make it easier to diagnose routing failures in your BizTalk deployments, with the help of the new query facilities in the BizTalk Server 2006 Administration Console. Imagine for example that you've got an incoming message through a receive location that failed routing and was suspended.

The first thing you'll want to do is open up the BizTalk Server 2006 Administration Console, go to the Group Hub page and create a new query. To diagnose a routing failure, you can do two different queries.

Querying for Messages
The first possible query is to query for messages. If a routing failure occurred, you will find the message listed in the results pane in the "Suspended (resumable)" state, as the following screenshot shows:

The first record you see in the screenshot above (the one where the MessageType field is empty) is the actual message that failed routing. If you double click on it, you will see a new dialog window open where you can see the message details, as well as the message context and even the content of each part associated with the message. This is one of my favourite windows in the new UI because it is much more usable than the old HAT windows.

The second record you see in the results pane, however, is far more interesting. This one is actually a Routing Failure Report pseudo-message, which has no actual body, but contains the real state (and message context) of the message at the point the routing failure occurred. You can always recognize an RFR because its Service Class field contains the value "Routing Failure Report".

Since the Routing Failure Report contains the real message context, you can use it to check if the expected context properties were promoted, and what the values of them were. So this is the place to look for if you feel that perhaps the routing problem occurred because your pipeline or adapter didn't promote the right values or the right properties.

Querying for services
You can also start by querying for suspended service instances (message receives/sends are also service instances):

The Messaging Service Instance is the actual instance that was suspended. By opening up the Service Details window, you can look at the exact error message that was logged in the Error Information tab:

The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.

You can also see the list of messages associated with this service instance (in this case only one) in the Messages tab of the window.

By analogy, the Routing Failure Report instance is a service instance associated with the routing failure report; from here you can get access to the Routing Failure Report message as well.

Troubleshooting the routing failure
One really interesting option here is that you can right-click on either of the suspended service instances in the Query Results pane and you'll see a new "Troubleshoot Routing Failure" submenu with some options to help you diagnose why the routing failure happened:

• The Find failed service instance option will run a new query that will find you the specific service instance that failed. It is not as useful in the above example because we already new exactly what service instance it was (it had been already returned in the original query), but in cases where you have hundreds of service instances, this can make it a lot easier to find the relevant instance.
• The Show all subscriptions option will open a new query window that queries for all subscriptions defined in the message box.
• The Show all active subscriptions option is the same as above, but it filters the results so that only subscriptions in an Active state are returned.
• The How to troubleshoot routing failures option will open up the help topic on troubleshooting routing failures in the BizTalk help.

As you can see, BizTalk Server 2006 makes it much easier to see what’s going on in your environment and does offer a few new options integrated into the management console itself; instead of having to go through HAT to view all this stuff. Also, the new UI is great, far more usable than what HAT provided (though you still need to go to HAT for some scenarios including orchestration debugging), and gives you a much more integrated view of how subscriptions, service instances and messages relate to each other.

In BizTalk Server 2006, the BTSSubscriptionViewer.exe tool that was in the 2004 SDK is no more. Instead, the functionality to query the subscriptions defined in the MessageBox is included in the new BizTalk Server Administration Console. To find it, do the following:

1. Open up the BizTalk Server Administration Console
2. Select in the left-side tree view your BizTalk group node (for example "BizTalk Group [KEPLER:BizTalkMgmtDb]" in my machine).
3. Click on the New Query tab that appears on the right side or use the context menu to create a new query window. In the query expression pane, select "Search For - Equals - Subscriptions", and click the Run Query button.

After that, the Query Results pane will contain all the subscriptions defined in your group's MessageBox. To find more details about a particular subscription, you can double click on it, or right click and select "Subscription Properties" from the context menu. A new dialog will pop up: the General Tab will contain some basic information about the subscription, but the most interesting information will be in the Expression tab, which contains the filter expression that defines this subscription.

When using the MIME/SMIME Decoder Pipeline Component in BizTalk Server 2004 and 2006, you might get an error at runtime saying that "The revocation status of the certificate used to sign the message is unknown" or something to that effect.

The cause of this error is that BizTalk is trying to check for certificate revocation against the Certificate Revocation List (CRL) of the certificate authority that generated the certificate used. There are two ways to fix this problem:

The first one (and I would say preferred one in some scenarios) would be to configure things so that BizTalk can actually query the CRL. How this is done will depend on who your certificate authority is.

The second option is the easiest, though most insecure one, and is to disable CRL checking altogether. You do this by setting the "Check Certificate Revocation" property of the MIME/SMIME Decoder component to false, like this:

Once you've done this, just recompile and re-gac (or redeploy) your pipeline and you'll be all set. I would also recommend checking the BizTalk Server 2004 Technical Guide for Certificate Management document, which should provide some good practices for working with X.509 certificates in BizTalk Server.