WF from Getting started to proficient (tenth chapter): Event Activities

After completing this chapter, you will learn:

1. Create a specific event handler using the Handleextenalevent activity

2. Use delay activities in your workflow

3. Use EventDriven activities in your workflow

4. Use listen activities in your workflow

5. Understanding how Eventhandlingscope Activities Monitor events in the event of concurrent execution

In chapter eighth ("Invoking external methods and workflows"), you have seen how workflows use callexternalmethod activities to communicate with host applications. When a workflow calls an external method, using a local communication service that you provide, the host application receives an event and the host processes the data and produces some corresponding action.

The opposite call procedure is that the event triggered by the host application is handled by the workflow capture (although Workflow event processing can be used in a broader task rather than just communicating with the host). In chapter eighth, I mentioned that after describing the activities that the workflow uses to handle events, we will also revisit the communication between the host/workflow, which we will do in this chapter.

In the other chapters so far, I've described a workflow activity separately, and then provided a small application to demonstrate the process of the activity. Unlike these chapters, this chapter describes and demonstrates multiple activities in a sample application. Why do you do that? Because the activities I'm describing here are interrelated and interdependent. I can't demonstrate one of these activities without demonstrating to other activities. Listen activities can be used as containers for eventdriven activities. Within the EventDriven activities, you will also be expected to find the only one handleexternalevent activity and so on. So in this chapter I will create only one application to describe and demonstrate these activities from beginning to end. The "Host to Workflow" section is the main line of this chapter. Let's start with the handleexternalevent activity first.

Using handleexternalevent Activities

The handleexternalevent activity is the workflow activity that ultimately handles the event, regardless of where you handle the event in your workflow, or what kind of activity you discover to perform when your workflow is in the execution state, as long as an event comes to your workflow path. For me,. NET has many powerful features, and its ability to trigger and handle events is one of these most powerful features. The process of including workflow events is equally powerful.

The role of the handleexternalevent activity is to respond to an event based on the Ieventactivity interface, which has three main members: the QueueName attribute, the subscribe, and the Unsubscribe method. QueueName represents the workflow queue that is waiting for the event, and the subscribe and unsubscribe methods are used to inform the workflow runtime of a particular instance of the event that your event handler will receive (or not receive).

The handleexternalevent activity itself can also be used in conjunction with callexternalmethod activities (as we have seen in chapter 8th). Workflows use Callexternalmethod activities to send data to the host application, but when the workflow executes, the workflow uses HandleExternalEvent to receive data sent from the host.

Note: Keep in mind: the timing of using external data exchange is not just when sending data from your hosting application to Workflow. When you create your workflow instance, you can always provide initial data for it. However, once a workflow is in progress, it is the only mechanism available for local communication directly to your host application (and, of course, it can be replaced with more indirect methods, such as using FTP protocols or Web services to invoke these methods).

Table 10-1 and table 10-2 list some of the main properties and methods that are often used when using handleexternalevent activities. Note that some methods and properties are common to all activities (as shown in table 4-1 and Table 4-2 in chapter Fourth "Activities and workflow type descriptions"). The properties and methods I'm showing here are certainly not all of the properties and methods that are available, but they are often used.

Table 10-1 Properties of handleexternalevent activities that are frequently used

Property	Function
CorrelationToken	Gets or sets a binding to the association tag (correlation token). We will handle the association in chapter 17th ("Association and Local Host communication").
EventName	The event that the activity will handle. Note If you do not set it, the activity will not listen to the event and communication with the host is not possible. Oddly, ignoring the property value will not receive any error validation information.
InterfaceType	Gets or sets the type of interface to use for communication. The interface must be decorated (marked) with the Externaldataexchange attribute. (You may recall the 8th chapter, you provide an identical interface for the Callexternalmethod method.) ）

Table 10-2 Methods of handleexternalevent activities frequently used

Method

Function

Oninvoked

This is a very useful protective (protected) method that binds the values in this event argument to the fields or dependent properties in your workflow. Overriding the method (or handling the event it triggers) is a primary mechanism for retrieving data from the host and being saved to the event arguments, and typically you will create a custom event parameter to embed the data into the parameter object itself.

Although you can use handleexternalevent activities directly from the Visual Studio's toolbox, But the more common scenario is to use the Wca.exe tool you've seen in chapter 8th to create a custom class that derives from HandleExternalEvent for the communication interface you're using. For example, if you define an event called Senddatatohost in your interface, Wca.exe will generate a new activity called senddatatohost (which derives from HandleExternalEvent), and has specified EventName and interfacetype for you, and also for you and Senddatatohost events through the event parameters you create Data binding was made. I will provide an example later in this chapter.

Using HandleExternalEvent is easy, simply put the activity in your workflow, specifying the interface and event name. If you want, you can also provide an event handler for the invoked event, and then you can execute your workflow. If you use Wca.exe, you can provide an activity that derives from handleexternalevent, you can drag it directly into your workflow, add bindings to the Properties window, and bind the data in the event arguments to a local field or dependency property.

After you have a handleexternalevent activity in your workflow, all processes that pass through that sequential stream are stopped when the wait event occurs. To some extent, the behavior of putting this activity into your workflow is like the AutoResetEvent in. NET Framework programming terminology. Unlike AutoResetEvent, the thread of the process is not paused. It is like a door or channel that allows the workflow process to proceed along its path order only if the event is triggered.