In order to better understand the architecture of the F2 workflow engine, it took some time to draw a system diagram of the entire architecture. The F2 workflow engine follows the reference WFCM specification . The goal is to realize a lightweight workflow engine, support multiple databases and quickly apply to any .net-based management system, and realize the intelligence and flexibility of workflow approval and business flow (BPM). It has strong expandability, integration, independence, openness and stability, and realizes visual process design or optimization. Common serial, parallel, branch, and aggregation can be implemented very conveniently and quickly. Relying on the powerful customization of workflow, administrators can also adjust the process according to the situation of the enterprise at any time, so as to truly realize the continuous optimization of the enterprise process. Graphical and visual design process definition A "drag and pull" graphical user process design environment that does not require programming through the pure JS process designer on the web side , supports general process conditions, multiple nodes, and multiple flow directions.
About lightweight: easy to integrate and really embeddable architecture determines whether it is really lightweight. The so-called lightweight is easy to use and easy to integrate, there is no bloated third-party framework, and the extensive use of third-party frameworks will make users The threshold is very high, and a large number of applications of third-party frameworks are not only very difficult to integrate, but also need to solve various version conflicts. Ultimately, the self-proclaimed lightweight workflow cannot achieve true embedded integration or it costs money to do embedded integration. A lot of time and labor cost to solve various version conflicts. Almost all of the search results on Baidu claim to be lightweight, but most of them are called lightweight for the sake of claiming to be lightweight, but the actual application is still heavy-duty workflow. Integrating the embedding is very difficult, various DLL or Jar packages conflict.
From my understanding, why do you want to be lightweight in the first place? The reason is that you have to serve other systems. As a workflow engine, you have to face various business systems and be integrated into the business systems. Because Such an application determines that the workflow engine itself must be a very pure code environment. Therefore, the most lightweight is the native code of C# or Java. The entire engine uses at most one of the most commonly used architectures in the industry, such as Java's SpringMVC, .net's asp.net MVC, and does not use any third architecture. , so your engine code will be very pure, and can only be compiled into a DLL or a Jar package. In this way, not only there is no conflict during integration, but also it will not cause the original business system environment to be more complicated due to excessive references, which will lead to a skyrocketing maintenance cost in the future.
The architecture design of the F2BPM workflow engine is based on the extremely lightweight design, which is truly lightweight. Doing good things practically leads to more tangible achievements than beautiful publicity.
Above: F2BPM Workflow Engine Microkernel Technology Architecture
Above: Five interfaces of F2BPM process engine
l Web modeling tool: also known as "process designer", which is a "drag and pull" graphical user process designer tool based on browser-based pure JS process designer without programming.
l Process Engine: Schedule, advance workflow processes and activities.
l Task Manager: Maintenance activities, providing data for external system call participant task lists
l Organizational model: Process tasks are ultimately applied to people to achieve the effect of human-computer interaction and provide participants for process operation.
l ORM that supports multiple databases : The workflow engine needs to be applied to each system, it needs to have its own ORM database access layer, and supports multiple database types at the same time.
l Process data: the model database data, the process definition related data.
l Related data: that is, motion database data, related to-do tasks, motion data such as activity instances, process context data, etc.
l Process instance: Process instance work order data.
l Task data: To-do work item data.
l Formal parameter data: parameter type data specified in external Tools and Apps.
l Control data: migration precursor ID, follow-up activity ID, workflow object status and other data.
l Business form data: the data of the work task activity interface, that is, the form display
l External organization model data: user organization role data of external systems
l External application data: data required for external data execution
Workflow: Workflow
Workflow Definition: WorkflowDefinition
Activity Activity: Activity means step.
Actor: An actor is a human, machine, or organizational unit that is directly or indirectly involved in performing work.
Task: The user to-do task instance is the smallest unit of work, that is, a work item.
Migration: The turn of flow, indicated by the line with the sword. That is, transitions in Petri nets
SplitXOR: XOR distribution, that is, only one branch can be selected in the subsequent steps.
SplitOR: or distribution, that is, the subsequent steps can choose a branch greater than or equal to 1
JoinXOR: XOR aggregation, that is, as long as there is one branch aggregation in the previous step, it satisfies
JoinOR: Aggregate, 1 or more branches need to be aggregated according to the rules
WorkFlowEnactmntService (workflow execution service) This component is what we usually call the workflow execution service or the workflow engine. It contains multiple workflow machines. The main function is to read the workflow definition, drive the flow of the workflow according to the workflow definition, and divide the workflow. There are three stages:
1. Model building stage: use workflow modeling tools to design, and parse and import XPDL files into the model library.
2. Model instantiation stage: import the model library database into the motion library, initialize the state, and allocate the resource parameters required for each activity to execute.
3. Model execution stage: According to the status of the runtime library and condition judgment, it promotes the migration of the process state and completes related tasks, and provides monitoring and tracking of the running process of the injection process instance.