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