LMES Flow Engine

Abstract

This document details the principles, configuration methods, and application scenarios of the LMES Flow Engine. The LMES Flow Engine is a specific application and deepening expansion of workflow in the production line MES field, designed specifically to meet the complex automated process management needs of production lines. The document is suitable for system administrators, developers, and business analysts to read, helping to understand and use the LMES Flow Engine.

1. Principles

What is a flow engine? As the name suggests, it is an engine base that supports process orchestration and process execution. Low-code platforms, office automation (OA), BPM platforms, and workflow systems all require flow engine functions. The problems it solves are mainly the flexible management of states in complex processes and orchestration capabilities.

The LMES Flow Engine is a specific application and deepening expansion of workflow in the production line MES field. It differs from general workflows in terms of functions, application scenarios, and design goals, being more professional and targeted to meet the complex automated process management needs of production lines.

The following describes the elements that make up the LMES Flow Engine from a static perspective, and how these elements are organized into a process definition, and then the working principle of the flow engine from a dynamic perspective.

1.1 Static Model: Process Definition

A process definition consists of a series of basic processing activities according to certain logical sequence rules. From an abstract perspective, a process can be mapped into a directed graph composed of steps and transition connections, while flow data is the data and information carried on the process at runtime. The following describes these three components separately.

1.1.1 Activity

In the flow engine, Activity is the basic unit that constitutes a business process, representing a specific operation or step in the process. In an automated business process engine: translating Activity as "Step" is a good choice. Because this type of engine focuses on various operations automatically executed by the system, "Activity" usually corresponds to specific system operation steps, such as data query, file transfer, command sending, etc., "Step" can accurately convey its function and action in the automated process.

Steps often carry relevant properties, including built-in properties such as name, description, operation mode, identifier, etc., as well as extended information contained in different step types. For example, manual participation steps need to store personnel/role and other related information, and extensible steps contain user-defined script attributes. Steps are extensible, definable, combinable, and reusable. In addition,

Each step also has Join/Split property information.

1.1.1.1 Step Types

• From the perspective of operation, steps can be divided into Automatic Execution and Manual Participation. For example, "Automatic Execution Step" refers to the operation link that the system automatically performs according to preset rules and logic without manual intervention during the process operation. "Manual Participation Step" refers to notifying the user through tasks, relying on manual start of the application to complete the corresponding function (such as user selecting Pass or Reject in the approval process).
• From the perspective of scale, it can be divided into atomic steps and mixed steps. Atomic steps are built-in operation steps that cannot be decomposed, such as: start step, end step. Mixed steps are combinations of multiple atomic steps.
• From the perspective of type, there can be predefined steps such as start step, end step, start sub-process step, etc., or extensible steps defined by .NET scripts.

1.1.1.2 Step Name

Step Name: Refers to the unique identifier of the step, which must remain unique throughout the process definition file.

1.1.1.3 Enter/Exit

Each step triggers three events at runtime: OnEnter, OnExecute, and OnExit.

• Enter Mode

  There are two options: "Manual" and "Automatic", indicating the way to enter the step.

  If the enter mode of the step is "Manual", when the process runs to this step, it will only trigger the OnEnter event of the step, and then wait for the user to process this step (Flow.RunAsync(ActivityName)) before triggering the OnExecute event;

  If the enter mode of the step is "Automatic", when the process runs to this step, it will trigger the OnEnter and OnExecute methods of the step.

• Exit Mode

  There are two options: "Manual" and "Automatic", indicating the way to exit the step.

  If the exit mode of the step is "Manual", when the process runs to this step, it will only trigger the OnExecute event of the step, and then wait for the user to process this step (Flow.RunAsync(ActivityName)) before triggering the OnExit event;

  If the exit mode of the step is "Automatic", when the process runs to this step, it will trigger the OnExecute and OnExit methods of the step.

Enter mode discusses the execution mode from OnEnter to OnExecute, while exit mode is the mode from OnExecute to OnExit.

Note: When the step is the start step of the process, whether manual or automatic, the OnEnter method will not be executed. When the step is the end step, whether manual or automatic, the OnExit method will not be executed.


1.1.1.4 Join/Split

• Split Mode

  Meaning: Describes how the process will continue to flow after the step execution is completed, that is, the post-condition or exit condition of the step. It defines which subsequent steps the process will go to based on different results or conditions after the current step is executed. There are two options: "SplitAND" and "SplitXOR".


SplitAND (AND Split): Multiple successor steps of a step. As long as the transition conditions of the subsequent steps are met, all subsequent steps will be triggered. That is, Parallel Split means that the process splits from a point in a thread into multiple activities executed in parallel in multiple threads. The completion of a activates the simultaneous execution of b and c.

SplitXOR (XOR Split): Multiple successor steps of a step. When the transition conditions of the subsequent steps are met, only the first subsequent step is triggered. That is, Exclusive Choice, which means a point in the workflow flows to one of several branches based on decisions or data in the process. The completion of a can only activate the execution of one of b or c.

• Join Mode

  Meaning: Describes under what conditions a step is triggered to enter, that is, the pre-condition or entry condition of the step. It defines how the process reaches the current step, including from which other steps and satisfying what specific conditions. There are two options: "JoinAND" and "JoinXOR".


JoinAND (AND Join): Multiple predecessor steps of a step. All predecessor steps must be completed and the transition conditions must be met for the step to be triggered. That is, Synchronization, indicating that multiple activities in the process converge into a thread at a point. Requires both b and c to be completed for d to be activated.

JoinXOR (XOR Join): Multiple predecessor steps of a step. As long as one predecessor step is completed and the transition condition is met, the step will be triggered. That is, Simple Merge, indicating that after d or c is completed, d is activated, without requiring both b and c to be completed.

1.1.2 Transition

Transition represents switching from one step (source step) to another step (target step), where the source step is the predecessor step of the target step, and the target step is the successor step of the source step. Transition combined with condition completes the transition process by judging whether the condition on the transition is established. Different condition types are bound on the transition.

Transitions are divided into Unconditional Transition and Conditional Transition. Conditional transition means that certain conditions must be met to execute the transition, such as setting an expression ok==true. As long as the expression is true, the transition is executed, otherwise it is not executed. Unconditional transition means that the transition will definitely be executed without meeting any conditions.

1.1.3 Condition

The base class for the condition for the transition to be established. Implement ICondition to define the condition. Transition is the link between links. Each transition must have a direction (one-way). When links are connected by transitions, it does not mean that the link can jump from the source link to the target link during execution. Because each transition can also be bound with transition conditions. Only after the transition condition is established can the transition truly connect the two links.

1.1.3.2 Property Condition (PropertyCondition)

If the business data is bound to an object, object property conditions can be used to directly judge whether the condition is established by comparing a certain property of the object. When the transition of the condition is related to a data item in the form, the property condition can be used as the transition condition. It is particularly emphasized that: when a property condition is used, it is necessary to ensure that the object associated with the process has such a property, otherwise the operation of the process may generate errors.

Condition Expression Mask for Property Condition: {Parameter}.{Property} {Operator}{PropertyToCompare}

Parameter Name (Parameter): Process context identifier, that is, a Key value in the process data dictionary. If it is empty, reference the ApplicationData parameter.

Property Name (Property): If the data corresponding to the Key is a complex type, further evaluation can be done by ParameterName.PropertyName. When PropertyName is empty, directly compare the value obtained by ParameterName.

Operator: Judgment operation of the property.

Value to Compare (PropertyToCompare): If comparing properties of the same object, the property name can be set directly. If you need to compare the property of another object in the process parameters, express it in the form of Parameter.Property.

Constant Value: If the value to compare is a constant, you can directly fill in Constant Value, otherwise use Value to Compare, choose one of the two.


1.1.3.3 Composite Condition (CompositeCondition)

Composite condition can be seen as a container for conditions, combining different conditions through AND and OR relationships to achieve complex condition calculations.


1.2 Dynamic Model: Process Instance

1.2.1 Process Instance (FlowInstance)

The process definition describes the execution of the business process, and the process instance is an instance that is actually run according to the process definition. Process instance processing includes a definition copy of the process and flow data.

From a mathematical model perspective, the execution of a process instance can be marked as follows:

Use a directed graph M = {D,A,T} to express the process instance, where:
	D={d1,d2,„,dn} represents the set of flow data
	A={a1,a2,„,an} represents the set of links
    T={t1,t2,„,tn} represents the set of transition connections, where t1=(aj,ak) is the transition from aj to ak, aj,ak∈A
Convention:
	∀ai,aj∈A, if there is t=(ai,aj)∈T, then ai is the predecessor link of aj, aj is the successor link of ai, t is an output transition of ai, t is an input transition of aj;
	If there is A'⊆A, and A'={a'|(a',a)∈T}, then A' is the set of predecessor links of link a; if there is A'⊆A, and A'={a'|(a,a')∈T}, then A' is the set of successor links of link a;
	If there is T'⊆T, and T(a)'={t|t(a,a')∈T}, then T' is the set of output transitions of link a; if there is T'⊆T, and T(a)'={t|t(a',a)∈T}, then T' is the set of input transitions of link a; Join/Split sets support XOR or AND operations;
Record state function
	For ∀a∈A, there is a state function state(a)={-1,0,1}, when the link is in the unexecuted state, state(a)=-1; when the link is executing, state(a)=1; when the link is executed, state(a)=0; initial state, ∀a∈A, state(a)=-1;
Record transition function
	For ∀t∈T, there is a transition function tran(t)={-1,0,1}, when tran(t)=1, it means transition is allowed; when tran(t)=0, it means transition cannot occur; when tran(t)=-1, it means transition is not yet determined; for Join/Split set T', support XOR/AND
Flow rules exist as follows:
	∀a∈A, state(a)≠1, tran(T(a))=1, then state(a)=1; when state(a)=1, and execution is complete, state(a)=0;
	∀t=(a,a')∈T, when state(a) changes from 1 to 0, if tran(T(a'))=1, transition occurs, if tran(T(a'))≠1, transition does not occur, until next time state(a) changes from 1 to 0, this rule is applied

The data description above constitutes the working principle of the flow engine. The process instance processed by the flow engine constantly checks the steps that meet the trigger conditions according to the process definition used under interaction with third parties or automatic triggering by the system, and according to the execution situation. If a step is executed, the state corresponding to the step is set to End, thereby triggering the flow engine to continue flowing until the End step is encountered.


1.2.2 Flow Data (DataItems)

Flow data can also be called Process Context data. Process context is a "virtual container" used by the flow engine to store and manage information such as process instance related data, status, parameters, etc., when executing a process. It is the core element supporting process node interaction and logic advancement. It is divided into internal data and external data by type.

Internal data includes:

• Standard parameter data: such as process identification, process instance identification, etc.
• Flow calculation related data: including historical traces (logs) of the process operation process, current status of the process, current status of each step
• Temporary data during flow calculation

External data includes:

• Data carried on the process instance at runtime, which can be a file or a business data record
• Station configuration data triggering the process at runtime

Core Functions:

• Data sharing: Implement data transfer between different nodes
• Logic driving: Serve as the basis for process branching and condition judgment
• Status tracking: Record process running trajectory, support backtracking and monitoring. For example, the nodes passed by the process and processing records can be viewed through the process instance ID


1.2.2 Lifecycle

Lifecycle of a process instance: Refers to the process of a specific process actually running from start to end according to the links and steps set by the process and complying with the rules and specifications of the process. The following are the different stages of the general process instance lifecycle:

1. Creation Stage: When a specific business instance triggers a process, a process instance is created. At this time, a unique identifier will be assigned to the instance, and the system will initialize related variables, data structures, etc., to prepare for the subsequent execution of the process. For example, in the process business flow, after the flow service is started, the system will create process instances corresponding to the associated processes for all stations.
2. Running Stage: The process instance starts to execute according to the preset process path, passing through each link and step in turn. In this process, variable operations, data processing and transmission operations may be involved, and each link has corresponding processing logic and operations.
3. Waiting Stage: During process execution, it may enter a waiting state because certain conditions are not met. For example, in the inbound process, it is necessary to listen to "Inbound Signal == 1". At this time, the process instance will pause execution until the conditions for continued execution are met.
4. Completion Stage: When the process instance passes the End Step, this indicates that a specific execution process of the process has ended, and related business processing has also been completed. Of course, there are also some processes without clear end steps. Such processes usually have the characteristics of looping, continuous running, or dynamically changing according to specific conditions. Processes without an End Step will never end automatically unless the process throws an exception, actively stops, or the program exits.
5. Exception Handling Stage: During process execution, if errors, abnormal situations occur, or process rules are violated, exception handling is required. This may include rollback operations, recording error information, restarting the process, etc., to ensure the correctness of the process and data consistency. Abnormal processes are automatically marked as Ended.
6. Archiving Stage: After the process instance is completed, relevant execution logs will be archived and saved for subsequent query, audit, and analysis. Process instance context data is not persisted for the time being.
7. Destruction Stage: When a process instance completes its task and enters the end stage, the memory space occupied by it needs to be released so that other programs or process instances can use these resources. Failure to release memory in time may lead to system memory leaks, gradually reducing available memory, and ultimately affecting system performance or even causing system crashes.


2. Configuration

2.1 Process Management


• Whenever a modification operation occurs in the process definition, the system automatically adds a corresponding record in the database and synchronizes updating the version number of the current process. The main purpose of adopting this mechanism is to provide strong support for subsequent possible process rollback operations, ensuring that in case of changes in business requirements or operational errors, it can be easily and accurately traced back to any previous valid process state.

• System built-in processes do not open modification permissions at this stage. There are two main reasons. On the one hand, due to the existence of customer groups in different languages, the process content needs to be translated into multiple languages. Unified built-in processes can ensure the smooth development of translation work and maintain consistency in content transmission; on the other hand, the process definition must be upgraded synchronously when the software is upgraded. Once users define processes themselves, conflicts will arise during the upgrade process, causing the software to fail to upgrade normally and affecting user experience.

• All flow instances of the same process definition use the same process definition (process template). During the flow process, as long as the same process template definition is cloned, it can become the process definition of the flow instance. All operations can be performed in memory, and performance is very well guaranteed. If the process changes during use, only the process definition template needs to be modified, and all flowing process instances can be adjusted to flow according to the revised process.

• Process Management Functions:

  • New Process: Create a new process definition, start from a blank process, or choose a template as a basis.
  • Import Process: Import process definition from an external file (such as an XML file).
  • Export Process: Export process definition to an external file for backup, sharing, or deployment in other environments.
  • Clone Process: Copy an existing process definition to create a new process, which can be modified and customized based on the existing process.
  • View Process: View the flowchart in read-only mode.
  • Delete Process: Delete user-defined processes.
  • Enable/Disable: Only processes with status "Enabled" can be automatically started by Flow Service. All processes (including disabled ones) can be manually started in the console.

2.2.1 New Process

You can use the process management function to add a user-customized process. System built-in processes are designed to be unmodifiable. Users can choose to clone and then customize functions on the copy.

• Process Name: The unique name of the process, duplication is not allowed in the entire process management.

• Interaction Type: Includes inbound/outbound interaction, inbound interaction, outbound interaction, and other interactions.

  Constraint: For inbound interaction and outbound interaction type processes, only one can be selected for the same process. For other interaction processes, multiple can be selected. Among them: Inbound/Outbound interaction (includes inbound interaction and outbound interaction).

2.2.2 Parameter Configuration

Select a process definition data in the process management interface, right-click "Parameter Configuration" to customize process function options and field configurations.


The following are the contents included in "Parameter Configuration":

1. Function Configuration:
   • Enable/Disable Function: Certain functions of the process can be enabled or disabled, such as product state detection, missing process detection, duplicate code detection.
   • Configure Enum Parameters: Optional parameters for certain functions can be configured, such as barcode acquisition method, qualification judgment method, etc.


1. Field Configuration:

   • Show/Hide Fields: Control whether to show or hide certain fields in the SOP manual dashboard, as well as the type of component rendered.
   • Modify Field Properties: Modify field properties, such as required, read-only, default value, etc.
   • Custom Field Validation Rules: Define field types, such as constant, variable, generate barcode, parse barcode, printer, etc.
   • Field Mapping: Fields in the process can be mapped to Variables in Variable Management to achieve data synchronization and integration.

   Through the "Parameter Configuration" function, you can flexibly customize process functions and fields according to actual business needs, making it better adapt to different application scenarios.


2.2.3 Process Design

There are two main ways for process design:

• Load Process Definition from XML File

  Loading process definition from XML requires familiarity with the XML format of the flow engine, which allows fine-grained control over all aspects of the process definition.

  Involves the following steps:

  1. Write XML File
     • Ensure the XML file conforms to the XML Schema required by the flow engine.
  2. Import Existing Process
     • Access the Web interface provided by the flow engine, find the visual designer entry, enter the designer, and select Import Existing Process.
     • The flow engine will verify the XML file to ensure it conforms to the XML schema and process definition rules.

• Use Web Visual Designer:

  The Web Visual Designer is a graphical tool that allows you to design processes by dragging and configuring components without manually writing XML code. You can quickly combine control flow activities by dragging and dropping. After modification, you can export the XML process definition file or directly call the WebAPI interface to save it to the system database.

  Using the Web Visual Designer typically includes the following steps:

  1. Open Designer:
     • Access the Web interface provided by the flow engine and find the visual designer entry.
  2. Drag and Configure Components:
     • Drag components such as nodes, tasks, events, gateways, etc., from the component panel to the design canvas.
     • Configure properties for each component, such as name, description, execution logic, input/output parameters, etc.
  3. Connect Components:
     • Use connection lines to connect various components to define the execution path of the process.
     • Conditional branches, parallel branches, etc., can be set to achieve complex business logic.

  

2.2 Process Association

For process flows, the process cannot be started and run alone, but acts as a "Process Template" that can be associated and used by multiple processes, thereby achieving that the same business process can adjust process behavior according to different parameters of station configuration at runtime. Process templates capture common patterns and logic in business processes, and through parameterization, configuration, modularization, standardized interfaces, and encapsulation of business rules, process templates can flexibly adapt to different scenarios. This greatly improves process development efficiency, reduces maintenance costs, and enhances system flexibility.

Core Functions of Process Templates:

1. Process Reuse: By defining common business processes as templates, they can be reused in different processes or scenarios, avoiding rewriting code for the same process, greatly improving development efficiency.
2. Process Standardization: Process templates can ensure that the execution of business processes remains consistent in different processes or scenarios, thereby achieving process standardization.
3. Process Configuration: Process templates allow customizing process behavior through configuration parameters without modifying the process definition. This enables the system to adapt to different business needs and improves system flexibility.
4. Centralized Process Management: When a process needs to be modified, only the process template needs to be modified, and all processes or scenarios using that template will be automatically updated.

The following are the approximate steps for process association:

1. Process Association Flow: In the process definition, you can select multiple process templates that need to be associated.

   

2. Station Automatically Brings Out Process Info: In station configuration, the system can automatically bring out the process template information associated with the station.

3. Automatically Select Function Configuration and Field Configuration: Automatically select corresponding function configurations and field configurations based on the association relationship between the station and the process template.


2.3 Process Execution

Before executing the process, please confirm that the processes to be executed are all in Enabled status.

Follow Start: All Enabled process definitions will automatically start/stop following the Flow Service start/stop. Flow Service can be manually started/stopped in CMS Editor. CMS Vision does not require manual operation and will automatically start after starting the software. Note that when Flow Service is stopped, all running process instances will be stopped.


Manual Start: Manual execution is suitable for debugging in time after adding or modifying a process. At this time, if CMS Vision is installed, the Flow Service cannot be restarted, and the entire software needs to be restarted. At this time, we can use the Flow Console (applicable to processes not associated with processes; for processes associated with processes, use the Station Console component) to manually operate the start and stop of the process.


For processes associated with processes, you can use the Station Console to reset the process.


2.4 Process Log

LMES Process Log Configuration File: CMS Editor\plugins\cms.plugin.messuite\Configs\NLog-Flow.config The maximum number of archive files generated for each type of log can be configured as needed (default: no more than 50), and the maximum size of each file (default: 20MB).

2.4.1 Variable Trace Log

Storage path: logs/flow_logs/{ProcessName_StationName}/tracelog_xxxx-xx-xx.log

Function Description: Variable trace log is specifically used to track LMES operations on variables.

Key Information of Variable Trace Log:

• Operation Type:
  • Read Variable: Records when LMES read the value of a variable.
  • Write Variable: Records when LMES modified the value of a variable, and the modified value.
  • Subscribe Variable: Records when LMES received a change in a variable so that it can be processed when the variable value changes.
• Variable Name/Value: Clearly indicates which variable was operated on, and the value of the variable.
• TraceId: A unique identifier used to trace the complete lifecycle of a single request or transaction.
• Timestamp: Records the time the operation occurred, used to analyze the sequence and time relationship of operations.

2.4.2 Instance Run Log

Storage path: logs/flow_logs/{ProcessName_StationName}/flowlog_xxxx-xx-xx.log

Function Description: Process instance run log records the processing status of each step in the complete lifecycle of the process instance from creation to end. This log is crucial for process monitoring, troubleshooting, and performance analysis.

Analysis Method:

• Flow Console: LMES provides built-in monitoring tools that can be used to view the run logs of process instances.
• Log Management Tool: Use log management tools to centrally store and manage process instance run logs, and provide powerful search and filtering functions.
• Custom Analysis Tool: Custom analysis tools can be developed as needed to analyze process instance run logs and generate various reports.

Below we use Notepad++ software to specifically analyze the running status of a process instance.

• Use {ProcessName}_{StationName} to retrieve log information of multiple consecutive inbound and outbound stations for the current station.


• Use Instance={xxxx} to retrieve log information of a certain inbound/outbound for the current station.


• Use TraceId={xxxx} to retrieve variable operation logs, combined with CMS and SIOT logs, to achieve full-link analysis of cross-process logs.


3. Application

3.1 Process Patterns

Process patterns are verified reusable solutions summarized to solve specific recurring problems in software development and business process management. They provide a set of standard, general methods to design and implement processes, thereby improving efficiency, reducing costs, and ensuring quality.


3.1.1 Basic Patterns (5 types)

(1) Sequence Pattern (Sequence)

The most basic process model: execute activities in order. The completion of the predecessor activity is a necessary condition for the start of the subsequent activity. Every flow engine system directly implements this pattern, which is an important cornerstone for the flow engine to run.


This theoretical model is very simple, just one work unit is completed, followed unconditionally by the execution of the next work unit.

(2) Parallel Split Pattern (Parallel Split)

In the process execution, a control point of a single process needs to be divided into multi-process controls that can be executed in parallel, thus allowing tasks to be executed simultaneously or in any order. This pattern is actually the SplitAND model we often encounter.


It is worth noting that this definition generally means B, C, and D are concurrent, and implementation is generally different threads/processes.

(3) Synchronization Pattern (Synchronization)

After the AND branch, a most common merge method is JoinAND merge. The next task can only start execution when multiple parallel tasks are completed.


The detail to note is the issue of "synchronization". Often there are realistic business considerations, even if it is the same action, it does not necessarily have to be merged.

Generally, parallel branching and merging are used in combination. The combined execution model is as follows:


(4) Exclusive Choice Pattern (Exclusive Choice)

Exclusive Choice Pattern is actually the SplitXOR "Exclusive Selection" pattern. At a node in the process, based on a result or process control data, one path is selected from multiple branch paths for execution.


Note the "exclusive" nature, only one branch can be selected, and other branches will not proceed.

(5) Simple Merge Pattern (Simple Merge)

At a point in the process, two or more alternative branches need to be aggregated without synchronization; in other words, "merge" is triggered when any entry connection is triggered.


This pattern is mainly to deal with processes where the predecessor has only one branch. This pattern is also a very commonly used pattern. In many flowcharts, those not explicitly stated can generally be regarded as JoinXOR, that is, completion of any predecessor triggers the next work unit. Generally, exclusive choice pattern and simple merge pattern are used in combination. The combined pattern is as follows:



3.1.2 Advanced Branching and Synchronization Patterns

(1) Multiple Choice Pattern (Multiple Choice)

At a point in the process, based on judgment or process control data, select one or more branches to execute. Usually, this is what we call OR_Split.


(2) Synchronizing Join Pattern (Synchronizing Join)

At a point in the process, multiple paths converge into one thread. If more than one path is triggered, the active threads need to synchronize; if only one path is triggered, the alternative branches should reconverge without synchronization.

Multiple paths in the process are converged into a single process at a point. If more than one path arrives, the active threads need to synchronize. If only one path arrives, then other paths should asynchronously reconverge.

This pattern is to deal with branches generated by Multiple Choice or commonly known OR-Split.


Explanation: The merging of this branch requires understanding the context. If only branch A was generated previously, then reaching the And-Join node can trigger subsequent activity D. If branches A, B, and C generated previously are all activated and triggered, and branches A, B, and C are concurrent, then when A and B have reached the Synchronizing-JOIN node, but branch C has not yet arrived, then it is necessary to Wait. Only when branch C also arrives at this node can the execution of the next node activity D be triggered.

(3) Multiple Merge Pattern (Multiple Merge)

Multiple Merge pattern means multi-path merge. At a node in the process, two or more branches reconverge without synchronization. If more than one branch is activated or multiple branches are activated simultaneously, and the process needs to respond once for each activated branch, then the Multiple Merge pattern needs to be adopted. In fact, multiple merge is not a merge in the true sense, but continuing the same subsequent branch when reaching the Multi-path_Join node.


Explanation: As shown in the figure, for three activities B, C, and D, when B reaches the "Multi-path_Join" node first, E1 is triggered. When C arrives, E2 is triggered. When D arrives, E3 is triggered. After all branches are triggered, E trigger is completed and ended. In fact, the same E is triggered each time, but the generated tasks are E1, E2, E3. They respond once for each inflowing branch. After all triggers are completed, the process continues to enter the subsequent process activities of E.

(4) Discriminator Pattern (Discriminator)

Path Discriminator refers to waiting for the completion of many incoming branches before activating subsequent tasks at a point in the process. From the moment it starts, it waits for the completion of all remaining branches and "ignores" them. Once all incoming branches are triggered, it resets itself so that it can be triggered again.


Discriminator pattern only applies to the case of simultaneous execution of And_Split; this pattern has three cases:

(1) B and C arrive at the Discriminator node at the same time, then execute D.

Generally, this situation will not happen because when the computer executes, there is always a sequence of execution, and one will always execute first.

(2) B arrives at the Discriminator node first, then there is no need to wait for the execution result of C, directly execute D. When C completes and arrives at the Discriminator node, the process will automatically ignore the result of C, restore the Discriminator to its original position, and continue to wait to be triggered.

(3) C arrives at the Discriminator node first, then there is no need to wait for the execution result of B, directly execute D. When B completes and arrives at the Discriminator node, the process will automatically ignore the result of B, restore the Discriminator to its original position, and continue to wait to be triggered.

(5) N-out-of-M Join Pattern (N-out-of-M Join)

N-out-of-M Join refers to M parallel paths converging to a point in the process. As long as N paths are completed, the subsequent task is activated, and the completion of all other remaining paths should be ignored. Similar to route discrimination, as long as all incoming branches are triggered, the merge resets itself so that it can be triggered again. N-out-of-M is actually merging multiple paths, performing partial synchronization, and executing subsequent activities only once.


Explanation: As shown in the figure above, M is 3, and we set N to 2. Then, if B and C both complete and reach the N-out-of-M Join node, meeting the N-out-of-M rule, there is no need to wait for the execution result of D, directly turn to execute E; when D completes and reaches the N-out-of-M Join node, the process ignores the execution result of D and resets the N-out-of-M Join node waiting to be triggered again. (LMES does not support yet)

3.1.3 Structural Patterns

(1) Arbitrary Cycles Pattern (Arbitrary Cycles)

During the execution of the workflow process, one or more tasks can be executed repeatedly.


(2) Implicit Termination Pattern (Implicit Termination)

This pattern is called implicit termination, or natural termination. It means that when all running nodes have no successor nodes, the process is considered ended. That is, there is no need to specify an end node. As long as all nodes are run (or no successor node is found), the process is considered ended.

3.1.4 Multiple Instances Patterns

(1) Multiple Instances with a Priori Design-Time Knowledge

A task in the process may need to create multiple instances, the number of which is known when designing the model. That is, in some cases, a task is activated multiple times, and the number of instances of the specified task in a given situation is known at design time. This pattern is used to establish the entry method for multiple instances. The main problem handled by the entry is to determine the number of instances N required. And this N is determined when designing the process.

(2) Multiple Instances with a Priori Run-Time Knowledge

The number of instances of a task is dynamic, that is, unknown at design time, but the number can be known at a certain point before all instances need to be executed during runtime. This pattern can be seen as a For loop initializing the task. In some cases, tasks can be activated multiple times. The number of instances of a given task is a variable in specified situations, depending on situation characteristics or resource availability, but it is only known at certain stages of the runtime, that is, the instances of the task are determined at runtime.

The entry method can also be determined dynamically. This pattern means that during the process operation, N is determined before the first instance in B is generated. Of course, the timing of determining this N can be the preceding A, or the work task before A. In short, it is determined before the first instance is generated, which can also be regarded as an application of this pattern.

(3) Multiple Instances without a Priori Run-Time Knowledge

The number of instances is dynamic, that is, the number of instances is unknown at design time, and cannot be known at any stage before all these instances need to be activated during runtime. This pattern can be seen as a while loop for task instantiation.

(4) Synchronizing Multiple Instances without a Priori Run-Time Knowledge

The number of instances is unknown at design time. Another task can only start (or begin) after all instances of the task are completed.

3.1.5 State-based Patterns

(1) Deferred Choice

One thread activates task A, another thread activates task B, and both tasks are in the task list. As long as one thread starts, the other thread should disappear (that is, if task A starts, task B should disappear from the work list).

At a node in the process, one or more branches have been selected. Compared with XOR split, there is no clear choice, but the choice depends on the environment. Compared with AND split, only one of the two is executed. This means that once the environment starts one of them, the other is cancelled. Note that the choice is delayed until one of the two branches actually starts execution, that is, the choice can be delayed as much as possible. Example: After receiving goods, there are two ways to deliver them. The choice depends on the availability of relevant resources. Therefore, the choice will be delayed until one of the resources is available.

(2) Interleaved Parallel Routing

A set of activities is executed in arbitrary order. Each activity is executed. Their order is determined at runtime, and no two activities are executed at any one time.

(3) Milestone

Whether an activity can be executed depends on a specified state. That is, the activity is executed only when a specific unexpired milestone is reached.

3.1.6 Cancellation Patterns

(1) Cancel Activity

An executable activity or step is forced to fail, that is, the thread where an activity or step waiting to be executed is located is removed.

Example: If a customer cancels a request, the activities associated with it are also cancelled.

(2) Cancel Instance

A process instance is completely cancelled.

(3) Cancel Flow

All instances of a process are cancelled.

3.1.7 Other Patterns

Structured Loop (Cancel Activity), Recursion, Transient Trigger, Persistent Trigger, Cancel Region,

Cancel Multiple Instance Activity...

3.2 Process Advancement

3.2.1 Business Creation

Users create process definitions in the Web-side process management, configure process stations in process management, associate business processes, and configure trigger variables and other parameter signals.

3.2.2 Process Start

After the first step is completed, start the business process. There are multiple ways to start the process, such as manual start, automatic start, external start, etc. The process start process is as follows:

1. Initialize Process
   • Create flow manager FlowManager, load process definition model (FlowDefinition), initialize process object (Processflow), and generate activity instances (ActivityInstance) for all steps.
   • Load station configuration data (ProcessModel), initialize process context data (DataItems);
   • Create process instance (FlowInstance), status: Begin [Process Start]
2. Status Change
   • Generate work tasks (FlowItem) for the start step, change status to Completed.
   • Change process instance status to: Running [Process Running]

3.2.3 Process Execution

After the process starts, the design pattern of the LMES process is that all tasks of the first start step have been completed, and the second step is executed directly. At this time, the whole process begins to execute truly, and step instances need to be analyzed. Step types are divided into the following two types:

1. Normal Step

   • Refers to that in the workflow process, there are no branches in the path between various activities (manual activities or automatic activities), only a single flow direction
   • In this case, directly read the information of the subsequent step in the transition table

   

2. Routing Step

   • Refers to that in the flow process, there are multiple (greater than 1) branches in the path transition between steps
   • Routing steps are divided into three cases:
     • Split
     • Converge
     • Loop

   

   

   

Step Execution Flow:

1. Condition Check

   • After the first start step is executed, determine whether to start activating and running the next step instance according to the transition conditions

2. Instance Activation

   • Step instances are all created when the process instance is created
   • Here only execute activating and running step instances

3. Create Task

   • Create work task items

4. Event Trigger

   • Each step triggers three events at runtime: OnEnter, OnExecute, and OnExit. As shown in the figure below: (IFlowProcessor is a flow processor, used for secondary development extension)

   

3.2.4 Business End

End methods are divided into: Finished (Process End), Process Unexpected Termination (Abnormal end, manual cancellation or program exception)

Upon the end of the business process, the system will automatically clear process instances, step instances, work task records, and change the status of process execution and task execution records to corresponding end statuses.


4. FAQ

4.1 Flow Engine Related Questions

4.1.1 What is a "Blocking Step"?

Blocking steps are activities that do not complete execution immediately after the step Enter. They usually pause the progress of the workflow until resumed. The nature of this stop creates the term "blocking". Commonly used blocking steps are: "Variable Listener Step", "Timing Trigger", "Task Delay", "Parallel Process End".

4.1.2 What is the difference between Process Instance and Process Definition?

Process definition is the static template of the process, describing the structure, steps, and rules of the process; while process instance is a runtime entity created based on the process definition, containing data and status in a specific execution process. A process definition can have multiple process instances.

4.1.3 How does the flow engine handle concurrency?

The flow engine handles concurrency through parallel branch patterns, allowing multiple steps to execute simultaneously. Each process instance has its own execution context, which does not interfere with each other, ensuring data isolation and consistency. In high concurrency scenarios, the flow engine uses thread pools and queue mechanisms to manage task execution to avoid resource exhaustion.

4.2 Process Design Related Questions

4.2.1 How to judge if the process runs normally?

You can judge whether the process runs normally in the following ways:

1. View the flow console and confirm that the process instance status is "Running"
2. Check the flow log file (logs/flow_logs/{ProcessName_StationName}/flowlog_xxxx-xx-xx.log) to see if there are any error messages
3. Use the station console component to monitor the process status

4.2.2 How to design efficient processes?

Key principles for designing efficient processes:

• Keep the process simple and avoid unnecessary complexity
• Reasonably use parallel processing to improve efficiency
• Clearly define conditional branches to avoid ambiguity
• Use appropriate exception handling mechanisms
• Regularly optimize and refactor process definitions

4.2.3 How to handle exceptions in the process?

Exception handling methods in the process include: setting error boundary events, using compensation processing, implementing rollback mechanisms, and recording detailed logs for analysis and debugging.

4.3 Process Optimization Related Questions

4.3.1 How to optimize process performance?

Methods to optimize process performance:

• Reduce unnecessary steps and condition judgments
• Reasonably use parallel processing to improve throughput
• Optimize conditional expressions to reduce complex calculations
• Appropriately use caching mechanisms to reduce repetitive calculations
• Regularly clean up historical data to reduce system burden

4.3.2 What are the common performance bottlenecks of the flow engine?

Common performance bottlenecks of the flow engine include: calculation of complex conditional expressions, management of a large number of concurrent instances, frequent database access, excessive event listeners, overly detailed log records, etc.

4.4 Process Modification and Exception Handling

4.4.1 What if the process modification does not take effect?

1. Confirm that the modified process has been set to "Enabled" status
2. Restart the Flow Service (operate in CMS Editor) or use the flow console to manually restart the process
3. Check the flow log to confirm if there is a record of loading the new process definition
4. If it is a process associated with a station, you may need to use the station console to reset the process

4.4.2 How to handle exceptions during process execution?

1. View the flow log to locate the step and reason for the exception
2. Check if the condition configuration in the process definition is correct
3. Verify if the process context data meets expectations
4. Use the station console to reset the process, or restart the process in the flow console
5. If the problem persists, you may need to modify the process definition or check related system components

4.5 Process Loop and Instance Management

4.5.1 How to start a new process instance when the process ends?

Enable the "New Instance" property in the "End" step.


4.5.2 What situations lead to "Infinite Loop" and how to avoid it?

Common causes and avoidance methods for infinite loops:

1. Logic Error (PLC Signal Interaction):

   • Reason: When the process ends, the PLC signal is not reset correctly, causing the signal status to be abnormal when the process restarts, the condition continues to be true, and it falls into an infinite loop.
   • Avoidance Method:
     • Add signal reset logic in the PLC program.
     • Add a reset function in the monitoring system to check and reset signals before restarting the process.
     • Check and verify signal status at key process nodes.

2. Unhandled Exceptions:

   • Reason: An exception occurs during program operation (such as division by zero), but there is no appropriate exception handling mechanism, causing the process to continuously repeat the execution of error operations.
   • Avoidance Method:
     • Delay restarting the process instance and wait for the system environment to return to normal.
     • Use exception capture statements to perform pre-set processing when exceptions are captured to ensure system stability.

In summary, the key to avoiding infinite loops lies in ensuring that process conditions can terminate and properly handling possible exceptions.