Task automatic approval method and system, storage medium, and computer device
Patent Information
- Application Number
- CN202611006560.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-07
- Publication Date
- 2026-11-03
AI Technical Summary
[0004]当业务管控要求调整、监管规则更新时,运维人员必须修改业务系统底层代码才能完成规则迭代,频繁的规则变更不仅需要走完整的代码评审、版本发布流程,还可能因代码改动引入未知运行异常,直接打断正在流转的审批任务,造成大量待审批任务阻塞、流程节点卡死等问题,严重干扰正常业务的审批进展,最终导致整体业务流程推进不顺,难以适配灵活多变的实际业务管控需求
[0010]借由上述技术方案,本申请提供的一种任务自动审批方法及系统、存储介质、计算机设备,通过Drools实时监测数据库规则变更、动态编译生成规则文件,无需修改业务代码、重启服务即可完成审批规则迭代,降低规则更新的运维成本。
Smart Images

Figure CN123032302A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method and system for automatic task approval, a storage medium, and a computer device. Background Technology
[0002] With the continuous popularization of enterprise digital office systems, various business systems have been widely used to cover daily office scenarios such as travel expense reimbursement, expense application, and qualification review. The approval tasks in these scenarios are massive and highly standardized, and automatic approval mechanisms have become the core support means to ensure the efficiency of business flow.
[0003] Currently, most business systems in the industry use hard-coding to solidify approval rules in business code for automatic approval logic. The approval rules for different business systems and different business processes are independent and significantly different. For example, in the reimbursement scenario, the reimbursement threshold for employees of different job levels and the invoice verification standards for different types of expenses, as well as the admission judgment conditions for different applicants in the qualification review scenario, all require the configuration of differentiated rule logic.
[0004] When business control requirements are adjusted or regulatory rules are updated, operations and maintenance personnel must modify the underlying code of the business system to complete the rule iteration. Frequent rule changes not only require a complete code review and version release process, but may also introduce unknown runtime anomalies due to code modifications, directly interrupting the approval tasks in progress, causing a large number of pending approval tasks to be blocked, process nodes to be stuck, etc., seriously interfering with the approval progress of normal business, and ultimately leading to the overall business process not being smooth and difficult to adapt to the flexible and ever-changing actual business control needs. Summary of the Invention
[0005] In view of this, this application provides a method and system for automatic task approval, a storage medium, and a computer device. By using Drools to monitor database rule changes in real time and dynamically compile and generate rule files, the approval rule iteration can be completed without modifying business code or restarting the service, thereby reducing the operation and maintenance costs of rule updates.
[0006] According to one aspect of this application, an automatic task approval method is provided, applied to a business system built on a process engine framework, wherein the business system is equipped with a database and integrated with the Drools rule engine, the method comprising: When a user submits a task pending approval through the business system, triggering the business system to generate a task event, the process engine intercepts the task event through the event listening mechanism and creates a process instance for the task pending approval. The process engine extracts task data based on task events and binds the task data to the process instance. The task data is input by the user through the business system when submitting a task to be approved. The process engine calls the Drools rule engine to enable the Drools rule engine to monitor whether the automatic approval rules in the database have changed. When a change is detected, the Drools rule engine pulls the latest automatic approval rules from the database and dynamically compiles and generates an automatic approval rule file. The database has pre-configured automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements. The Drools rule engine outputs a judgment result on whether a task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. The process engine obtains the judgment result. When the judgment result shows that the task meets the automatic approval requirements, the process engine drives the process instance to perform automatic approval operation.
[0007] According to another aspect of this application, an automatic task approval system is provided, applied to a business system built on a process engine framework. The business system is equipped with a database and integrated with the Drools rule engine. The system includes: The process instance creation module is used to intercept the task event through an event listening mechanism when a user submits a task to be approved through the business system, triggering the business system to generate a task event, and create a process instance for the task to be approved; extract task data based on the task event, and bind the task data to the process instance, wherein the task data is input by the user through the business system when submitting the task to be approved; The rule dynamic compilation module is used to monitor whether the automatic approval rules in the database have changed. When a change is detected, the module pulls the latest automatic approval rules from the database and dynamically compiles them to generate an automatic approval rule file. The database is pre-configured with automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements. The automatic approval module is used to output a judgment result on whether a task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. When the judgment result shows that the task meets the automatic approval requirements, it drives the process instance to perform automatic approval operation.
[0008] According to another aspect of this application, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described automatic task approval method.
[0009] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described automatic task approval method.
[0010] By utilizing the above technical solutions, this application provides an automatic task approval method and system, storage medium, and computer equipment. Through Drools, it monitors database rule changes in real time and dynamically compiles and generates rule files. It can complete the approval rule iteration without modifying business code or restarting services, thereby reducing the operation and maintenance costs of rule updates.
[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description
[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an automatic task approval method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating another automatic task approval method provided in an embodiment of this application is shown; Figure 3 A schematic diagram of the structure of an automatic task approval system provided in an embodiment of this application is shown. Detailed Implementation
[0013] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.
[0014] This embodiment provides a method for automatic task approval, such as... Figure 1 As shown, the method includes: Step 101: When a user submits a task to be approved through the business system, triggering the business system to generate a task event, the process engine intercepts the task event through the event listening mechanism and creates a process instance for the task to be approved.
[0015] Currently, common technical solutions in the industry for automatically skipping process nodes based on Activiti (process engine) mainly include the following: A skipping solution based on conditional gateways. This solution adds an exclusive gateway during process design, using gateway branch conditions to determine whether to execute a certain approval step. For example, a gateway node can be set up before an approval node, deciding whether to proceed to that approval node based on business parameters. The disadvantages are strong invasiveness, high modification costs, difficult maintenance, and poor management.
[0016] Activiti 6.0 offers a SkipExpression-based skipping solution, allowing configuration of skip expressions at user task nodes. The system determines whether to automatically skip a task based on the value of a process variable. The working principle is as follows: a SkipExpression (e.g., ${skipFlag==true}) is set on the UserTask node in the flowchart. When the process reaches this node, the engine parses the expression; if the expression evaluates to true, the current task is skipped, and the process proceeds directly to the next stage. The drawbacks are: enabling SkipExpression requires setting the _ACTIVITI_SKIP_EXPRESSION_ENABLED process variable, and each task node requiring skipping needs separate configuration, making configuration cumbersome; skipping conditions are based on expression judgment, requiring modification of the expression logic when approvers change or business rules change, limiting flexibility; and the expression-based skipping method cannot effectively determine skipping conditions in some scenarios, and requires a complete overhaul of the business system, which is time-consuming and labor-intensive.
[0017] The automatic skipping scheme based on a timeout timer utilizes Activiti's boundary events to launch scheduled tasks. When the task's dwell time exceeds a preset threshold, an automatic skip operation is triggered by the timer. The implementation involves setting a timer boundary event on the user task node, configuring the timeout period, and triggering the timer event after the timeout, allowing the process to continue flowing along the boundary event path. The drawbacks are that the cause of timer failure cannot be effectively obtained, the exception handling mechanism is incomplete, and error logs are stored in an underlying byte array table, making effective exception localization and handling difficult.
[0018] To address the above issues, the embodiments described in this application utilize a process engine and a Drools rule engine to achieve automatic task approval. This approach enables real-time monitoring of database rule changes and dynamic compilation and generation of rule files. It allows for rule iteration without modifying business code or restarting the service, reducing the operational costs of rule updates. Specifically: A process engine is a software module in a business system responsible for defining, executing, and monitoring processes. Examples include Activiti and Flowable, which manage the lifecycle of tasks through pre-defined process models (such as BPMN diagrams), including task creation, state transitions, and branch condition checks.
[0019] As the infrastructure layer of the business system, the process engine is the underlying support of the business system. It is directly embedded in the business logic and is responsible for coordinating the entire process of a task from submission to completion.
[0020] When a user submits a task, the process engine intercepts the task event through an event listening mechanism (such as TaskListener) and triggers subsequent automation logic, such as calling the rules engine.
[0021] Next, based on the judgment result of the rule engine, the process engine decides whether the task should proceed to an automatic approval branch (end the process) or a manual approval branch (jump to a specified node).
[0022] The core functionalities of the process engine include the following: Process modeling is used to define approval nodes and conditional branches.
[0023] Task status management includes tasks that are pending approval, approved, or rejected.
[0024] Integration with external systems, such as calling rule engines and recording approval results.
[0025] Drools rule engine is a Java-based Business Rule Management System (BRMS) used to separate business logic (such as approval conditions) from code. It enables dynamic decision-making through declarative rules (DRL files) and supports capabilities such as complex condition judgments, rule priorities, and factual reasoning.
[0026] As a decision service layer of the business system, the Drools rules engine is an independent service or component that is called to execute approval logic. It does not directly manage task processes, but focuses on judging whether the conditions are met.
[0027] The Drools rule engine enables dynamic rule management. Rules can be stored in a database and updated by preloading or dynamically generating DRL files, allowing approval logic to be adjusted without modifying business code.
[0028] The Drools rule engine collaborates with the process engine, meaning that the output of Drools (such as approved=true) is received by the process engine and used as the basis for process branches.
[0029] The core functionalities of the Drools rule engine are as follows: Rule definitions, such as DRL files or database storage.
[0030] Fact matching compares task data with rule conditions.
[0031] Decision execution, such as returning approval results or triggering subsequent actions.
[0032] Furthermore, the collaboration between the process engine and the Drools rules engine and the business system is as follows: Users submit tasks through the business system, such as expense reimbursement approvals.
[0033] The workflow engine intercepts task events and extracts task data, such as amount and user ID.
[0034] The process engine calls the Drools rule engine, passing in task data as facts.
[0035] Drools loads the rule base (DRL file or database rules) and executes the matching logic: If the automatic approval criteria are met (e.g., amount < allowable reimbursement amount), it will return approved=true.
[0036] Otherwise, return approved=false.
[0037] The process engine uses the results from Drools: Automatic approval: End the process and record the approval result to the decision record layer (including rule matching details and task snapshot).
[0038] Automatic approval rejection: Redirects to the manual approval node, awaiting human intervention.
[0039] Regarding rule updates, business systems can dynamically adjust approval logic by modifying database rules or regenerating DRL files without restarting the service.
[0040] Therefore, the process engine acts as the process commander of the business system, responsible for task flow and branch selection. The Drools rule engine is the intelligent decision-making core of the business system, responsible for dynamically determining whether a task meets the conditions. The two collaborate through a model where the process engine triggers the rule engine—the rule engine returns the result—the process engine advances the process, achieving automated approval while supporting dynamic rule updates to adapt to business changes.
[0041] Specifically, for example, after the person seeking reimbursement fills out the reimbursement form and uploads the invoice in the financial system (corresponding to the business system) and clicks submit, the financial system first completes the invoice verification and basic information verification. After the verification is passed, a reimbursement form submission event is automatically generated, which carries core task data such as the reimbursement amount, the department of the person seeking reimbursement, and the invoice details.
[0042] The workflow engine uses a pre-defined global event listener to capture the submission event of this newly generated expense report in real time. Without intruding on or modifying the original expense report submission code, it can detect new tasks awaiting approval immediately.
[0043] The workflow engine creates a dedicated workflow instance for the expense report based on the preset expense report workflow definition template, binds all expense report data carried by the event to the instance, and completes all subsequent approval processes and rule verifications based on this instance.
[0044] Furthermore, by adding an event listener mechanism to intercept task events, non-intrusive extensions can be achieved without modifying the original submission logic of the business system. Custom approval logic can be inserted at key points in the process through event listeners, intercepting the task event the instant it is generated in the business system. Task data is extracted and process instances are created immediately, ensuring no pending approval tasks are missed and guaranteeing that all tasks enter the automatic approval chain. It also enables cross-system decoupling; the business system only needs to generate events normally without needing to be aware of subsequent process engine operations, avoiding strong binding between business code and process engine logic and reducing subsequent maintenance costs.
[0045] Step 102: The process engine extracts task data based on task events and binds the task data to the process instance. The task data is input by the user through the business system when submitting a task to be approved.
[0046] Next, the workflow engine directly reads all the fields attached to the intercepted expense report submission event and extracts all the expense data entered by the user when submitting, such as the name of the person seeking reimbursement, the department, the total amount of reimbursement, the invoice details, and the reason for the trip.
[0047] The process engine will write all the extracted expense data into the built-in data container of the newly created expense-specific process instance, achieving a strong binding between a single expense data and a single process instance. All subsequent automatic approval rule verifications and workflow node jumps will directly read the bound data in this instance, and there will be no data misalignment.
[0048] Step 103: The process engine calls the Drools rule engine to enable the Drools rule engine to monitor whether the automatic approval rules in the database have changed. When a change is detected, the engine pulls the latest automatic approval rules from the database and dynamically compiles them to generate an automatic approval rule file. The database is pre-configured with automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements.
[0049] Next, relying on the Drools engine's mechanism for autonomously monitoring database rule changes, the approval rules can be dynamically updated without modifying business code or restarting the service. The rule iteration process does not interrupt the ongoing approval processes such as expense reimbursement, achieving complete decoupling of rules and business logic, significantly reducing the operation and maintenance costs of rule adjustments, and flexibly adapting to the automatic approval condition change requirements in different scenarios.
[0050] Optionally, the automatic approval rules have corresponding global verification identifiers, and the database stores an automatic approval rule table that carries the automatic approval rules. In step 103, the Drools rule engine monitors whether the automatic approval rules in the database have changed, including: Step 1031: The Drools rule engine polls the automatic approval rule table stored in the database according to a preset time period, and compares the global verification identifier of the automatic approval rule loaded in the current cache with the global verification identifier of the automatic approval rule in the automatic approval rule table. Step 1032: When any automatic approval rule is inconsistent with the global verification identifier in the cache and the database, it is determined that the automatic approval rule in the database has been changed.
[0051] In the above embodiments of this application, the Drools engine polls the automatic approval rule table of the database at a preset period, for example, any number of seconds between 5 and 30 seconds, compares the global verification identifier of the rules in the local cache and the database, and determines that the rule has been changed if the identifier is inconsistent.
[0052] Optionally, in step 103, the Drools rule engine pulls the latest automatic approval rules from the database and dynamically compiles them to generate an automatic approval rule file, including: Step 1033: The Drools rule engine fully retrieves the field content of the latest automatic approval rules stored in the database; Step 1034: The Drools rule engine performs compliance verification on the automatic approval rules based on the retrieved field content, and assembles the compliant automatic approval rules into a structured rule script that conforms to the Drools syntax specification. Step 1035: The Drools rule engine calls the built-in rule compilation module to dynamically compile the assembled structured rule script into a rule bytecode file that can be directly loaded and executed by the process engine, thus obtaining the automatic approval rule file.
[0053] In the above embodiments of this application, taking the reimbursement scenario as an example, the Drools engine pulls all the structured fields of all reimbursement approval rules at once, such as the reimbursement amount threshold, applicable department, invoice verification requirements, travel day limit and other configuration fields, to completely obtain the latest rule configuration data.
[0054] Next, the process engine first verifies the retrieved fields, removes invalid rules with negative amounts or conflicting conditions, and then concatenates the compliant reimbursement rule fields into a standard DRL script according to Drools' IF-THEN syntax. For example, it assembles a structured rule text that conforms to the syntax rules, such as IF Reimbursement Amount ≤ 5000 AND Department is a regular employee THEN Trigger automatic approval.
[0055] Here, an employee level judgment condition can also be added. When the employee level judgment condition determines that the user submitting the task is a supervisor or above, it can be reviewed by a separate preset manual approval process. If it is a regular user, automatic approval can be triggered.
[0056] Next, the process engine calls the built-in drools-compiler module (rule compilation module) to dynamically compile the assembled DRL script (structured rule script) into rule bytecode directly in JVM memory, generating an automatic approval rule file that can be directly loaded and executed by the process engine. There is no need to generate physical files on the ground throughout the process, and the new rules can be used immediately for the automatic judgment of subsequent expense reports.
[0057] Optionally, in step 103, the latest automatic approval rules are retrieved from the database and dynamically compiled to generate an automatic approval rule file, including: Step 1036: The Drools rule engine pulls the latest automatic approval rules from the database and dynamically compiles them to generate automatic approval rule files, or directly preloads the latest automatic approval rule files stored in the database.
[0058] In the above embodiments of this application, the Drools rule engine can dynamically compile and generate automatic approval rule files, or it can directly load the latest automatic approval rule files.
[0059] Step 104: The Drools rule engine outputs a judgment result on whether the task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance.
[0060] Next, the Drools rule engine outputs a judgment result on whether the task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. This result is used to determine whether automatic approval can be performed in subsequent steps.
[0061] Optionally, in step 104, the Drools rule engine outputs a judgment result on whether the task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance, including: Step 1041: The Drools rule engine encapsulates the extracted full task data into standardized fact objects and loads them into its internal working memory. Step 1042: The Drools rule engine extracts all rule conditions defined in the loaded auto-approval rule file into the agenda queue; Step 1043: The Drools rule engine performs pattern matching between the fact objects in the working memory and the rule conditions in the agenda queue based on the Rete algorithm to verify whether the task data meets the rule conditions. Step 1044: When the task data fully matches all rule conditions, the Drools rule engine generates a judgment result that meets the automatic approval requirements. Step 1045: When the task data does not meet any of the rule conditions, the Drools rule engine generates a judgment result that does not meet the automatic approval requirements.
[0062] In the above embodiments of this application, the Drools rule engine maps and encapsulates the full reimbursement data (task data) bound to the process instance into an ApprovalFact standardized Java fact object, and inserts the object directly into the working memory inside the engine as the input carrier for subsequent rule matching.
[0063] Next, the Drools rules engine extracts the condition parts of all rules from the loaded automatic approval rules file for expense reimbursement and adds these unmatched rule conditions to the Agenda queue.
[0064] The Drools rule engine builds a two-layer matching network based on the Rete algorithm. First, it filters single-attribute conditions of expense reports through the Alpha network, and then completes multi-condition association verification through the Beta network, allowing fact objects to flow through network nodes and verifying whether the expense report data matches all rule conditions one by one.
[0065] When the expense claimant passes through all nodes of the Rete network and meets all preset rules such as "amount ≤ 5000, invoice verification passed, and travel days compliant", the engine directly generates a positive judgment result that meets the requirements for automatic approval.
[0066] If any condition of the reimbursement data is not met, such as the reimbursement amount exceeding the threshold or the invoice verification failing, the Drools rule engine immediately terminates the matching process, generates a reverse judgment result that does not meet the requirements of automatic approval, and directly jumps to the manual approval link.
[0067] Step 105: The process engine obtains the judgment result. When the judgment result shows that the task meets the automatic approval requirements, the process engine drives the process instance to perform the automatic approval operation.
[0068] Next, when the judgment result shows that the task meets the automatic approval requirements, the process engine drives the process instance to perform the automatic approval operation to realize the automatic approval of the task.
[0069] Optionally, in step 105, the process engine drives the process instance to perform automatic approval operations, including: Step 1051: The process engine obtains the current approval node of the task, updates the approval status of the current approval node to "approved", and records the operation log and approval timestamp of the task being automatically approved. Step 1052: The process engine determines whether there are subsequent approval nodes after the current approval node; Step 1053: If there are no subsequent approval nodes, the process engine will update the status of the process instance to "completed". Step 1054: If there are subsequent approval nodes, the process engine will automatically activate the pending tasks of the next approval node and transfer the process instance to the next approval node to continue execution until all approval processes corresponding to the task are completed.
[0070] In the above embodiments of this application, the process engine locates the department head approval node of the current expense report, marks the node status as automatically approved, and writes it to the log synchronously. The log content is as follows: the system automatically approved, the rule is: ordinary employees' expense reports under 5,000 yuan are exempt from manual approval, and the current approval timestamp is recorded to the second.
[0071] The process engine reads the process definition template corresponding to the expense report and verifies whether subsequent approval nodes such as financial review are configured after the current node.
[0072] If the 3,000 yuan travel expense reimbursement form has no subsequent nodes, the process engine will directly update the status of the corresponding process instance to "completed" (finished), triggering the subsequent payment notification.
[0073] If the purchase reimbursement form of 4,800 yuan has a subsequent financial review node, the engine will automatically generate a pending task for the finance department, transfer the process instance to the finance node, and wait for the finance personnel to complete the subsequent verification.
[0074] Optionally, the method further includes: Step 106: When the judgment result shows that the task does not meet the requirements for automatic approval, the process engine drives the process instance to automatically flow to the preset manual approval stage.
[0075] In the above embodiments of this application, if the task does not meet the requirements for automatic approval, the process engine drives the process instance to automatically flow to the preset manual approval stage, without affecting the overall approval process.
[0076] In one specific embodiment, the automatic task approval process may involve the following three levels: The rule execution layer is used to introduce the Drools rule engine to dynamically generate DRLs or preload rule files from the database.
[0077] The Activiti extension layer is used to intercept task creation events through TaskListener and inject automatic approval logic.
[0078] The decision logging layer is used to record the rule matching details and fact snapshots for each automatic approval.
[0079] Specifically, such as Figure 2As shown, when a user submits a task awaiting approval, such as a travel expense reimbursement application, including information such as amount, reason, and attachments, the workflow engine (Activiti) listens for task events through TaskListener and automatically calls the rules engine (Drools) to execute rule judgments. At this time, the rules engine loads the latest automatic approval rules from the database, such as "automatically approve when the reimbursement amount for ordinary employees is ≤5000 yuan and there are no abnormal attachments." Rules can be updated through the "Rule Change" operation and dynamically loaded into the rules engine by "Scheduled Tasks" to ensure that the rules take effect in real time.
[0080] The rules engine performs rule matching based on the expense (task) data submitted by the user (such as an amount of 3800 yuan and compliant attachments): If the rules are met: the process enters the "automatic approval" node, automatically completes the approval, such as marking the expense report as "automatically approved", and writes the decision log, including the approval time, rule basis, operator "system", into the database; If the rules are not met: the process will be moved to the "manual approval" node, where the department head or finance personnel will manually review the application.
[0081] Ultimately, regardless of whether the approval is completed automatically or manually, the process enters the "end" node, marking the closure of the task approval process.
[0082] Specifically, the interaction specifications for key components are as follows: When a company adjusts its approval rules, such as raising the automatic approval threshold from 5,000 yuan to 8,000 yuan, it can modify the rule configuration in the database through the "Rule Change" operation. The scheduled task will automatically load the new rule into the rule engine without restarting the system. All operations of automatic approval (rule matching results, approval time, system identifier) are recorded in the database, supporting subsequent auditing and traceability.
[0083] This process, through the collaboration of the process engine and the rule engine, enables the automatic processing of tasks that conform to the rules, thereby improving approval efficiency; at the same time, it retains the manual approval channel to ensure flexible handling of special scenarios.
[0084] Specifically, the automatic approval rules include the following content, as shown in Table 1.
[0085] Table 1
[0086] The approval decision log table, which records operation logs and approval timestamps, is shown in Table 2.
[0087] Table 2
[0088] Regarding the decision log recording, AOP can be used to implement logging, ensuring that asynchronous database storage does not affect the performance of the main process and fully records the automatic approval decision process.
[0089] In another specific embodiment, the automatic task approval method of this application can also be used for software version release orders in different environments. A "tiered approval mechanism" is specifically designed to automatically determine the approval method for each release order through a preset priority order, including automatic approval and manual approval. This can ensure the security of the production environment, improve the release efficiency in low-risk environments, and set up a fallback mechanism to avoid process omissions. Specifically, the tiered approval mechanism may include the following types of situations: Approval forms issued from the production environment (equivalent to tasks submitted by users through the business system for approval) have the highest priority. Once a version release form is submitted to the production environment, it is directly determined that manual approval is required and automatic approval is not allowed, thus avoiding the risks of online releases from the process perspective.
[0090] Approval forms for test environment releases have a lower priority. As long as the release form is valid for either of the two types of regular test environments, it will be automatically approved without manual intervention, which can speed up the release process in the test phase.
[0091] Approval forms released in the development environment have a slightly lower priority than those released in the testing environment. As long as the approval form is validly released in the development environment, it will be automatically approved without review, which is suitable for the high-frequency iteration needs of the development stage.
[0092] The default approval scenario has the lowest priority. If none of the previous specific scenarios are met, this rule will be automatically triggered, and the issued approval form will be converted to manual approval. This ensures that all submitted approval forms can enter the compliance process and there will be no situation where no judgment result is obtained.
[0093] Furthermore, the rules engine first matches the environment type of the published approval form in descending order of preset priority. It first checks whether it is a production environment. If it is, it proceeds directly to manual approval. If it is not, it checks whether it is a test environment. If it is, it is automatically approved. Then it checks whether it is a development environment. If it is, it is approved without review. If none of the above conditions are met, the fallback rule is automatically triggered to transfer to manual approval. Finally, the corresponding approval result record is generated, completing the entire judgment process.
[0094] Currently, common solutions for automating process node approval in the industry include adding conditional gateways during process design, configuring skip expressions, or using automatic timeout skip mechanisms. However, these solutions have significant drawbacks, such as high invasiveness, poor flexibility, and difficulty in auditing, as follows: Business rules are implemented through hard coding, and iterating on business rules requires modifying the code, resulting in high development costs. When business rules change, such as changes in approvers or approval conditions, it is often necessary to redefine the process and redeploy it, resulting in high maintenance costs. At the same time, the automatic approval log is incomplete, making it difficult to trace back to the specific scenario at that time.
[0095] Furthermore, in real-world business scenarios, the need for automated approval processes often exhibits dynamic and uncertain characteristics. For example, when an approval step is unnecessary in the current business context, it's necessary to dynamically determine whether to skip that step based on business parameters. Existing automated approval technologies have significant shortcomings in the following aspects: Iterating business rules requires modifying the code, and the development cycle for changing a set of rules is relatively long, making it difficult to adapt to the "high frequency and uncertainty" characteristics of business changes.
[0096] Business rules are tightly bound to process definitions, making it difficult to dynamically determine skip conditions based on runtime business context. The judgment logic of condition gateways and skip expressions is predefined at the process definition level. After process deployment, it is difficult to flexibly adjust the skip strategy based on runtime business data (such as changes in approver identity, whether business approval rules are adjusted, etc.), and changes to business rules require modification of the process definition and redeployment.
[0097] There is a lack of robust audit trail mechanisms after a node is skipped. Activiti's SkipExpression solution does not generate any log records by default when automatically skipping nodes, making it difficult to trace the operation records of automatic approvals.
[0098] In summary, existing automated approval technologies for workflow processes based on Activiti have significant shortcomings in terms of flexibility, dynamic adaptability, and non-intrusiveness.
[0099] By applying the technical solution of this embodiment, the Drools rule engine is introduced to replace the traditional hard-coded implementation of business logic. Business rules are independent of process definitions, and rule changes do not require code modification. The Drools rule engine supports hot reloading and dynamic activation. It can read rules from the database every 30 seconds and dynamically generate DRLs (Automatic Approval Rule Files), then hot-load them into the Drools KieContainer. This allows running process tasks to dynamically adjust and complete approval based on rule conditions without redeploying the process. Furthermore, it can completely record the automatic approval decision-making process, that is, record detailed data for each automatic approval, meeting auditing requirements.
[0100] Furthermore, as Figure 1 To specifically implement the method, this application provides an automatic task approval system, such as... Figure 3As shown, this is applied to a business system built on a process engine framework. The business system is equipped with a database and integrated with the Drools rule engine. The system includes: The process instance creation module 201 is used to intercept the task event through an event listening mechanism when a user submits a task to be approved through the business system, triggering the business system to generate a task event, and to create a process instance for the task to be approved; extract task data based on the task event, and bind the task data to the process instance, wherein the task data is input by the user through the business system when submitting the task to be approved; The rule dynamic compilation module 202 is used to monitor whether the automatic approval rules in the database have changed, and when a change is detected, it pulls the latest automatic approval rules from the database and dynamically compiles them to generate an automatic approval rule file. The database is pre-configured with automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements. The automatic approval module 203 is used to output a judgment result on whether the task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. When the judgment result shows that the task meets the automatic approval requirements, it drives the process instance to perform automatic approval operation.
[0101] It should be noted that other corresponding descriptions of the functional units involved in the automatic task approval system provided in this application embodiment can be found in the following references. Figures 1 to 2 The corresponding descriptions in the method will not be repeated here.
[0102] Based on the above, Figures 1 to 2 Accordingly, this application also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-described method. Figures 1 to 2 The method for automatically approving tasks is shown.
[0103] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.
[0104] Based on the above, Figures 1 to 2 The method shown, and Figure 3To achieve the above objectives, the virtual system embodiment shown in this application also provides a computer device, specifically a personal computer, server, network device, etc. This computer device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to achieve the above-described objectives. Figures 1 to 2 The method for automatically approving tasks is shown.
[0105] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB ports, card reader ports, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.
[0106] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.
[0107] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages and stores the hardware and software resources of a computer device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software within the physical device.
[0108] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. The process engine intercepts task events, creates process instances and binds task data. The Drools rule engine monitors the automatic approval rules in the database. When changes occur, it pulls the latest automatic approval rules and dynamically compiles them to generate an automatic approval rule file. Based on the rule conditions in the automatic approval rule file and the task data bound to the process instance, the Drools rule engine outputs a judgment result indicating whether the task meets the automatic approval requirements. The process engine obtains the judgment result, and when the judgment result shows that the task meets the automatic approval requirements, the process engine drives the process instance to execute the automatic approval operation. By monitoring database rule changes in real time and dynamically compiling and generating rule files, Drools can complete the approval rule iteration without modifying business code or restarting the service, reducing the operational costs of rule updates.
[0109] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the system of the embodiment scenario can be distributed throughout the system of the embodiment scenario as described, or they can be modified to reside in one or more systems different from this embodiment scenario. The modules of the above-described embodiment scenario can be combined into one module, or further divided into multiple sub-modules.
[0110] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any modifications that can be made by those skilled in the art should fall within the protection scope of this application.
Claims
1. A method for automatic task approval, characterized in that, Applied to business systems built on a process engine framework, wherein the business system is equipped with a database and integrated with the Drools rule engine, the method includes: When a user submits a task pending approval through the business system, triggering the business system to generate a task event, the process engine intercepts the task event through the event listening mechanism and creates a process instance for the task pending approval. The process engine extracts task data based on task events and binds the task data to the process instance. The task data is input by the user through the business system when submitting a task to be approved. The process engine calls the Drools rule engine to enable the Drools rule engine to monitor whether the automatic approval rules in the database have changed. When a change is detected, the Drools rule engine pulls the latest automatic approval rules from the database and dynamically compiles and generates an automatic approval rule file. The database has pre-configured automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements. The Drools rule engine outputs a judgment result on whether a task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. The process engine obtains the judgment result. When the judgment result shows that the task meets the automatic approval requirements, the process engine drives the process instance to perform automatic approval operation.
2. The method according to claim 1, characterized in that, Each automatic approval rule has a corresponding global validation identifier. The database stores an automatic approval rule table containing these rules. The Drools rule engine monitors whether the automatic approval rules in the database have changed, including: The Drools rule engine polls the automatic approval rule table stored in the database at preset time intervals, and compares the global verification identifier of the automatic approval rule currently loaded in the cache with the global verification identifier of the automatic approval rule in the automatic approval rule table. If any automatic approval rule is inconsistent with the global validation identifier in the cache and the database, it is determined that the automatic approval rule in the database has been changed.
3. The method according to claim 1, characterized in that, The Drools rule engine pulls the latest auto-approval rules from the database and dynamically compiles them into auto-approval rule files, including: The Drools rule engine fully retrieves the field content of the latest auto-approval rules stored in the database; The Drools rule engine performs compliance checks on the automatically approved rules based on the retrieved field content, and assembles the compliant automatically approved rules into a structured rule script that conforms to the Drools syntax specification. The Drools rule engine calls the built-in rule compilation module to dynamically compile the assembled structured rule script into rule bytecode files that can be directly loaded and executed by the workflow engine, thus obtaining the automatic approval rule file.
4. The method according to claim 1, characterized in that, The process engine drives process instances to perform automatic approval operations, including: The workflow engine obtains the current approval node of the task, updates the approval status of the current approval node to "approved", and records the operation log and approval timestamp of the task being automatically approved. The workflow engine determines whether there are subsequent approval nodes after the current approval node; If there are no subsequent approval nodes, the process engine will update the status of the process instance to "completed". If there are subsequent approval nodes, the workflow engine will automatically activate the pending tasks for the next approval node and transfer the workflow instance to the next approval node to continue execution until all approval processes corresponding to the task are completed.
5. The method according to claim 1, characterized in that, The Drools rule engine outputs a judgment result on whether a task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance, including: The Drools rules engine encapsulates the extracted full task data into standardized fact objects and loads them into its internal working memory. The Drools rule engine extracts all rule conditions defined in the loaded auto-approval rule file into the agenda queue; The Drools rule engine uses the Rete algorithm to perform pattern matching between fact objects in the working memory and rule conditions in the agenda queue to verify whether task data meets the rule conditions. When the task data fully matches all rule conditions, the Drools rule engine generates a judgment result that meets the requirements for automatic approval; When the task data does not meet any of the rule conditions, the Drools rule engine generates a judgment result that does not meet the requirements for automatic approval.
6. The method according to claim 1, characterized in that, The latest automatic approval rules are retrieved from the database and dynamically compiled to generate an automatic approval rule file, including: The Drools rule engine pulls the latest auto-approval rules from the database and dynamically compiles them into auto-approval rule files, or directly preloads the latest auto-approval rule files stored in the database.
7. The method according to claim 1, characterized in that, The method further includes: When the judgment result shows that the task does not meet the requirements for automatic approval, the process engine drives the process instance to automatically flow to the preset manual approval stage.
8. An automatic task approval system, characterized in that, This is applied to business systems built on a process engine framework, wherein the business system is equipped with a database and integrated with the Drools rule engine, and the system includes: The process instance creation module is used to intercept the task event through an event listening mechanism when a user submits a task to be approved through the business system, triggering the business system to generate a task event, and create a process instance for the task to be approved; extract task data based on the task event, and bind the task data to the process instance, wherein the task data is input by the user through the business system when submitting the task to be approved; The rule dynamic compilation module is used to monitor whether the automatic approval rules in the database have changed. When a change is detected, the module pulls the latest automatic approval rules from the database and dynamically compiles them to generate an automatic approval rule file. The database is pre-configured with automatic approval rules, and the automatic approval rule file includes rule conditions for determining whether a task meets the automatic approval requirements. The automatic approval module is used to output a judgment result on whether a task meets the automatic approval requirements based on the rule conditions in the automatic approval rule file and the task data bound in the process instance. When the judgment result shows that the task meets the automatic approval requirements, it drives the process instance to perform automatic approval operation.
9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for automatic task approval as described in any one of claims 1 to 7.
10. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for automatic task approval as described in any one of claims 1 to 7.
