Low-code approval process configuration method

Abstract

The invention discloses a low-code approval process configuration method, which relates to the technical field of information processing, and comprises the following steps: S1, creating a new approval process through visual operation, determining the name of the approval process, selecting the category and type of the approval process, and configuring a node operation authority group, a message notification template, an association form and a process level switch; s2, establishing a plurality of approval process branches, arranging an approval node sequence for each approval process branch, and defining trigger rules of the approval process branches based on a preset condition expression; s3, configuring required nodes and an execution sequence in the approval process branches; and S4, an approval process initiation form and a node form are constructed through visual operation, and form fields support different types of field modes. According to the low-code approval process configuration method provided by the invention, the risk of handwritten EL expression is reduced by adopting a visual engine, and the functions of dynamic approval and shortened query time can be realized.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and more specifically to a low-code approval process configuration method. Background Technology

[0002] Approval refers to the review and approval of official documents submitted by subordinates to superiors, and the submission of such documents for final approval. It typically employs mainstream approval engines, often using BPMN.js to design and edit flowcharts via drag-and-drop, enabling a visual configuration of the approval process. No complex code is required; simply dragging and dropping nodes and connecting process lines completes the visual configuration. Once configured, the engine parses and executes the flowchart configuration, automating the approval process flow, automatically assigning approval tasks, and making conditional routing decisions (based on EL expressions). It also supports form binding, approval monitoring (using JavaDelegate to trigger business logic), and comprehensively records the historical trajectory and operational status of the approval process, meeting enterprise-level approval process management needs.

[0003] However, the above approval method has the following defects: (1) Manually writing EL expressions becomes a high-risk point for the collapse of the approval process, because BPMN.js does not have a syntax validation function and requires manual writing of EL expressions to implement conditional routing. When an error occurs in the EL expression, taking financial approval as an example, if one of the symbols is wrong (such as mistakenly writing > as <), the financial node will be skipped incorrectly, resulting in direct monetary loss. (2) The approver in the approval process is usually a static approver, that is, the approver is fixed and the assignee attribute of the approval node is fixed to a static value, such as assignee="userA". When the employee who is the approver leaves or changes positions, the approval process will be interrupted due to personnel changes. The assignee="userA" fixed in the BPMN node needs to redeploy the approval process. The system may consume multiple deployments as a result, which increases the operation and maintenance cost. (3) In high-concurrency scenarios, database lock contention can lead to systemic crashes. When the backlog of approval tasks exceeds 10,000, pessimistic lock contention on the ACT_RU_TASK table (Activiti runtime task table) can cause task allocation delays to spike to more than 5 seconds, increasing the risk of system crashes. Therefore, in order to overcome the above defects, a new approval process configuration method is needed. This invention addresses this technical problem. Summary of the Invention

[0004] This invention provides a low-code approval process configuration method that uses a visual engine to reduce the risk of manually writing EL expressions and can achieve dynamic approval and reduce query time, thereby improving the configuration efficiency of the approval process.

[0005] A low-code approval process configuration method includes the following steps:

[0006] S1. Create a new approval process through visual operation, determine the name of the approval process, select the category and type of the approval process, and configure the corresponding nodes for permission groups, message notification templates, associated forms and process-level switches.

[0007] S2. Establish multiple approval process branches, arrange approval node sequences for each approval process branch, and define the triggering rules of the approval process branch based on preset condition expressions. When a business request is triggered, the parameter values ​​in the request are automatically parsed, and the corresponding approval process branch is matched with the parameter values. The approval is then carried out through the node sequence arranged by the approval process branch.

[0008] S3. Configure the required nodes and execution order in the approval process branches. The configuration of each node includes node information configuration, node handler configuration and node strategy configuration, which is used to realize the dynamic configuration of the approval process.

[0009] S4. Construct approval processes and initiate forms and node forms through visual operations. Form fields support different types of field patterns.

[0010] Furthermore, the preset condition expression in step S2 is configured through a visual interface, and the routing conditions are displayed through a visual structured table.

[0011] Furthermore, the node information configuration in step S3 includes the following steps:

[0012] S311. Set the approval steps and order of nodes in the approval process, and determine the execution time and execution order of each node through a visual interface;

[0013] S312. Specify the node type, which includes single-step approval type and countersigning approval type. Select the matching node type according to the business scenario.

[0014] S313. Determine whether the node is a fixed node or a fixed approver. A fixed node means that the node's position in the approval process remains unchanged, and a fixed approver means that it is approved by a specific person.

[0015] S314. Determine whether the node needs to be associated with a node form. If so, bind the corresponding node form to the approval process of the node.

[0016] Furthermore, in step S3, the assignment method configured for the node processor includes role assignment, personnel assignment, and dynamic field assignment.

[0017] The role assignment includes: the system calls the user center interface according to the organization type to obtain the corresponding user information, which serves as the approver for the current node;

[0018] The personnel assignment includes: calling the user center interface, obtaining user information, filtering out valid users, and assigning valid users as approvers for the current node;

[0019] The dynamic field assignment includes: obtaining the corresponding value in the process instance according to the field name configured in the node, using this value as the user domain account, transmitting the user domain account after calling the user center interface, filtering valid users, and using the valid users as the approvers of the current node.

[0020] Furthermore, in step S3, when the node type is a countersigning approval type, the approval is carried out according to the adjudication mechanism. The adjudication mechanism includes an approval mechanism and a rejection mechanism. The approval mechanism includes proportional approval, single-vote approval, and unanimous approval. The rejection mechanism includes step-by-step approval, return node processing, and return person processing.

[0021] Furthermore, in step S3, the triggering timing of the node policy configuration includes when the process starts, when the node arrives, and when the node ends. The execution types include message notification, automatic review, and API call. After the configuration timeout, remedial and retry actions will be triggered.

[0022] Furthermore, in step S4, the form configuration includes field attribute configuration, which includes setting field type, validation rules, layout style and read / write permissions for form fields. The process initiation form serves as the business data entry point, and the node form is bound to a specific approval node as needed.

[0023] Furthermore, it also includes a dynamic adjustment strategy for processors, which includes:

[0024] S51. Obtain and parse the list of task nodes passed from the front end, and use it to modify the user information that needs to be changed;

[0025] S52. Delete the personnel information and temporary personnel information corresponding to the task based on the task node ID;

[0026] S53. Save the modified user information that needs to be changed.

[0027] One or more technical solutions proposed in this application have at least the following technical effects:

[0028] (1) This solution uses a visual interface to configure the approval process. Staff do not need to master EL expression writing, nor do they need to write EL expressions when configuring the approval process. This makes the approval process configuration process visual. Staff can complete the configuration of the approval process by clicking. Moreover, it can promptly identify problems in the approval process configuration. The operation is simple and does not require BPMN configuration. It achieves low-code design, thereby improving practicality.

[0029] (2) This solution adopts a mixed storage strategy with different fields to meet the dynamic needs of business: structured storage ensures strong consistency of key data, JSON dynamic storage supports the extension of non-standard business fields, and there is no need to write SQL table creation statements or database connection code. Business personnel can complete the configuration independently according to actual needs. After the form is submitted, the system automatically determines the storage mode without manual selection, thereby reducing the operation threshold and helping to improve approval efficiency. Attached Figure Description

[0030] Figure 1 This is a flowchart of the present invention;

[0031] Figure 2 This is a schematic diagram of the approval process branches in this invention;

[0032] Figure 3 This is a schematic diagram of node jumping in this invention;

[0033] Figure 4 This is a schematic diagram of the countersigning and approval process in this invention. Figure 1 ;

[0034] Figure 5 This is a schematic diagram of the countersigning and approval process in this invention. Figure 2 . Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0036] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indicators will also change accordingly.

[0037] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text includes three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0038] See Figures 1-5 This invention proposes a low-code approval process configuration method, including the following steps:

[0039] S1. Create a new approval process through visual operation, determine the name of the approval process, select the category and type of the approval process, and configure the corresponding nodes for permission groups, message notification templates, associated forms and process-level switches.

[0040] S2. Establish multiple approval process branches, arrange approval node sequences for each approval process branch, and define the triggering rules of the approval process branch based on preset condition expressions. When a business request is triggered, the parameter values ​​in the request are automatically parsed, and the corresponding approval process branch is matched with the parameter values. The approval is then carried out through the node sequence arranged by the approval process branch.

[0041] S3. Configure the required nodes and execution order in the approval process branches. The configuration of each node includes node information configuration, node handler configuration and node strategy configuration, which is used to realize the dynamic configuration of the approval process.

[0042] S4. Construct approval processes and initiate forms and node forms through visual operations. Form fields support different types of field patterns.

[0043] Furthermore, the preset condition expressions in step S2 are configured through a visual interface, and the routing conditions are displayed through a visual structured table.

[0044] The permission groups represent multiple handlers at each node in the approval process. Each handler is responsible for approving the process, and at certain stages, they must take appropriate action. Message notification templates can be configured through node policies. A suitable template is selected within the policy, and the template is formed by combining text with corresponding EL expressions. For associated forms, there are process forms and detail forms. Detail forms are associated within the approval process; when an approval process is associated with a detail form, the information in that form will be displayed on the interface. Process forms are associated within nodes; when a node is associated with a process form, that node will approve according to the content of the process form. Process-level switches include several "yes" and "no" options, such as whether to allow withdrawal or communication, which are configured by selecting "yes" or "no".

[0045] The core logic of traditional BPMN solutions is to connect approval nodes with "lines" and store routing conditions with "line attributes". All "jump rules from node A to node B" must be implemented by drawing a physical connection, and the judgment conditions (such as ${amount>10000} "amount exceeds 10,000") will be hidden in the attribute configuration of this connection and cannot be seen directly.

[0046] For example, a company's "procurement approval process" has 5 core nodes (applicant → department manager → finance → director → CEO) and 3 core routing rules:

[0047] Purchase amount ≤ 10,000: Department Manager → Finance → Process End;

[0048] For amounts between 10,000 and 50,000: Department Manager → Finance → Director → Process End;

[0049] For amounts > 50,000: Department Manager → Finance → Director → CEO → Process End.

[0050] According to the traditional BPMN scheme, to implement these 3 rules, at least 5 physical connections need to be drawn (applicant → department manager, department manager → finance, finance → director, director → CEO, finance → end, director → end), and the corresponding amount judgment condition needs to be hidden in the attributes of each connection.

[0051] For more complex processes (such as those with 10 nodes and 8 routing rules), the number of lines that need to be drawn can reach dozens or even hundreds. These lines intersect, overlap, and become tangled on the flowchart, making it difficult to find the routing rules. Furthermore, due to visual clutter, configuration personnel may overlook key routes when sorting out the process, leading to errors. Therefore, this solution proposes to display routing conditions using structured tables.

[0052] This embodiment uses a visualization engine to visualize the approval process configuration. Specifically, it is developed based on the Vue.js + Element UI front-end framework, integrates the SortableJS drag-and-drop component library and the NRules rule engine module, supports node drag-and-drop orchestration and visual configuration of conditional rules, and does not depend on the BPMN.js framework.

[0053] While visual approval methods already exist, such as DingTalk approval and Lark approval, the implementation method in this solution differs from the aforementioned technologies. The specific differences are as follows:

[0054] DingTalk's approval routing rules rely on simplified EL expression configuration and do not have structured table display functionality; moreover, node approvers are statically assigned and do not have the function of dynamically adjusting node approvers.

[0055] Lark Approval: The storage solution is a single JSON storage, and it does not have an automatic "structured + JSON" mixed mode;

[0056] Therefore, the technical solution adopted in this application is different from the existing approval method.

[0057] Furthermore, the node information configuration in step S3 includes the following steps:

[0058] S311. Set the approval steps and order of nodes in the approval process, and determine the execution time and execution order of each node through a visual interface;

[0059] S312. Specify the node type. The node type includes single-step approval type and countersigning approval type. Select the matching node type according to the business scenario.

[0060] S313. Determine whether the node is a fixed node or a fixed approver. A fixed node means that the node's position in the approval process remains unchanged, and a fixed approver means that it is approved by a specific person.

[0061] S314. Determine whether the node needs to be associated with a node form. If so, bind the corresponding node form to the approval process of the node.

[0062] Preferably, this solution can also include available operation buttons to further optimize the node approval process, such as common "Agree", "Reject", "Transfer", "Add Signature", "Communicate", "Cc", "Withdraw", etc. These buttons determine the specific actions that the approver can perform at this stage.

[0063] Since the approval process in this solution consists of a series of nodes, nodes can be changed under normal circumstances. However, a fixed node is one that cannot be changed. A node may include one or more approvers. A fixed approver is one who cannot be replaced at that node. For example, in the financial aspect, approval must be made by the finance manager. Other approvers can be replaced, so the finance manager is the fixed approver at that node.

[0064] Furthermore, in step S3, the assignment methods for the node handler configuration include role assignment, personnel assignment, and dynamic field assignment.

[0065] Role assignment includes: the system calls the user center interface according to the organization type to obtain the corresponding user information, which is then used as the approver for the current node;

[0066] Personnel assignment includes: calling the user center interface, obtaining user information, filtering out valid users, and assigning valid users as approvers for the current node;

[0067] Dynamic field assignment includes: retrieving the corresponding value from the process instance based on the field name configured in the node, using this value as the user domain account (e.g., employee ID / username), transmitting the user domain account (e.g., employee ID / username) after calling the user center interface, and filtering for valid users, assigning valid users as approvers for the current node. Valid users refer to users who are currently in their work positions; if a user leaves the company, that user is no longer considered a valid user. The process instance represents the current approval process.

[0068] The phrase "retrieving the corresponding value in the process instance" mentioned above specifically relies on the JSON structured data model of the process instance. It is obtained through the unified data interface ProcessInstanceDataAPI (following the RESTful specification), and the returned data structure is a key-value pair format of {fieldName: value, fieldType: type, ...}. The fieldName must exactly match the field name configured in the node.

[0069] The following are examples of scenarios for configuring node handlers:

[0070] Scenario Example: Engineering Maintenance Process:

[0071] Basic configuration (role assignment): Select repairman Zhang San directly.

[0072] Intermediate configuration (personnel assignment): Select the "Maintenance Department" role, and the system will automatically search for available personnel from the role library.

[0073] Advanced configuration (dynamic field assignment): Associate the ${repairStaff} field in the form to dynamically obtain the maintenance manager for the current process.

[0074] The specific implementation logic of the above content is as follows:

[0075] 1. When the approval process reaches the current node and generates the corresponding approval task, the system first needs to determine the user type configured for that node, and then accurately match the node approver according to the following logic:

[0076] 1.1 If the user type is a role, first determine the application scenario limited by the role, and then execute the corresponding addressing logic.

[0077] 1.1.1 If the role is limited to BPM approval applications:

[0078] First, determine if the organization type is a floor / personnel group. If so, retrieve the corresponding organization system code / organization ID from the JSON field of the process instance; otherwise, directly retrieve the organization code (groupCode) from the JSON field. Then, pass the organization system code / organization ID, target role, and BPM approval application code to the user center interface to obtain user information and designate that user as the approver for the current node.

[0079] 1.1.2 If the role is limited to merchant applications:

[0080] The shop code (shopCode) is obtained directly from the JSON field of the process instance. The merchant user's interface is called, and the shop code and role are passed as input parameters to the merchant user's interface to obtain the merchant user information, thereby making the merchant user the approver of the current node.

[0081] 1.1.3. If the role is limited to production office applications:

[0082] Retrieve the enterprise code from the JSON field of the process instance, call the user center's interface, pass the enterprise code, role, and production office application code to the interface, obtain the production office user information, and set the production office user as the approver of the current node.

[0083] 1.2 If the user type is "personnel":

[0084] Call the user center interface, pass the user domain account (such as employee ID / username) configured in the node to the interface, obtain the corresponding user information, and determine which users are valid based on the obtained user information. Then, use the remaining valid users as the approvers of the current node.

[0085] 1.3 If the user type is a field:

[0086] Based on the field name configured in the node, extract the corresponding value (i.e., user domain account) from the process instance, then pass the user domain account to the user center interface to obtain user information, filter out valid users, and use them as the approvers of the current node.

[0087] Furthermore, in step S3, when the node type is a countersigning approval type, the approval is carried out according to the adjudication mechanism. The adjudication mechanism includes an approval mechanism and a rejection mechanism. The approval mechanism includes proportional approval, single-vote approval, and unanimous approval. The rejection mechanism includes step-by-step approval, return of node processing, and return of person processing.

[0088] Specifically, the joint signature approval decision-making mechanism is mainly applied to multi-person joint signature decision-making scenarios: when the node type is joint signature, the system will count the number of tasks that agree, and can either handle nodes with relatively lenient review by passing with one vote, or meet strict and complex nodes by setting a ratio.

[0089] If you want to veto a node, you can set the option to "unanimous approval". In this case, if even one person votes against the node, the node will be rejected.

[0090] In addition, there are three ways to handle rejections: you can choose to continue approval at each level after rejection, or return to the return node for processing or the node of the person returning the rejection. This process node configuration scheme can basically meet all the possibilities in the approval scenario of joint signing.

[0091] The code implementation for the joint approval is as follows:

[0092] / / Multi-person signature decision-making algorithm (ProcessHelper.class)

[0093] public boolean checkJointlySignPass(WorkflowProcessFormdataformdata, Integer num, Integer count){

[0094] BigDecimal percent = formdata.getJointlySignPassPercent();

[0095] / / If it passes unanimously, the pass percentage will be set to 100%.

[0096] if(formdata.getJointlySignPassModel()==1){

[0097] percent = new BigDecimal(100);

[0098] }

[0099] / / If it passes with one vote, return true directly.

[0100] return formdata.getJointlySignPassModel()==3

[0101] / / Otherwise, calculate the actual pass percentage and compare it with the preset pass percentage. If it is greater than or equal to the preset percentage, return true.

[0102] || new BigDecimal(num).multiply(new BigDecimal(100)).divide(new BigDecimal(count), 2, RoundingMode.HALF_UP).compareTo(percent)>=0;

[0103] }

[0104] Furthermore, in step S3, the triggering timing of the node policy configuration includes when the process starts, when the node arrives, and when the node ends. The execution types include message notification, automatic auditing, and API call. After the configuration timeout, remedial and retry actions will be triggered.

[0105] Specifically, a specified time can be preset, and when a task is not processed within the specified time (hours / days), the corresponding message notification or remedial action will be triggered, and the number of retries can be configured.

[0106] Furthermore, in step S4, the form configuration includes field attribute configuration, which includes setting the field type, validation rules, layout style and read / write permissions for the form fields. The process initiation form serves as the business data entry point, and the node form is bound to a specific approval node as needed.

[0107] Specifically, the form configuration function is responsible for defining the data carriers in the approval process, mainly covering the process initiation form (the main form filled out by the user when submitting an application) and node forms (auxiliary forms dynamically displayed during the approval process). Form configuration supports two field construction modes: structured fields and custom dynamic fields.

[0108] Structured field mapping: Directly associates database table fields (such as material number, quantity, etc.), and the data will be stored in the corresponding physical table, ensuring seamless integration with the enterprise's existing data model;

[0109] Custom dynamic fields: Temporary fields (such as approval comments, attachment uploads, etc.) are generated visually, and the data is stored in extended fields in JSON format, which can flexibly adapt to non-standard business needs.

[0110] Both types of forms support configuring field types, validation rules, layout styles, and read / write permissions. The process initiation form serves as the data entry point, determining the completeness of the initial business information; node forms are bound to specific approval stages as needed (such as displaying cost details during financial review), enabling refined data control in approval scenarios. Ultimately, all form data will be automatically aggregated according to preset rules—structured fields will be stored in the business table, while custom fields will be serialized into JSON for unified storage, forming an end-to-end data loop.

[0111] Furthermore, it also includes strategies for handling dynamic adjustments to personnel, which include:

[0112] S51. Obtain and parse the task node list passed from the front end, and use it to change the user information that needs to be changed; that is, according to actual needs, change or add / remove users (approvers) within a certain node.

[0113] S52. Delete the personnel information and temporary personnel information corresponding to the task based on the task node ID;

[0114] S53. Save the modified user information that needs to be changed.

[0115] Preferably, this embodiment features a unique hybrid storage scheme that combines structured fields of the database table with dynamic fields of JSON. This architecture achieves the integration of "strong consistency of critical business data" and "unlimited expansion of non-standard data," completely resolving the fundamental contradiction between "rigid data models" and "dynamic business requirements" in enterprise-level approval workflows.

[0116] Among them, the structured storage mode is adapted to fixed business scenarios: when the user explicitly binds the target database table field to the form field (such as mapping "material quantity" to the inventory.quantity column), when the form is submitted, the system will automatically generate a standardized SQL statement based on the field mapping relationship, and the data will be directly written to the corresponding business database (such as MySQL). This ensures strong transactional consistency of key data (complies with ACID principles) and supports efficient data retrieval in complex query scenarios.

[0117] Dynamic JSON storage mode adapts to flexible business scenarios: When form fields do not need to be bound to database tables (non-routine business without fixed data structure), the system will automatically serialize all form field values ​​into JSON format data objects and store them centrally through a single JSON type field (such as the form_data column) in the pre-set process table, so that the fields can be flexibly expanded without modifying the database table structure.

[0118] The specific implementation logic is as follows:

[0119] Configure data source: Enter the connection parameters of the target business database, including core information such as database connection address, login account, and access password, and establish a stable communication link with the business database;

[0120] Data instance configuration: The system automatically parses the designed form structure, extracts the form fields (including field type, length, validation rules and other attributes), and generates the corresponding physical database table based on the field information, without the need to manually write table creation SQL statements;

[0121] Data model configuration: Define the relationships between database tables (such as one-to-many / many-to-one relationships between the main table and child tables), and specify unique identifier fields in the data model (such as order number, approval number) to ensure the uniqueness and relevance of data storage;

[0122] Post-form submission storage logic adaptation: After a user submits form data, the system first automatically determines whether the corresponding data model has been configured based on the current business type, and then dynamically selects the storage mode.

[0123] No data model scenario: If the current business does not have a data model configured, it means that structured storage is not required. The system directly encapsulates the full form data into a JSON object and stores it by associating it with the corresponding process instance. Subsequent approval nodes are based on this JSON data to read the required approval information, achieving seamless data flow.

[0124] In scenarios with a data model: If the current business has a configured data model, the system will extract field values ​​and assemble the information to be stored based on the incoming form JSON data using a recursive parsing algorithm. During the assembly process, the system will accurately match the corresponding data records based on the unique fields preset by the data model (used to distinguish between inserting new data or updating existing data). Subsequently, based on the connection information configured in the data source, the system will generate standardized SQL statements and execute them in the target business database to ensure strong consistency between key data and the business system.

[0125] The method described in this solution allows data sources, data instances, and data models to be configured visually on a webpage, eliminating the need to write SQL table creation statements or database connection code. Business users can complete the configuration independently, and the system automatically determines the storage mode after the form is submitted, eliminating the need for manual selection of "store structured data" or "store JSON," thus lowering the operational threshold.

[0126] Regarding the automatic determination of storage mode, this embodiment adopts the following method:

[0127] (1) Establish a business data model configuration list to record the relationship between business types and structured tables, such as which fields in the business type are stored in JSON and which are stored in structured tables, to represent the judgment logic of storage mode;

[0128] (2) When the form is submitted, the system queries the storage method of different fields according to the business data model configuration list, and then stores the fields according to the corresponding storage method;

[0129] (3) This method can complete the switching between "structured storage / JSON dynamic storage" in a short time. This automatic judgment logic is a design not covered by the existing hybrid storage solution.

[0130] Furthermore, regardless of the storage mode used, the data is strongly associated with the process instance, and subsequent approval nodes can directly read it (structured fields are queried via SQL, and JSON fields are parsed via key-value pairs), eliminating the need for manual re-entry. It also supports seamless integration with existing enterprise business databases (such as MySQL and Oracle), and pre-configured process tables are compatible with JSON storage, eliminating the need to refactor the existing data architecture and reducing the cost of development.

[0131] This allows for a hybrid storage solution combining structured fields and dynamic JSON fields in the database table. Structured fields offer high reliability, while dynamic JSON fields provide flexibility. Combining the two improves both data reliability and flexibility, thereby enhancing the efficiency of the approval process.

[0132] The above description is merely an exemplary embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention specification and drawings under the technical concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A low-code approval process configuration method, characterized by, The method comprises the following steps: S1, a new approval process is created through a visual operation, the name of the approval process is determined, the category and type of the approval process are selected, and the node configurations of the permission group, message notification template, associated form and process level switch are performed; S2, a plurality of approval process branches are established, the approval node sequence for each approval process branch is arranged, and the trigger rule of the approval process branch is defined based on a preset condition expression; when a business request is triggered, the parameter value in the request is automatically parsed, the corresponding approval process branch is matched according to the parameter value, and the nodes arranged by the approval process branch are used for approval; S3, the required nodes and execution order in the approval process branch are configured, the configuration of each node includes node information configuration, node handler configuration and node strategy configuration, which is used to realize the dynamic configuration of the approval process; S4, the approval process initiation form and node form are constructed through a visual operation, and the form field supports different kinds of field modes.

2. The low-code approval process configuration method of claim 1, wherein, The preset condition expression in the step S2 is configured through a visual interface, and the routing condition is displayed through a visual structured table.

3. The method of claim 1, wherein, The node information configuration in the step S3 comprises the following steps: S311, the approval step and approval order of the node in the approval process are set, the execution time and execution order of each node are determined through a visual interface; S312, the node type is specified, the node type includes a single-step approval type and a countersigning approval type, and the matching node type is selected according to the business scenario; S313, it is determined whether the node is a fixed node or a fixed approver, the fixed node means that the position of the node in the approval process is unchanged, and the fixed approver means that the node is approved by a specific person; S314, it is determined whether the node needs to be associated with a node form, if associated, the corresponding node form is bound to the approval link of the node.

4. The method of claim 1, wherein, In the step S3, the assignment mode of the node handler configuration includes role assignment, personnel assignment and dynamic field assignment; The role assignment includes: the system calls a user center interface according to the organization type, obtains the corresponding user information, and takes the user information as the approver of the current node; The personnel assignment includes: calling a user center interface, filtering the valid users after obtaining the user information, and taking the valid users as the approver of the current node; The dynamic field assignment includes: obtaining the corresponding value in the process instance according to the field name configured by the node, taking the value as a user domain account, calling a user center interface after transmitting the user domain account, and filtering the valid users to take the valid users as the approver of the current node.

5. The method of claim 3, wherein, In the step S3, when the node type is a countersigning approval type, the approval is performed according to a decision mechanism, the decision mechanism includes a passing mechanism and a rejection mechanism, the passing mechanism includes passing by proportion, passing by one vote and passing by full vote, and the rejection mechanism includes step-by-step approval, returning to node processing and returning to person processing.

6. The method of claim 1, wherein, In the step S3, the trigger time of the node strategy configuration includes the start of the process, the arrival of the node and the end of the node, the execution type includes message notification, automatic review and API calling, and after the configuration timeout, a remediation and retry action is triggered.

7. The method of claim 1, wherein, The form configuration in the step S4 includes field attribute configuration, and the field attribute configuration includes setting field types, verification rules, layout styles and read-write permissions for form fields, the process initiation form serves as a business data portal, and the node form is bound to a specific approval node on demand.

8. The method of claim 1, wherein, The method also includes a handler dynamic adjustment strategy, which includes: S51, acquiring and parsing the task node list transmitted by the front end, and changing the user information that needs to be changed based on the task node list; S52, deleting the personnel information and temporary personnel information corresponding to the task according to the task node id; S53, saving the changed user information that needs to be changed.

Images