BizTalk: Internals: Enlisted/Unenlisted; Started/Stopped; Enabled/Disabled. Errors and Suspended messages generated by Subscribers

Why some BizTalk artifacts can be Enlisted and Started and others can only be Enabled?
What kind of errors depends on these actions (Enlisted, Started, Enabled)?


 
One of the main rule of the BizTalk message system is:
Only messages with subscription can come to the message system. System cannot "consume" messages without subscription, otherwise they would overfill it (messages without subscription would come into the message system but could not go out, noone want them.)
 

 
There are two places where messages come into: Orchestrations ("Send Port" shapes) and Receive locations. They are "Publishers".
And two places where messages go out: Orchestrations again ("Receive Port" shapes) and Send ports. They are "Subscribers".
Operations on Publishers and Subscribers are not symmetrical in names!
 
Publishers can be Enabled/Disabled, that's all. But Subscribers can be Enlisted/Unenlisted and Started/Stopped. Enlist/Unenlist means Create_Subscribtion/Remove_Subscribtion. (I don't know why MS guys created such mess in terms. It looks like terms were taken from the transaction sciences area.) I can only propose my view of things in http://geekswithblogs.net/leonidganeline/archive/2006/12/18/101541.aspx

Subscribers should be "Enlisted". That's mean your subscribtion espressions are written to the routing table. Only after that your messages can come to the BizTalk message box. Otherwise you've got different kind the errors (see below).
 

How does the system depend of these Enlisted, and Enabled statuses? 
 
We have four variants with messages received by adapter :
 
1).
 After Subscriber is Enlisted and Started, the messages come to the Message box and then routed to the Subscriber.
 
2).
After Subscriber is Enlisted but not Started yet, the messages are waiting inside Message box in the Suspended (Resumable) state. When Subscriber is started, those messages go out from Message box to this Subscriber. [BTW We don't need to restart the BizTalk service to get the messages gone to Subscriber. Just Start the Subscriber and resume suspended messages.]
 

3).
If the Subscriber is not Enlisted, and the message type in well-known by BizTalk, we've got  4 (!) error event: 5755, 5778, 5753, and 5752. The most clear is the second:
 
"
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5778
...
Description:
The Messaging engine failed to process a message submitted by adapter:FILE Source
URL:C:\Solutions\Monitor\TestData\In\*.xml. Details:Could not find a matching subscription for the message. . This error occurs if the subscribed orchestration schedule or send port has not been started, or if some of the message properties necessary for subscription evaluation have not been promoted. Please refer to Health and Activity Tracking tool for more detailed information on this failure
...

"
 
It means the message was recognized by BizTalk, because BizTalk knows of its type. But there is no one subscription to this message. What BizTalk should do with such message? It was also processed by adapter, it is inside the BizTalk, but there is not any destination point to it.
In this case we've got those events and two Suspended (not resumable) messages in the MessageBox, one is a "Routing failure report" in the Service class field, and second is a "Messaging" in the Service class field. Why two? That is how BizTalk works with unsubscribed messages.
Bad situation: our system received a message, but it is stopped inside. For FILE adapter it means the file disappears from the drop folder, but was suspended in the MessageBox. How we can restore the file and start it again? It's a different story...

4). 
If the Subscriber is not Enlisted, and if the received by adapter message has unknown namespace or has an error by promoting the promoted properties, we've got 4 (!) error event: 5719, 5755, 5753, and 5752. The most clear is the third:
 
"
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5753
...
Description:
The "FILE" adapter is suspending a message coming from Source
URL:"C:\Solutions\Monitor\TestData\In\*.xml". Details:"Error in accessing the part data or one of its fragments. The part or fragment may not exist in the database. ".
...
"
It is similar to the previous case. One difference is we have one Suspended (not resumable) message in the MessageBox.
It is still a bad situation: our system received the message, but it is stooped inside. For FILE adapter it means the file disappears from the drop folder, but was suspended in the MessageBox. How we can restore the file and start it again? It's a different story too...
 
I would really appreciate your response!!!
Print | posted on Tuesday, February 20, 2007 1:40 PM

Feedback

# re: BizTalk: Enlisted/Unenlisted; Started/Stopped; Enabled/Disabled. Errors and Suspended messages generated by Subscribers

left by Baskar BV at 2/21/2007 4:36 AM Gravatar
Good info!

# re: BizTalk: Enlisted/Unenlisted; Started/Stopped; Enabled/Disabled. Errors and Suspended messages generated by Subscribers

left by LG at 5/15/2008 7:52 AM Gravatar
I think your orchestrations were finished by delay shape or something else and gone to the suspended state. I mean they should waiting the message [from this stoped port].
http://msdn.microsoft.com/en-us/library/aa561219.aspx - "Resuming Suspended Service Instances of a Specific Orchestration Using WMI"

# re: BizTalk: Enlisted/Unenlisted; Started/Stopped; Enabled/Disabled. Errors and Suspended messages generated by Subscribers

left by sandeep at 5/15/2008 7:57 PM Gravatar
Actually this is the scenerio.

I stop my orchestration.
The receive port picks up the message and drops into msgbox. Since the subscribing orch is stopped, the message gets suspended.
Now after sometime i start the orchestration, the suspended orchs do not resume atutomatically. I have to manually do that in Admin Console o use a WMI query.

Why do they not get resumed automatically?


Now if it was a send port instead of a orchestration, then the messages get resumed automatically.
Why is it so?

Please advice.

Thanks
Sandeep
Post A Comment
Title:
Name:
Email:
Comment:
Verification: