State machine workflows do not follow a fixed, linear path. 'J OrderOpenState -£¡1 OrrOrderUpdated i OnOrdarProcessedįigure 26-4. Sequential workflows have a clear starting point and ending point. NET Framework 3.5 SDK documentation for further information if you are interested. Note In this introductory chapter, I don't dig into the details of building state machine workflows. Once that occurs, an event forces the flow of activity to the order open state, which may trigger an order processed state (or loop back to the previous open state), and so forth. Here, we have a request state that is waiting for an order to be created. State machine workflows can be very helpful when you need to model a business process that can be in various states of completion, typically due to the fact that human interaction is involved to move between states. Don't worry about the details of what each activity is doing behind the scenes, but do notice that each request state in the workflow can flow across various states based on some internal event. Figure 26-4 illustrates a simple state machine WF diagram that represents the processing of an order. Instead, the workflow defines a number of request states and a set of related events that trigger transitions between these states. In contrast to sequential workflows, state machine workflows do not model activities using a simple linear path. If the car isn't in stock, we send a notification e-mail, provided that we have the client's e-mail address at our disposal. If the car is indeed in stock, the order is processed using some block of custom code (whatever that may be).

For example, the business process modeled in Figure 26-3 has two possible outcomes: the car is in stock or it isn't. Sequential workflows work well when the workflow models interactions with various systemlevel atoms, and when there is no requirement for backtracking in the process. Figure 26-3 shows a simple sequential workflow that models a partial business process for verifying a given automobile is in stock. Within the Visual Studio 2008 workflow designer, the path of execution begins at the top of the WF diagram and proceeds downward to the end point. The key aspect of a sequential workflow is that it has a crystal-clear beginning and ending point. This is not to say that a sequential workflow is necessarily linear or predictable in nature-it is entirely possible to build a sequential workflow that contains various branching and looping activities, as well as a set of activities that execute in parallel on separate threads. Create lean-forward learning moments with interactive sorting, labeled graphic, process, timeline, and accordion blocks. As its name implies, a sequential workflow allows you to model a business process where each activity executes in sequence until the final activity completes. The most straightforward workflow type is sequential. Ultimately, both categories are constructed by piecing together any number of related activities however, exactly how they execute is what sets them apart. The WF API provides support for modeling two flavors of business process workflows: sequential workflows and state machine workflows.

Sequential workflow designer