none
How can I handle events in my XAMLX workflow?

    Question

  • I have a WCF Workflow Service which receives a request from a user, replies and then needs to make a call to WMI.  The fact that it uses WMI is not significant, other than that the WMI object uses events to communication progress and completion.  I'm still quite new to WF4.  What I'd like to have my workflow do is subscribe to the events, make the WMI call and then wait for one of the events.  Since the WMI call can take minutes to complete, it'd be ideal if the workflow could be persisted whilst it waits.  Is this possible and, if so, how?
    Friday, January 07, 2011 1:40 PM

Answers

  • You could do this a couple of ways. You could write an Async activity to make the call and wait for the event in order to continue. That would probably be the easiest, but your workflow would not persist (workflows don't persist during an Async activity). The workflow would simply be held in memory until the async activity completed. However the workflow would not be hogging up the workflow thread (like it would if you were to write an activity with a long Thread.Sleep) so that is ok. It would be up to you to decide if remaining in memory for a few minutes is ok. If you wanted to follow that approach, then you can see the types of async activities that you can create here: Creating Asynchronous Activities.

    If you wanted to workflow to persist while it was waiting for this event, then you could create a workflow extension that you could call from a custom NativeActivity that has a bookmark. this extension would make the call and then wait for the event, and then signal back to the workflow (by resuming the bookmark). I don't have any sample code handy for this approach, but could provide some if you are interested in this approach. Let me know and I will find or create some for you.

    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

    Friday, January 07, 2011 9:52 PM

All replies

  • You could do this a couple of ways. You could write an Async activity to make the call and wait for the event in order to continue. That would probably be the easiest, but your workflow would not persist (workflows don't persist during an Async activity). The workflow would simply be held in memory until the async activity completed. However the workflow would not be hogging up the workflow thread (like it would if you were to write an activity with a long Thread.Sleep) so that is ok. It would be up to you to decide if remaining in memory for a few minutes is ok. If you wanted to follow that approach, then you can see the types of async activities that you can create here: Creating Asynchronous Activities.

    If you wanted to workflow to persist while it was waiting for this event, then you could create a workflow extension that you could call from a custom NativeActivity that has a bookmark. this extension would make the call and then wait for the event, and then signal back to the workflow (by resuming the bookmark). I don't have any sample code handy for this approach, but could provide some if you are interested in this approach. Let me know and I will find or create some for you.

    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

    Friday, January 07, 2011 9:52 PM
  • Thanks for the reply. 

    I've looked into the Async activities and I can that I'll use them in some scenarios but I think it'd be useful to know more about the workflow extensions, particularly because of the persistence aspect.  I'd be grateful if you could post some sample code.

    The simplest case would be to call a method (presumably on another assembly) and wait for a single event.

    A more advanced case (and one of the scenarios I have to deal with) is where the external method can result in one of four different events.  Do we handle all four event with the same handler and pass in a parameter so that we know which event fired?

    I did a little reading on bookmarks and came across the different types: default (blocking), non-blocking and multi-resume.  Going beyond what I need to achieve immediately (so if it's too tricky, don't worry) what about a scenario here where an external call might have two events, say, ProgressChanged and Completed.  ProgressChanged might be fired several times and Completed only once.  Is it possible to create an extension with two bookmarks, one mutli-resume for the ProgressChanged and the other a default, blocking one for Completed - I admit that I can't see how this would connect back to the workflow at the mo - or would you have a single Multi-resume bookmark that had to deal with the different event types?

    One final question: if I were to have to fire up a large number of workflows, say 500, and they were to call an external method, waiting around 5 minutes and getting the event back, can you say if there would there be a natural preference for Async over workflow extension or vice-versa?

    Tuesday, January 11, 2011 8:58 AM
  • Hi, SSG31415926

    You'd better post the last question in a new thread.

    Thanks
    MSDN Community Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: http://xhinker.com
    Microsoft Windows Workflow Foundation 4.0 Cookbook
    Friday, January 14, 2011 8:50 AM