BizTalk Admin Console

Anything you missing there? anything you don’t like?

I’m trying to compile a list of suggestions for it, put a comment or drop me a line….

Admin console wish list feature

I’ve been fortunate enough to have to go through a bunch of suspended items on our production server from the last week and do some impact analysis – understand what failed, why it failed, what is the impact on the business, and how we can mitigate (technically or non-technically)

I have to admit this is very interesting work, but I suspect only until it gets somewhat repetitive...

Anyway, this has made me come up with a new wish list item for BizTalk, this time for the admin console –

I was going through all the items in the list, for each one I had done some investigation, and possibly raise some queries with others to understand the process/impact/etc.

Getting answers takes a while, so I end up having a bunch of suspended/dehydrated items waiting there until I can get around to resume/terminate them.

To make matters worse - often in BizTalk server you would get more than one instance in the admin console that relates to a failure. the send port might be suspended, the orchestration sending the message might be suspended as a result and another orchestration that called that (or that is waiting for a correlated response) might simply be dehydrated)

All of this made it harder to know, at a glance, where I stand - what have I looked at, what haven't I checked yet, what is this one waiting for and which other process it relates to.

I think there are a bunch of feature that can be added to the admin console to make this work much better.

Things like being able to relate several suspended items together, tagging/colour coding items to categorise them, adding notes to items to indicate where in the investigation process I am etc.

I'm aware that there are several tools out there to help track support tickets etc. but they lack the relation to the tools admin use to monitor the application - in our world this would be primarily the BTS Admin Console!

Orchestration Statuses

I was surprised to find out there's some confusion around the possible statuses a deployed orchestration can be in, but after spending 20 minutes browsing MSDN I realised I simply couldn't find one clear description of those, so here's my attempt -

An orchestration deployed into BizTalk server can be in one of four states -

1. Unenlisted (unbound) – the process has been deployed to the server, but is unconfigured (host and/or port bindings are not set), unsubscribed and is not running.
2. Unenlisted (bound) - the process is configured, but is still unsubscribed and is not running.
3. Enlisted (stopped) – the process is fully configured, subscriptions have been created, but it is stopped.
4. Started – process is ready to run (and will do so when activated by a message)

The first two are obvious I should think, so is probably the last state, the Enlisted state however, may cause some confusion - when enlisted but stopped the orchestration's subscription is active on the message box meaning it will get evaluated for every message published. if the evaluation succeeds, the message will get queued for this orchestration but it would not start (as it is in stopped state). the messages will remain waiting until the orchestration is started or they are terminated.

Wish list: searching for expression in subscriptions

And while I'm on the subject of subscriptions (see my last post) -

In the BizTalk Administration Console you can run a query to view subscriptions (which is a huge step forward from the old subscription viewer for BizTalk 2004, I have to admit)

You can, however, only filter based on the subscription type (activation or correlation), the service name or the service ID.

What that means is that while you can find all the subscriptions that start a particual orchestration, you can't find all the orchestrations that would be started by a message arriving through a particual receive port, which would have been quite useful, don't you think?

What's even worse though, is that even if you were happy to do a lot of manual work, there doesn't seem to be any practical way of finding out this information using the admin console, although it is all there in the database -

When you bind an orchestration recieve shape to a receive port, the subscription is is created for you using the receive port's id rather than the port's name, so it would look something like -

http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {E1E7FE08-D421-4D5A-8CD8-CA51E25FA508}

This is not very readable, but, unfortunately there is a much greater problem with it -

There doesn't seem to be a way to know a receive port's id through the admin console; so even if you did have the patience required to go through all your receive ports, matching their GUIDs to the one in the subscription hoping to figure out this way which ones will get your orchestration activated, you would find it impossible to find out which receive port actually has the id -'{E1E7FE08-D421-4D5A-8CD8-CA51E25FA508}'

The only way to find this out is to go to the management database and lookit up yourself in the bts_receiveport table, baring in mind, of course, that this id will change on the next deploy.