Wf Events1

Event-Driven Activities

Event-Driven Activities • Event-driven activities suspend execution of a workflow until an event is received. • The event is commonly raised externally by a local service, but it can also be raised internally from within a workflow. • These types of activities are vital to state machine workflows, since they are typically used to trigger state transitions.

Event-Driven Activities •

WF includes a group of activities that work together to provide event handling within a workflow.

•

Some of these activities wait for an external event (e.g., HandleExternalEventActivity), while others trigger and handle an event internally (e.g., DelayActivity). In both cases, the activities implement the IEventActivity interface.

•

ListenActivity, act as containers for multiple instances of EventDrivenActivity. Each EventDrivenActivity represents a branch of execution that is triggered by a different event. The EventDrivenActivity is the only child activity permitted by the ListenActivity.

The DelayActivity is useful since it enables you to declare the activities to execute when an expected event is never received.

Using the HandleExternalEventActivity • The HandleExternalEventActivity is one of the most frequently used event handling activities. You often use it in combination with the CallExternalMethodActivity to enable two-way communication between a workflow instance and a local service.

Event-Driven Activities • Use HandleExternalEventActivity to process local service events. • The typical patterns used to call an external method and then wait for a response from the host application in the form of one or more events.

The example we are doing! • The workflow will randomly choose a number and allow you to make guesses until you finally choose the correct number. Each time you make an incorrect guess, the workflow sends you a string message with a hint. The host application for this example is a Windows Forms application.

WF- Events Workflow host environment can communicate with runtime Work flow.

e workflow needs to be informed my the host that something of certain Has occurred for eg: the email or web service call has arrived……

The model of communication between the Host and WorkFlow happens Via the Event model

Host will fire the event and the Workflow will Sink the event via this interface model we have to work it through

Suppose we wish to send a simple string from host to workflow. We will create a Events args and pass the String over it

Implementing the Event Arguments Class • Before you can define an event in the local service interface, you need to define the event arguments class that the event will pass.

• The class is derived from ExternalDataEventArgs since this is a requirement in order to handle the event with HandleExternalEventActivity. • This base class provides the InstanceId property, which identifies the workflow instance that should receive the event.

So that it is transmittable to the Work Flow

Local service

Defining the Service Interface

Notice that the interface is decorated with the ExternalDataExchangeAttribute. This is required to identify this as a local service interface and make it available to workflows.

Implementing the Local Service class • The local service class implements the interface to provide communication with workflow instances.

are ready to implement the local service class itself

Registering the EDES In the work flow.

The end