locked
How to return an exception without terminating/suspending the workflow? RRS feed

  • Question

  • I have a long-running workflow which moves when it receives messages of various kinds. Some of these messages must be responded to, but I want to return error conditions as exceptions. Is there a way to throw exceptions back to the caller without causing the whole workflow to be suspended/terminated?
    Thursday, August 5, 2010 12:54 PM

Answers

  • I think I found the solution - I can send a FaultException<T> as the message content of a SendReply activity, and that is rethrown as an exception on the client side - exactly what I was looking for.
    • Proposed as answer by Tim Lovell-Smith Monday, August 9, 2010 4:10 AM
    • Marked as answer by Zhen Lin Monday, August 9, 2010 12:02 PM
    Friday, August 6, 2010 3:17 PM

All replies

  • Hi Zhen,

    I'm not sure what you really need, you want none suspend state?

    Every Exception wile throw an unexpected exeption to workflowapplication, you could choose properties of workflowapplication to.

    If you don't want it you'll have to use a custom extension to raise event out of worklfow.


    Jérémy Jeanson MCP, MCTS http://blogs.codes-sources.com/JeremyJeanson/ (French or English spoken)
    Thursday, August 5, 2010 1:12 PM
  • Well, for example, if I have an operation which is only valid when certain conditions external to the workflow are satisfied, I want to be able to throw an exception to the client who invoked that operation, but I don't want the workflow to terminate yet. In other words, I want the workflow to essentially ignore invalid messages, but the client needs to know whether the message was ignored or not, and I prefer to transmit that information as an exception rather than e.g. a error code return value.
    Thursday, August 5, 2010 1:17 PM
  • Ok,

    It could be a nice solution to expose an OutArgument with a list of "errors" or somthing like that (cutom class or string cold be a good type). Your worklow will run, add "errors" in liste, and ignore the problem.

    After exezcution you'll be able to look for "errors" list in outargument.


    Jérémy Jeanson MCP, MCTS http://blogs.codes-sources.com/JeremyJeanson/ (French or English spoken)
    Thursday, August 5, 2010 1:21 PM
  • I don't see how that helps. The clients don't have access to the workflow engine at all. 

    Basically: I want to implement a stateful service using Workflow Foundation. Something like the HiringRequest sample application, except with more robust validation and security - which means I need to be able to throw exceptions when the client is not authorised without terminating the workflow instance. This seems like a reasonably common scenario, and I would be very surprised if there isn't a way to do it.

    Thursday, August 5, 2010 1:29 PM
  • As proposed before, with WF4 you can code all you need ;)

    You have only to choose where you want be notice about errors. I undertand OutArguments isn't a good idea in you service. An error information in response message (or arguments in repsonse) could be the solution. Or some rows in a database. The choose is yours


    Jérémy Jeanson MCP, MCTS http://blogs.codes-sources.com/JeremyJeanson/ (French or English spoken)
    Thursday, August 5, 2010 1:41 PM
  • Hi Zhen,

    Are you using WF to build a WCF service and is what you want to do send a WCF Fault back to the caller of the WCF service? Or are you using another messaging system?

    I'm not to clear on how the WCF faults work with WCF services yet (would be a good thing for me to learn), but I think the non-termination behavior part is doable, if you have persisted your workflow prior to receiving the message which causes the fault.

    Here is the flow -

    1. Workflow starts up, reaches a point where it waits for a message to come in, and persists (because you have enabled persist-on-idle).
    2. Message comes in, workflow rehydrates
    3. Workflow hits an error, throws an exception, and
    3a) a fault is returned to the client
    3b) instead of suspending/persisting the workflow at the point of fault, the workflow's current state is discarded without persisting.

    Then you are basically back waiting for step 2: the next request that comes in should find the persisted old version of the workflow, and never be aware the fault happened.

    Does this help? Or have you tried something like this already, but are getting stuck?

    Tim

    Thursday, August 5, 2010 5:57 PM
  • I think I found the solution - I can send a FaultException<T> as the message content of a SendReply activity, and that is rethrown as an exception on the client side - exactly what I was looking for.
    • Proposed as answer by Tim Lovell-Smith Monday, August 9, 2010 4:10 AM
    • Marked as answer by Zhen Lin Monday, August 9, 2010 12:02 PM
    Friday, August 6, 2010 3:17 PM