thePoet

I have a single event fired, and multiple external event handlers that need to receive that event and do special processing. By design, only one of those listeners will actually be run. I know there are ways to control which handler gets which event through correlation if you have multiple handlers and you need to direct the event to a specific one, but is there a mechanism, or pattern that has been developed, that allows all the handlers to be notified

Re: Windows Workflow Foundation Single Event / Multiple Handlers

Laurence Melloul - MSFT

Hi,

Can you have one event-driven activity only followed by a Replicator or a list of children that will bind to the necessary data






Re: Windows Workflow Foundation Single Event / Multiple Handlers

thePoet

The problem is that these are scoped within different areas of the workflow. They may or may not be active at the same time. There is really no way to predict (which is actually what is really nice about doing it this way).

I guess I could have a branch running in the global scope that is always waiting on the event and have it set some local variable that these other locations could be checking while running a while loops, but that isn't really pretty.




Re: Windows Workflow Foundation Single Event / Multiple Handlers

Laurence Melloul - MSFT

Hi,

I am curious about your scenario that requires processing of the same event at different execution points and in differenrt branches Smile In any case, we do no support this out of the box, and I don't see a design pattern that would make it work easily. Yep, it seems one listener, one event handler, and some data binding would be the best solution.

Cheers,






Re: Windows Workflow Foundation Single Event / Multiple Handlers

thePoet

Sorry for the delay in responding to this:

Here is the basic setup. We are running these workflows in a semi-realtime simulation. To do this, we have to use manual runtime control of the workflow. The workflow is run as the last step in the simulations time-slice and is expected to go idle or complete before we move on to the next time-slice.

One of the most important events in the process is the event that indicates to the workflow that a new time slice has begun. This is a place where generic code is put that checks on the previous pass of the simulation and makes changes based on that.

I have a statemachine to handle high-level states in the simulation. But the system would be too difficult to describe as a statemachine alone. It is advantagious, to have the equivalent of state specific sequence workflows. We do this by running sequences off of events where the sequences don't change state. This works well and allows us to use state when it makes sense, and sequence when it makes sense, and we aren't tied to the negatives of either.

Logically, when I need to do something every time I go through a time-slice in the workflow, I would handle the event that the slice has begun in the global scope. That isolates the code nicely. However, if I need to accomplish an additional task in every slice while in a specific state, it would make sense to handle that event there as well. It would be run in the global and state specific contexts. There would be no worry about replicated code, or trying to call external workflows and deal with the hassle of getting data back from that process. However, given the current design, it doesn't appear that I can do that without a lot of hassle building out a special system in the workflow.

There are a lot of other use cases, but this is the one I currently have to deal with.