WF from Getting started to proficient (14th chapter): Workflow based on state

After completing this chapter, you will learn:

1. Understand the concept of the state machine and how it is simulated into workflow processing

2. Create a state-based workflow

3. Application of initial (initial) and termination (terminal) condition

4. Use code to switch status

In the fourth chapter, "Introduction to activities and workflow types," I explained the types of workflows you can create with WF, where I mentioned stateful workflows. A stateful workflow model is considered to be a finite automaton (finite state machine). A stateful workflow is a great place to be in the context of many interactions between workflow needs and external events. When an event is triggered and processed by a workflow, the workflow can switch status as required.

WF provides a rich development experience for creating stateful workflows, and many of the things you've seen so far in this book apply to state based workflows. For example, when a state is switched over, you can perform several sequential activities, make conditional decisions (using rules or code), or use an iterative activity structure to iterate through some data points, if you want. The only real difference is how the activity is queued for execution. In sequential or parallel workflows, they are queued in the order in which they appear. However, in a state-based workflow, the activity queues in and out of state transitions. Events typically drive these switching processes, but this rule is not generic. Let's take a look at the concept of the state machine and combine these concepts with the WF activities that you can use to build your workflow.

The concept of the state machine

The purpose of the state machine is to build discrete points in your business process, and to switch control by events. For example, put your washer on the power supply, then close the door and press the Start button. When the Start button is pressed, a state machine is initialized that cleans your laundry until all of these cycles are complete by running a variety of cleaning cycles.

The state machine has a known starting point and a known endpoint. The intermediate state should be controlled by the triggering of the expected event, but the machine is always in a particular state. Sometimes an event throws a state machine into an invalid state, which is no different from the case of maintaining an unhandled exception in your application, and the whole process either stops suddenly or collapses completely. In either case, switching to an invalid state is closely monitored, at least in the digital electronic system (digital electronic Systems).

In general, the 4th chapter covers the basic concepts involved in State machines. See the section "State activity" for a quick review. Let's move from how to design activities to how to use activities in a stateful workflow.

Working with State activities

You may not be too surprised that State activity builds a status in your state-based workflow. It is a combination activity, but it is limited to accepting only certain types of activity as its child activities: EventDriven activities, stateinitialization activities, statefinalization activities, and other State activities. The EventDriven activity waits (listens) for events that will result in switching to another state, and when the state is switched in and out, stateinitialization and statefinalization are guaranteed to perform the corresponding processing separately. It may seem odd to drag a second state activity into an existing state activity, but the intention is to provide an ability to embed the child states machine in the parent machine.

There is also a limit to the number of effective activities that your state can hold. Only one stateinitialization and statefinalization are allowed, you can only one of them, but each one cannot be more than one. None of them are necessary.

But it doesn't say you can't have just one or more eventdriven and state activities. In fact, multiple EventDriven activities can generally be found, because each event can cause a switch to a different state. For example, a "disapprove" event may switch to the final state (end state), while an "approval (approve)" event may switch to a predetermined state and require more approval. As for state activity, there is no doubt that more than one should be allowed if you want to create an embedded workflow. A stateful workflow with only one State (toggle) is built into a simple sequential workflow, so you should use a sequential workflow directly in that case. In any case, using a state activity simply drags one instance of it from the Toolbox to the Workflow View Designer, and the only requirement is that the workflow itself must be a stateful workflow rather than a sequential workflow. Then determine what child activities your state activity should contain and drag them in as needed, bearing in mind that you can only insert four types of activity.