WF Study Notes-development Basics

Directory

1. PASS Parameters

2. Execution Context

Three-State Graph Modeling

1. PASS Parameters

(1) parameter transfer between workflow and host

Parameters are defined as attributes in the workflow class. They can be common or dependency attributes. The specific differences will be discussed later.

If a common attribute is definedCodeShape:

Public DoubleLeft {Get;Set;}Public DoubleRight {Get;Set;}Public DoubleResult {Get;Set;}
 

The Code of passing parameters to a workflow is as follows:

  dictionary  string ,  Object  wfargs =  New  dictionary  string ,  Object   (); wfargs. add (  "  left  " ,  1  ); wfargs. add (  "  right  " ,  2  ); workflowinstance  = workflowruntime. createworkflow ( typeof  (workflowlibrary. workflow), wfargs);  

Obtains the attribute values of output parameters in a workflow. The Code is as follows:

 
(Double) E. outputparameters ["Result"]
 

(2) Dependency attributes

Attribute values of dependency properties are stored in a central repository (similar to a dictionary), rather than common instance variables in the class. The main difference between dependency attributes and common attributes is that attribute values can be bound to instance data at runtime. You can bind the attributes of Activity A to the attributes of Activity B, or to the attributes of the workflow (the workflow can use common attributes ). The actual value of the property generated by the binding is determined at runtime. Dependency properties are often used when custom activities are defined.

Vs built-in dependency attribute implementation template:

Code Format:

(3) Binding

To assign an attribute of Activity A to a member of Activity B or a member of a workflow, bind the attribute to the workflow. Binding can be declared to process passed values without explicitly assigning values using code. Bind the system. workflow. componentmodel. activitybind class definition.

1. bind it to the designer

2. Bind in the code

View the background code of the workflow. We can see that if vs is bound by code, its code is like:

  system. workflow. componentmodel. activitybind activitybind3 =  New   system. workflow. componentmodel. activitybind (); activitybind3.name  =  "  workflow  " ; ///   Object Name  activitybind3.path = "   right  " ;  //   Object member   This . sumactivity1.setbinding (activitylibrary. sumactivity. rightproperty, (system. workflow. componentmodel. activitybind) (activitybind3); ///   bind  

Generally, you do not need to explicitly define the binding. The process designer will generate the relevant code.

3. bind it to the configuration file

WF supports setting binding in the configuration file, but I did not try it. For more information, see the documentation on the WF configuration section of msdn.

2. Execution Context

The execution of each activity is accompanied by an execution context (including the execution context of one or more activities), which provides a mechanism to safely reference Parent and Child activities. The execution context is represented by activityexecutioncontext, which mainly applies to three aspects:

• DurabilityThe execution context provides a container for storing the workflow status.
• LoopThe built-in cyclic activities (replicatoractivity, whileactivity, and conditionactivitygroup) of WF are used to execute subactivities multiple times. Essentially, cyclic activity creates sub-active copies within the cyclic body and executes these copies (deep replication ).
• CompensationEach execution of an activity is accompanied by the execution context, so that the compensation can obtain a series of operations of the completed activity to help the compensation to restore the activity status.

Most of the time, the execution context does not need to be explicitly called. However, we need to consider using the execution context in the following three aspects:

• Access sub-activities in a loop
• Write rules
• Develop custom activities

In subsequent blog posts, I will provide the instance code, which will not be discussed in this article.

Three-State Graph Modeling

This section briefly introduces the knowledge of state chart Modeling in UML. Readers may think that UML is beyond the scope of WF development, but I believe that familiarity with state chart modeling is the basis for developing state machine workflows. The excellent entrance point of the UML state chart.

A state chart is used in UML to create a dynamic model. A status chart is used to describe the lifecycle of objects, subsystems, and systems. Shows the business model for form approval:

it can be seen that the form is in the "new" state when the user fills in the application. After entering the information and sending the signature, the form changes to "flow. Before the approver processes the application, the applicant can also revoke the application. At this time, the form is changed to "new. In the form approval process, regular signing and return operations do not change the form's "flow" state. However, when the last level-1 approver is approved, or a approver is decommissioned, the form will be changed to "closed" and "voided" respectively. It can be seen that the state chart focuses on the transition between States. Therefore, we should first identify all target States and then consider the transition events between States.