Most of the time there isn’t much of a problem when developing custom activities and workflow persistence. After all when an external system send a message, the service retrieves this, extracts the WorkflowInstanceId and queue name and signals the workflow. Everything’s works just fine and if the workflow runtime restarts the message received will cause the workflow to be reloaded.
However there is a catch. Suppose the external service isn’t passively waiting for an external event but must do so in a more active mode. An example of this is a service waiting for a particular file to be recreated. In this case the service needs to be aware of the file we are waiting for even after a restart of the workflow runtime. When the workflow starts and uses a SqlWorkflowPersistenceService each workflow waiting for a DelayActivity is actually reloaded if the delay timer has expired. When this happens an OnActivityExecutionContextLoad() function is called on the activity waiting. This activity can now signal the external service that it is waiting for the file. Adding a dummy timer subscription isn’t all that hard.
Activity parent = this;
while (parent.Parent != null)
parent = parent.Parent;
TimerEventSubscriptionCollection timers = (TimerEventSubscriptionCollection)parent.GetValue(TimerEventSubscriptionCollection.TimerCollectionProperty);
TimerEventSubscription item = new TimerEventSubscription(WorkflowInstanceId, DateTime.UtcNow);
This code will prevent the requirements for an extra persistence service for use with the runtime service waiting for the file. Keep in mind though that this behavior depends on the internal, and undocumented, behavior of the DelayActivity and the SqlWorkflowPersistenceService so it could well change in the future.