Today I’m sitting in a “BizTalk Administration” class being taught to 20 of my co-workers by my buddy Victor. I’ve retired from teaching internal training classes on BizTalk, so the torch has been passed and I get to sit in the back and heckle the teacher.
One thing that I finally confirmed today after having it on my “todo” list for months was the behavior of the BizTalk Admin Console when terminating messages. What I specifically wanted to confirm was the scenario presented below.
Let’s say that I have 10 suspended messages for a particular receive port.
What happens if while I’m looking at this, another 5 suspended messages come in for this service instance? I’ll confirm that 5 more came in via another “query” in the console.
So we know for sure that 5 more came in, but, let’s say I was still only looking at the “Suspended (resumable)” query tab. If I choose to”terminate” the 10 suspended messages, in reality, all suspended messages that match this search criteria (now 15) get terminated.
So even though the default query result set showed 10 suspended messages, the “terminate” operation kills anything that matches this suspension criteria (15 messages). How do we avoid this potentially sticky situation? The best way is to append an additional criteria on your Admin Console query. The “Suspension Time” attribute allows you to put a date + time filter on your result set. In the screenshot below, you can see that I’ve taken the greatest timestamp in my visible result set and used that. Even though additional failures have occurred, then don’t get absorbed by this query.
So, if you are a regular BizTalk administrator, and don’t already do this (and maybe I’m the only sap who didn’t realize this all along), make sure that your suspension queries always have a date restriction prior to terminating (unless you don’t care about messages that have arrived since the query last executed).
Technorati Tags: BizTalk