What do you do if you have 1000’s of suspended orchestrations, each one would have put a message to the event log when it suspended, however the event log entry does not tell you which instance of the orchestration generated the message, given they could all be the same orchestration called 1000’s of times that is failing.
I read with interest: http://geekswithblogs.net/sthomas/archive/2004/09/20/11424.aspx
That you can get the Service Instance id of the Orchestration :
OrchestrationInstanceID = System.Convert.ToString(Microsoft.XLANGs.Core.Service.RootService.InstanceId);
When the message is displayed in hat under service instances, that will be the ID that appears on the end.
This led to us implementing a sophisticated error logging, and reporting pattern when we suspended an orchestration.
We catch all errors, you have to really, if it is fatal, we use a suspend shape to suspend the orchestration gracefully.
When we suspend, we can put additional information in the event log, like what was I doing, what was the error code, and what the orchestration id was.
This enabled our MOM/Operations staff to trap the event, and then go and find the physical orchestration in HAT.
WHY? If you use the suspend shape, it will suspend resumable, and keep all the details of what the orchestration did.
We had an additional reason for this, when we failed it was usually because of an error in an external system, not being set up correctly. Not so good if you are ½ way through a long transaction.
We would raise the error in the event log, suspend, the operations staff could then raise it with the external system, it would be configured correctly, and they could resume the orchestration, that would send the message again, and this time it should work, or suspend again.
The result was great error reporting, and no loss of transaction. Plus the bonus feature of resubmission / continuation of a message
.