Quick Handy SQL Script to get the instance count

select sc.nvcName "Service Name", [Status]=CASE
WHEN i.nState IN(1) THEN 'Ready To Run'
WHEN i.nState IN(2) THEN 'Active'
WHEN i.nState IN(4) THEN 'Suspended (Resumable)'
WHEN i.nState IN(8) THEN 'Dehydrated'
WHEN i.nState IN(16) THEN 'Completed With Discarded Messages'
WHEN i.nState IN(32) THEN 'Suspended (Not Resumable)'
WHEN i.nState IN(64) THEN 'In Breakpoint'
END, count(i.uidInstanceID) "MsgCount" from [Instances] AS i with(nolock)
JOIN [ServiceClasses] AS sc on sc.uidServiceClassID = i.uidClassIDwhere i.uidServiceID in
(select distinct uidServiceID from [Services] with(nolock))
OR i.uidServiceID not in
(select distinct uidServiceID from [Services] with(nolock))
group by sc.uidServiceClassID, sc.nvcName, i.nState
This might not be optimized AT ALL !!

Message receive in BizTalk

A few days back, I was wondering what exactly could happen to pull in the message to the MessageBoxDb ... though I had a fair knowledge on this but I was looking for something concrete. I asked a friend of mine and he passed on this to me.


Each adapter has its own instance of a TransportProxy object that it uses to interact with the Messaging Engine. Adapters perform work against the Messaging Engine in batches, which are processed atomically. A batch is a collection of operations such as SubmitMessage, SuspendMessage, or DeleteMessage. The following is the sequence of events for the scenario where an adapter submits a message to the Messaging Engine:

1. The adapter creates a new message and connects the data stream to the message.
2. The adapter gets a new batch from the Messaging Engine.
3. The adapter adds the message to the batch to be submitted.
4. The batch is committed and queued up on the Messaging Engine thread pool.
5. The Messaging Engine thread pool starts processing the new batch.
6. The message is processed in the receive pipeline.
7. The receive pipeline produces zero or more messages. Pipelines can consume messages providing they do not return any errors. Receive pipelines can produce more than one message; typically this happens when the dissassembler component disassembles a single interchange into many messages. Typically the receive pipeline normalizes the submitted message into XML.
8. The message(s) produced by the pipeline will be processed in the mapper if mapping is configured.
9. The message(s) are published to the Message Agent or to the MessageBox database.
10. The Messaging Engine calls back the adapter to notify it of the outcome of the batch of work.