A process handling method and device for an approval chain

Abstract

This invention provides a method and apparatus for processing approval chains, relating to the fields of business process management and workflow automation. The method includes, during the execution of the approval chain process, if it is determined that a field in the form data that has changed is the target field, then obtaining the identifier of the current approval node; if it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, then generating a recalculation event; consuming the recalculation event, starting from the first node after the current approval node that has not completed the approval process, recalculating the remaining process path based on the changed target field data to obtain an updated approval chain; and executing the updated approval chain process. The approval chain processing method and apparatus provided by this invention recalculate subsequent paths in real time based on changes in key fields during execution, thereby improving the adaptability and automation level of the approval process.

Description

Technical Field

[0001] This invention relates to the field of business process management and workflow automation technology, specifically to a process processing method and apparatus for an approval chain. Background Technology

[0002] Business Process Management (BPM) systems are key platforms for enterprises to standardize and automate core business processes such as approval, expense reimbursement, and procurement. Current mainstream systems (such as those built on BPMN 2.0 compatible process engines like Activiti, Camunda, or Flowable) typically employ the following working mode: The approval chain is statically configured through a visual designer, meaning nodes (such as user tasks and gateways) are predefined in the process model, handlers are set, forms are bound, and conditional expressions (such as ${amount} > 10000) are configured for the workflow path. Some systems also support dynamically assigning approvers at runtime through task listeners. After the process definition is deployed, when a user submits a form to start an instance, the engine parses and generates the next pending task level by level based on the model, the current node, and real-time form data.

[0003] Although this model achieves basic automation, it still has the following significant drawbacks: If key fields (such as amounts) are allowed to be modified during process execution, the existing mechanism cannot automatically reassess subsequent approval paths. Even if data changes lead to adjustments in branch conditions, the system still uses the initial path, which can easily result in mismatched approval permissions, increased compliance risks, and often requires manual intervention to roll back or restart. Summary of the Invention

[0004] To address the problems in the prior art, embodiments of the present invention provide a process handling method and apparatus for an approval chain, which can at least partially solve the problems existing in the prior art.

[0005] On the one hand, this invention proposes a process handling method for an approval chain, including: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0006] Prior to the step of executing the updated approval chain process, the approval chain process processing method further includes: Generate a snapshot of the updated approval chain, and then generate a visual view of the updated approval chain based on the snapshot.

[0007] The approval chain process handling method further includes the following steps before the approval chain is executed: Generate the initial approval chain and a visual view of it; In response to the user's initial approval chain confirmation trigger action based on the visual view of the initial approval chain, a snapshot of the approval chain and form data are obtained.

[0008] Determining the target field includes: The current form data is compared with the form data, and the fields that have changed are identified as candidate fields; the current form data is automatically updated during the execution of the approval chain process; The fields that affect the approval path are determined from the candidate fields based on the pre-configured rule base and used as the target fields.

[0009] The generation of the initial approval chain includes: Obtain the request sent by the user; the request carries the form data; Obtain the key fields from the form data, and determine the approval rules corresponding to the key fields based on the pre-configured rule base; The required approval personnel information for each approval node is determined based on the aforementioned approval rules; Simulate the execution of the business process path and generate the initial approval chain based on the simulation results.

[0010] The approval chain process method further includes, after the step of obtaining the user's request, the following steps: The system validates the user's request. If the validation passes, it retrieves the key fields from the form data.

[0011] On one hand, the present invention proposes a process processing device for an approval chain, comprising: The acquisition unit is used to acquire the current approval node identifier if, during the execution of the approval chain process, it is determined that the field in the form data that has changed is the target field; the target field is a key field that affects the approval path. The generation unit is used to generate a recalculation event if it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes. The update unit is used to consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduces the remaining process path based on the changed target field data to obtain the updated approval chain. The execution unit is used to execute the updated approval chain process.

[0012] In another aspect, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0013] This invention provides a computer-readable storage medium, comprising: The computer-readable storage medium stores a computer program that, when executed by a processor, implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0014] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0015] The approval chain processing method and apparatus provided in this invention, during the execution of the approval chain process, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is a key field affecting the approval path; if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute, then a recalculation event is generated; the recalculation event is consumed, and starting from the first node after the current approval node that has not completed the approval, the remaining process path is recalculated based on the field data of the changed target field to obtain an updated approval chain; the updated approval chain process is executed, and during the execution process, the subsequent path is recalculated in real time based on the change of the key field, thereby improving the adaptability and automation level of the process approval. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart illustrating the approval chain processing method provided in an embodiment of the present invention.

[0017] Figure 2 This is a flowchart illustrating the approval chain processing method based on modular implementation provided in this embodiment of the invention.

[0018] Figure 3 This is a schematic diagram illustrating the rule configuration module provided in an embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram illustrating the form data collection module provided in an embodiment of the present invention.

[0020] Figure 5 This is a schematic diagram illustrating the approval chain calculation module provided in an embodiment of the present invention.

[0021] Figure 6 This is a schematic diagram illustrating the visualization generation module provided in an embodiment of the present invention.

[0022] Figure 7 This is a schematic diagram illustrating the process engine interaction module provided in an embodiment of the present invention.

[0023] Figure 8 This is a schematic diagram of the module composition structure provided in an embodiment of the present invention.

[0024] Figure 9 This is a schematic diagram of the process processing device for the approval chain provided in an embodiment of the present invention.

[0025] Figure 10 This is a schematic diagram of the physical structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and descriptions of the present invention are used to explain the present invention, but are not intended to limit the present invention. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other.

[0027] Figure 1 This is a flowchart illustrating an approval chain processing method according to an embodiment of the present invention, as shown below. Figure 1 As shown, the approval chain process handling method provided in this embodiment of the invention includes: Step R1: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then obtain the current approval node identifier; the target field is the key field that affects the approval path.

[0028] Step R2: If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, then a recalculation event is generated.

[0029] Step R3: Consume the recalculation event, starting from the first unfinished approval node after the current approval node, re-deduce the remaining process path based on the changed target field data, and obtain the updated approval chain.

[0030] Step R4: Execute the updated approval chain process.

[0031] In step R1 above, during the execution of the approval chain, if the device determines that the field in the form data that has changed is the target field, it obtains the identifier of the current approval node; the target field is a key field affecting the approval path. The device can be a computer device that executes this method. The acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant regulations.

[0032] In step R2 above, if the device determines that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated.

[0033] In step R3 above, the device consumes the recalculation event, starts from the first unfinished approval node after the current approval node, and re-deduces the remaining process path based on the field data of the changed target field to obtain the updated approval chain.

[0034] In step R4 above, the device executes the updated approval chain process.

[0035] The approval chain process can be implemented in a modular way, such as Figure 2 As shown, it includes the following modules: (1) Rule configuration module: This module is used to maintain an approval rule base independent of the process model. Each rule is associated with specific form fields, conditional expressions (such as ${amount} > 50000), and corresponding approval roles or assignment strategies. It supports graphical configuration and version management, decoupling approval logic from process structure, allowing business rules to be flexibly adjusted without redeploying process definitions.

[0036] (2) Form data collection module: Responsible for monitoring and collecting key business data throughout the entire process lifecycle. During the form filling stage, collect user input in real time and trigger pre-calculation of the approval chain; during the process execution stage, when the authorized node modifies the form, capture the updated field values ​​and trigger dynamic recalculation.

[0037] (3) Approval chain calculation module: It contains two core components: Approval chain pre-computation component: Before the process is submitted, based on the current form data and rule base, the BPMN process path is simulated in memory, all gateway branches are traversed, the actual approver, flow order and triggering conditions of each task node are determined, and a complete structured initial approval chain is generated.

[0038] Dynamic recalculation component: During process execution, when a change in a key field affecting the approval path is detected, starting from the first incomplete node after the currently completed node, the subsequent approval path is incrementally reconstructed based on the new form data, generating a new approval chain snapshot to ensure that the approval logic is consistent with the latest business status.

[0039] (4) Visualization generation module: As a data adaptation layer, it receives structured data output from the approval chain calculation module and converts it into a standard format suitable for front-end display. It formats elements such as approval chain nodes, approvers, conditions, and statuses to generate display data objects (such as flowchart data structures, JSON paths, etc.) that can be directly called by the front-end, supporting the front-end to implement functions such as graphical display, path highlighting, and version comparison.

[0040] (5) Process Engine Interaction Module: Responsible for interfacing with underlying BPMN workflow engines (such as Activiti, Camunda, Flowable, etc.). Launch workflow instances based on the final approval chain snapshot, persistently store the snapshot, and dynamically inject the recalculation results into the engine context during workflow execution to ensure that task allocation, notifications, and other operations are consistent with the latest approval logic.

[0041] The inter-module collaboration mechanism adopts an event-driven architecture. Changes in form data are captured by the form data acquisition module and trigger the approval chain calculation module; the calculation results are output to the visualization generation module to be converted into display data; after user confirmation, the process engine interaction module drives the creation and execution of the real process instance; if form changes occur during the process, a closed-loop process of "recalculation → generation of display data → synchronization of the engine" is automatically triggered. The rule configuration module provides unified strategy support for all modules.

[0042] like Figure 2 As shown, this demonstrates how the system, through the collaborative work of various functional modules, achieves pre-generation of the approval chain before submission, dynamic monitoring during runtime, and real-time updates throughout the complete lifecycle from user-initiated process to process completion. This process is event-driven at its core, triggering approval chain calculations based on changes in form data, ultimately ensuring that the approval path remains consistent with the business status. Overall, this process can be divided into five key stages: (1) Process initiation and preview stage: User fills in form → System pre-calculates approval chain → Displays pre-generated approval chain for confirmation; (2) Process submission and initiation phase: Submitted after user confirmation → Initiation of a real process instance; (3) Process execution and change response stage: approval node processing task → detect form field changes → trigger dynamic recalculation; (4) Approval chain update and task distribution stage: Regenerate subsequent paths → Push update results → Engine allocates tasks according to the new paths; (5) Process termination and result archiving stage: complete all approvals → end the process → persist the record.

[0043] The following combination Figure 2 Each step is explained in detail.

[0044] S1: Process Initiation and Form Completion: S1.1 Users initiate process requests through a front-end interface (such as a web application or mobile client) and fill in business form data, such as contract amount, project type, and reason for reimbursement.

[0045] The S1.2 front-end system encapsulates the form data filled in by the user into a standard HTTP request and sends it along with the user's identity credentials to the back-end server.

[0046] S2: The backend system receives and verifies the request. The API gateway of the S2.1 backend system receives the request and forwards it to the corresponding form data processing service according to the preset routing rules.

[0047] The S2.2 form data processing service performs preliminary validation on the received request data, including field integrity, format validity, and mandatory field checks, to ensure that the data meets basic business rule requirements.

[0048] After the data verification in S2.3 passes, the system transmits the request and its associated form data to the approval chain pre-calculation module to trigger the generation of the initial approval chain.

[0049] S3: Pre-calculated approval chain: The S3.1 approval chain pre-computation module loads the BPMN process definition file corresponding to the current process type and reads the approval rule base configured independently within the organization as well as the form data submitted by the user.

[0050] S3.2 This module matches the corresponding rules in the approval rule base based on the key fields (such as amount and urgency) in the form, thereby determining the approval role or specific personnel required for each task node in the process model.

[0051] The S3.3 module simulates the execution of the BPMN process path in memory (without actually creating a process instance), traverses all possible gateway branches, evaluates conditional expressions in real time based on the current form data, and selects the correct flow path accordingly.

[0052] After the S3.4 simulation is completed, a complete and structured initial approval chain is generated. This approval chain is usually temporarily stored in a temporary storage area in a standardized format such as JSON, and then passed to the visualization generation module for front-end preview and display.

[0053] S4: Monitoring of Process Submission and In-Process Changes S4.1 After the user previews and confirms the approval chain is correct on the front end, they click "Submit". The front end then submits the finalized form data and the snapshot of the approval chain generated during the preview stage to the back end.

[0054] The S4.2 workflow engine officially launches the workflow instance based on the submitted data. Afterward, the system continuously monitors changes to the form data within this workflow instance, focusing on key fields marked as "affecting the approval path."

[0055] S4.3 When the process reaches an approval node and that node is configured with the extended attribute editableForm="true" (meaning the form can be edited) in the BPMN model, if the approver modifies a key field (for example, changing the contract amount from 80,000 yuan to 120,000 yuan), the system will capture this change.

[0056] After the S4.4 system's change trigger identifies a valid change in a key field, it generates a recalculation event and notifies the dynamic recalculation module to prepare to update the subsequent approval path.

[0057] S5: Dynamically update the approval chain: The S5.1 dynamic recalculation module receives and consumes recalculation events. Starting from the first incomplete node after the currently completed node, the module recalculates the remaining process path based on the updated form data.

[0058] S5.2 adopts an incremental reconstruction strategy, recalculating only subsequent nodes affected by this data change, while fully retaining the historical trajectory and approval records of completed nodes to meet audit and compliance requirements.

[0059] After S5.3 recalculates, a new approval chain snapshot is generated to overwrite the old version, and change notifications are pushed to relevant parties in real time via message queues (such as Pulsar, Kafka) or WebSocket connections.

[0060] After receiving an update signal, the S5.4 front-end interface automatically refreshes the visual view of the approval chain, ensuring that the process initiator and all pending approvers can see the latest approval path.

[0061] S6: Execute the task according to the latest approval chain: When assigning the next task, the S6.1 underlying BPMN workflow engine reads the latest approval chain snapshot and extracts the approver information of the corresponding task node.

[0062] S6.2 After logging into the system, the approver can see the assigned tasks in their to-do list and perform approval operations (such as approval, rejection, additional signature, etc.).

[0063] The S6.3 system records the approval results and drives the process instance to the next node based on the latest approval chain path.

[0064] S7: Process End and Follow-up: S7.1 When a process instance reaches the End Event and all necessary approval nodes have been processed, the system marks the status of the process instance as "Completed".

[0065] The S7.2 system persistently stores the final approval chain snapshot, detailed processing records of each node, and process results (such as "approved" or "rejected") for post-event auditing, querying, and statistical analysis.

[0066] S7.3 can trigger subsequent automated actions based on predefined business rules, such as automatically generating electronic contracts, sending email notifications, or updating the status of related business systems.

[0067] like Figure 3 As shown, this module is independent of the underlying BPMN process engine, providing graphical or API-driven full lifecycle management capabilities for approval rules, ensuring that changes in business strategy do not require modification or redeployment of process definitions. The following section, combining system architecture and practical application scenarios, provides a detailed explanation of the module's composition, functions, internal component collaboration mechanisms, and interactions with other modules.

[0068] (I) Core Objectives and Design Principles of the Module: The rule configuration module aims to solve the maintenance rigidity problem caused by "approval logic hard-coded into BPMN expressions or listener code" in existing technologies. Its design follows three main principles: Independence: Rule storage is physically separated from the process model, supporting separate version management; Configurability: Rules can be defined through a visual interface or standardized interface without programming. Context awareness: Rule conditions can reference multi-dimensional context variables such as form fields, user attributes, and organizational structure.

[0069] (II) Internal Component Composition and Functional Description: The rule configuration module consists of the following five cooperating sub-components: (1) Rule Definition Editor: It provides a web-based graphical interface that allows users to define approval rules using forms. Each rule contains the following elements: Related process types (such as "purchase request" and "contract approval"); Trigger node range (can specify one or more BPMN UserTask node IDs); Conditional expressions (e.g., ${amount} > 50000 && ${projectType} == 'R&D', supporting standard expression syntax such as SpEL and MVEL); Approver assignment strategy (supports multiple modes such as role, position, designated user, dynamic script, etc.); Key field markers (select which form field changes should trigger a recalculation of the approval chain, such as amount, vendorId).

[0070] Supports enabling / disabling rules and prioritizing them (for conflict resolution when multiple rules are matched).

[0071] (2) Rule Version Manager: For each modification to a rule, a new version is generated (e.g., v1.0 → v1.1), preserving a complete history.

[0072] Supports version rollback, difference comparison, and effective time window settings (such as "the new rule only applies to processes initiated after January 1, 2025").

[0073] During the approval chain calculation, the corresponding rule version is automatically matched based on the creation time of the process instance to ensure the consistency of historical process behavior.

[0074] (3) Rule Storage Service: Persist rule metadata to a database (such as MySQL, PostgreSQL) or a configuration center (such as Apollo, Nacos).

[0075] The storage structure uses JSON Schema or relational tables, which include fields such as rule ID, process type, node mapping, condition expression, allocation strategy, key field list, version number, and status.

[0076] It provides efficient indexing and supports quick retrieval of applicable rules by process type + node ID.

[0077] (4) Rule Validator: Perform syntax and semantic validation before saving the rules: Expression syntax validity (calling the expression engine for pre-compilation); Does the referenced form field exist in the corresponding process template? Are the roles / positions in the allocation strategy registered in the organizational structure? Avoid circular dependencies or deadlock paths (such as A→B→A).

[0078] When validation fails, a clear error message is returned to prevent invalid rules from being entered into the database.

[0079] (5) Rule Publisher & Syncer: When a rule is created, updated, or deleted, a RuleChangeEvent is published to a message broker (such as Apache Pulsar).

[0080] The approval chain calculation module and the form data collection module, as subscribers, refresh the local rule cache in real time to ensure that subsequent calculations use the latest strategies.

[0081] Supports canary releases: the release can be applied to some tenants or process types first, and then pushed to the full population after verification.

[0082] (III) Workflow of the rule configuration module: The workflow of the rule configuration module can be divided into the rule definition phase and the rule application phase: (1) Rule definition and management phase (backend configuration): S1: The administrator logs into the system and enters the "Approval Rule Configuration" page.

[0083] S2: Select the target process type (such as "travel expense reimbursement") and click "Create new rule".

[0084] S3: In the rule definition editor, enter the conditional expression (e.g., ${expenseAmount} > 10000), select the approver strategy (e.g., the "Chief Financial Officer" role), and check the key field expenseAmount.

[0085] S4: The rule validator automatically performs the validation; if it passes, it allows saving.

[0086] S5: The rule version manager generates a new version (such as v2.3), and the rule storage service writes it to the database.

[0087] S6: The rule publisher and synchronizer publishes change notifications to the event bus, triggering cache updates on each compute node.

[0088] (2) Rule application phase (process runtime): S7: When a user initiates a "travel expense reimbursement" process and enters an amount of 8,000 yuan, the form data collection module passes the form context to the approval chain calculation module.

[0089] S8: The approval chain calculation module calls the rule storage service to query all rules applicable to this process type and the current UserTask node.

[0090] S9: The rule version manager returns the matching rule version (e.g., v2.3) based on the creation time of the process instance.

[0091] S10: The approver parser determines the actual approver as "Zhang (Chief Financial Officer)" based on the conditional expression and allocation strategy in the rule.

[0092] S11: If the approver subsequently modifies expenseAmount to 12,000 yuan, the form data collection module will identify expenseAmount as a key field through the rule storage service, thereby triggering a recalculation event.

[0093] (iv) Interaction with other modules: The approval chain calculation module provides a rule base query interface, which supports accurate matching by process type, node ID, effective time and other dimensions. The calculation module relies on this interface to obtain the latest rules during pre-calculation and dynamic recalculation.

[0094] With the form data acquisition module: it provides a "key field list" interface for the change detector to determine whether a form modification needs to trigger a recalculation; it also receives rule change events to refresh the local cache.

[0095] Indirect interaction with the visualization generation module: Although there is no direct interaction, the node-role mapping relationship defined in the rules is ultimately reflected in the approval chain display results, improving the accuracy of front-end information.

[0096] (v) Alternative implementation plan: Without departing from the core idea of ​​this invention, the rule configuration module can be implemented using the following alternatives: Storage method: Rules can be stored in a Git repository (YAML / JSON format) and deployed through a CI / CD pipeline, which is suitable for DevOps scenarios; Expression engine: In addition to SpEL, it can integrate JavaScript, Groovy, or a self-developed DSL; Allocation strategy expansion: Supports AI recommendations (such as predicting the best approver based on historical approval behavior) or real-time queries from external HR systems; Access control: Introduce the RBAC model to restrict administrators of different departments to only configuring process rules for their own departments.

[0097] like Figure 4 As shown, this module is responsible for capturing, structuring, and transmitting user-inputted or modified business data in real time throughout the entire lifecycle to trigger pre-computation or dynamic recomputation logic in the approval chain. This module consists of five core components working together, and its process unfolds according to two different scenarios: "process initiation" and "process execution".

[0098] (a) Five core components: (1) Form Listener: Deployed on the front end, responsible for listening to the user's input operations on form fields (such as onChange or onInput events); only listens to key fields marked as "affecting the approval path" in the rule base (such as amount, projectType); enabled in both the process initiation stage and the process execution stage, to achieve full lifecycle data awareness.

[0099] (2) Debounce & Change Aggregator: Debounces high-frequency inputs (e.g., delays by 500ms), aggregates changes within the aggregation window, submits only the final stable form state, and generates different context identifiers based on the scenario (pre-calculated / runtime).

[0100] (3) Form Capture Service: As a core backend service, it provides a unified API to receive requests, perform identity verification, data cleaning and information supplementation, and build a standardized FormContext context object.

[0101] (4) Change Detector (Runtime Only): Enabled only during process execution. By comparing old and new form data, it accurately identifies the list of changed fields and determines whether it contains key fields that trigger recalculation based on the rule base.

[0102] (5) Event Publisher (Runtime Only): Enabled only when recompute is required. It is responsible for constructing standardized RecomputeApprovalChainEvent events and asynchronously publishing them to message brokers (such as Apache Pulsar) to achieve decoupled communication.

[0103] (II) Two different scenario stages: (1) Data collection and pre-calculation triggering before process submission (preview stage): This stage aims to trigger pre-calculation of the approval chain based on the form data filled in by the user for preview. The process path is: Fill in / modify form → Form listener → Debouncing and change aggregator → Form collection service → Determine the process status as "Initiated" → Trigger approval chain pre-calculation. The detailed process is as follows: S1: Form template loading: S1.1 After logging into the system, users can select a process template (such as "Purchase Request") on the "Initiate Process" page.

[0104] The S1.2 system loads the corresponding front-end form from the form template library, which includes metadata such as field definitions, validation rules, and whether a field is a key field.

[0105] S1.3 front-end renders the form interface, initialized to empty or default values.

[0106] S2: User input listening: S2.1 The front end binds an onChange or onInput event listener to all form items.

[0107] S2.2 Special monitoring is performed on key fields in the rule base marked as "affecting the approval path".

[0108] S2.3 employs a debounce mechanism, triggering data acquisition only after the user stops inputting.

[0109] S3: Front-end data assembly and validation: S3.1 Assembles all field values ​​of the current form into a JSON object.

[0110] S3.2 Perform basic front-end validations (not empty, format, range, etc.). If the validation fails, prompt the user and do not initiate a back-end request.

[0111] S4: Request sent: The S4.1 frontend sends structured form data to the backend form collection service via a RESTful API.

[0112] The S4.2 request header carries a User Identity Token (JWT) for authorization verification.

[0113] S5: Backend Processing and Context Building S5.1 Backend verifies user identity and process initiation permissions.

[0114] S5.2 Supplement contextual information (such as user department, role, and query the project manager based on fields such as projectType).

[0115] S5.3 Construct a complete form context object (FormContext) and mark the mode as PREVIEW.

[0116] S6: Trigger approval chain pre-computation: S6.1 uses FormContext as input to call the approval chain pre-calculation component (see details). Figure 5 (as described).

[0117] The pre-calculated results of S6.2 are passed to the visualization generation module for users to confirm the approval path on the front end.

[0118] (2) Data change collection and recalculation triggering during process execution (runtime phase): During this stage of the workflow, when an approver modifies a key field, a dynamic recalculation of the approval chain is triggered. The workflow path is: Fill out / modify form → Form listener → Debouncing and change aggregator → Form collection service → Determine workflow status as "Executing" → Change detector → Recalculation required → Yes → Event publisher → Trigger dynamic recalculation of the approval chain → Visualization generation module. The detailed process is as follows: S7: Load editable tasks: The S7.1 workflow engine will assign approver A.

[0119] S7.2 This task node is configured with the extended property editableForm="true" in the BPMN model.

[0120] S7.3 Approver A opens the task, and the system loads the latest form snapshot associated with this process instance.

[0121] S8: Field Modification and Monitoring: S8.1 The front end only allows modification of authorized fields.

[0122] S8.2 Monitors key fields.

[0123] S8.3 After the approver makes the changes, click "Save and Submit" or "Save Only".

[0124] S9: Submit updated data: In S9.1, the frontend sends the updated complete form data, task ID, and process instance ID to the backend.

[0125] The S9.2 request includes the original snapshot ID for comparison.

[0126] S10: Form Change Detection S10.1 The backend reads the current form history snapshot of the process instance from the database.

[0127] S10.2 Compare the newly submitted data with historical snapshots field by field to identify the list of changed fields (such as ["amount"]).

[0128] S10.3 Query the approval rule base to determine whether the change field contains a "trigger recalculation field".

[0129] S11: Generate and publish recalculation events: S11.1 If a valid change exists: Construct a RecomputeApprovalChainEvent object containing information such as process instance ID, task ID, old and new form data, list of changed fields, and modifier ID.

[0130] S11.2 Publish the event to the message middleware.

[0131] S12: Trigger dynamic recalculation of the approval chain: The dynamic recalculation component in the S12.1 approval chain calculation module listens for and consumes this event.

[0132] S12.2 Initiate the recalculation process (see details) Figure 5 (As shown).

[0133] After the new approval chain snapshot is generated in S12.3, the front-end display is refreshed by the visualization generation module.

[0134] like Figure 5 As shown, this module serves as the core for realizing a "dynamic, visual, and adaptive" approval process. It employs three major technical paradigms: event-driven, memory-simulated execution, and rule decoupling. Its goal is to generate and maintain an approval path consistent with the current business status based on real-time form data throughout the entire process lifecycle. This module consists of two functional components and four shared basic capability units, collectively serving the approval chain calculation needs in different scenarios.

[0135] (I) Module Architecture and Core Components: (1) Two functional components: Approval Chain Pre-computation Component: Triggered before the user formally submits the process. Based on the form data currently filled in by the user, this component fully simulates the execution of the BPMN process in memory, traversing from the start event to the end event, dynamically parsing the actual approver of each user task node in the path, and generating a structured initial approval chain for front-end preview.

[0136] Dynamic recalculation component: Triggered during process execution. When the system detects changes in key form fields affecting the approval path (via event notification), this component starts from the "first incomplete node after the currently completed node" and incrementally recalculates the remaining path based on the new data, generating an updated approval chain snapshot to ensure the path is synchronized with the latest business status.

[0137] (2) Four shared basic capabilities: Model Loader and Parser: Responsible for loading the BPMN 2.0 XML process definition file, parsing it into a directed acyclic graph (DAG) in memory, and extracting all nodes, sequential flows (including conditional expressions), and node metadata.

[0138] Path traverser: Simulates process progression in memory. Based on injected form variables, it evaluates the conditional expressions of nodes such as the Exclusive Gateway in real time (using engines such as SpEL and MVEL) to select the correct flow path and prevents loops by maintaining a "set of visited nodes".

[0139] Approver parser: For each UserTask node in the path, it queries an independent approval rule base. If a rule is matched and the conditions are met, it calls the organizational structure service to map the role to a specific user; if no matching rule is found, it falls back to the default handler logic defined in the BPMN model.

[0140] Link Builder: Integrates path traversal results with approver parsing information, encapsulates the structured attributes of each node (such as ID, name, type, handler, conditions and results, status, etc.) in the execution order, and adds metadata such as process definition and form snapshot, and finally outputs a standardized JSON format approval chain object.

[0141] The following combination Figure 5 This section details the complete steps of this module from process initiation to dynamic updates: S1: User Login and Form Loading: S1.1 Users log in to the system through identity authentication.

[0142] The S1.2 system displays the types of processes that can be initiated (such as expense reimbursement and procurement) based on user permissions.

[0143] S1.3 The user selects the process type, and the system loads the corresponding form template, which contains key business fields.

[0144] S2: Form Completion and Data Submission: S2.1 Users fill in form data item by item on the front-end interface, and the front-end system performs basic validation.

[0145] S2.2 The front end monitors changes to key fields in real time and employs a debouncing mechanism.

[0146] S2.3 When a change is detected and the debouncing threshold is met, the frontend submits the current complete form data (JSON format) to the backend.

[0147] S3: Data Preprocessing and Rule Loading The S3.1 backend receives form data and performs cleaning, validation, and standardization.

[0148] S3.2 Synchronously load the approval rule base and organizational structure data related to this process.

[0149] S4: BPMN Model Loading and Parsing: S4.1 Load the corresponding BPMN 2.0 XML file from the process repository based on the process ID.

[0150] S4.2 uses a model loader and parser to parse XML into a directed graph structure in memory, extracting all nodes and their flow relationships.

[0151] S5: Path traversal (simulated execution): S5.1 Create a simulated execution context, inject the current form variables, and initialize the set of visited nodes and the list of approval chain results (initially empty).

[0152] S5.2 Initialize the current node as the start event and start traversal.

[0153] S5.3 Repeat steps S5.4 to S5.8 until an end event (EndEvent) is reached or the path is interrupted.

[0154] S5.4 Get all outgoing sequential flows of the current node.

[0155] S5.5 If the current node is an exclusive gateway, iterate through the conditional expressions of all its exits, call the expression engine to evaluate the form variables, and select the first path with a true result; if there is no true value, select the default flow.

[0156] If S5.6 is a node such as UserTask, then it proceeds sequentially along the single exit path.

[0157] S5.7 records visited nodes and selected paths to avoid loops.

[0158] S5.8 Set the next node as the current node and continue executing S5.3.

[0159] S6: Dynamic Analysis of Approver: S6.1 Traverse all UserTask nodes in the path determined in step S5.

[0160] S6.2 For each node, the approver parser queries the approval rule base for matching (for example, matching rule: {"nodeId": "task_finance_dir", "condition": "${amount > 10000}", "assigneeStrategy": "ROLE_FINANCE_DIRECTOR"}).

[0161] S6.3 If the rule exists and the conditions are met, the organization structure service is invoked to resolve the specified role into a specific user account and handle the proxy, substitute, and other logic.

[0162] S6.4 If there is no matching rule, the default handler expression defined for this node in the BPMN model shall be used.

[0163] S6.5 outputs the final approver information corresponding to each UserTask node.

[0164] S7: Approval Chain Construction and Return: S7.1 Create an empty approval chain container. The link builder creates an empty approval chain container.

[0165] S7.2 Encapsulates the structured information of each node in the execution order, including: node ID, name, type, approver (for UserTask), trigger condition, condition evaluation result, estimated processing time, status (marked as "PENDING_PREVIEW" in the preview stage), etc.

[0166] S7.3 Additional process definition key, form snapshot, generation timestamp and other metadata.

[0167] S7.4 serializes the complete information into a JSON object and returns it to the front end for the visualization module to display, so that users can confirm the approval path.

[0168] S8: User Confirmation and Process Initiation: S8.1 After the user confirms that the approval chain is correct, the user submits the application.

[0169] S8.2 The front end submits the final data, and the back end generates and temporarily stores the final approval chain snapshot.

[0170] Based on this snapshot, the S8.3 process engine interaction module calls the underlying engine API to start a real process instance.

[0171] S9: Process Execution and Change Capture: The S9.1 process instance runs to an approval node with the editableForm="true" attribute configured, and the task is assigned to approver A.

[0172] S9.2 Approver A opens the task in their to-do list and modifies one or more key fields in the form (e.g., changing "Contract Amount" from 80,000 yuan to 120,000 yuan).

[0173] The S9.3 front-end system monitors changes to key fields in real time and sends the updated complete form data along with the task ID to the back-end.

[0174] S9.4 The backend calls the form change detector to compare the current data with the historical snapshots stored in the process instance and identify a list of fields that have changed (such as changes in the value of the amount field).

[0175] S9.5 If at least one field is identified as a "triggering recalculation field", an approval chain recalculation event (RecomputeApprovalChainEvent) is generated. The event payload includes the process instance ID, the current task ID, the changed form data, and the list of changed fields.

[0176] The S9.6 system publishes the above events to the internal event bus (Apache Pulsar) to achieve decoupled communication.

[0177] S10: Dynamic Recalculation Approval Chain The S10.1 dynamic recalculation module acts as an event consumer, receiving and processing the event.

[0178] S10.2 Obtain the execution context of the current process instance from the process engine and locate the "first unfinished node after the current completed node" as the starting point for recalculation.

[0179] S10.3 Using the updated form data as input, the path traverser is invoked to incrementally deduce the remaining path starting from the starting point.

[0180] S10.4 Combine the approver parser to redetermine the approver for subsequent UserTask nodes.

[0181] S10.5 Generates a new snapshot of the approval chain (including node order, approver, conditions, status, etc.) and compares the differences with the old snapshot.

[0182] S10.6 Store the new snapshot in the approval chain version table of the database and mark it as the current valid version.

[0183] S11: Synchronization Updates and Notifications: S11.1 Inject the metadata of the new approval chain into the process instance variables through the process engine interaction module.

[0184] S11.2 Trigger the notification mechanism to push information that the approval chain has been updated to relevant parties such as the process initiator and subsequent approvers. For example, the process initiator (informing them that the approval chain has been updated), all approvers of tasks that have not yet been processed (showing the latest approval path), and relevant personnel who have approved tasks but may be affected by the path change (optional).

[0185] S11.3 The visualization module refreshes the approval chain view for all relevant users.

[0186] S12: Continue execution along the new path: S12.1 When the process engine advances to the next task node, the task assignment logic (such as TaskListener or AssignmentHandler) reads the latest approval chain snapshot.

[0187] S12.2 Distribute tasks based on the approver information recorded in the snapshot.

[0188] S12.3 The process continues to execute under the new path until it ends.

[0189] like Figure 6 As shown, this module acts as a data adaptation layer, receiving raw approval chain data from the approval chain calculation module and converting it into a standard display format that can be directly rendered by the front end. It supports various visualization scenarios such as preview, runtime updates, and historical comparisons. The following section provides a detailed explanation of the module's structure, functions, internal processing logic, and collaboration mechanisms, based on the system architecture and practical application scenarios.

[0190] (I) Core Objectives and Design Principles of the Module: The visualization generation module aims to address the pain point of existing BPM systems that "only display the current task and lack a full-link view." Its design follows three main principles: Data decoupling: It does not depend on a specific front-end framework and outputs general structured data; Status synchronization: Ensure that the displayed content is strictly consistent with the snapshot of the approval chain; Multi-scenario adaptation: Supports differentiated display needs at different lifecycle stages such as preview, execution, and historical replay.

[0191] (II) Internal Component Composition and Functional Description: The visualization generation module consists of the following four cooperating sub-components: (1) Data Receiver: Listen for output events (such as ApprovalChainComputedEvent or ApprovalChainUpdatedEvent) from the approval chain calculation module.

[0192] It receives a structured approval chain object (usually in JSON format), which includes fields such as node ID, name, type, approver, conditional expression, evaluation result, and status (e.g., PENDING_PREVIEW, APPROVED, SKIPPED).

[0193] It can interface with different sources: it can process both pre-calculated results and new snapshots after dynamic recalculation.

[0194] (2) Display Model Transformer: Map the original approval chain data to a front-end-friendly display model.

[0195] The core conversion logic includes: Node type standardization (UserTask → “Approval Node”, ExclusiveGateway → “Branch Decision”); Enhanced approver information (user ID is converted to name + avatar URL, and role is converted to Chinese description); Conditional expression beautification (e.g., ${amount > 10000} → “Amount > 10,000 yuan”); Semantic status (PENDING → “Pending”, REJECTED → “Rejected”).

[0196] It supports multilingual internationalization (i18n) configuration, facilitating global deployment.

[0197] (3) Flowchart Data Builder: Based on the presentation model, a flowchart data structure that conforms to the requirements of standard graphics libraries (such as AntV G6, ECharts, and mxGraph) is constructed.

[0198] The output contains two core types of information: a list of nodes (nodes): each node has a unique ID, coordinates (optional), label, icon, and status color; and a list of edges (edges): representing the flow relationships between nodes, supporting the annotation of conditional results (such as "yes" or "no").

[0199] Automatic layout algorithms (such as DAG hierarchical layout) ensure that the graphics are clear and readable, and avoid intersections and overlaps.

[0200] (4) Diff & Highlight Engine (optional but recommended): When a new approval chain snapshot is generated through dynamic recalculation, it is automatically compared with the old version in terms of structure and content.

[0201] Identify change types: new node, deleted node, change of approver, changes in path jump, etc.

[0202] When displaying changes on the front end, highlight the changed parts visually (e.g., with red dashed boxes, flashing animations, and change markers) to help users quickly locate the differences.

[0203] (III) Workflow of the visualization generation module: The workflow of this module is divided into two scenarios based on the process lifecycle stages: (1) Preview Phase: S1: The approval chain pre-computation component completes the memory simulation execution and generates an initial approval chain snapshot (all are in the PENDING_PREVIEW state).

[0204] S2: The data receiver captures this snapshot and passes it to the presentation model converter.

[0205] S3: The converter converts technical fields (such as nodeId="task_finance") into business language (such as "financial approval") and populates the default status style.

[0206] S4: The flowchart data builder generates flowchart data (including nodes and edges) in standard JSON format.

[0207] S5: The front-end calls this data to render a complete approval path diagram, allowing users to view "who approved under what conditions".

[0208] S6: If the user modifies the form, triggering a new round of pre-calculation, this module repeats the above process to achieve real-time preview refresh.

[0209] (2) Runtime update and history display scenario: S7: During process execution, due to changes in key fields of the form, the dynamic recalculation component generates a new approval chain snapshot (some nodes are in the APPROVED state, and subsequent nodes are in the PENDING state).

[0210] S8: The data receiver receives a new snapshot and triggers the difference comparison and highlighting engine.

[0211] S9: The engine compares the old and new snapshots and identifies that "the original path was to the CFO, but now the CEO approval is required due to the amount exceeding the limit".

[0212] S10: The presentation model converter generates a presentation model containing status (passed / pending) and change markers.

[0213] S11: The flowchart data builder outputs flowchart data with highlighted labels.

[0214] S12: The front-end automatically refreshes the view and pushes the updated approval chain to the process initiator, pending approvers, etc., supporting the intuitive presentation of information such as "currently at which step", "who else is next", and "has the path changed".

[0215] S13: After the process is completed, the system can call the same module to generate an archived version of the flowchart based on the final snapshot for auditing or knowledge preservation.

[0216] (iv) Interaction with other modules: The approval chain calculation module is its direct downstream consumer. The approval chain object output by the calculation module is the only input source for this module, and the two are decoupled through a standardized data contract (such as JSON Schema).

[0217] With the form data collection module: There is no direct data interaction, but it indirectly relies on the recalculation event triggered by the form data collection module. This module will only be activated when a form change triggers the generation of a new approval chain.

[0218] For the front-end system: Provides a data display interface via a RESTful API or WebSocket. The front-end does not need to understand BPMN or rule logic; it only needs to render according to the agreed format.

[0219] The interaction module with the process engine does not communicate directly, but the final "completed node" status must be consistent with the actual task status in the engine. Therefore, it relies on the engine interaction module to correctly synchronize the task results to the approval chain snapshot.

[0220] (v) Alternative implementation plan: Without departing from the core idea of ​​this invention, the visualization generation module can be implemented using the following alternatives: Output format: In addition to JSON, it can output SVG, XML (BPMN DI format) or GraphQL responses to adapt to different front-end technology stacks; Graphics library adaptation: The flowchart data builder is pluggable and supports switching between different drawing engines such as AntV, GoJS, and JointJS; Mobile optimization: For small-screen devices, a linear list view (not a flowchart) can be generated to highlight the approval order and responsible person; Accessibility support: Generate ARIA tags or voice description text to improve accessibility for users with disabilities.

[0221] like Figure 7 As shown, this module is responsible for injecting the automatically generated approval chain snapshots and dynamically updated results into the underlying BPMN 2.0 compatible workflow engine, ensuring that the task allocation and workflow paths of real workflow instances are consistent with the latest business logic calculated by the system. This module acts as an adapter between the computation layer and the execution layer, solving the problem of "disconnect between rule calculation and task distribution" in existing technologies. The following section, combining system architecture and actual operating scenarios, provides a detailed explanation of the module's composition, functions, internal component collaboration mechanisms, and interactions with other modules.

[0222] (I) Core Objectives and Design Principles of the Module: The workflow engine's interaction module design follows the principles of "declarative configuration + event-driven + context injection" to ensure high availability and maintainability. It aims to achieve the following three main goals: Precise synchronization: Accurately write the pre-generated or recalculated snapshot of the approval chain into the process instance context; Non-intrusive integration: Without modifying the underlying engine source code, it achieves integration through standard APIs and extension points; Closed-loop control: Supports full-process status feedback and exception handling from start to finish.

[0223] (II) Internal Component Composition and Functional Description: The process engine interaction module consists of the following five collaborative sub-components: (1) Engine Connector: It is responsible for establishing communication channels with the underlying process engine and supports multiple deployment modes (such as Spring Boot embedding, remote REST API, and JNDI connection).

[0224] Provide a unified interface to encapsulate the differences between different engines (such as Activiti, Camunda, and Flowable, all of which use RuntimeService) to achieve cross-engine compatibility.

[0225] (2) Process Instance Starter: After the user confirms the submission, the engine API is invoked to start the process instance.

[0226] Input parameters include: process definition key, initiator ID, form data, and final approval chain snapshot (stored as a variable).

[0227] Automatically set process variables (such as approvalChainSnapshot) at startup for subsequent task allocation logic to read.

[0228] (3) Task Assignment Processor: It is triggered by the engine (via TaskListener or AssignmentHandler) when the process progresses to the next UserTask node.

[0229] Read the latest approval chain snapshot from the process instance context and parse the approver information corresponding to the current node.

[0230] If a clear allocation strategy exists in the snapshot (such as the role "CFO"), the organizational structure service is invoked to map it to a specific user account and a to-do task is created.

[0231] It supports automatic processing of complex scenarios such as proxy, substitute, and multi-person countersigning.

[0232] (4) Status Synchronizer: Listen for events such as task completion, rejection, and signature in the monitoring engine, and update the node status (such as APPROVED, REJECTED, SKIPPED) in the approval chain snapshot in real time.

[0233] The modified snapshot is persisted to the database, and the visualization generation module is notified to refresh the front-end display.

[0234] Ensure that "system logs" and "engine facts" are always aligned to meet audit compliance requirements.

[0235] (5) Exception Handler & Rollback Mechanism: When there is a discrepancy between the approval chain snapshot and the engine's actual execution path (such as when a task is not correctly assigned due to a network interruption), an alarm is automatically triggered and an attempt is made to repair it.

[0236] It supports manual or automatic rollback to the previous stable version snapshot to avoid process freeze.

[0237] Record conflict logs for maintenance personnel to troubleshoot.

[0238] (III) Workflow of the process engine interaction module: The workflow of this module spans the entire process lifecycle and is divided into the initiation phase, execution phase, and termination phase: (1) Process initiation phase: S1: After confirming that the approval chain is correct on the front end, the user clicks "Submit".

[0239] S2: The process engine interaction module receives the submission request and obtains the final approval chain snapshot (generated by the approval chain calculation module).

[0240] S3: The engine connector establishes a connection with the process engine.

[0241] S4: The process instance launcher calls the startProcessInstanceByKey() method, passing in the process definition key, form data, and approval chain snapshot as variables.

[0242] S5: The engine creates a process instance and assigns the first task based on the default path.

[0243] S6: The system stores the snapshot in the approval_chain_snapshot table of the database and marks it as "current valid version".

[0244] (2) Process execution phase: S7: When the process progresses to an approval node configured with editableForm="true", the approver modifies key fields (such as amount).

[0245] S8: The form data acquisition module captures changes and triggers a dynamic recalculation event.

[0246] S9: The approval chain calculation module generates a new approval chain snapshot.

[0247] S10: After receiving a new snapshot, the process engine interaction module injects it into the current process instance context through the setVariable() method, overwriting the old version.

[0248] S11: As the process engine continues to advance to the next node, the task assignment processor reads the latest snapshot and assigns tasks according to the new path.

[0249] S12: If the original path was "Finance → Legal", and it has now changed to "Finance → CEO → Legal" due to exceeding the limit, then the CEO will be added as a pending person.

[0250] (3) Process termination stage: S13: Once all tasks are completed, the process reaches the end event.

[0251] S14: The state synchronizer detects the end of the process, marks the final approval chain snapshot as "completed", and archives it to the history database.

[0252] S15: The system triggers subsequent automated actions (such as sending emails or generating electronic contracts) to complete the closed loop.

[0253] (iv) Interaction with other modules: The approval chain calculation module is its downstream consumer. It receives snapshots of the approval chain generated by pre-calculation and dynamic recalculation, and uses them as input to start or update process instances.

[0254] Indirect collaboration with the visualization generation module. When the state synchronizer updates the snapshot, it notifies the visualization module to refresh the display; conversely, the "approved" status displayed on the front end also depends on the status feedback from the engine interaction module.

[0255] With the form data collection module: there is no direct interaction, but it relies on the recalculation event triggered by the form data collection module. This module will only intervene to update the engine context when a form change triggers the generation of a new snapshot.

[0256] Indirect dependency with the rule configuration module. The approver policies in the approval chain snapshot come from the rule base, so this module needs to ensure that the engine can correctly parse the roles and allocation logic defined in the rules.

[0257] (v) Alternative implementation plan: Without departing from the core idea of ​​this invention, the process engine interaction module can be implemented using the following alternatives: Integration methods: It can be embedded as a plugin into an existing process engine (such as the Camunda Plugin), or communicate with the engine via a RESTful API in the form of a microservice; Task allocation strategy: In addition to snapshot-based allocation, AI recommendation engines can also be introduced to assist decision-making; Multi-engine compatibility: Supports dynamically loading adapter classes for different engines, enabling one-click switching; Asynchronous processing: For large-scale concurrent scenarios, snapshot injection operations can be placed in a message queue for asynchronous execution to improve throughput.

[0258] like Figure 8 As shown, through modular design, real-time calculation, visualization, and dynamic adjustment of the approval path are achieved. It supports previewing the complete approval chain before process initiation and automatically updating subsequent paths in response to changes in key fields during execution. The following, combined with... Figure 8 The specific implementation method of the system is described.

[0259] (I) Overall Introduction to System Modules: This system mainly comprises five core modules: a rule configuration module, a form data acquisition module, an approval chain calculation module, a visualization generation module, and a workflow engine interaction module. These modules communicate through standardized interfaces and an event-driven mechanism, forming a loosely coupled, highly cohesive collaborative system that jointly supports a "dynamic, visual, and adaptive" approval process.

[0260] (II) Detailed description of core module functions: (1) Rule configuration module: Function: As the system's strategy hub, independent of the workflow engine, it is responsible for defining and managing the approval rule base. The rule base is associated with business conditions (such as contract amount, project type), approval strategies, role mapping relationships, and marks form fields that "trigger recalculation".

[0261] Function: Provides a graphical interface or API to support dynamic configuration and version management of rules, decouples approval logic from the BPMN process model, and provides unified policy support for other modules of the system.

[0262] (2) Form data collection module: Functionality: Responsible for listening to, capturing, and processing user-input form data throughout the entire process lifecycle. It internally comprises five collaborative components: Form listeners: The front-end listens for input events of key fields.

[0263] Debouncing and Change Aggregator: Optimizes request frequency and aggregates changes.

[0264] Form data collection service: The backend receives, validates, cleans, and builds a standardized context.

[0265] Change detector: During the process execution phase, compare data snapshots to identify valid changes.

[0266] Event publisher: Publishes recomputed events to the message middleware when needed.

[0267] Function: To ensure accurate and efficient collection of business data, and to trigger subsequent calculation logic only when critical changes occur that affect the approval path.

[0268] (3) Approval chain calculation module: Function: The core computing unit of this invention is responsible for generating and maintaining the latest approval path in real time based on form data and rules. It includes: The system consists of two functional components: the "Approval Chain Pre-calculation Component" which generates the complete path before submission; and the "Dynamic Recalculation Component" which incrementally updates the subsequent path at runtime.

[0269] The four basic capabilities are: "Model Loader and Parser" which is responsible for parsing the BPMN model; "Path Traverser" which simulates process execution in memory and evaluates conditions; "Approver Parser" which dynamically determines the actual handler for each task node; and "Link Builder" which integrates information and outputs a standardized approval chain data structure (such as JSON).

[0270] Function: By decoupling simulated execution from rules, it provides high-precision, low-latency approval path calculation services.

[0271] (4) Visualization generation module: Function: As a data adaptation layer, it receives structured data output from the approval chain calculation module and converts it into standardized display data (such as chart data, JSON) that can be directly used for rendering on the front end.

[0272] Function: Supports the front-end to realize graphical display of the approval chain (such as flowchart), node status highlighting, historical version comparison and other functions, so as to improve process transparency and user experience.

[0273] (5) Process Engine Interaction Module: Function: Serves as a bridge between the system and the underlying BPMN workflow engine. It is responsible for launching workflow instances based on approval chain snapshots and synchronously injecting the results of dynamic recalculation into the engine context.

[0274] Function: To ensure that the task allocation and flow of real process instances are consistent with the latest approval logic calculated by the system, thereby achieving a closed loop of calculation and execution.

[0275] (III) Inter-module collaboration and signal flow: The modules work together in the following order and manner: Rule supply: The rule configuration module provides the approval chain calculation module and the form data collection module with strategy information such as approval rules and field tags.

[0276] Data Triggering: User actions on the front end trigger the form data collection module. After processing the data, this module directly calls the pre-calculation during the preview stage; during the runtime stage, it triggers the calculation by publishing events (such as to Apache Pulsar).

[0277] Calculation and Visualization: The approval chain calculation module responds to the trigger, performs pre-calculation or dynamic recalculation, and sends the generated approval chain data to the visualization generation module.

[0278] Display and Confirmation: The visualization generation module converts data for front-end display, allowing users to confirm processes or view updates.

[0279] Engine execution: After the user confirms the submission, or after a dynamic update occurs, the process engine interaction module is responsible for calling the engine API to start or update the real process instance, ensuring that the task is assigned according to the latest path.

[0280] The entire system adopts an event-driven architecture, with modules communicating through clear data interfaces or events, achieving a high degree of decoupling and supporting independent deployment and expansion.

[0281] (iv) Explanation of achieving the invention objective: Through the modular design and collaboration described above, this system achieves: Dynamism: The approval chain calculation module can generate and update paths based on real-time data.

[0282] Visualization: The visualization generation module is responsible for data conversion, ensuring real-time graphical display of information across the entire chain.

[0283] Adaptability: Change detection and event publishing in the form collection module, combined with dynamic recalculation in the calculation module and synchronization in the engine interaction module, form an automatic adaptive closed loop of "detection-recalculation-synchronization".

[0284] Efficiency and compliance: Memory simulation execution improves performance; the incremental update mechanism preserves an immutable historical record, meeting audit requirements.

[0285] (v) Alternative solutions: Without departing from the core idea of ​​this invention, those skilled in the art can adopt various alternative implementation schemes: Storage and configuration: Approval rules can be stored in a configuration center (such as Nacos or Apollo) or in versioned files instead of directly using database tables.

[0286] Communication mechanism: Pulsar can be replaced by message middleware such as Kafka or RabbitMQ for the event bus.

[0287] Calculation and parsing: The evaluation of conditional expressions can be performed using script engines such as JavaScript and Groovy; the parsing of approvers can be integrated with AI recommendations or external HR system interfaces.

[0288] Algorithm and Architecture: Path traversal can use different graph algorithms (such as DFS, BFS); the overall system can be embedded as a plugin into the existing process engine, or it can be broken down into microservices that interact through RESTful APIs.

[0289] All of the above substitutions can achieve the core function of this invention, demonstrating the technical flexibility and wide applicability of the solution.

[0290] The method of the present invention can also solve the following technical problems: (1) Unpredictable approval chain: The approval path depends entirely on the evaluation of form data and conditional expressions at runtime. Users cannot know the complete approval chain before submission, making it difficult to predict the approval cycle and the personnel involved, which affects decision-making efficiency and collaboration experience.

[0291] (2) Lack of full-process visualization: The system usually only displays the current task and historical trajectory, and cannot fully present all approval nodes and responsible persons from the start to the end to the initiator or approver, resulting in low process transparency.

[0292] (3) Strong coupling between approval logic and process model: The approval rules are embedded in the expressions or listener code of the BPMN file. Changes in business rules require redesigning or deploying the process model, resulting in high maintenance costs, slow response, and difficulty in adapting to frequently changing business rules.

[0293] The approval chain process handling method provided in this embodiment of the invention has the following beneficial technical effects: (1) Improve process adaptability and response speed: The approval chain is dynamically generated based on form data and independent rules. When business elements (such as amount and project type) change, the system automatically recalculates and adjusts the subsequent approval path without manual intervention or remodeling. This ensures that the process is always consistent with the latest business status, significantly enhancing the adaptability and responsiveness to complex and ever-changing scenarios.

[0294] (2) Enhance process transparency and collaboration efficiency: The entire approval chain can be previewed before submission, and the updated path can be synchronized in real time during operation. The process initiator and all approval participants can clearly understand the approval nodes, responsible persons, conditions and status, eliminating information asymmetry and improving process monitorability and team collaboration efficiency.

[0295] (3) Simplify user operations and optimize user experience: Users can intuitively verify whether the approval chain meets expectations before submitting, avoiding rejection, interruption or repeated submission due to incorrect path, reducing invalid operations, lowering the threshold for use, and improving the overall interactive experience and satisfaction.

[0296] (4) Reduce system maintenance costs and operational burden: The approval logic is managed in the form of an independent rule base, decoupled from the BPMN process model. Changes to business rules only require configuration adjustments, without modifying or redeploying the process model, significantly reducing development, testing, and deployment workload; the fully automated construction of the process also reduces reliance on manual configuration, avoiding operational risks and error correction costs caused by human error.

[0297] (5) Improve the accuracy and timeliness of approval and execution: By simulating the execution of the BPMN path in memory and combining it with the rule engine for automatic evaluation, the results generated by the approval chain are ensured to strictly follow business rules. Combined with preview confirmation and dynamic recalculation mechanisms, the process preparation and decision-making cycle is shortened, effectively preventing execution delays or compliance risks caused by mismatched approvers or unreasonable paths.

[0298] (6) Possesses good compatibility and integration capabilities: Adopting standard interfaces, an event-driven architecture, and a design compatible with BPMN 2.0 semantics, it can be seamlessly integrated into mainstream workflow engines (such as Activiti, Camunda, Flowable, etc.) and existing enterprise BPM platforms without modifying the underlying engine. It has low deployment costs, short implementation cycles, and broad applicability and promotional value.

[0299] In summary, this invention not only achieves a functional leap from "static and rigid" to "dynamic and intelligent" approval chains, but also brings substantial progress in system stability, ease of operation, cost-effective maintenance, and technological scalability, providing strong support for enterprises to build an efficient, transparent, and compliant intelligent process management system.

[0300] The approval chain process processing method provided in this embodiment of the invention, during the execution of the approval chain process, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is a key field affecting the approval path; if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute, then a recalculation event is generated; the recalculation event is consumed, and starting from the first node after the current approval node that has not completed the approval, the remaining process path is recalculated based on the field data of the changed target field to obtain the updated approval chain; the updated approval chain process is executed, and during the execution process, the subsequent path is recalculated in real time based on the change of key fields, thereby improving the adaptability and automation level of the process approval.

[0301] In the above optional embodiments, before the step of executing the updated approval chain process, the approval chain process processing method further includes: Generate a snapshot of the updated approval chain, and then generate a visual view of the updated approval chain based on the snapshot. Refer to the above embodiments for further details.

[0302] In the above optional embodiments, before the approval chain process is executed, the approval chain process processing method further includes: Generate an initial approval chain and a visual view of the initial approval chain; the above embodiments can be referred to for explanation, and will not be repeated here.

[0303] In response to the user's initial approval chain confirmation trigger action based on the visual view of the initial approval chain, a snapshot of the approval chain and form data are obtained. This can be referred to the above embodiment for further explanation, and will not be repeated here.

[0304] In the above optional embodiments, determining the target field includes: The current form data is compared with the form data, and the fields that have changed are identified as candidate fields; the current form data is automatically updated during the execution of the approval chain process; the above embodiments can be referred to for explanation, and will not be repeated here.

[0305] The fields that affect the approval path are determined from the candidate fields based on a pre-configured rule base, and these fields are used as the target fields. This can be referred to the above embodiment for further explanation, and will not be repeated here.

[0306] In the above optional embodiments, generating the initial approval chain includes: Obtain the request sent by the user; the request carries the form data; please refer to the above embodiments for explanation, and will not be repeated here.

[0307] The key fields in the form data are obtained, and the approval rules corresponding to the key fields are determined according to the pre-configured rule base; the above embodiments can be referred to for explanation, and will not be repeated here.

[0308] The required approval personnel information for each approval node is determined according to the aforementioned approval rules; this can be referred to the above embodiments for explanation, and will not be repeated here.

[0309] The business process path is simulated, and the initial approval chain is generated based on the simulation results. This can be referred to the above embodiment for further explanation, and will not be repeated here.

[0310] In the above optional embodiments, after the step of obtaining the request sent by the user, the approval chain process method further includes: The user-sent request is validated. If the validation passes, the key fields in the form data are retrieved. This can be referred to the above embodiment for further details.

[0311] Figure 9 This is a schematic diagram of the process processing device for the approval chain provided in an embodiment of the present invention, as shown below. Figure 9 As shown, the approval chain process processing device provided in this embodiment of the invention includes an acquisition unit 901, a generation unit 902, an update unit 903, and an execution unit 904, wherein: The acquisition unit 901 is used to acquire the current approval node identifier if it is determined that the field in the form data that has changed is the target field during the execution of the approval chain process; the target field is a key field that affects the approval path; the generation unit 902 is used to generate a recalculation event if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute; the update unit 903 is used to consume the recalculation event, starting from the first node after the current approval node that has not completed the approval, and re-deduce the remaining process path based on the field data of the changed target field to obtain the updated approval chain; the execution unit 904 is used to execute the process of the updated approval chain.

[0312] Specifically, the acquisition unit 901 in the device is used to acquire the current approval node identifier if it is determined that the field in the form data that has changed is the target field during the execution of the approval chain process; the target field is a key field that affects the approval path; the generation unit 902 is used to generate a recalculation event if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute; the update unit 903 is used to consume the recalculation event, starting from the first node after the current approval node that has not completed the approval, and re-deduce the remaining process path based on the field data of the changed target field to obtain the updated approval chain; the execution unit 904 is used to execute the process of the updated approval chain.

[0313] The approval chain process processing device provided in this embodiment of the invention, during the execution of the approval chain process, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is a key field affecting the approval path; if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute, then a recalculation event is generated; the recalculation event is consumed, and starting from the first node after the current approval node that has not completed the approval, the remaining process path is recalculated based on the field data of the changed target field to obtain an updated approval chain; the updated approval chain process is executed, and during the execution process, the subsequent path is recalculated in real time based on the change of key fields, thereby improving the adaptability and automation level of the process approval.

[0314] The embodiments of the approval chain process processing device provided in this invention can be used to execute the processing flow of the above method embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the above method embodiments.

[0315] Figure 10 This is a schematic diagram of the physical structure of a computer device provided in an embodiment of the present invention, such as... Figure 10 As shown, the computer device includes: a memory 1001, a processor 1002, and a computer program stored in the memory 1001 and executable on the processor 1002. When the processor 1002 executes the computer program, it implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0316] This embodiment discloses a computer program product, which includes a computer program that, when executed by a processor, implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0317] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the following method: During the execution of the approval chain, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is the key field that affects the approval path. If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

[0318] Compared with existing technical solutions, the approval chain processing method provided in this invention, during the execution of the approval chain process, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; the target field is a key field affecting the approval path; if it is determined that the current approval node corresponding to the current approval node identifier has a pre-configured extensible attribute, then a recalculation event is generated; the recalculation event is consumed, and starting from the first node after the current approval node that has not completed the approval, the remaining process path is recalculated based on the changed target field data to obtain the updated approval chain; the updated approval chain process is executed, and during the execution process, the subsequent path is recalculated in real time based on the change of key fields, thereby improving the adaptability and automation level of the process approval.

[0319] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0320] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0321] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0322] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0323] In the description of this specification, the references to terms such as "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0324] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A process handling method for an approval chain, characterized in that, include: During the execution of the approval chain process, if it is determined that the field in the form data that has changed is the target field, then the current approval node identifier is obtained; The target field is a key field that affects the approval path; If it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes, a recalculation event is generated; Consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduce the remaining process path based on the changed target field data to obtain the updated approval chain; The updated approval chain process is executed.

2. The workflow processing method for the approval chain according to claim 1, characterized in that, Prior to the step of executing the updated approval chain process, the approval chain process processing method further includes: Generate a snapshot of the updated approval chain, and then generate a visual view of the updated approval chain based on the snapshot.

3. The workflow processing method for the approval chain according to claim 1, characterized in that, Before the approval chain process is executed, the approval chain process processing method further includes: Generate the initial approval chain and a visual view of it; In response to the user's initial approval chain confirmation trigger action based on the visual view of the initial approval chain, a snapshot of the approval chain and form data are obtained.

4. The workflow processing method for the approval chain according to claim 3, characterized in that, Determining the target field includes: The current form data is compared with the form data, and the fields that have changed are identified as candidate fields; the current form data is automatically updated during the execution of the approval chain process; The fields that affect the approval path are determined from the candidate fields based on the pre-configured rule base and used as the target fields.

5. The workflow processing method for the approval chain according to claim 3, characterized in that, The generation of the initial approval chain includes: Obtain the request sent by the user; the request carries the form data; Obtain the key fields from the form data, and determine the approval rules corresponding to the key fields based on the pre-configured rule base; The required approval personnel information for each approval node is determined based on the aforementioned approval rules; Simulate the execution of the business process path and generate the initial approval chain based on the simulation results.

6. The workflow processing method for the approval chain according to claim 5, characterized in that, Following the step of obtaining the user-sent request, the approval chain process method further includes: The system validates the user's request. If the validation passes, it retrieves the key fields from the form data.

7. A process processing device for an approval chain, characterized in that, include: The acquisition unit is used to acquire the current approval node identifier if, during the execution of the approval chain process, it is determined that the field in the form data that has changed is the target field; the target field is a key field that affects the approval path. The generation unit is used to generate a recalculation event if it is determined that the current approval node corresponding to the current approval node identifier has pre-configured extensible attributes. The update unit is used to consume the recalculation event, starting from the first unfinished approval node after the current approval node, and re-deduces the remaining process path based on the changed target field data to obtain the updated approval chain. The execution unit is used to execute the updated approval chain process.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images