Message engine failed

SURE!

[quote:c860078cde]This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure[/quote:c860078cde]

The way BTS components communicate amongst each other is through the message box via messages. The pieces arent really connected together but rather either publish a message or subscribe to one (or many in either case)

So, one phase completes its processing (a pipeline for example) and publishes its result to the message box. this publishing contains information about that component (the publisher) and pieces of information regarding the type and state of the message.

Other phases in your flow are awaiting these messages, so they subscribe to the message in the message box. What that means is that they inform the message box engine that they are awaiting for any messages that come from publisher X for example.

and so on until the message is fully consumed by all subscribers and its lifetime completes.

So, with that said, here is the scenario that this error message is explaining; basically, one of your components published a message whose state is not complete (ie its lifetime is not finished and is expecting more processing) but no one is waiting for it.

now how to drill down and figure out where the issue is breaking. Well, first on that same error screen, find out which component is throwing that error. ( itll be in the context properties of that message ) and find out which component you WANT to follow it.

then go to your administration and go to the new query tab. select subscriptions and hit run. You’ll be able to see all the subscriptions that your message box is aware of. (mind you, you wont find what you expect obviously since you are getting this error) but look for that component that should be next in line and double click it. check out the filter and see which context properties its looking for. Compare those with the actual props of the suspended message and figure out the problem.

Most probabily you have an orchestration that is next in line and it is filtering on a recieve filter that was configured at design time. if thats the case, youll have to fix it in VS and redeploy. it you set it during runtime somehow, adjust it to match the message context props.

hope that helps… shoot with any questions and/or some more data examples if you cant get it fixed.