Summary of the basic concepts of osworkflow (basic concepts, package Usage Analysis and code snippets, table structure analysis, main advantages, and core concepts)

Transferred from: a q's home

1. Basic concepts of osworkflow
In the commercial and open-source world, osworkflow is different from these existing workflow systems. The biggest difference is that osworkflow has excellent flexibility. It may be difficult to get started with osworkflow (some people say it is not suitable for beginners of workflow). For example, osworkflow does not require graphical tools to develop workflows, but it is recommended to manually write workflow descriptors in XML format. It can provide integration for application developers and integrate with existing code and databases. This seems to cause trouble for those looking for a quick "plug-and-play" workflow solution. However, research has found that, plug-and-play solutions cannot provide sufficient flexibility in a mature application to meet all requirements.
2. Main advantages of osworkflow
Osworkflow gives you absolute flexibility. Osworkflow is considered as a "low-level" workflow implementation. Compared with other workflow systems that can use icons to represent "loops" and "conditions", osworkflow is only implemented by manual "encoding. However, this does not mean that the actual code requires full manual encoding. The script language is competent for this situation. Osworkflow does not want a non-technical user to modify the workflow. Although some other workflow systems provide a simple GUI for workflow editing, changing the workflow like this usually destroys these applications. Developers are the best candidates for workflow adjustment, and they know how to change the workflow. However, in the latest version, osworkflow also provides a GUI designer to assist in workflow editing.

Osworkflow is based on the finite state machine concept. Each State is represented by a combination of step ID and status (which can be simply understood as a step and its status, indicating the State of a finite state machine ). The transition from one State to another is dependent on the action, and there are at least one or more active states in the workflow life cycle. These simple concepts demonstrate the core idea of the osworkflow engine and allow a simple XML file to explain workflow business processes.
3. core concepts of osworkflow
3.1. Definition

Step)
A step describes the position of a workflow. It may be transferred from one step to another, or in the same step (because the step can be subdivided by status to form multiple States ). Multiple steps are allowed in a process.

Status)
Workflow status is a string used to describe the specific step status in a workflow. Osworkflow has three statuses: underway (in progress), queued (waiting for processing), and finished (complete. An actual state is actually composed of two parts: State = (Step + status ).

Transfer)
Transfer a State to another State.

Action)
Action triggers the flow occurring within or between steps, or State-based flow. A step can contain multiple actions. The relationship between action and step is that step indicates "where" and action indicates "where ". An action is typically composed of two parts:
Condition and the result after the action is executed ).

Condition)
Similar to logical judgment, it can contain "and" and "or" logic. For example, the "approval stage of the Department" in a leave process uses the "and" logic to determine whether the process status is waiting for processing and whether the approver is the department director.

Result)
Result indicates the result after the action is executed, pointing to the new step and its step status, or entering split or join. There are two types of results: contidional-result (conditional result). This result is used only when the condition is true, and unconditional-result (unconditional result ), this result is used when the condition is not met or there is no condition.

Split/join)
Splitting and integration of processes. A simple concept: Split can provide multiple results; join is used to determine the state of multiple current steps to provide a result ).
3.2. Steps, statuses, and actions (step, status, and Action)
The workflow must describe the steps, the status of the steps, the relationship between the steps, and the conditions and permissions for performing the steps, each step can contain one or more actions, which change the status of a step.

For an executed workflow, step switching is inevitable. A workflow has one or more current steps at a specific time. Each previous step has a status value. The status value of the current step constitutes the status value of the workflow instance. Once a step is completed, it is no longer the current step (but a new step). Generally, a new step is created to ensure that the workflow continues to be executed. The final status value of the completed step is specified using the old-status attribute. The setting of this status value will occur before switching to another step. The value of old-status can be arbitrary, but we usually set it to finished.

Switching itself is the execution result of an action. Each step can contain multiple actions. The actual action to be loaded is determined by the automatic call of the final user, external event, or tigadh. As the action is completed, a specific step switch will also take place. Actions can be restricted to users, user groups, or the current status. Each action must contain one unconditional result and zero or more conditional results.

Therefore, a workflow consists of multiple steps. Each step has a current status (for example, queued, underway or finished), and one step contains multiple actions. Each step contains multiple executable actions. Each action has execution conditions and functions to be executed. Actions include the results that can change the status and the current workflow step.
3.3. Results, branches, and connections (results, joins, and splits)
3.3.1. Unconditional result (unconditional result)
For each action, an unconditional result must exist. A result is a series of commands that tell osworkflow what to do for the next task. This includes switching a workflow from one status to another.
3.3.2. Conditional result)
Conditional result is an extension of unconditional result. It requires one or more condition sub-labels. The first true conditional (using the and or type) indicates the switch step. This switch step occurs because a user executes an action.
3.3.3. Three different results (conditional or unconditional)
A new, single combination of steps and states.
A combination of two or more steps and states.
Combine this and other switches into a new single step and state combination.
Different results correspond to different XML descriptions. For more information, see http://www.opensymphony.com/osworkflow/workflow_2_7.dtd.
Note: Generally, a split or join operation will no longer lead to a split or join operation.
3.4. Auto actions)
Sometimes, we need some actions that can be automatically executed based on some conditions. To achieve this, you can add the auto = "true" attribute to the action. The process will examine the conditions and restrictions of this action. If the conditions are met, the action will be executed. Auto action is executed by the current caller. Therefore, the caller of this action is checked for permissions.
3.5. Integrated abstract instances (integrating with abstract entities)
We recommend that you create a new attribute workflowid in your core entity, such as "document" or "order. In this way, when a new "document" or "order" is created, it can be associated with a workflow instance. Then, your code can use the osworkflow API to find this workflow instance and  and actions of this workflow.
3.6. workflow instance state)
In some cases, it is helpful to specify a status for the entire workflow instance, which is independent of the Process execution steps. Osworkflow provides "meta-states" that can be included in some workflow instances ". These "meta-states" can be created, activated, suincluded, killed, and completed. When a workflow instance is created, it is in the created state. Then, as long as an action is executed, it will automatically become activated. If the caller does not explicitly change the instance status, the workflow will remain in this status until the workflow ends. When a workflow cannot execute any other action, the workflow automatically changes to the completed state.

However, when a workflow is activated, the caller can terminate or suspend the workflow (set the workflow status to killed or suincluded ). A terminated workflow can no longer execute any action, and it will always be terminated. A suspended workflow will be frozen and cannot be executed. In addition to its status, it becomes activated.
4. osworkflow package Usage Analysis and code snippets
4.1. com. opensymphony. Workflow
This package provides core interfaces for the entire osworkflow engine. For example, the com. opensymphony. workflow. workflow interface can be said that most of the work in development is centered around this interface, which has three implementation classes: basicworkflow, ejbworkflow, and ofbizworkflow.
4.2. com. opensymphony. workflow. Basic
The package has two classes: basicworkflow and basicworkflowcontext. Basicworkflow does not support transactions. transactions cannot enclose transactions even if they depend on persistent implementations. Basicworkflowcontext is rarely used in actual development.

Public void setworkflow (INT userid ){
Workflow workflow = new basicworkflow (integer. tostring (userid ));
}

4.3. com. opensymphony. workflow. config
This package has an interface and two implementation classes for this interface. Before osworkflow 2.7, the status was maintained by static fields in multiple locations. This method is convenient, but it has many defects and constraints. The main drawback is that you cannot run multiple osworkflow instances through different configurations. Defaultconfiguration is used to load general configuration files. Springconfiguration allows spring containers to manage configuration information.

Public void setworkflow (INT userid ){
Workflow workflow = new basicworkflow (integer. tostring (userid ));
}
4.4. com. opensymphony. workflow. EJB
This package has two interfaces: workflowhome and workflowremote. Among the several classes of this package, ejbworkflow is the most important. This class, like basicworkflow, serves as the core of osworkflow and uses EJB containers to manage transactions, it is also used as the wrapper of the workflow Session Bean.
4.5. com. opensymphony. workflow. Loader
This package has several classes and uses xxxxdescriptor most. If you need to know the specified action, step status, name, and other information when running the workflow engine, these descriptors play a major role.

Public String findnamebystepid (INT stepid, string wfname ){
Workflowdescriptor WD = workflow. getworkflowdescriptor (wfname );
Stepdescriptor stepdes = WD. getstep (stepid );
Return stepdes. getname ();
}
4.6. com. opensymphony. workflow. OFBiz
Ofbizworkflow and basicworkflow are very similar in many aspects, except that the transactionutil of OFBiz needs to be called to wrap transactions.
4.7. com. opensymphony. workflow. Query
This package is designed for query, but not all workflow storage supports query. Generally, both Hibernate and JDBC are supported, but memory workflow storage is not supported. It is worth noting that the hibernate storage does not support hybrid queries (for example, a query contains both the history step context and the current step context ). To execute a query, create a workflowexpressionquery instance and call the query method of the workflow object to obtain the final query result.

Public list querydepadmin (INT userid, int type ){
Int [] arr = getsubperson (userid, type );

// Construct an expression
Expression [] expressions = new expression [1 + arr. Length];
Expression expstatus = new fieldexpression (fieldexpression. status,
Fieldexpression. current_steps, fieldexpression. Equals, "queued ");
Expressions [0] = expstatus;

For (INT I = 0; I <arr. length; I ++ ){
Expression expowner = new fieldexpression (fieldexpression. Owner,
Fieldexpression. current_steps, fieldexpression. Equals,
Integer. tostring (ARR [I]);
Expressions [I + 1] = expowner;
}

// Query the number of unfinished streams
List wfidlist = NULL;
Try {
Workflowexpressionquery query = new workflowexpressionquery (
New nestedexpression (expressions, nestedexpression. And ));
Wfidlist = workflow. Query (query );
} Catch (exception e ){
E. printstacktrace ();
}
}
4.8. com. opensymphony. workflow. Soap
Osworkflow supports remote calling through soap. This call is implemented using webmethods.
4.9. com. opensymphony. workflow. SPI
This package can be said to be a way for osworkflow to deal with the persistent layer, such as the current workflow entity, including: EJB, hibernate, JDBC, memory, OFBiz, OJB, and prevayler.

Hibernateworkflowentry hwfe = (hibernateworkflowentry) gethibernatetemplate ()
. Find ("from hibernateworkflowentry where id ="
+ Wfidlist. Get (I). Get (0 );
4.10. com. opensymphony. workflow. util
This package is an osworkflow toolkit that supports beanshell, BSF, EJB local, EJB remote, and JNDI.
5. osworkflow Table Structure Analysis
5.1. OS _wfentry
Workflow master table, which stores the workflow name and status

Field name data type description
ID number
Name varchar2 (20) workflow name
State number workflow status

5.2. OS _currentstep
The current step table stores the data of the currently ongoing step

Field name data type description
ID number
Entry_id number workflow ID
Step_id number step number
Action_id number
Owner varchar2 (20) Step owner
Start_date Start Time
Finish_date End Time
Due_date date authorization time
Status varchar2 (20) Status
Caller varchar2 (20) operator's account name

5.3. OS _currentstep_prev
The previous step table stores the associated data of the current step and the previous step.

Field name data type description
ID number current step number
Previous number

5.4. OS _historystep
The historical step table stores the data of the currently ongoing step.

Field name data type description
ID number
Entry_id number workflow ID
Step_id number step number
Action_id number
Owner varchar2 (20) Step owner
Start_date Start Time
Finish_date End Time
Due_date date authorization time
Status varchar2 (20) Status
Caller varchar2 (20) operator's account name

5.5. OS _historystep_prev
The previous history step table stores the associated data of the previous step.

Field name data type description
ID number current historical step number
Previous number previous steps no.

5.6. OS _propertyentry
Attribute Table for storing temporary variables

Field name data type description
Global_key varchar2 (255) Global keyword
Item_key varchar2 (255) entry keyword
Item_type number entry type
String_value varchar2 (255) character value
Date_value date value
Data_value BLOB Data Value
Float_value float floating point value
Number_value number numeric value