When a workflow runs an activity and that activity throws some kind of unhandled exception you would notice that your workflow get terminated. I have see in many articles that explain how the termination happens. Now this is fine only for a rare set of hello world scenarios. When it comes to an enterprise application we usually expect to notify that some error has happened and probably redo our work.
Now if the workflow terminates how the heck are we supposed to re-execute the workflow cause its already terminated right 🙂 and you get the “Workflow not found in persistence store” when you use a store like SQL . Now this happens when our activity doesn’t have a fault handler associated with this it. So one of the solutions we tried for state machine error handling was this.
- View the FaultHandlers in the event driven activity in the state.
- Add a new Fault activity and set the fault type to System.Exception (this is to capture generic faults and nothing fancier) you can customize this but then again we are trying to avoid workflow termination here.
- in the fault handler use a CallExternalMethodActivity.
- How to catch the exception – You can promote the Fault property as a dependency property. Another easy way would be to call a methodInvoked(ie the method to be executed before the callExternal method is invoked) and in that access the exception as the fault property in the parent of the callExternalMethodActivity.
- You can then pass on what ever data you get to the external method.
I believe there are many more ways of fault handling. I even know of cases where customers hacked the stored procedure of Insertworkflow to avoid workflow deletion on termination.
Anyway this is just on of the easier ways out to clean up incase you have better practices do leave a link 🙂