Answered Reach out and cancel existing workflows?

  • 9. května 2012 17:13
     
     
    I am using WorkflowApplication to kick off workflows.  After a button is clicked on a wpf page, i want to reach out to all the currently running workflows on the machine and simply cancel them.  Cancelling workflows is easy within the workflow itself, but how can I reach out from an external app and cancel them from there?

Všechny reakce

  • 11. května 2012 12:27
    Moderátor
     
     

    Hi,

    If you want to remotely control workflow instance, I'd suggest you host the workflow by using WorkflowServiceHost. Then you can use workflow control endpoint to call control operations to remotely control workflow instances.

    Workflow Control Endpoint
    http://msdn.microsoft.com/en-us/library/ee358723.aspx

    Workflow Management Endpoint Sample
    http://msdn.microsoft.com/en-us/library/dd807500.aspx

    Hope this helps, thanks.


    Leo Tang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

  • 16. května 2012 14:25
    Moderátor
     
     

    Hi,

    In your application, do you maintain a list of all of the WorkflowApplication instances that refer to running workflows? If so you could iterate the list and call cancel on them:

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

    If the workflows are long running workflows and are persisted, then you could iterate the persistence database (Query the Instances view, http://msdn.microsoft.com/en-us/library/ee943755.aspx) , load them up into a WorkflowApplication, and then call cancel on them at that point.

    Do either of these approaches map with how your host manages its WorkflowApplication instances?

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

  • 16. května 2012 17:34
     
     

    The first option sounds good (iterating a list of running workflowapplication instances and calling cancel).  A few questions though:

    1) What if that list of workflow instances contains instances that have already canceled themselves (the workflows themselves cancel when the last state machine is reached).  Can I still call cancel on already canceled workflows?  If not, how can i determine the state of the workflow instance?

    2) What about scaling?  There could potentially be hundreds of workflows running at once.  Would maintaining a large global list of workflow instances in a windows service application scale well?

    Thanks!!!!

  • 16. května 2012 18:32
    Moderátor
     
      Obsahuje kód

    How are you managing the workflow instances currently? Are they short running fire and forget type of workflows? It sounds like they are state machine workflows with multiple states. Do they pause and go idle in between states waiting for something to happen? If they do, are you keeping them in memory or do they persist and unload?

    If there is persistence and they are unloading, then getting the list from the persistence database would be the way to go. Keeping a big list in memory would not be the way to go. The only way the list of instances in memory would be applicable would be if that was already how you were managing them, and there was no persistence.

    You can use a query such as this to get the Instance Ids of the persisted instances:

    Select [InstanceId] from [System.Activities.DurableInstancing].[Instances]

    Then you could load each instance, and then cancel or terminate it:

    WorkflowApplication wfApp = new WorkflowApplication(new MyWorkflowDefinition());
    wfApp.InstanceStore = store;
    
    // Load it from persistance
    wfApp.Load(instanceId);
    
    // Terminate it
    wfApp.Terminate("Terminated by host");
    
    // or Cancel it
    wfApp.Cancel();

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm


  • 16. května 2012 19:32
     
     

    Steve, they kind of are fire and forget short running workflows.  They do have multiple states, but they don't go idle or unload because they are finished pretty quick.  So there is no persistence being used.  Based on that, the list of instances would work along with the way the application is currently designed.  With that being said, how do you suggest handling my questions above (checking the workflow instances in the list being active or not)?

    It works as follows: A loop iterates and spawns off new worklflow instances.  In each iteration, i am adding the instance to the global list.  When a user clicks a "Stop" button, the loop stops spawning off workflow instances, and at that point, I want to iterate through the global list and cancel any workflows that haven't been canceled yet.  I'm just concerned with iterating through a global list that contains 70-80% workflow instances that are not active anymore.

    Thanks!

  • 16. května 2012 20:06
    Moderátor
     
     Odpovědět

    What you could do, since they don't go idle and there is no persistance, after you fire one off, you could add it to a dictionary<Guid, WorkflowApplication>. For each WorkflowApplication you start, wire up handlers for Completed, Aborted, and OnUnhandledException (as described here: http://msdn.microsoft.com/en-us/library/system.activities.workflowapplication.aspx) and in those handlers, remove the WorkflowApplication reference from the dictionary. That way the dictionary maintains a reference to the running instances. When you go to cancel or terminate the instances out of the list make sure you synchronize things so that you are not contending for access to the dictionary at the same time as completing workflows. Possibly locking around access each time to the dictionary and a do-nothing failure in the handlers (after checking to be sure the item is still there). I would have to make some sample code and see what happens. But I think this could be a good approach.

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm