• EventHandlingScopeActivity

    The EventHandlingScopeActivity is a dramatically different type of event handling activity. It has two discrete sections: a main line child activity and a set of event handling activities. The single main line child activity executes in a normal manner. When the main line activity completes, the entire EventHandlingScopeActivity comes to an end. In addition to the main line child activity, event handling activites are contained within a single EventHandlersActivity that is a child of EventHandlingScopeActivity. The EventHandlerActivity is the parent for one or more EventDrivenActivity instances, with each one activing as a seperate branch of execution. Each EventDrivenActivity contains one or more child activities, but the first child must implement IEventActivity(e.g. HandlingExternalEventActivity) in order to start execution of the branch. When an event is received, the activites within EventDrivenActivty are executed. However, unlike the more common event handling of ListenActivity, the order event branch are all still alive. They can also receive their events and execute the activities within their execution branch. The orginal branch that recived its event cal even receive it again.

  • Manually controlling correlation

            <p>
            In the previous examples, you’ve seen that as local service events are raised, they are routed to the correct workflow instance. The magic that accomplishes this is the workflow instance ID that is passed with the ExternalDataEventArgs. The InstanceId property of ExternalDataEventArgs identifies the workflow instance that should receive the event.
            It is common for a workflow to wait for multiple events, using a different
            HandleExternalEventActivity instance to wait for each event. The standard event routing also handles this situation, passing the event to the correct HandleExternalEventActivity instance in the workflow. When one event is received, all other EventDrivenActivity branches are canceled.
            </p>
            <p>
            This type of event routing is sufficient for most situations. However, what happens if a workflow must handle multiple instances of the same event? This might be the case if the workflow includes an activity such as a ParallelActivity that permits multiple branches of execution. Each execution branch may be waiting for the same type of event. The standard event routing will identify the correct workflow instance, but how do you determine which activity should receive the event?
            </p>
    
  • Using HandleExternalEventActivity

            <p>
            Implement the class that will be used as the vent arguements,this argument must derived from ExternalDataEventArgs.
            </p>
            <p>
            Define the evetn in a local service interface. A local service interface is one that has been decorated with the ExternalDataExchangeAttribute and implemented by a local service class.
            </p>
    
  • Event-Driven Activities

            <p>
            WF includes a group of activites that work together to provide event handling within workflow. Some of these activites wait for an external event(eg HandleExternalEventActivity), while others trigger and handle an event internally( DelayActivity) In both case, the activites implment the IEventActivity interface, which is a requirement for any activity that handles an event. Other activity are composites that act as containers for these event handler activities. EventDrivenActivity is similar to SequenceActivity in that it contains a set of child activites that are executed in sequence. However, EventDrivenActivity requires that first activity implment IEventActivity. When this first child executes, it immediately begins waiting for its event. Execution of the entire EventDrivenActivity is suspended until the event is received or the activity is canceled.
            </p>
            <p>
            Other actvities , such as ListenActivity as as containers for multiple instance of EventDrivenActivity. Each EventDrivenActivity represents a branch of execution that is triggered by a different event. The EventDrvienActivity is the only child activity permitted by the ListenActivity.
            </p>
    
  • Adding Workflow persistence service

            <p>
            This can be done programatically or declaratively. Below is section of code that do it programtically.
            </p>