Pro WF windows workflow in net3-learning notes-state machine

To define a state machine workflow, you start with the statemachineworkflowactivity class (found in the system. workflow. activities namespace ). this is the base class for your workflow when you select state machine workflow as the Add item template or when you select one of the state machine workflow project templates. you can add a state machine workflow to any project that supports workflows. this means you can mix and match sequential and state machine workflows in the same project.
To define a state machine workflow, you must start with statemachineworkflowactivity. statemachineworkflowactivity is a basic class when you use a state machine workflow as an add Project template or create a state machine project template. you can add a state machine workflow to any project, which means that you can mix and match the state machine and sequential workflow to the same project.

Individual States are defined in the workflow using the stateactivity (also in the system. workflow. activities namespace ). each event that you wish to handle is represented by an eventdrivenactivity. this is a composite activity that triggers execution when an event is already ed.
The first child of an eventdrivenactivity must support the ieventactivity interface in order to trigger execution of the other child activities when the event is already ed. when used in a state machine workflow, this typically means that the first event is a handleexternaleventactivity. following the handleexternaleventactivity, you include the other activities that you wish to execute when the event is already ed.
In a workflow, individual state instances are declared and defined through stateactivity. Each event must be called and declared through eventdrivenactivity. when an event receives a notification, the compound activity is triggered and executed. to trigger the execution of other sub-activities when the event receives the notification, the first eventdrivenactivity must inherit the ieventactivity interface. when a State Machine workflow is used, this feature means that the first event must be handleexternaleventactivity followed by the handleexternaleventactivity entity. You can add other entities that want this event to be executed after the notification is received.

The only direct child activities that are allowed for the statemachineworkflowactivity are the stateactivity and the eventdrivenactivity. this makes sense based on what you already know about state machine workflows. they contain States and can also directly handle events.
Statemachineworkflowactivity has only stateactivity and eventdrivenactivity, which constitute the foundation of the state machine workflow (or the state machine workflow is based on them). They contain statuses and can directly call events.

Each stateactivity has a select list of direct child activities that it supports. as I already mentioned, it accepts multiple instances of eventdrivenactivity, with each instance associated with one, and only one, event. A stateactivity also accepts a single stateinitializationactivity and a single statefinalizationactivity. both of these activities are composites and are optional.
Each stateactivity has a column of Immediate Child entities that it supports for use. As I mentioned earlier, it supports several eventdrivenactivity instances, in addition, each instance can be associated with only one event. A stateactivity can have a stateinitializationactivity and a statefinalizationactivity.

If you include a stateinitializationactivity, the activities that it contains are executed as soon as the stateactivity begins execution. this is done before it begins listening for any events that you have defined. if you include a statefinalizationactivity, it is executed immediately prior to transitioning to another State.
If you introduce a stateinitializationactivity, once the activity starts to be executed, all the activities it contains will be executed. before doing this, it will first listen to all the events you have defined. If there is a statefinalizationactivity, it will be immediately executed and switched to another State.

To transition to another state, you use the setstateactivity. you include the setstateactivity as the last child of an eventdrivenactivity instance. since this activity causes a transition to another State, it doesn' t make sense to include other activities following it.
To switch to other states, you can use setstateactivity. You can use the setstateactivity activity as the last subactivity of the eventdrivenactivity instance. Once this activity (setstateactivity) switches to another state, it does not execute other activities that follow it.

As shown in Figure 9-2, a state machine workflow (statemachineworkflowactivity) contains one or more instances of stateactivity. each stateactivity contains one or more eventdrivenactivity instances. each eventdrivenactivity begins with an activity that is capable of processing ing an event (handleexternaleventactivity ). following this activity, you include other activities that you wish to execute when the event is already ed. finally, the last child activity of the eventdrivenactivity can be a setstateactivity which transitions to another State. A similar stack of eventdrivenactivity instances can also be added directly as children of the state machine workflow. these activities enable handling of events regardless of the current state. the stateinitializationactivity and statefinalizationactivity are optional activities that are children of the stateactivity.
As shown in figure
As shown in Figure 9-2, a state machine workflow (statemachineworkflowactivity) can contain one or more stateactivity instances.
Each stateactivity can contain one or more eventdrivenactivity instances.
A handleexternaleventactivity starts.
Handleexternaleventactivity) is the other activities you want to execute when the event is called. Finally,
The last subactivity of eventdrivenactivity is a setstateactivity activity that can be switched to another State.
Eventdrivenactivity instances similar to Stacks can be directly added to the state machine workflow as subactivities. These activities (eventdrivenactivity) can
Process events regardless of the Current Status. stateinitializationactivity and statefinalizationactivity are
Stateactivity is optional and not mandatory.
Figure: Figure 9-2

Note: You may notice that the statemachineworkflowactivity class derives from stateactivity. This is what enables statemachineworkflowactivity to exhibit the behavior of a State, such as handling events and acting as the parent for other States.
Note that the state machine workflow activity starts from the stateactivity activity.

Initial and completed states
Initialization and completion status
Since a State Machine workflow is composed of multiple states, you may be wondering which state
The workflow is in when it first begins execution. The statemachineworkflowactivity class des
An initialstatename property. This property identifies the Initial State and must be set by you when
Implementing the workflow. Failure to set this property results in an error when you build the project
Containing the workflow.
Because a state machine workflow consists of multiple states, you may be wondering which state the workflow is in when it first begins execution.
The state machine workflow class includes an initialstatename attribute, which determines the Initial State and must be set during workflow instantiation (which may be incorrect ),

the statemachineworkflowactivity class also includes another important property named
completedstatename. this property identifies the state that causes the completion of the workflow.
when you transition to this completion state, this marks the end of the workflow and it stops
execution and completes. A completion state is an ordinary stateactivity, But if you select it in
the completedstatename property, it takes on this special meaning. one notable restriction is that a
completion state cannot contain any children. as soon as you transition to this state, the workflow
completes so there is no need to define any children. if any children were defined, they wouldn't be
executed.
the state machine workflow class also includes another important attribute: completedstatename, which determines the reason for workflow completion.
when you execute this completion state, it will cause the workflow to complete. completion state is a normal State activity, but if you set the
completedstatename attribute, it has a special meaning. it is worth noting that the completion status cannot contain any sub-activities. to switch to this status,
and end the workflow, you cannot add any sub-activities in the completion status. If you have added sub-activities, they will not be executed.

the completedstatename property is optional. at first, you might think this is a mistake, since
without it the workflow will never complete. this is not a mistake and that is exactly the behavior you
will see if you don't include a completion state. the workflow will never complete. instead, it will
continue to transition from State to State and handle the events defined for those States. for some
applications, this is exactly the type of behavior that you want. obviusly, for such long-running
(never ending) workflows, you wowould want to make sure that you use a persistence service. otherwise,
the workflow wocould end prematurely if the host process was ever shut down.
the completion status attribute is optional. In the beginning, you may think this is a misunderstanding or error because it will cause the work to never be completed.
This is not an error. Not including the completion status in the workflow is a strict (legal) action. the workflow will not be completed, but it will continue to switch from one status
to another and call the events defined in these statuses. obviously, as a workflow that has been running (never stopped), you can use it as a continuous
service. in addition, once the host is closed, the workflow will also be terminated too early (TRANSLATOR: this should be problematic, and the process instance can be serialized to the database or
file system, when the service is re-enabled, these process instances can be reloaded into the workflow.)

recursive composition of States
recursive combination status
the stateactivity can also include other instances of stateactivity. this is called recursive composition
of States. the primary use of this technique is to allow handling of selected events from more
than one state. for example, assume that you have two states: State A and State B. you may have an
event that you wish to handle while you are In either State. you have two ways to handle this. your
first option is to define the event within each State, duplicating the stack of activities you 've defined
to handle the event. this approach is shown in Figure 9-3.
stateactivity can also contain other stateactivity instances, which are called recursive composition
of States) the main technology used here is to allow you to process selected events from one or more States (What do you mean, cross-state ?).
For example, assume that you have two statuses: Status A and status B. You want to have a method that can be processed in any status. you have two ways to solve this problem.
One option is to define this method in each state.

Your second option is to enclose both of these States in a new parent State and handle the event
In the parent State. Using this second approach, you cocould create a new State C, and move States
And B into it as children. You can then add the eventdrivenactivity to State C to handle the event.
This approach is already strated in Figure 9-4.
Your second choice is to encapsulate the events to be processed in these two states into a new parent State. To implement the second approach, you need to create a State C
State A and State B are added to C as sub-States, and an eventdrivenactivity is added to State C to process events.

Since it is defined in a common parent state, the event can now be handled when the Workflow
Is currently in State A or B. Although not shown in Figure 9-4, each of the Child states (A and B) can
Still contain their own set of events that they alone handle. You will see an example of this type
State composition in one of the upcoming example workflows.
Because status C is defined as a common parent State, State A and State B in the workflow can process these events. Although not displayed in Figure 9-4, each sub state (A and B)
You can include your own events to implement specific processing. You will soon see an example of this.

when you transition to another State using setstateactivity, you can only transition to leaf
states. leaf states are those that do not contain in other States. using the previous example, you cocould
transition to State A or B but not to the parent State C since it contains other States. the parent State
(C in this example) is also not a valid candidate state for the initialstatename and COM Pletedstatename
Properties of the state machine workflow. since you can't transition to a composite parent state, you are
not allowed to designate it as the initial or completed state.
you can use setstateactivity to switch to another status. you can only switch to leaf states (what does leaf states mean ????)
leaf states cannot contain any other State (it should be a leaf state, that is, there is no extended state, and nnd is still unclear ).
in the preceding example, you can switch to A or B, but not to C, because C contains other states. the
initialstatename and completedstatename attribute cannot be set for this parent State (State C in this example), because you cannot switch to the combination parent state, it cannot be set to initial or completed status