Why some BizTalk artifacts can be Enlisted and Started and others can only be Enabled?

What kind of errors depends of those 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 “eat” messages without subscription, otherwise they would overfill it (messages without subscription would come into the message system but cannot go out, anyone want this.)

 





 

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“.
 

Publishers can be Enabled/Disabled, that’s all. But Subscribers can be Enlisted/Unenlisted and Started/Stopped. Enlist/Unenlist means Start_Subscribe/Stop_Subscribe. (I don’t know why MS guys created such mess in terms. It looks like something historical. (?)) 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 message type + routing parameters (here it is your promoted element) are written to the routing table. Only after that your messages (with your message type + routing parameters) 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 subscribed by this subscription can come to the Message box and then to this Subscriber .

 

2).

After Subscriber is Enlisted but not Started yet, those 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.]

 


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 namespace. 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) copies of the message in the MessageBox, one is with “Routing failure report” in the Service class field, and second with “Messaging” in the Service class field. Why two? Maybe because the message was passed to the second processing stage (Adapter –> Routing) and now it is stored in two places.
Bad situation: our system received the message, but it is stooped inside (and in two copies!). 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 copy of the 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 realy appreciate your response!!!