locked
Cancellation Handler RRS feed

  • Question

  • Can someone enlighten me?

     

    What is the Cancellation Handler and when does it fire?

     

    Also on a similar vein, I want to know if they terminate the call so I can do something. How do I detact this?

     

    I thought maybe they were one and the same Smile

     

    Cliff

     

    Friday, June 8, 2007 6:09 PM

Answers

  • Suppose you were asking for the CancellationHandlerActivity. Actually it’s a standard .NET framework WF activity. You can check the introduction information as following:

     

    The CancellationHandlerActivity activity contains cleanup logic for a composite activity that is canceled before all the composite activity's child activities are finished executing. A CancellationHandlerActivity activity cannot exist on its own; it is always associated with another activity.

    For example, a ListenActivity activity or a ConditionedActivityGroup activity can have multiple child branch activities executing at once. A specific condition, such as an arriving message, can cause the entire activity to close immediately, before all the child activities are finished executing. The parent activity then cancels the execution of all uncompleted child activities, and their corresponding CancellationHandlerActivity activity is called to perform the cleanup logic defined there.

    For more information about the CancellationHandlerActivity activity, see the CancellationHandlerActivity class of the System.Workflow.ComponentModel namespace in the Windows Workflow Foundation Class Library reference.

     

    More information, please also check

    http://msdn2.microsoft.com/en-us/library/system.workflow.componentmodel.cancellationhandleractivity.aspx  and

    http://msdn2.microsoft.com/en-US/library/aa349442.aspx

    Monday, June 11, 2007 7:31 AM

All replies

  • Suppose you were asking for the CancellationHandlerActivity. Actually it’s a standard .NET framework WF activity. You can check the introduction information as following:

     

    The CancellationHandlerActivity activity contains cleanup logic for a composite activity that is canceled before all the composite activity's child activities are finished executing. A CancellationHandlerActivity activity cannot exist on its own; it is always associated with another activity.

    For example, a ListenActivity activity or a ConditionedActivityGroup activity can have multiple child branch activities executing at once. A specific condition, such as an arriving message, can cause the entire activity to close immediately, before all the child activities are finished executing. The parent activity then cancels the execution of all uncompleted child activities, and their corresponding CancellationHandlerActivity activity is called to perform the cleanup logic defined there.

    For more information about the CancellationHandlerActivity activity, see the CancellationHandlerActivity class of the System.Workflow.ComponentModel namespace in the Windows Workflow Foundation Class Library reference.

     

    More information, please also check

    http://msdn2.microsoft.com/en-us/library/system.workflow.componentmodel.cancellationhandleractivity.aspx  and

    http://msdn2.microsoft.com/en-US/library/aa349442.aspx

    Monday, June 11, 2007 7:31 AM
  • Chris

     

    Thanks, didn't realise it was a standard workflow thing.

     

    What about my second point. How do I detect that they dropped the line? I have some MIS code that I want to fire no matter whether they say "bye" or just drop the line.

     

    I just read something about a Call Disconnected Fault Handler, that sounds promising...

     

    Cliff

     

    Monday, June 11, 2007 12:15 PM
  • If the end user hung up in the middle of the workflow, a exception called “CallDisconnectedException” will be thrown.

    CallDisconnectedException happens when a speech activity tried to run while the call is not connected, and can happen for two reasons:


     (1) The user hung up on the app in the middle of the flow.  This is expected and normal.
     (2) You disconnected the call locally, and then attempted to run a speech activity. This is an application bug, and so we break if the debugger is already attached.

     

    You can add your custom function code in the CallDisconnectedException section just as the following:

            private void HandleCallDisconnected(object sender, EventArgs e)

            {

                if (((CallDisconnectedException) callDisconnectedHandler.Fault).LocalInitiation && Debugger.IsAttached)

                {

                    LogError(callDisconnectedHandler.Fault.Message); //Add custom actions

                }

            }

     

    Tuesday, June 12, 2007 7:08 AM
  • On a related note: I should point out that the code-snippet above has a small bug in it. That HandleCallDisconnected code is taken verbatim from what we generate in the "New Project" wizard. Unfortunately, the "&& Debugger.IsAttached" should have been deleted. We should be calling LogError in all cases when LocalInitiation is true.

     

    The impact of the bug is that default projects will not log anything if you have a mistake in your app such that: (1) you perform a local disconnect and then (2) you try to run a speech activity and (3) the debugger is NOT attached. The method "LogError" causes a breakpoint if the debugger is attached, and that is the only thing that should be conditional based on whether the debugger is attached (i.e., we don't want to cause a breakpoint if you are not already debugger; we just want to log the possible error in your code.)

     

    Dan

     

    Tuesday, June 12, 2007 10:58 PM
  • Hi!

     

    Is the HandleCallDisconnected always run if I have a CallDisconnected faulthandler?

    I have an application where some logs are created before the system disconnects the call or when the user hangs up.

    We have a scenario where consecutive silences are handled differently depending on where the user is in the workflow. The cons silence code has a goto and redirects the user to a new starting point. And after this (cons silence + goto), the HandleCallDisconnected is not run if the user hangs up.

     

    For all normal scenarios HandleCallDisconnected is run.

     

    Is there any workaround? Could I hook up these events again if they are lost?

     

    Thanks for your input!

    Monday, June 18, 2007 9:33 AM
  • So what is the CancellationHandlerActivity useful for in a speech application workflow? 

     

    Is there any case where the CancellationHandlerActivity would be called but the HandleCallDisconnected would not? 

     

    If the user hangs up, are both called?

     

    I'm wondering because I keep getting these warnings about having an empty cancellationHandlerActivity and I would like to know if I can safely ignore this or if there's something I should be putting there.

    Monday, June 18, 2007 7:12 PM
  • I believe you are getting those warnings about having an empty cancellation handler simply because you at some point clicked on the "View Cancel handler" link your workflow. When you do that, you add some bit of code to your page and the workflow designer then begins to complain that you have an empty handler. Try removing the line like

     

    this.Activities.Add(this.cancellationHandlerActivity1);

     

    from your .designer.cs file.

     

    The CancellationHandlerActivity is a built-in workflow activity. I don't think it's particularly useful for speech applications, but you need to read up on the Workflow documentation to understand what it's used for.

     

    The HandleCallDisconnected method is invoked, in a default speech project, whenever a CallDisconnectedException is raised. But you can alter that behavior if you add, remove, or edit your own FaultHandlers. A CallDisconnectedException is raised whenever the call state goes disconnected as a speech workflow activity is running or starts to run.

     

    Dan

     

    Monday, June 18, 2007 8:27 PM