I recently created a retry activity that I’ve been wanting to write for some time now, and had a few features that I wanted to add. I was teaching a class a couple of weeks ago and took the opportunity to add a retry interval to the activity.  The activity is designed as a composite activity which can retry its child activities if it detects that a fault/exception has occurred.  Rather than retrying immediately, I wanted the consumer of my activity to be able to specify a TimeSpan indicating how long to wait between retry attempts.

The simplest part was adding a property that allowed people to specify the interval. 

private TimeSpan retryInt;

public TimeSpan RetryInterval 
{
    get { return retryInt; }
    set { retryInt = value; }
}

 

The next step was to actually use this information.  When the child activity closes, my Retry activity checks if it faulted and then needs to reschedule the child activity for execution.  With the interval, I need a way to wait for a duration and then schedule the activity for execution.  Since my workflow could be persisted during this interval, I have to use a mechanism that will both support passivation, and allow for the workflow to be resumed automatically when the duration has been reached.  To support this I used the same mechanism that the delay activity uses, which is to create  timer subscription and then wait for an event signaling the time has expired. 

In my event handler for closing child activities, if I determine that I should retry the child activity, I use the following code to 1) create a new workflowqueue where the timer can signal completion, 2)register for data arriving on the queue, 3) create a TimerEventSubscription with my duration and my queue information and 4) add my timer subscription the collection on the workflow. 

 

DateTime expires = DateTime.UtcNow.Add(RetryInterval);
SubscriptionID = Guid.NewGuid();
thisContext.GetService<WorkflowQueuingService>().CreateWorkflowQueue(SubscriptionID, false).QueueItemAvailable += new EventHandler<QueueEventArgs>(RetryActivity_QueueItemAvailable);
TimerEventSubscription subscription = new TimerEventSubscription(SubscriptionID, WorkflowInstanceId, expires);
TimerEventSubscriptionCollection timers = GetTimerSubscriptionCollection();
timers.Add(subscription);

 

The GetTimerSubscriptionCollection simply grabs the collection from the parent workflow by recursively climbing the parent hierarchy. 

 

private TimerEventSubscriptionCollection GetTimerSubscriptionCollection()
{
    Activity parent = this;
    while (parent.Parent != null)
    {
        parent = parent.Parent;
    }
    TimerEventSubscriptionCollection timers = (TimerEventSubscriptionCollection)parent.GetValue(TimerEventSubscriptionCollection.TimerCollectionProperty);
    return timers;
}

 

Finally, I have the event handler for when data arrives on the queue for the timer.  I simply empty and delete the queue, then begin my next iteration on the child activity. 

 

void RetryActivity_QueueItemAvailable(object sender, QueueEventArgs e)
{
    ActivityExecutionContext ctx = sender as ActivityExecutionContext;
    ctx.GetService<WorkflowQueuingService>().GetWorkflowQueue(e.QueueName).Dequeue();
    ctx.GetService<WorkflowQueuingService>().DeleteWorkflowQueue(e.QueueName);

    BeginIteration(ctx);
}

 

So adding a retry interval turned out to be pretty simple and I was also able to provide a good example of how you can put your own delay into your activities.  In a later post, I’m going to talk about the other issue I had to manage which is how to deal with exceptions and control whether or not my Retry activity got put into the faulting state. 

 

The updated retry activity can be found here, and has been updated for Visual Studio 2008.  If you want the updates for 2005, just download the original, and then copy the class file for the retry activity from the new project.  I didn’t use any new features of 2008, just updated the project and solution files, so it should work fine.