locked
Logging WWF 4 failure.....? RRS feed

  • Question

  • We are new to WWF. Our developer is concerned that if, for some reason, WWF encounters an issue, we need to be know about it (email?) as well as capture the issue (in a sql database).  In particular, he is concerned if, for some reason, the email and sql server database on the WWF server are not accessible,  that we won't know an error occurred and have no way to capture it.

    Can anything be done to address these (unlikely) failings?

     

    TIA,

    Barkingdog

     

     

    Friday, October 28, 2011 3:31 AM

Answers

  • Hi,

    Apart from the approach Joao has suggested , there is one more way you can log your exceptions.

    If you are using WorkflowApplication class object to run workflows you can attach event to cath excpetion raised in workflow life cycle.

    try this link

    http://msdn.microsoft.com/en-us/library/dd560894.aspx 

    and

    for other option like WorkflowServiceHost you can add behaviours/workflow extensions to cath exceptions

    http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/44ff6271-8864-40b0-a051-1585b8b8c6fa

     

    Thanks

     


    MB
    • Proposed as answer by MadhurBhardwaj Saturday, October 29, 2011 10:57 PM
    • Marked as answer by LeoTang Sunday, November 6, 2011 8:57 AM
    Saturday, October 29, 2011 10:57 PM
  • If he is expecting exceptions on particular parts of the workflow, those exceptions should always be treated inside that same workflow. Moreover, handling WorkflowApplication's OnUnhandledException doesn't prevent workflow from stopping (it will, no matter what,  Abort, Cancel or Terminate) which, I suppose, isn't what he wants.

    Possible scenario: A particular activity make changes to the database. Surround it with TryCatch and log somewhere that "something went wrong and nothing was saved". That way it's logged that an error occurred and workflow execution continues as expected. That's how these situations should be treated.


    • Edited by João Correia Saturday, October 29, 2011 11:22 PM
    • Marked as answer by LeoTang Sunday, November 6, 2011 8:57 AM
    Saturday, October 29, 2011 11:20 PM

All replies

  • You can surround workflows with TryCatch activity which will catch any exception that may occur inside it. When it catchs an error you can deal with it the way you want. Probably log it somewhere.

    Something along this lines:

    DelegateInArgument<OverflowException> overflowEx = new DelegateInArgument<OverflowException>();
    DelegateInArgument<Exception> generalEx = new DelegateInArgument<Exception>();
    
    new TryCatch
    {
        Try = YouMainWorkflowHere,
    
        Catches = 
        {
            new Catch<OverflowException>
            {
                Action = new ActivityAction<OverflowException>
                {
                    Argument = overflowEx,
                    Handler = new WriteLine() { Text = "An overflow somewhere within you workflow. Log this somewhere, maybe with other activity than WriteLine." }
                }
            },
            new Catch<Exception>
            {
                Action = new ActivityAction<Exception>
                {
                    Argument = generalEx,
                    Handler = new WriteLine() { Text = "Some other error happened with this message: " & generalEx.Message  }
                }
            }
        }
    }
        
    

    Moveover, TryCatch is a container. This means you can have Variables within its context.
    Saturday, October 29, 2011 1:51 PM
  • Hi,

    Apart from the approach Joao has suggested , there is one more way you can log your exceptions.

    If you are using WorkflowApplication class object to run workflows you can attach event to cath excpetion raised in workflow life cycle.

    try this link

    http://msdn.microsoft.com/en-us/library/dd560894.aspx 

    and

    for other option like WorkflowServiceHost you can add behaviours/workflow extensions to cath exceptions

    http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/44ff6271-8864-40b0-a051-1585b8b8c6fa

     

    Thanks

     


    MB
    • Proposed as answer by MadhurBhardwaj Saturday, October 29, 2011 10:57 PM
    • Marked as answer by LeoTang Sunday, November 6, 2011 8:57 AM
    Saturday, October 29, 2011 10:57 PM
  • If he is expecting exceptions on particular parts of the workflow, those exceptions should always be treated inside that same workflow. Moreover, handling WorkflowApplication's OnUnhandledException doesn't prevent workflow from stopping (it will, no matter what,  Abort, Cancel or Terminate) which, I suppose, isn't what he wants.

    Possible scenario: A particular activity make changes to the database. Surround it with TryCatch and log somewhere that "something went wrong and nothing was saved". That way it's logged that an error occurred and workflow execution continues as expected. That's how these situations should be treated.


    • Edited by João Correia Saturday, October 29, 2011 11:22 PM
    • Marked as answer by LeoTang Sunday, November 6, 2011 8:57 AM
    Saturday, October 29, 2011 11:20 PM
  • Yes agree .

    But if the workflow is designed from re-hotsed designer, you can't force a user to design workflow using TryCatch  activity .

    In that case using workflow Extension ORworkflowapplication object events you can catch exception.

    using OnUnhandledException event you can get details/nested error message.

     

    http://msdn.microsoft.com/en-us/library/system.activities.workflowapplication.onunhandledexception.aspx

     

    Thanks,


    MB
    Sunday, October 30, 2011 8:19 PM