From getting started to mastering WF (chapter 4): Introduction to activities and workflow types

Previous Article: WF from entry to mastery (Chapter 3): workflow instances

After learning this chapter, you will learn about:
1. How is a workflow activity formed?
2. Differences between ordered workflows and state machine workflows
3. Create an ordered Workflow
4. Create a state machine Workflow

Activity is the basic unit of workflow processing in WF. If you break down a business processing process (or workflow task), you will find that it consists of smaller and finer tasks. If such a large task needs to be designed and the information needs to be sent to a series of data processing systems for processing, the subtask may include the following: Reading data from the database, use the data to generate a file, upload the file to a remote server by using FTP or XML Web Service, and mark that the information has been processed (such as by writing data to the database and entering the audit step. These subtasks focus on a specific task: Reading databases, uploading files, and auditing. In other words, they are activities.
When you create a workflow, you bundle these individual activities and transfer them from one activity to another. Some activities can be used as containers for other activities. We have discussed how to execute a single task in some activities. Container-based activities are used to accommodate other activities. In the previous chapter, we talked about root activities. The root activity is both an ordered activity and a state machine activity. In this chapter, we will describe the types of these activities.
How do I know what to do next after this step is completed? This chapter focuses on this. The activity may be executed in the sequence specified when you create a root activity, or it may be executed only after a specific event occurs. To better understand the activity, we should first look at the WF activity object and then see how the activity is linked together.

activity Introduction: basic work units
WF provides you with an activity object. Activity implements a basic class that looks simple. It does not do many smart tasks, but it can interact with each other (this is not simple ). Activity objects are derived from "activity" and provide powerful functions. You can freely create your own activities. This topic will be introduced in chapter 13th (custom activities. In fact, the second part of this book is introducing the activity (Chapter 1 to Chapter 2 ). Table 4-1 lists the attributes of many activities that we are usually interested in. Table 4-2 lists the frequently used methods. In Chapter 13th, you will also see more methods and attributes related to custom activities.
Table 4-1 activity attributes

attributes	function
description	gets or sets user-defined activity descriptions.
enable	gets or sets a value indicating whether the instance can be executed and verified.
executionresult	activityexecutionresult ). (Canceled, compensated, faulted, none, and succeeded ).
executionstatus	obtain the status of workflow, which is one of the enumerated values of activityexecutionstatus (canceling, closed, compensating, executing, faulting, and initialized.
name	get or set the name of the active instance.
parent	obtain the parent activity that contains the activity.
workflowinstanceid	obtains the identifier of the workflow instance associated with the activity.

Table 4-2 activity method

attributes	function
cancel	cancel the execution of the activity.
clone	return a deep copy of the activity.
execute	run the activity in synchronous mode.
getactivitybyname	If a combination activity is executed, this method returns the activity with the specified name contained in the combination activity.
load	load an active instance from a stream.
raiseevent	triggers an event related to the specified dependency attribute.
raisegenericevent	triggers events related to the referenced dependency attribute. Raiseevent and raisegenericevent have the same role -- the first event raiseevent directly points out dependencypropenty, while raisegenericevent is a generic version.
Save	Save the activity to the stream.

Activity methods generally have virtual and protected attributes. The purpose is that you can override them to provide an implementation that meets your own activity needs. So far, the most critical method is execute. When workflow calls this method during running, your activity starts to be executed.
activities can be divided into two categories: combined activities and basic activities. A combination activity contains other activities. An excellent example is the sequential activity that we have run through the book so far, visual Studio has already been created for us when creating an ordered workflow, which can be seen in the view designer ). So far, all Programs instances run workflow instances in a sequential activity, including other activities, such as its own, delay activity, and code activity.
basic activities, like the delay and code activities I just talked about, are a single-task-based activity that I talked about earlier in this chapter. In the end, you need basic activities to actually carry specific tasks. A combination of activities may direct the flow of tasks and data, but basic activities can do more.

Activityexecutioncontext object
Many activity object methods require an activityexecutioncontext object for input. The activityexecutioncontext object is created when the workflow instance you want to execute is queued during Workflow running. Therefore, it is not the object you want to create directly. Create it for you when workflow is running.
The activityexecutioncontext object is used to provide activities for methods and services to hook up with the workflow instance. Such as initialization, timer, and execution flow. It is essentially a helper object. In Chapter 13, we will discuss the activity context (environment) in more detail.
Note: If you are familiar with ASP. NET programming, the context object is essentially the same as the system. Web. httpcontext object. Others are similar to system. Threading. thread. currentcontext. The goals of all these context objects are the same: provide a storage location and easily restore information of a currently executed instance. In this case, it is an instance of the activity being executed.

Dependency Properties)
In Table 4-2, you will see some dependencyproperty ). What are dependency attributes?
Generally, If you create an attribute for the class, you will also create a field in the class to store the attribute value. CommonCodeAs follows:

Class Myclass
{
Protected Int32 _ x = 0 ;

Public Int32 x
{
Get   {Return_ X ;}
Set   {_ X=Value ;}
}
}

Field _ x is more officially called backing store. In this example, your class provides backing store for the X attribute.
However, WF and WPF usually need to access the attributes in your class. WPF needs to specify the space and size of controls in the container so that they can be render at the best. WF requires dependency attributes to facilitate activity binding. The activitybind class in WF allows you to easily bind activities.

Activity Verification
Activities generally have verification capabilities. you can recall Chapter 1.
In the example in chapter 1, Visual Studio reminds us of this situation. For example, if you do not specify the desired branch for execution in the ifelse activity, Visual Studio reminds us. Verification is performed for other activities.Algorithm. If we compile code with verification errors, our compilation will fail. We must correct the Code with insufficient verification conditions to compile and execute our workflow code.

Workflow type
You have created a workflow application, so you may notice that you can create different types of workflow applications.
The type of the workflow application depends largely on the root activity you choose.
Although you notice that there are only two types of workflow applications available in the new project dialog box,
However, there are three main types in actual use. You have created sequential workflows in this book so far, so they are not mysterious.
When you create a workflow, your activities are executed in the order you specified.
Another type of workflow displayed in the new project dialog box is the state machine workflow. I will discuss more about it in this chapter.
The third type of workflow is based on the ordered workflow, but it is rule-driven. It is not just to execute the task you specified,
It is a rule-based workflow consisting of policy activities and Rule Conditions to execute a workflow Task Based on your specified business rules.
We will learn more about this type of workflow in Chapter 12: "policy activity ". This type of workflow uses sequential activities as the root,
Therefore, this type of workflow application template is not available in the new project dialog box. You should start with an ordered workflow,
Then add a rule-based activity.

Select a workflow type
Under what circumstances is one type of workflow better than the other type of workflow? How do you select the appropriate workflow type?
Table 4-3 provides some basic references.
Table 4-3 selection of basic workflow types

Workflow type	Applicable Conditions
Sequential Workflow	Workflow tasks can be executed in an autonomous manner, with little external control. Workflow controls the executed tasks. There are only a few or no users to interact with it. Its root activity is a sequentialworkflow activity.
State Machine Workflow	A workflow task relies heavily on external entities to control and instruct its execution. Many user interactions (or other external controls) are expected ). For status-based workflow, the root activity is the statemachineworkflow activity.
Rule-based workflow	Business Logic contains complex judgment conditions, neither sequential workflow nor state machine workflow. A rule-based workflow may have an ordered root activity or a status-based root activity.

the ideal application of a sequential workflow is to perform business processing. If you need to read data from the source, process the data, send notifications, and write results to a data pool, the ordered workflow may meet your needs. This does not mean that ordered workflows are not suitable for processing specific tasks that depend on user interaction, such as approval tasks that agree or disagree. In fact, such user interaction should not be the focus of workflow itself.
if you need a lot of user interaction, when your workflow sends a notification to the user or other systems (for various reasons: notification, approval required, select an option, etc) for users or other systems to respond (their responses come from events), the state machine workflow may be a better choice. These events trigger the conversion of workflow from one processing state to another processing state. I will discuss this more later in this chapter and in chapter 14 ("state-based workflows.
the last workflow type (which we will see in Chapter 12) is rule-based workflow. These workflows determine whether to perform Conversion Based on business rules and determine the target after conversion. These workflows are usually preset with more complex plots.
you may think that all workflows can be created based on the Rule type, but we generally do not use this method to create them. Because other workflow types, such as sequential workflows and state machine workflows, can be easily created and tested.
use the most appropriate workflow type to build your system. Generally, in many real cases, you will find that you use a combination of all three workflow types.

ordered activities
let's dive deeper into ordered compound activities. Although we have used these activities throughout the book so far, I have intentionally delayed talking about more about it. Now we understand how the workflow runtime and the workflow instance work, and know that the workflow instance is the version of the workflow activity we are running, so we can better understand what happened.
executing ordered activities means that these activities are executed in a specified order. The first thing to do is execute first, and the last thing to do is finally execute. An ordered activity is like executing in a directory. You need to write down the first task, the next task, and the last task. If these tasks are stored as ordered activities, WF will precisely execute each task in the order you specify.
'note: we will not see Adding Activities dynamically in this book, but you should know that this can be done.
in Visual Studio, the view designer of workflow can help you display your workflow. When you create an ordered workflow application and open the root activity in the designer, you can place the task at the top of the screen to be executed first. Those tasks toward the bottom will be executed later. From the visual interface, we can see that the running sequence of the activity is from top to bottom. Of course, a sequential activity can also be a composite activity.

Create an ordered Workflow
So far, we have created some sequential workflow applications in this book, so I will not create them here. But I will repeat the complete steps.
Create an ordered workflow application
1. Open Microsoft vistual studio 2008.
2. select new project from the File menu. The new project dialog box is displayed.
3. In the project type panel, expand the vistual C # tree node and present a template based on the workflow project.
4. On the template panel, click the application or sequence workflow library in the ordered workflow console. The former creates an executable application and executes it on the console, while the latter creates a dynamic link library for use in other applications.
5. Enter the name of your project or application.
6. Enter or select the path where you want to save your project.
7. Click OK. Visual Studio 2008 will create a basic project for you, which includes the Workflow view designer user interface.
Then, you can easily drag the activities you need from the toolbox and adjust their attributes to meet your needs. If you need to add more workflow library projects, you can refer to the descriptions in the previous chapter, or simply add a new workflow class to your application. Next we will see a lot of examples.

Status Activity
So far, we have not seen the state machine workflow in this book. Chapter 14 focuses entirely on the work of State-based workflows, but here I will introduce some concepts and we will quickly create a state-based workflow.
Let's look at the term finite state machine. We divide this term into three words: finite, State, and machine. Limited means that the number of States we will convert is limited. Status is the logical condition for our application to convert when an event occurs. Machines mean automation. I will illustrate it with an example.
In engineering schools, you may be asked to use finite state machines to design some digital systems. Such as vending machines and washing machines. Look at the vending machine and think about the steps required for machine work so that it can provide you with the products you need (such as soda, candy, snacks, and so on ). When you invest a coin, it will aggregate the amount of coins you have invested until the amount of coins you have invested can be used to buy goods. When you select a product, it checks the inventory list. If there is goods, it will distribute the things you choose to you.
We can use finite state machines to build vending machines. In the graph of finite automatic machines, we use circles to represent States, arrows to represent transition between states, and switching is triggered by events. The figure shows a logical start point and one or more logical endpoints. If we stop somewhere else, our application is called an unspecified state or an invalid state. Our job is to prevent invalid status. For example, if we cannot get products for free, we should not receive extra money exceeding the product price. If the vending machine accepts the money but does not provide the goods, the user will undoubtedly be furious.
Imagine a simplified vending machine. Let's plot the status and the events that lead to status conversion. As I mentioned, the State is represented by a circle. Events that change your machine from one status to another are represented by arrows. They can all be named so that we can know what the status and related transformations are. We undoubtedly need a starting state, such:

Figure 4-2 starting state symbol of a finite state machine
This State indicates the location where the machine is located: Waiting for someone to invest a coin. So when someone puts a coin but it is not enough to buy a commodity, we can simulate it by creating a new status called waitcoins, switch to this status through the coininserted event, 4-3:

Figure 4-3 transition to waitcoins status
The machine remains in the waitcoins state and accepts the coininserted event until the user invests enough money to buy the product. Otherwise, sufficientcoins (the amount is sufficient) will be triggered) the event changes our machine to the waitselection status. Here, our vending machine will patiently wait for the user to choose a product. (In real life, users can also invest coins at any time. For the sake of simplicity, I will leave it alone in this example .)
After the user selects a product, the product will be distributed to the user, and our (state) conversion will end. The completion status, or the ending status, is specified by two circles. See Figure 4-4.

Figure 4-4
Although the vending machine may be too simple in the real world, I would like to provide you with a brief description of how the state machine works. When we design a state machine, we specify its discrete state or logical location to wait for the event to happen, and then we specify the event that changes the state of the machine. Some events allow the machine to return to the same status, such as the start status. Other events will convert the machine to a new state after a new event is processed. If no event is triggered, there is no state transition. Ideally, there should be no unexpected events or exceptions.
This model is very different from the sequential workflow model we have used. In a sequential workflow, activities are executed in the specified order. Once an activity on the chain finishes its tasks, the next activity on the chain begins to execute its work. Some events may be involved in workflow processing, but they are relatively simple in processing workflow tasks (such as timer events.
However, the status opportunity takes a lot of time to wait. They wait for events and rely on events to convert their statuses. Status itself does not trigger events (although they may call external code ). They are event processing, so they will patiently wait for the events they need to perform state conversion. Depending on the event, it is entirely possible to switch from a State to any discrete state. Assume that our vending machine is in the waitcoins status. When we receive a coininserted event, refundrequested event, or imminentpowerdown event, we will do different things separately. However, I did not Plot these events in the simplified model in Figure 4-4, but I believe you can understand how different events drive your finite state machine to switch to different States.
In WF, individual States in state-based workflow are created by State activity. A State activity is a composite (combination) activity, but it has limits on its sub-activities. You will learn more about status-based workflow in chapter 14.
Note: just as a sequential workflow uses a special sequence activity to accommodate the entire workflow, a state-based workflow also has a special root activity to do this. This is the statemachineworkflow activity, it is a special State activity. In particular, it is required so that the initialization parameters can be accepted by the root activity during initialization.

Create a state machine workflow application
How to Create a status-based workflow? Creating a status-based workflow is as easy as creating a sequential workflow. Now let's take a look at how to create a State Machine workflow. However, we do not add any code now. Although this is often the case later in this book, we only need to know how to create a State Machine workflow.
Create a state machine workflow application
1. Start Microsoft Visual Studio 2008.
2. Select create a project from the File menu. The Create Project dialog box is displayed.
3. Expand the Visual C # node in the project type panel, which will display all the project types that use the C # language.
4. Click the workflow node under the Visual C # node, which displays all workflow-based project templates.
5. In the template panel, click the state machine workflow console application or state machine workflow library. As shown in:

6. enter the name of the program or project.
7. Enter or select the location where the project file is to be saved.
8. Click OK. Visual Studio 2008 will create a project for you that contains the Workflow view designer user interface, such:

We need to trigger events that trigger workflow state changes. Therefore, we need to understand how workflow instances communicate with their host applications. We will see the communication between the host and workflow in chapter 8 ("calling external methods"). In Chapter 10 ("event activity"), we will learn the event-driven state machine workflow.

Next article: [translation] WF from entry to mastery (chapter 5): workflow tracking