Handling faults in WorkFlows is an important concept to consider because sometimes a routine that your workflow is inherently calling will just fart out. It just happens, sucks, but happens. It happens with generic .NET development, it happens when building custom workflows. An error will occur with your workflow, bubble up, and it must be handled appropriately. Typically, within a workflow, as an exception occurs, you want to do generally do one of two things, either exit the workflow and clean-up the persistence, or attempt to keep the persistence of the workflow.

Since a majority of the default activities that you are offered with the workflow foundation are pretty worthless (I am being negative since I had a bad day with them), you are going to end up writing a bunch of your own custom WorkFlow activities, in which case this becomes very important. The activity execution might fail, in which case an exception will bubble which has to be handled.

So how does one go about handling these dreaded faults as they occur within your WorkFlow code, and more importantly, when creating custom activities that are going to be tapped within a custom workflow?

I do this through the use of the ISharePointService interface and by overriding the HandleFault method. This is a good way to handle faults as they occur within your workflow activities The ISharePointService interface is one of the 4 local communication interfaces that you are afforded tapping into. There are also the three other communication interfaces that you can exploit, namely, IListService, ITaskService, and IWorkflowModificationService.

You will also see the use of ActivityExecutionStatus.Closed. This is because the clean-up work that is required before the activity within this code is assumed, and therefore I can close the execution status of the activity. It is possible to as well use ActivityExecutionStatus.Faulting is

When the HandleFault execution handler is dispatched by the runtime, it is expected that the activity will perform any cleanup work that is required prior to its transition to the Closed state. If your clean up work is short, you can do that and return ActivityExecutionStatus.Closed. If it is long, then return ActivityExecutionStatus.Faulting and wait for the required callbacks before ultimately creturning Closed.

This is pretty simplistic, and not exceptionally impressive, however it is getting the job done for me and may save you some time while you are developing your custom WorkFlows .

Article Or Research Filed Under SharePoint Development.

---

7 Comments »

1. [...] Fault Handling In SharePoint Workflows [...]

   Pingback by Sharepoint link love 06-22-2007 at Virtual Generations — June 22, 2007 @ 12:31 am

2. 

   Thanks! That’s what I was looking for.

   Comment by Vitaly Mogoreanu — July 6, 2007 @ 9:47 am

3. 

   Thanks!

   Comment by PeterB — March 3, 2009 @ 9:10 pm

4. 

   Thanks!

   Comment by PeterB — March 3, 2009 @ 9:10 pm

5. 

   This just save my hair. THANKS!!!!

   Comment by Omarie Case — February 24, 2010 @ 2:20 pm

6. 

   glad it helped!
   

   Comment by adam — February 24, 2010 @ 3:48 pm

7. 

   Hi,

   Is there any way to handle error in WF only using SPD. Because we have some restrictions to use Visual Studio to do custom coding

   Comment by Prineeth — March 4, 2010 @ 10:09 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

Name (required)

Mail (will not be published) (required)

Website