Web workflow system and method based on JSON data analysis

Abstract

The invention provides a Web workflow system and method based on JSON data analysis, and relates to the technical field of workflow design. A standardized JSON process definition file is generated by adopting a visual process designer, process semantic verification and BPMN conversion are realized through a three-level analysis architecture, and efficient management of the whole process of process modeling, execution and auditing is realized in combination with a plug-in task executor, a thread security context manager and a process monitoring module, so that the process modeling, execution and auditing efficiency is improved. The method has the advantages of fast analysis, strong expansion, easy collaboration, traceability and the like.

Description

Technical Field

[0001] The present invention relates to the technical field of workflow design, and in particular to a Web workflow system and method based on JSON data parsing. Background Art

[0002] Traditional enterprise-level workflows often rely on XML or proprietary formats to describe processes, which have problems such as redundant syntax, complex nesting, time-consuming parsing, and incompatibility with modern JSON APIs. This leads to high development barriers, difficulty in expansion, and low integration efficiency in microservices and cloud-native environments.

[0003] To address the above pain points, although the industry has tried to improve performance by using custom binary formats or caching on the engine side, it still faces defects such as limited dynamic process adjustment, weak context data management, difficulty in plug-in expansion of task types, and lack of audit monitoring, making it difficult to support rapidly changing business needs. Summary of the Invention

[0004] In order to overcome the shortcomings of the existing technology, the purpose of the present invention is to provide a Web workflow system and method based on JSON data parsing. By constructing a JSON-based process parsing and execution architecture, the system achieves simplified process modeling, efficient execution performance, plug-in-based task expansion, and traceable data management, significantly improving the flexibility and reliability of the workflow system.

[0005] To achieve the above object, the present invention provides the following solutions:

[0006] A web workflow system based on JSON data parsing, including:

[0007] Process Designer, used to model business processes visually and output process definition files that conform to the preset JSON Schema;

[0008] A process JSON parser, configured to perform lexical analysis, syntax analysis, and semantic validation on the process definition file, and convert the file into an internal data structure that complies with the BPMN 2.0 specification after passing the validation;

[0009] The process execution engine is used to instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resumption, and termination;

[0010] The context manager is used to provide thread-safe data storage, version control, and audit tracking during process execution, and to achieve persistence and backtracking of process context data;

[0011] The version controller is used to persist multi-version process definitions and load the specified version of the process model when the instance starts;

[0012] A plug-in task executor is used to dynamically load the corresponding task processor according to the task type, execute REST service call tasks, script tasks, message queue tasks, conditional judgment tasks or sub-process tasks, and write the execution results back to the context manager;

[0013] Among them, the process JSON parser communicates with the process designer to receive the process definition file; the process execution engine communicates bidirectionally with the context manager, version controller and plug-in task executor to complete process flow, data reading and writing and task scheduling.

[0014] Preferably, the semantic verification module of the process JSON parser constructs a directed acyclic graph of task dependencies and performs loop detection and data reachability analysis to ensure that there are no circular dependencies or isolated nodes in the process definition.

[0015] Preferably, the conversion module of the process JSON parser automatically inserts BPMN start events and end events when the internal data structure lacks an explicit start or end node, and generates a SequenceFlow element for each control dependency.

[0016] Preferably, the context manager comprises:

[0017] Thread-safe storage module, used to allocate independent context space for each process instance;

[0018] Standardized parsing engine module, used to provide structured data access interface;

[0019] The full-link version control and audit system module is used to generate a timestamped version snapshot for each change in context data.

[0020] Preferably, the process execution engine monitors task status changes in an event-driven manner, and pushes the current process instance node location, execution time and timeout alarm information to the monitoring and analysis module in real time.

[0021] Preferably, the JSON process definition file output by the process designer includes: process metadata, task nodes, approvers, form permissions, button permissions, countersignature nodes, condition nodes, opinion nodes and routing node information.

[0022] Preferably, the data reachability analysis verifies that the production nodes of the data that each task input depends on are located at the front-order position of the execution path by performing a depth-first traversal of the directed graph from the starting node.

[0023] Preferably, the plug-in task executor supports loading third-party or user-defined task processors through the registry, and starts the exception handling module to perform compensation operations and record audit logs after the task execution fails; the plug-in task executor supports configuring retry strategies when executing asynchronous tasks, and triggers the exception handling module to generate a failure event after reaching the retry limit.

[0024] Preferably, when the process execution engine resumes after the instance is suspended, the execution environment is restored according to the latest version snapshot in the context manager to achieve breakpoint-resume execution of long transaction processes.

[0025] A workflow execution method based on JSON data parsing, applied to the above system, includes:

[0026] Model business processes visually and output process definition files that conform to the preset JSON Schema;

[0027] Performing lexical analysis, syntax analysis, and semantic verification on the process definition file, and converting it into an internal data structure that complies with the BPMN 2.0 specification after passing the verification;

[0028] Instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resume, and termination;

[0029] Provide thread-safe data storage, version control, and audit trails during process execution, enabling persistence and backtracking of process context data.

[0030] Persist multi-version process definitions and load the specified version of the process model when the instance starts;

[0031] Dynamically load the corresponding task processor according to the task type, execute the REST service call task, script task, message queue task, condition judgment task or sub-process task, and write the execution result back to the context manager.

[0032] According to the specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0033] 1. This paper adopts a three-level parsing architecture based on JSON, hierarchically processing process definition files through lexical analysis, syntax analysis, and semantic validation, replacing the complex nested structure of traditional XML. This effectively reduces the computational complexity and resource consumption during parsing. It also introduces automatic completion and canonical conversion mechanisms for BPMN data structures to ensure the integrity and consistency of process definitions before execution, significantly improving the responsiveness of process startup and operation, and meeting the parsing performance requirements of high-concurrency business scenarios.

[0034] 2. This invention designs a plug-in task execution mechanism that supports dynamic loading of various types of processors, including REST interface calls, script execution, MQ message push, conditional judgment, and sub-process tasks. It can flexibly access third-party services or expand customized logic. Compared with traditional process engines that require core code modifications, this application can complete task type expansion without interrupting system operation, significantly improving the system's adaptability and maintenance efficiency in multiple scenarios, multi-tenant, and microservice architectures.

[0035] 3. This invention introduces a thread-safe context management mechanism, combined with a structured data access interface and a full-link version snapshot system, to achieve multi-version management and precise traceability of context data during process execution. By combining timestamp auditing and change logging, it supports process breakpoint resumption, exception recovery, and compliance backtracking, overcoming the issues of data loss and irreversible state after process interruption in traditional workflows, thereby improving system stability and reliability.

[0036] 4. This invention provides a visual process designer, using a modeling approach that conforms to a pre-set JSON Schema. This allows business personnel to configure process elements such as task nodes, form permissions, and routing rules through a graphical interface, generating standardized process definition files. Combined with the process parser's automatic verification and completion mechanisms, this significantly simplifies process development, enhances the ability of non-technical personnel to participate in modeling, effectively shortens service launch cycles, and improves collaboration efficiency between process management and IT departments within an enterprise. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0038] Figure 1 A schematic diagram of the overall structure of the system provided in an embodiment of the present invention;

[0039] Figure 2 A schematic diagram of a process design provided for an embodiment of the present invention;

[0040] Figure 3 Schematic diagram of JSON definition file output provided by an embodiment of the present invention;

[0041] Figure 4 A schematic diagram of a workflow provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0043] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments.

[0044] Figure 1 The overall structural diagram of the system provided by the embodiment of the present invention is as follows: Figure 1 As shown, the present invention provides a Web workflow system based on JSON data parsing, including:

[0045] Process Designer, used to model business processes visually and output process definition files that conform to the preset JSON Schema;

[0046] A process JSON parser, configured to perform lexical analysis, syntax analysis, and semantic validation on the process definition file, and convert the file into an internal data structure that complies with the BPMN 2.0 specification after passing the validation;

[0047] The process execution engine is used to instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resumption, and termination;

[0048] The context manager is used to provide thread-safe data storage, version control, and audit tracking during process execution, and to achieve persistence and backtracking of process context data;

[0049] The version controller is used to persist multi-version process definitions and load the specified version of the process model when the instance starts;

[0050] A plug-in task executor is used to dynamically load the corresponding task processor according to the task type, execute REST service call tasks, script tasks, message queue tasks, conditional judgment tasks or sub-process tasks, and write the execution results back to the context manager;

[0051] Among them, the process JSON parser communicates with the process designer to receive the process definition file; the process execution engine communicates bidirectionally with the context manager, version controller and plug-in task executor to complete process flow, data reading and writing and task scheduling.

[0052] Specifically, the workflow engine of the present invention adopts a modular design. The Web workflow system based on JSON parsing mainly consists of a process designer, a process JSON parser, a process execution engine, a context manager, a version controller, and task executor related components. The core components of this embodiment are described in detail below:

[0053] 1. Process Designer

[0054] The Process Designer is the core component of this invention, responsible for workflow modeling, configuration, import and export. It provides a visual, zero-code modeling interface for business and development users and outputs standardized JSON workflow definition files. The Process Designer includes a visual interface and a JSON format definition module.

[0055] (1) Visual interface: Provides a graphical operation interface, where users can define workflows by dragging, clicking, etc. This part mainly involves front-end interaction and graphical layout, using self-developed UI logic and no specific classic algorithm. The designer usually has a built-in node library (such as start, task, gateway, end, etc.), and users configure the properties of each node (such as approver, conditions, etc.). After the user completes the design, the process designer serializes the process model into a format such as JSON for storage.

[0056] (2) JSON format definition module: The present invention designs a set of standardized JSON structures for the process designer to define workflows, including workflow metadata (process ID, process version, process description and other attributes), task nodes (node ​​ID, node name, node type and other attributes), approvers (approval type, approver ID and other attributes), form permissions (form fields, display name, editing permissions and other attributes), button permissions (button ID, button name, whether it is effective and other attributes), co-signature nodes (approval type, multi-instance approval mode and other attributes), condition nodes (ID, parent ID, branch display name and other attributes), opinion nodes (ID, parent ID, opinion branch name and other attributes), routing nodes (ID, parent ID, routing branch name and other attributes).

[0057] 2. Process JSON parser

[0058] The process parser, a core component of this invention, is responsible for performing structural, syntactic, and semantic parsing of the JSON files generated by the process designer, and verifying the standardization of definitions for nodes, tasks, forms, permissions, and more. It parses the JSON-formatted workflow defined by the process designer into the BPMN-formatted data structures supported by the workflow. The parser utilizes a three-level parsing architecture: lexical analysis, syntactic analysis, and semantic validation. Based on a proprietary JSON Schema validation engine (supporting recursive references and dynamic properties), it primarily includes syntax validation, semantic validation, schema validation, and conversion modules.

[0059] (1) Syntax verification module: Checks whether the JSON format complies with the workflow definition specifications, such as whether the JSON structure is complete and whether the attribute name is correct.

[0060] (2) Semantic verification module: ensures that task dependencies are correct and context references are valid, such as checking whether the reference relationship between parent nodes and child nodes is reasonable.

[0061] The semantic verification module ensures that the execution order of each task and the data flow in the process are semantically reasonable and conflict-free by generating a task dependency graph, verifying reference validity, detecting loops, and analyzing data accessibility. The verification logic specifically includes:

[0062] Constructing a task dependency graph: The verification engine first constructs a directed graph based on the standardized process model to represent the task dependencies. The nodes in the graph represent the tasks in the process. The engine traverses the control flow and data flow definitions in the process model to add directed edges: for explicit control dependencies (such as sequential flows), an edge is added from the predecessor task to the successor task; for implicit data dependencies (for example, the input of task B uses the output of task A), a dependency edge is added from task A to task B. In addition to dependencies between tasks, if a task references a variable in the initial context, the initial context can also be regarded as a special source node, pointing to the task that uses the variable. The dependency graph formed by this process fully depicts the order of task execution.

[0063] Reference validity check: Based on the constructed dependency graph, the verification module checks whether each task's reference to the context is valid and reliable. For each task's input parameters or variables / outputs referenced in the conditions, the module confirms that the reference source is defined in the process: if the reference is to the output of a predecessor task, there should be an edge from the predecessor task to the current task in the dependency graph; if the reference is to a global context variable, the variable should exist in the initial context declaration. The module verifies these relationships by traversing the task dependency graph or directly checking the reference links in the internal model. If an invalid reference is found, for example, a task references a non-existent variable name, an error is recorded.

[0064] Loop Detection: The semantic verification module runs a loop detection algorithm on the task dependency graph to identify existing circular dependencies. Using methods such as depth-first search (DFS) or topological sorting, the module traverses the directed graph to determine if loops exist. If the DFS process revisits a node (backward edge) that has not yet been traversed, or if the topological sorting fails to include all nodes, a loop exists. A loop means that certain tasks are interdependent, forming a closed loop, which is illegal in workflow definitions without special loop constructs. A common loop is: Task A depends on the output of Task B, and Task B also depends on Task A (directly or indirectly) through some path. Once a loop is detected, the verification module records the set of tasks involved in the loop and reports an error. This check prevents processes from experiencing unterminated loops or deadlocks. For example, if a closed loop A→B→C→A is found in the dependency graph, the module will determine that the process definition has a logical error because Tasks A, B, and C are mutually dependent, making it impossible to determine the correct execution order. Cycle detection ensures that the process dependencies are in the form of a directed acyclic graph (DAG), that is, topological sorting of tasks is possible so that the process can have a clear starting point and end point.

[0065] Data reachability analysis: After verifying acyclicity, the module further checks task and data reachability. Data reachability refers to whether, for each task in the process, the control flow path from the start node is reachable, and whether all required input data for the task is available via a preceding path. This module traverses the dependency graph starting from the start task node, marking reachable task nodes. If a task has no preceding control flow and is not itself a start node, it is unreachable. Furthermore, for each task's data dependency, the module checks whether the task node providing the data appears before the reachable path of the referencing task. If the data required by a task comes from an unreachable node or from a node that appears later in the process (i.e., the data producer is not at the beginning of the execution path), the data is unreachable during actual execution. For example, in a parallel branching scenario, if task X in one branch uses the output of task Y in another branch, and the two branches execute independently before merging, then without synchronization, X will be unable to obtain Y's data, resulting in data unreachability. Through reachability analysis, the verification module can discover potential hidden problems in process definitions, such as isolated task nodes (which are never executed) or data references that span disjoint execution paths.

[0066] (3) Schema verification module: Verify the workflow structure according to the predefined Schema and determine whether the workflow meets the predefined format requirements.

[0067] (4) Conversion module: converts the workflow in JSON format that complies with the standard into the BPMN format data structure supported by the workflow.

[0068] The conversion module converts elements according to the BPMN specification, handles nested structures, and generates corresponding process connections to ensure that the output flowchart is logically consistent with the input definition. The conversion process covers aspects such as node mapping rules, nested structure processing, sequence flow construction, and start and end symbol processing:

[0069] Node mapping rules: The conversion module converts the node types in the internal process model into corresponding BPMN elements according to predefined mapping rules. Each JSON-defined node (task, event, gateway, etc.) has a corresponding BPMN element type. For example, a common automatic task is mapped to a BPMN <servicetask>Elements, user interaction tasks are mapped to <usertask>Element, the script task is mapped to <scripttask>If a custom node cannot be directly matched, it is represented by a BPMN extended element or additional attribute.

[0070] Nested structure processing: The conversion module uses a recursive or hierarchical approach to handle nested structures in process definitions. Nested structures may include sub-processes, parallel branches, conditional branches, etc. For example, if the JSON model represents a task containing an internal list of steps, it is converted into a BPMN sub-process, and the sub-tasks and connections are mapped sequentially within the sub-process. When there are conditional branches, the module will insert a BPMN gateway element (such as the exclusive gateway ExclusiveGateway) and enter different branch paths based on the task elements of multiple branches. When processing nesting, the module needs to maintain a context stack to track the level of the sub-process currently being converted, ensuring that the inner layer is correctly attached back to the outer layer process after the conversion is completed. At the same time, the module solves the identification and naming issues caused by nesting (such as unique identification of nodes at different levels) to avoid element confusion. By processing the nested structure, the final generated BPMN model can accurately reflect the hierarchical relationship of the original process definition.

[0071] Sequence flow construction: After the node elements are generated, the conversion module generates BPMN sequence flow (SequenceFlow) connection elements according to the control dependency relationship in the process model. The conversion module will traverse the subsequent task list of each task object and create a corresponding task for each pair of tasks. <sequenceflow>Element. In XML representation, a SequenceFlow typically has source (ref) and target (ref) attributes pointing to the IDs of the two connected nodes. The module ensures that each mapped BPMN node (except the end node) has the correct outgoing and incoming sequence flows. For example, if Task A is followed by Task B according to the model, a SequenceFlow is created with sourceRef pointing to A's BPMN element and targetRef pointing to B's element. For branching structures, a SequenceFlow is established from the gateway to each branch's starting task, and when necessary, a SequenceFlow is established from the end of each branch back to the merge point (such as the converging gateway). The sequence flow construction process also handles conditional expressions: If an internal model connection has an execution condition (such as selecting a path based on context data), the transformation module will write this condition into the SequenceFlow's conditional expression attribute to conform to the BPMN description of conditional flows. By constructing a complete set of sequence flows, the module ensures that all task nodes in the BPMN flowchart are connected in the correct execution order, faithfully reflecting the logical flow of the original JSON process.

[0072] Processing of Start and End Symbols: The conversion module finally processes the start and end points of the process to conform to BPMN model requirements. Typically, a JSON-formatted process definition identifies one or more starting tasks and the conditions for the process's termination, but may not explicitly include start / end nodes. The module inserts BPMN start and end events (StartEvent) and end events (EndEvent) into the conversion results. Specifically, if the internal model explicitly specifies a start task, a StartEvent element is created and a SequenceFlow is generated, pointing it to the first actual task node. If there are multiple parallel start points, a single StartEvent can be connected to multiple tasks, or parallel gateways can be used at the BPMN level to branch the task flow after starting. For process termination, the module detects which tasks in the internal model have no subsequent nodes (i.e., natural endpoints of the process) and creates an EndEvent element for each such endpoint. A SequenceFlow is then established from the task node to the EndEvent. If the process has multiple end branches, multiple EndEvents can be retained or these branches can be merged in BPMN to form a single EndEvent. The addition of start and end symbols ensures that the generated BPMN model conforms to the specification: there are clear start and end nodes, all process paths have a beginning and an end, and there are no dangling process lines. After generating the final BPMN support structure, the conversion module can check the validity of the results, such as whether the source and target references of each SequenceFlow exist, whether the corresponding nodes are in the same scope, etc., and then output the BPMN process definition (XML text or model object) for subsequent execution engine deployment.

[0073] 3. Process execution engine

[0074] The process execution engine, the core scheduling module, is responsible for instantiating process definitions, managing the entire lifecycle of process instances, scheduling and executing tasks, task flow, and process monitoring and analysis. It includes a process instance management module, a process task management module, a process and form integration module, and a process monitoring and analysis module.

[0075] (1) Process instance management module: instantiate workflow definition, full life cycle management, support operations such as creation, start, pause, resume and termination of process instances

[0076] (2) Process task management module: provides task list, task query and task processing functions, and supports users to view pending tasks, completed tasks and delegated tasks

[0077] (3) Process and form integration module: supports integration with external forms (such as HTML forms, custom forms) to realize the collection and display of process data

[0078] (4) Process monitoring and analysis module: provides process instance running status monitoring, and can view information such as the current execution position of the process, historical execution records, and task execution time.

[0079] 4. Context Manager

[0080] The context manager is responsible for the full lifecycle management of process data and historical process data. It uses the data context during execution to parse JSON data, providing persistence and recovery capabilities for contextual data. Through standardized data operation interfaces and thread-safe mechanisms, it ensures data consistency and traceability in complex business scenarios. It includes a thread-safe storage module, a standardized parsing engine module, and a full-link version control and audit system module.

[0081] (1) Thread-safe storage module: provides thread-safe context storage. Each process instance has its own context space during execution, avoiding data contamination between different instances.

[0082] (2) Standardized parsing engine module: The standardized parsing engine implements the parsing of process JSON data. The upper-level business system can directly obtain the parsed structured data through the interface without having to pay attention to the underlying JSON parsing details.

[0083] (3) Full-link version control and audit system module: The full-link version control and audit system supports version control and auditing of context data, automatically records every change of context data, generates version snapshots with timestamps, supports tracing back historical status by version number, builds a complete audit log chain, and records the time, operator, operation type and difference between data operations before and after.

[0084] 5. Version Controller

[0085] The version controller is responsible for the distribution and storage management of process versions. It can persist different versions of processes in the database and obtain the design information of the process based on the process version. It includes a version storage module and a version acquisition module.

[0086] (1) Version storage module: persists different versions of processes into the database.

[0087] (2) Version acquisition module: obtains the design information of the process based on the process version.

[0088] 6. Task Executor

[0089] The task executor is also a core component of the present invention, responsible for executing specific task operations, invoking the corresponding processing logic based on the task type, and completing the actual business functions. The present invention uses a plug-in architecture to implement task execution, supporting a variety of task types such as REST service call tasks, script tasks, message queue tasks, conditional judgment tasks, and sub-process tasks. It also supports the registration and loading of third-party or custom task processors. It includes a task acquisition module, an executor parsing module, a context preparation module, a task execution module, a result processing module, a flow decision module, an exception handling module, and an audit tracking module.

[0090] (1) Task acquisition module: It obtains pending tasks from the task queue in an event-driven manner and supports task priority scheduling and timeout handling mechanisms.

[0091] (2) Executor parsing module: finds the corresponding processor according to the task type to process the task, supports plug-in extensions, and allows registration of custom task processors.

[0092] (3) Context preparation module: Builds a context object containing process instances, variables, and execution environment, and performs parameter mapping conversion and data verification.

[0093] (4) Task execution module: calls the execute method of the processor to execute the core business logic, supports transaction management and retry strategy configuration, and asynchronous tasks support status callback and result collection.

[0094] (5) Result processing module: parses the JSON format results returned by the task, updates the process context, and supports result mapping and data persistence.

[0095] (6) Flow decision module: Flow decision is made based on the gateway mechanism of BPMN 2.0 specification, supporting conditional branching, parallel gateway and event-driven flow.

[0096] (7) Exception handling module: implements task-level compensation mechanism, supports rollback operation, and exception event capture and notification mechanism.

[0097] (8) Audit tracking module: records the entire process of task execution and generates traceable audit logs.

[0098] As an optional implementation, this example uses a complete example of a "leave approval" process to demonstrate the entire process, from process design, JSON definition, parsing and validation, instance execution, to process monitoring. This process includes employee leave application submission, supervisor approval, and whether a higher-level approval is required based on the number of days of leave requested.

[0099] 1. Process design and definition.

[0100] Process drawing and node configuration: The process designer provides a graphical interface for users to configure nodes and connect process lines to design processes. This part is mainly front-end interaction and graphic layout, using self-developed UI logic, and there is no specific classic algorithm. The designer usually has a built-in node library (such as start, task, gateway, end, etc.). Users use the process designer to design the "leave approval" process. The process enters the "leave application" link from the start node (the user fills out the leave application form). Then it enters the "department leader approval" node, and the supervisor reviews the request. If the supervisor agrees and the number of leave days exceeds the threshold, the process flows along the condition to the "manager approval" node (conditional branch in the figure); if the supervisor agrees and the number of days does not exceed the threshold, it flows directly to the end node to skip the manager approval; if the supervisor refuses, it takes another conditional branch and ends directly. For the manager approval node, there is also an agreement to reach the end of the process, or a refusal to end the process. The entire flowchart contains a start node, two user task nodes (supervisor and manager approval), a conditional judgment node, and an end node. Figure 2 As shown:

[0101] Process export and save: After the user completes the design, the process designer serializes the process model into a format such as JSON for saving. During the export phase, the designer may call JSON Schema to verify whether the structure of the process definition complies with the specification (such as whether the start / end nodes must be included, whether the task nodes are fully configured, etc.). If the verification passes, a legal process JSON definition file is output, such as Figure 3 shown.

[0102] 2. Analysis and verification of the process.

[0103] When a process JSON definition is submitted to the process JSON parser, it is parsed into internal data structures. First, the parser checks whether variables like leaveDays and TeamLeadApproved are defined in contextVariables and verifies the syntax of conditional expressions. This validation utilizes a combination of JSON Schema and rule validation. The parser then creates node objects (such as StartEvent, UserTask, and EndEvent) and connection objects. A topological sort is also performed, which successfully lists the node execution order: start -> task_submit -> task_tl_approve -> task_mgr_approve -> end (manager approval may be skipped in some cases). The parser also compiles or encapsulates conditional expressions (${...}) into executable units for easy invocation by the execution engine. During this phase, the parser issues warnings if the definition is found to be illogical (for example, a condition that is always true or false, leading to a dead end).

[0104] 3. Instance startup and context initialization.

[0105] When an employee requests leave, the process execution engine creates an instance of the process definition. The engine calls the context manager to initialize the context and writes the employee's leave request data into context variables. For example, applicant = "Zhang San", leaveDays = 5, reason = "Annual leave". The context now contains all the information about the leave request. After initialization, the process instance enters the Ready state, awaiting execution.

[0106] 4. Supervisor approves task scheduling.

[0107] Now, task_tl_approve (department leader approval) becomes the next task to be executed. The engine checks that all its predecessor nodes have completed (except for task_submit), thus meeting the execution requirements. It then uses the thread pool to schedule this task to the task executor's worker thread. The task executor creates a to-do item and sends it to the designated supervisor (assignee: ${teamLead}). Because this is a manual approval, the process engine enters a wait state at this point. The context manager may persist a snapshot of the current context to handle system restarts or timeouts. After reviewing the application details (from the context, such as the applicant, number of days, and reason) on the approval interface, the supervisor clicks "Approve" or "Reject" to complete the task. Assuming the supervisor selects "Approve," the task executor captures this user action, writes TeamLeadApproved=true to the context, and notifies the process engine of the task's completion.

[0108] 5. Conditional gateway judgment.

[0109] After receiving the supervisor approval completion event, the process engine first reads the relevant variable values ​​through the context manager: TeamLeadApproved = true, leaveDays = 5. The engine then evaluates the conditional expressions of each transition from task_tl_approve to determine the next flow path. Based on the context data, the condition "Supervisor approves and number of days > 3?" is true (true && 5 > 3), leading to the corresponding flow transition to the task_mgr_approve node. The other two conditions (approval and number of days <= 3, and rejection) fail. Rejection is false, and days <= 3 is also false. Based on this, the engine selects the manager approval path and activates the task_mgr_approve node. The process now enters the manager approval phase. If the leaveDays value is 2 (not greater than 3), the other condition is true, and the engine skips the manager approval step and proceeds directly to the end node. If the supervisor rejects the application, the rejection branch ends the process. It can be seen that the engine uses logical judgment similar to if / else to dynamically select the process route based on context variables, implementing the business rule that "leave days greater than 3 require secondary approval."

[0110] 6. The manager approves the execution of the task.

[0111] Because the value of leaveDays=5 in this example triggers manager approval, the process engine schedules the task_mgr_approve task similar to supervisor approval. The task executor sends this task to the department manager ( ${manager} ) for processing. The process enters a waiting state again until the manager completes the approval. If the manager reviews the information and rejects the application, the task executor records ManagerApproved=false in the context and notifies the engine of the completion. The context now contains data such as TeamLeadApproved=true, ManagerApproved=false, leaveDays=5, applicant="Zhang San", and reason="Annual Leave."

[0112] 7. End of process and result processing.

[0113] After receiving the manager's approval result, the engine evaluates the subsequent conditions of the task_mgr_approve node. Because the manager rejected the request, the condition ${ManagerApproved} == false is true, matching the path to the end node. The engine then forwards the process to the end node. The process instance enters the end state. At this point, the context manager can write the final result to the context's result variable (for example, setting it to "rejected") or generate a completion record. The task executor and engine perform finishing operations, such as sending a notification to the applicant informing them of the approval result. The entire process instance execution record is also persisted for future auditing.

[0114] 8. Process monitoring and version management.

[0115] Throughout the entire process, the system's monitoring module allows administrators to monitor the progress of each instance. For example, if a supervisor's approval is complete but the manager's approval has not yet been completed, the monitoring interface will display the instance at the "Manager Approval" node, indicating that the previous node, "Department Head Approval," has been completed (approved). The corresponding operator and time are recorded. If the process is paused for an extended period, the administrator can intervene to check whether it has exceeded the deadline. All of this monitoring information is derived from real-time status data updated by the engine and context manager. Regarding version control, this instance references a fixed version of the process definition (for example, v1.0). Even if the process definition is modified and a new version is released later, this will not affect the already running instance. The new version will be used for subsequent leave requests, while all nodes and logic in this instance will continue to execute according to the definition at the time of creation, ensuring consistency.

[0116] Through the above examples, the process designer provides clear and intuitive process modeling; the JSON parser ensures that process definitions are correctly converted into executable models, using topological sorting and rule validation to ensure a rigorous process structure; the execution engine drives the process flow according to the definition, calculating conditions in real time at key routes to select the correct approval path; the context manager transmits and updates leave data (such as the number of days and approval opinions) throughout, allowing each node to obtain the required information and feedback the results; the task executor schedules the approval operations of user tasks through thread pool concurrency and event mechanisms, collecting user responses; and the version controller ensures that the evolution of the process definition does not disrupt ongoing process instances. Throughout the process, the system also records detailed execution logs and status to facilitate subsequent monitoring and auditing. In this example, it is clear how the various modules and algorithms described above jointly support the complete lifecycle of the approval process, from design to execution. The modules have clear division of labor and close coordination, thus achieving efficient digital management of the business approval process.

[0117] Specifically, the JSON data parsing module of the present invention uses an optimized parsing algorithm to efficiently convert workflow descriptions in JSON format into internal task models. This algorithm combines recursive descent parsing and table-driven mapping methods. The specific implementation logic is as follows:

[0118] 1. Hierarchical recursive parsing: The algorithm treats the entire workflow JSON as a tree-like hierarchical structure and recursively parses it from the root. For example, if the top level contains an array of task lists, the array elements are traversed; if the elements contain nested subtask lists (used to describe parallel branches or sub-processes), each sublist is recursively parsed again. This recursive descent method ensures that no matter how deeply the workflow is nested, it can be analyzed layer by layer to construct the corresponding nested task model. In addition, the algorithm maintains the context of the current level during the recursive process, including parent task node references, branch conditions, etc., to establish the correct parent-child relationship when constructing objects.

[0119] 2. Hash Table-Driven Object Mapping: To quickly process references between tasks, the algorithm uses a hash table to record task objects during the first pass through the task list. Newly created task objects are stored in the hash table, taskMap, using the task ID as the key. When recursive parsing encounters references (such as the ID of a subsequent task), the hash table can be queried to locate the created object, or references can be resolved uniformly in post-processing. The algorithm chooses to collect only created task objects during the initial pass, rather than linking references. Linking is performed only after all objects have been created, avoiding issues with finding objects due to ordering.

[0120] 3. Custom JSON Schema Verification: The algorithm implementation embeds a verification step specific to the system's JSON specification. Before parsing each task entry, the entry is checked for completeness and correctness based on the custom JSON Schema or field rules. For example, task entries are required to contain the id, type, and next fields; an error is logged if any are missing. The value of the type field is verified to be a known task type to prevent subsequent executions from failing to find the corresponding task. Only task entries that pass verification are processed further; those that do not conform to the specification are skipped or marked as exceptions. This step enhances the system's fault tolerance and reliability for input descriptions.

[0121] 4. Conditional Expression Parsing: For conditional expressions in task entries (if present, for example, a conditional gateway task might include "condition: "age > 5"), the parsing algorithm performs a degree of preprocessing rather than simply storing the string. The algorithm utilizes built-in expression parsing tools to parse the conditional string into an executable expression tree or anonymous function. The task model object stores the processed evaluable object, rather than the raw text. This approach allows the engine to directly call the prepared function or execution tree without having to parse the string expression, significantly improving judgment efficiency.

[0122] This JSON parsing algorithm offers significant advantages over directly processing text line by line: First, by combining recursion and hash mapping, it achieves near-linear time complexity (O(n) where n is the number of tasks and relationships), enabling rapid parsing even of large workflow JSON files. Second, built-in schema rules ensure data quality and reduce runtime errors. Third, pre-parsing of conditional expressions improves execution efficiency. This algorithm enables the system to efficiently convert from static configurations (JSON) to dynamic models, outperforming traditional manual parsing methods in both performance and reliability.

[0123] Furthermore, this embodiment also designs a plug-in-based task execution mechanism. This plug-in architecture enables the expansion of the task execution mechanism, improving the scalability of the system. Users can easily add new task processor types to meet changing business needs. Furthermore, the independent development and deployment of plug-ins also reduces system maintenance costs.

[0124] Furthermore, this embodiment implements audit tracking and data analysis. This comprehensive audit tracking feature records the entire task execution process, ensuring system security and compliance. The data analysis feature compiles and analyzes process execution data, providing a basis for process optimization and decision-making, and improving business process management.

[0125] like Figure 4 As shown, this embodiment first designs workflow orchestration, and then uses a JSON parser to parse the process definition data. After successful JSON parsing, the process is published, and the process engine generates a complete process definition based on the parsed data. The process is then bound to a business form to create a process instance. The process instance selects the corresponding task processor based on the task type to execute the task. If the task is successfully executed, the process instance continues execution and determines whether there are subsequent tasks to be executed. If so, the execution steps for the task are repeated. If the task fails, the error task is called to handle the error task, and the failure is logged. After all tasks are completed, the process ends.

[0126] As another optional implementation, this embodiment further provides a workflow execution method based on JSON data parsing, the method comprising:

[0127] Model business processes visually and output process definition files that conform to the preset JSON Schema;

[0128] Performing lexical analysis, syntax analysis, and semantic verification on the process definition file, and converting it into an internal data structure that complies with the BPMN 2.0 specification after passing the verification;

[0129] Instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resume, and termination;

[0130] Provide thread-safe data storage, version control, and audit trails during process execution, enabling persistence and backtracking of process context data.

[0131] Persist multi-version process definitions and load the specified version of the process model when the instance starts;

[0132] Dynamically load the corresponding task processor according to the task type, execute the REST service call task, script task, message queue task, condition judgment task or sub-process task, and write the execution result back to the context manager.

[0133] The beneficial effects of the present invention are as follows:

[0134] (1) Efficiency: The standardized JSON format is used to define workflows, combined with a dynamic JSON parsing mechanism, to improve the parsing speed and execution efficiency of workflow definitions. At the same time, the process execution engine achieves efficient and automated management of business processes through full lifecycle management and task scheduling optimization.

[0135] (2) Flexibility: The plug-in task execution mechanism allows the system to expand the task processor type through plug-ins, meeting the needs of different business scenarios. Users can customize the task processor according to actual business needs without modifying the core system code, which improves the flexibility of the system.

[0136] (3) Scalability: The modular design decouples the system components, facilitating functional expansion and upgrades. The design of the version controller and context manager supports the distribution of process versions and the full lifecycle management of process data, ensuring the long-term development of the system.

[0137] (4) Ease of use: The process designer provides visual editing functions and supports system import / export of workflow definitions. It provides business personnel and developers with a zero-code, visual process configuration tool, lowering the threshold for using the workflow system.

[0138] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. The methods disclosed in the embodiments are described briefly because they correspond to the systems disclosed in the embodiments. For relevant parts, refer to the description of the systems.

[0139] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The above examples are only intended to help understand the method and core concept of the present invention. At the same time, those skilled in the art will find that the specific implementation methods and application scopes may vary based on the concept of the present invention. In summary, the contents of this specification should not be construed as limiting the present invention.< / sequenceflow> < / scripttask> < / usertask> < / servicetask>

Claims

1. A Web workflow system based on JSON data parsing, characterized in that: include: Process Designer, used to model business processes in a visual way and output process definition files that conform to the preset JSON Schema; A process JSON parser, configured to perform lexical analysis, syntax analysis, and semantic validation on the process definition file, and convert it into an internal data structure that complies with the BPMN 2.0 specification after passing the validation; The process execution engine is used to instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resumption, and termination; The context manager is used to provide thread-safe data storage, version control, and audit tracking during process execution, and to achieve persistence and backtracking of process context data; The version controller is used to persist multi-version process definitions and load the specified version of the process model when the instance starts; A plug-in task executor is used to dynamically load the corresponding task processor according to the task type, execute REST service call tasks, script tasks, message queue tasks, conditional judgment tasks or sub-process tasks, and write the execution results back to the context manager; Wherein, the process JSON parser communicates with the process designer to receive the process definition file; The process execution engine communicates bidirectionally with the context manager, version controller and plug-in task executor to complete process flow, data reading and writing and task scheduling.

2. The Web workflow system based on JSON data parsing according to claim 1 is characterized in that: The semantic verification module of the process JSON parser builds a directed acyclic graph of task dependencies and performs loop detection and data reachability analysis to ensure that there are no circular dependencies or isolated nodes in the process definition.

3. The Web workflow system based on JSON data parsing according to claim 1, characterized in that: The conversion module of the process JSON parser automatically inserts BPMN start and end events when the internal data structure lacks explicit start or end nodes, and generates a Sequence Flow element for each control dependency.

4. The Web workflow system based on JSON data parsing according to claim 1, characterized in that: The context manager includes: Thread-safe storage module, used to allocate independent context space for each process instance; Standardized parsing engine module, used to provide structured data access interface; The full-link version control and audit system module is used to generate a timestamped version snapshot for each change in context data.

5. The Web workflow system based on JSON data parsing according to claim 1, characterized in that: The process execution engine monitors task status changes in an event-driven manner and pushes the current process instance node location, execution time and timeout alarm information to the monitoring and analysis module in real time.

6. The Web workflow system based on JSON data parsing according to claim 1, characterized in that: The JSON process definition file output by the process designer includes: process metadata, task nodes, approvers, form permissions, button permissions, countersignature nodes, condition nodes, opinion nodes and routing node information.

7. The Web workflow system based on JSON data parsing according to claim 2, characterized in that: The data reachability analysis verifies that the production node of the data that each task input depends on is located at the front order position of the execution path by performing a depth-first traversal of the directed graph from the starting node.

8. The Web workflow system based on JSON data parsing according to claim 1, characterized in that: The plug-in task executor supports loading third-party or user-defined task processors through the registry, and starts the exception handling module to perform compensation operations and record audit logs after the task execution fails; the plug-in task executor supports configuring retry strategies when executing asynchronous tasks, and triggers the exception handling module to generate a failure event after reaching the retry limit.

9. The Web workflow system based on JSON data parsing according to claim 2, characterized in that: When the process execution engine resumes after the instance is suspended, it restores the execution environment according to the latest version snapshot in the context manager, thereby realizing breakpoint-resume execution of long transaction processes.

10. A workflow execution method based on JSON data parsing, applied to the system according to any one of claims 1 to 9, the method comprising: Model business processes visually and output process definition files that conform to the preset JSON Schema; Performing lexical analysis, syntax analysis, and semantic verification on the process definition file, and converting it into an internal data structure that complies with the BPMN 2.0 specification after passing the verification; Instantiate the converted process model and manage the entire life cycle of process instances, including creation, start, pause, resume, and termination; Provide thread-safe data storage, version control, and audit trails during process execution, enabling persistence and backtracking of process context data. Persist multi-version process definitions and load the specified version of the process model when the instance starts; Dynamically load the corresponding task processor according to the task type, execute the REST service call task, script task, message queue task, condition judgment task or sub-process task, and write the execution result back to the context manager.

Images