How to Handle Events from the Host Process in WF?

In addition to enabling workflows to call methods on the host process, WF enables you to handle events that are raised in the host process, inside the workflow instance. For example, if a workflow parameter is bound to a control in Windows Forms, it is possible to capture the Changed event of that control (or create and raise a custom event if one does not already exist) and then configure the workflow to listen for that event.

Why Handle Events from the Host Process?

In WF applications, it is often necessary to handle events from the host process, such as when you need to synchronize processing threads, respond to user interface actions, or implement cross-process execution. Events enable asynchronous communication between processes, so WF enables you to handle events from external processes in your workflow applications.

Consider a scenario where a user interface dialog box contains a list of possible options that a user can select. You must implement workflow functionality when the user selects an item. You can add code to the application to raise an event when that item is selected, handle the event in the workflow instance, and then perform the required functionality.

Another scenario involves synchronization of processes. If you have a process to retrieve data from a database and you want to execute your workflow functionality when the data retrieval process is complete, you can raise an event at the end of the database call and handle the event in the workflow

Raising Events in the Host Process

To make host process events available to workflows:

  1. Define an interface that specifies events.

  2. Specify the ExternalDataExchange attribute on the interface.

  3. Define a service class that implements the interface and raises events.

  4. Register a service class instance with the workflow runtime.

Communication between workflows and the exchange service is a many-to-one relationship; therefore, many workflows subscribe to a singleton exchange service. The ExternalDataExchange service directs calls to a specific workflow instance. The workflow instance ID is used to identify the workflow instance. It is included on the outbound calling thread to enable the workflow runtime engine and exchange service to direct calls to the correct workflow.

The workflow instance ID is the globally unique identifier (GUID) that represents the workflow instance. You can retrieve it by using the WorkflowInstance.InstanceId property.

The following code examples show the creation of an ExternalDataExchangeService interface and an implementation of that service. In these examples, the HelloHost method creates the ExternalDataEventArgs object and populates it before raising the HelloWorkflow event and passing the ExternalDataEventArgs object. The final section of the examples shows how to add the service to the workflow runtime.

 

[ExternalDataExchange]

public interface ICommunicationService

{

    void HelloHost(string message);

    event EventHandler<ExternalDataEventArgs> HelloWorkflow;

}

 

public class CommunicationService : ICommunicationService

{

    event EventHandler<ExternalDataEventArgs> HelloWorkflow;

 

    public void HelloHost(string message)

    {

        Console.WriteLine("This is the message: {0}", message);

        HelloWorkflow(null, new ExternalDataEventArgs

            (WorkflowEnvironment.WorkflowInstanceId));

  }

}

// Interface hosting code

ExternalDataExchangeService externalService =

    new ExternalDataExchangeService();

workflowRuntime.AddService(externalService);

externalService.AddService(new CommunicationService());

For more information about the ExternalDataExchangeAttribute class, see ExternalDataExchangeAttribute Class.

For more information about the HandleExternalEventActivity class, see HandleExternalEventActivity Class