WF from Getting started to proficient (17th chapter): Correlation and local host communication (on)

After completing this chapter, you will learn:

1. Understand the workflow Association (correlation) and where it must be used, and why it is important

2. Use Workflow association parameters (correlation parameters)

3. Generate and use related local communication services

The applications you've seen throughout this book are generally based on a single same architecture, with WF support performing tasks in the workflow instance. These are one-to-one communication between the application and its workflow instance. If you're communicating with a workflow instance, you're ensuring that data transfer between applications and workflows is not confused in any way. One application corresponds to a workflow.

But at least one scenario is possible, which is when applications and workflows are executed in the same application domain (AppDomain). Your individual application will call multiple copies of the same workflow. What happens when you send data back and forth?

Obviously, some people need to know what work flow and what data work together. Usually we can't confuse and want to do a matching comparison. Once a workflow instance is created and executed by the team, if it is bound to a specified data identifier, there may be a problem with data integrity for processing different data identifiers with workflows.

In fact, WF provides some internal bookkeeping to help us prevent data integrity problems. In WF terminology, which is called an association (correlation), WF provides very powerful association support but it is also easy to use.

Host and workflow Local communication

Before we go into the associated topic, let's briefly review the entire communication process between the host and the workflow. In the 8th chapter, "Calling external methods and workflows", the callexternalevent activity is described and a local communication service is used to send data from the workflow to the host application. In the 10th chapter, "Event Activity", the handleexternalevent activity is used to handle the reverse process: The host can also send data to the workflow.

Regardless of how the data is routed, we first create an interface. The methods in the interface are destined to eventually become callexternalevent activities, and the events in the interface will eventually become handleexternalevent activities. We use the Wca.exe tool to generate these custom activities based on our interface for us. (We can also use callexternalevent activities and handleexternalevent activities directly, which provide each interface, method, or event to be processed, but creating custom activities in our workflows is strongly recommended.) ）

With the interface in hand, we then create a local service and insert it into the workflow runtime to manage our local communication needs. The local service consists of a data connector and a service class.

When an application needs to send data to a workflow, it needs to get the service from the workflow runtime and then fire the events provided by the interface. If you drag the event handler into the workflow and call the event at the appropriate time, your workflow will handle these events handler.

On the other hand, for local communication services, workflows have no need to query the workflow runtime. After dragging a callexternalmethod activity into the processing path of your workflow, the host is automatically notified when the data arrives--again assuming that the host application connects an event handler that receives the data event, the events handler, to the local communication service. The workflow runtime maintains the connection between the workflow instance and the local communication service and the host application.

Association

Again aftertaste the last paragraph of content. A workflow instance does not need to be searched around for services that communicate with the host application. However, the host application still needs to query the local communication service. However, in some ways, due to the nature of the interaction between the host and the workflow runtime, the process also emphasizes the one-to-many relationship between the host application and the workflow instance.

The host application needs to identify which workflow instance it wants to communicate with, because there may be many choices. However, a workflow instance does not have this option: because it is only possible to belong to a host application.

The host is always trying to get a service for data communication by querying the workflow, and the local communication service is one of the services you might want to visit. The reverse process is certainly the same. The workflow is bound to the local communication service without concern for the identity of the host application. This is an inevitable result of architectural design, because a workflow instance can only belong to one host application (they are a one-to-many relationship) and it is not possible to belong to more than one application, so it is not necessary to recognize the identity of the application. To sum up, the workflow runtime provides the local communication service for the workflow instance, and the workflow instance can call the external method at will.

So is it possible for the host to use the identifier of the workflow instance to route the data stream associated with it? In other words, if you have a workflow instance and then try to send and receive data back and forth from the workflow, is it just a workflow instance ID number that is not enough to uniquely identify the workflow instance and its associated data?

Yes, if your data stream is not a single stream of data. Because there are multiple data paths in and out of your workflow. For this reason, the correlation was born.

When you use related workflows to communicate, the workflow runtime eventually creates a storage container for the vast amount of information necessary to identify the workflows and data we are talking about. When the host and workflow transmit data back and forth they need to consult the relevant token (correlation token), if the relevant token indicates that the sessions on both sides are synchronized, it means that the correct workflow instance and the bound activity are communicating with the correct batch of data and can continue to communicate. However, if a related token indicates a problem, the workflow runtime does not allow data communication to continue and throws an exception. Problems may include using an incorrect workflow instance, positive and false data communications, invoking an activity that is bound to a different related token, or attempting to send data without first creating the relevant token.

The related tokens are maintained by the CorrelationToken class. When you drag Callexternalmethod or handleexternalevent activity into your workflow, if the association is invoked, you need to specify a related token. Related tokens are shared by name, so from the standpoint of a data session, you can effectively bind these activities together by assigning related tokens of the same name for more than one related activity. The name of the token is nothing more than a string, and its value is meaningless except for recognition.

Why didn't the book introduce the relevant tokens earlier? This is a good question. After all, we have undoubtedly used Callexternalmethod and handleexternalevent activities in the previous work.

The answer is that we choose not to call the association. The association is not always necessary in all cases, until you actually create such a workflow in this chapter. When you have a one-to-one mapping between your application and the workflow instance, the association is not required, and you can ignore it and enjoy a slight improvement in performance as a result.

Even when your single host application has more than one workflow instance, you can work without correlation. However, when you use an association, WF prevents you from inadvertently confusing data, which in many cases is a very desirable feature.

To activate the associated usage base, you use a specific WF based feature when you create your host communication interface. The good news is that handling the execution of the host traffic doesn't change a lot, but the effect on your workflow is exciting.