Rule compiling optimization method and device, computer equipment and readable storage medium

Abstract

The invention relates to a rule compiling optimization method and device, computer equipment and a readable storage medium. The method comprises the following steps: extracting complete meta-information and a dependency list of each rule in a rule source code file; generating a rule node corresponding to each rule and a dependency item node of a dependency item in the dependency list corresponding to the rule according to the complete meta-information and the dependency list, and constructing a dependency edge according to a dependency relationship between all the rule nodes and all the dependency item nodes to obtain a dependency graph; if it is monitored that the rule source code file is updated, determining a corresponding change node from the dependency graph, determining a target node influenced by the change node from the dependency graph based on the change node, and determining a to-be-compiled rule subset according to the target node and incremental data corresponding to updating; and compiling the to-be-compiled rule subset, and merging an obtained compiling result into a byte code warehouse corresponding to the rule source code file. By adopting the method, the compiling efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a rule compilation optimization method, apparatus, computer device, and readable storage medium. Background Technology

[0002] In enterprise-level rule-based decision management platforms (such as financial risk control rule platforms and e-commerce promotion rule platforms), rules are typically defined in domain-specific languages ​​and need to be converted into Java bytecode for execution. When the number of rules reaches thousands or tens of thousands and is updated more than a hundred times per day, the traditional full-scale compilation model has significant drawbacks, resulting in low compilation efficiency.

[0003] Therefore, a rule-based compilation optimization method is needed to improve compilation efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a rule compilation optimization method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve compilation efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a rule compilation optimization method, including:

[0006] Obtain the rule source code file, and extract the complete meta-information and dependency list of each rule in the rule source code file;

[0007] For each rule, generate a rule node corresponding to each rule and a dependency node of the dependency item in the dependency list corresponding to the rule. Based on the dependency relationship between all the rule nodes and all the dependency nodes, construct dependency edges to obtain a dependency graph.

[0008] If an update to the rule source code file is detected, the incremental data of the rule source code file is determined.

[0009] From the dependency graph, determine the change node corresponding to the incremental data; based on the change node, determine the target node affected by the change node from the dependency graph; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0010] The subset of rules to be compiled is compiled to obtain the compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0011] In one embodiment, obtaining the rule source code file and extracting the complete meta-information and dependency list of each rule in the rule source code file includes:

[0012] Obtain the rule source code file, perform lexical and syntactic analysis on the rule source code file, and generate the corresponding abstract syntax tree;

[0013] Traverse the abstract syntax tree to extract complete meta-information of each rule; the complete meta-information includes at least the rule identifier.

[0014] Static dependency data is obtained by performing static analysis on the abstract syntax tree, and actual dependency data is obtained by simulating the execution process of the abstract syntax tree using a preset lightweight rule execution simulator. The static dependency data includes the fully qualified names and signatures of all referenced global methods, and the actual dependency data includes all other rules and global methods called at runtime.

[0015] The dependency list corresponding to each rule is determined based on the static dependency data and the actual dependency data.

[0016] In one embodiment, the step of constructing dependency edges to obtain a dependency graph based on the dependency relationships between all the rule nodes and all the dependency item nodes includes:

[0017] For each rule node among all the rule nodes, construct dependency edges based on the corresponding dependency nodes among all the dependency nodes to obtain an initial dependency graph;

[0018] For the rule nodes and / or dependency nodes in the initial dependency graph, a breadth-first search is used to calculate the complete dependency chain of each node, identify indirect dependencies and construct the corresponding dependency edges to obtain the dependency graph; the nodes are rule nodes or dependency nodes.

[0019] In the dependency graph, the dependency edges are used to represent the dependency relationships between nodes, and the edge attributes include the dependency type, dependency strength, and dependency source of the dependency relationship.

[0020] In one embodiment, determining the incremental data of the rule source code file if an update is detected includes:

[0021] The rule source code file is monitored by file listening and code comparison to determine the change type of the rule source code file; the change type includes rule change, method change, non-dependent impact change that indicates only the internal implementation logic of the method is modified and the signature remains unchanged, and dependent impact change that indicates that the method signature, exception declaration or return value type has changed;

[0022] Determine the incremental data corresponding to the change type.

[0023] In one embodiment, determining the target node dependent on the changed node from the dependency graph, and determining the subset of rules to be compiled based on the target node and the incremental data, includes:

[0024] Based on the dependency relationships between nodes in the dependency graph, a forward traversal is performed based on the changed node to determine the target node that depends on the changed node; the changed node is the rule node and / or the dependency node.

[0025] The subset of rules to be compiled is determined based on the target node and the incremental data.

[0026] In one embodiment, determining the subset of rules to be compiled based on the target node and the incremental data includes:

[0027] A subset of candidate rules to be compiled is determined based on the rules corresponding to the target node and the rules corresponding to the incremental data.

[0028] The candidate subset of rules to be compiled is filtered out, and rules that depend only on non-dependent impactful changes are removed, thus obtaining the subset of rules to be compiled.

[0029] In one embodiment, the step of compiling the subset of rules to be compiled to obtain a compilation result, and merging the compilation result into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file includes:

[0030] The compilation units are obtained by segmenting the rules in the subset of rules to be compiled based on their dependencies.

[0031] Distributed compilation is performed on each of the aforementioned compilation units to obtain their respective compilation results;

[0032] The compilation result is determined based on the compilation results described above, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0033] In one embodiment, the step of segmenting according to the dependencies of each rule to be compiled in the subset of rules to be compiled to obtain multiple compilation units includes:

[0034] A task graph is constructed based on the compile-time dependencies between the rules to be compiled in the subset of rules to be compiled; the nodes in the task graph are the rules to be compiled, and the edges connecting the nodes are the compile-time dependencies.

[0035] Based on the compile-time dependencies between the rules to be compiled in the task graph, the rules to be compiled in the task graph are topologically sorted to obtain the compilation order among the rules to be compiled.

[0036] The compilation units are divided according to the compilation order of the rules to be compiled, resulting in multiple compilation units; there is no dependency between the rules to be compiled in each compilation unit.

[0037] In one embodiment, the distributed compilation of each compilation unit to obtain its corresponding compilation result includes:

[0038] Based on a master-slave architecture, the master node of the master-slave architecture distributes each compilation unit to an idle compilation node and obtains the compilation results of each compilation node; each compilation node has a unified dependency library and environment image.

[0039] In one embodiment, before compiling the subset of rules to be compiled to obtain the compilation result, the method further includes:

[0040] Based on the dependency graph, the source code file of the rule is subjected to dependency error detection to determine an error report of the dependency error; the error report includes the specific context and repair strategy of the erroneous dependency; the dependency error detection includes at least one of missing dependency detection, circular dependency detection and version conflict detection.

[0041] Specifically, the missing dependency detection involves comparing the actual dependency data in the dependency list with the dependencies declared in the rule source code file to detect whether there are any undeclared dependencies; the circular dependency detection involves performing circular dependency detection on the subgraphs of the dependency graph; and the version conflict detection involves checking whether the global method version referenced by the rule is compatible with the version currently deployed on the platform.

[0042] Secondly, this application also provides a rule compilation optimization apparatus, comprising:

[0043] The data extraction module is used to obtain the rule source code file and extract the complete meta-information and dependency list of each rule in the rule source code file;

[0044] The graph construction module is used to generate rule nodes corresponding to each rule and dependency nodes of the dependencies in the dependency list corresponding to the rule for each rule, and to construct dependency edges based on the dependency relationships between all rule nodes and all dependency nodes to obtain a dependency graph.

[0045] The module for determining the subset of rules to be compiled is used to determine the incremental data of the rule source code file if an update is detected in the rule source code file; determine the change node corresponding to the incremental data from the dependency graph; determine the target node affected by the change node from the dependency graph based on the change node; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0046] The compilation module is used to compile the subset of rules to be compiled to obtain the compilation result, and merge the compilation result into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0047] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0048] Obtain the rule source code file, and extract the complete meta-information and dependency list of each rule in the rule source code file;

[0049] For each rule, generate a rule node corresponding to each rule and a dependency node of the dependency item in the dependency list corresponding to the rule. Based on the dependency relationship between all the rule nodes and all the dependency nodes, construct dependency edges to obtain a dependency graph.

[0050] If an update to the rule source code file is detected, the incremental data of the rule source code file is determined.

[0051] From the dependency graph, determine the change node corresponding to the incremental data; based on the change node, determine the target node affected by the change node from the dependency graph; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0052] The subset of rules to be compiled is compiled to obtain the compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0053] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0054] Obtain the rule source code file, and extract the complete meta-information and dependency list of each rule in the rule source code file;

[0055] For each rule, generate a rule node corresponding to each rule and a dependency node of the dependency item in the dependency list corresponding to the rule. Based on the dependency relationship between all the rule nodes and all the dependency nodes, construct dependency edges to obtain a dependency graph.

[0056] If an update to the rule source code file is detected, the incremental data of the rule source code file is determined.

[0057] From the dependency graph, determine the change node corresponding to the incremental data; based on the change node, determine the target node affected by the change node from the dependency graph; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0058] The subset of rules to be compiled is compiled to obtain the compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0059] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0060] Obtain the rule source code file, and extract the complete meta-information and dependency list of each rule in the rule source code file;

[0061] For each rule, generate a rule node corresponding to each rule and a dependency node of the dependency item in the dependency list corresponding to the rule. Based on the dependency relationship between all the rule nodes and all the dependency nodes, construct dependency edges to obtain a dependency graph.

[0062] If an update to the rule source code file is detected, the incremental data of the rule source code file is determined.

[0063] From the dependency graph, determine the change node corresponding to the incremental data; based on the change node, determine the target node affected by the change node from the dependency graph; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0064] The subset of rules to be compiled is compiled to obtain the compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0065] The aforementioned rule compilation optimization method, apparatus, computer equipment, computer-readable storage medium, and computer program product extract the complete meta-information and dependency list of each rule from the rule source code file. Based on the complete meta-information and dependency list of each rule, they define the nodes and edges of the dependency graph to obtain a constructed dependency graph. When an update to the rule source code file is detected, the incremental data of the rule source code file is determined, and the changed nodes corresponding to the incremental data are identified from the dependency graph. Based on the changed nodes, the target nodes affected by the changed nodes are identified from the dependency graph. Based on the target nodes and the incremental data, a subset of rules to be compiled is determined. The subset of rules to be compiled is then compiled to obtain the compilation result, which is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file. This method determines the dependency scope based on the construction of the dependency graph and only compiles its dependency scope, avoiding full compilation and significantly improving compilation efficiency. Attached Figure Description

[0066] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 This is a flowchart illustrating the rule compilation optimization method in one embodiment;

[0068] Figure 2 This is a schematic diagram of the dependency graph structure in one embodiment;

[0069] Figure 3 This is a flowchart illustrating the compilation method for a subset of rules to be compiled in one embodiment;

[0070] Figure 4 This is a flowchart illustrating the method for partitioning a subset of rules to be compiled in one embodiment;

[0071] Figure 5 This is an overall flowchart of incremental compilation and dependency error detection in one embodiment;

[0072] Figure 6 This is an overall architecture diagram of the rule compilation optimization method in one embodiment;

[0073] Figure 7 This is a block diagram of the rule compilation optimization device in one embodiment;

[0074] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0075] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0076] In enterprise-level rule decision management platforms, when the number of rules reaches thousands or tens of thousands and is updated more than a hundred times per day, a traditional full compilation mode is used. However, rule decision management platforms typically use a full compilation mode, which requires recompiling all rules for each update. When the number of rules reaches thousands, a single compilation takes more than 10 minutes, which cannot meet the needs of real-time business updates. Moreover, full compilation repeatedly processes unchanged rules, resulting in peak CPU utilization exceeding 60% and memory consumption reaching tens of GB, leading to resource waste.

[0077] Furthermore, the call relationships between rules are complex, and the reference relationships between rules and global Java methods are also quite complex. In traditional compilation methods, missing dependencies (rules / methods not actually called) and redundant dependencies (declared but not used dependencies) are often exposed at runtime, leading to high troubleshooting costs. To address this issue, dependency error detection is usually performed at runtime, resulting in long error detection times, high online failure rates, and insufficient dependency error detection. In addition, in distributed environments, the configuration of remote hosts differs from the development environment, causing software dependencies to become problematic. Missing dependencies or incompatible dependency versions at runtime can cause applications to malfunction or even generate silent errors. Although static binaries can package all dependencies together, some applications (such as those using closed-source libraries) are difficult to compile statically. Docker containers: While applications and their dependencies can be packaged in a single container, deploying the Docker engine in a heterogeneous distributed environment requires administrator privileges, which is unlikely to be implemented in the core HPC infrastructure of most scientific computing experiments. Generating re-executable applications from third-party applications: Although a new bundle can be generated by collecting all dependencies, this method has certain complexities and limitations in practical applications.

[0078] Therefore, to address the technical problem of low compilation efficiency in the above-mentioned problems, a rule-based compilation optimization method is proposed.

[0079] In one embodiment, such as Figure 1 As shown, a rule compilation optimization method is provided. This embodiment illustrates the method's application to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0080] Step 102: Obtain the rule source code file and extract the complete meta-information and dependency list of each rule from the rule source code file.

[0081] The rule source code file can be, but is not limited to, a Java DSL rule source code file. A rule source code file is a file containing specific rule logic code. It can define a series of rules and conditions based on different application scenarios and purposes to achieve specific functions or goals. Complete rule metadata includes at least the rule identifier (i.e., rule ID), input parameters, output type, last modification time, and business scenario. The output type can be, but is not limited to, an enumeration type; the business scenario can be, but is not limited to, transaction risk control; and the input parameters can be, but are not limited to, user ID and transaction amount.

[0082] For example, the rule source code file includes Rule A and Rule B. Rule A (Large Transaction Rule): If a single transaction amount > 100,000 yuan, the risk level is high. Rule B (Suspicious Transaction Reporting Rule): If the risk level is high and the transaction location is overseas, a report is triggered; the judgment of Rule B depends on the result of Rule A. Extracting the metadata from these two rules yields the following: Rule ID: RULE_A; Input parameter: (transactionAmount: Double), requiring "transaction amount" as input; Output type: RiskLevel, representing the output as "risk level"; Last modified time: 2024-01-01 10:00:00; Business scenario: Anti-fraud.

[0083] It's important to note that while complete metadata extraction can be achieved, but is not limited to, existing methods, this example focuses not on the extraction method itself, but on incremental rule compilation to extract the set complete metadata. This allows for precise and efficient impact analysis and compilation. For example, a business user wants to change the threshold of rule A from 100,000 yuan to 50,000 yuan. The change is triggered (using "last modified time"): the intelligent system detects that the "last updated time" of rule A's file has changed, indicating it has been modified. Impact analysis is performed based on input parameters and output type: Since the output type is "risk level," the system queries the "dependency graph" and finds that rule B's input conditions require a "risk level." Therefore, it can be accurately inferred that rule B depends on rule A, and if rule A is modified, rule B likely needs to be re-checked. Precise compilation (using "rule ID"): rule A (the modified rule) and rule B (the affected rule) are identified and sent to the "compilation workshop" for rapid processing. After compilation, the report will show: "The rule compilation for this 'anti-fraud' business scenario took only 30 seconds."

[0084] The dependency manifest includes static dependency data and actual dependency data. Static dependency data includes the fully qualified names and signatures of all referenced global methods. Actual dependency data can include other rules and global methods dynamically invoked through reflection, string concatenation, or conditional branches. The complete meta-information of each rule and the dependency manifest are used to lay the data foundation for building the dependency graph.

[0085] The complete meta-information and dependency list of each rule can be extracted by performing lexical and syntactic analysis on the source code file using Java DSL syntax rules defined by ANTLR (a powerful parser generation tool), generating an abstract syntax tree (AST), and then identifying the AST and simulating the execution process through a rule execution simulator.

[0086] For example, obtain the rule source code file, and extract the complete meta-information of each rule in the rule source code file that represents identity information and the dependency list that represents dependency relationship.

[0087] Step 104: For each rule, based on the complete meta-information and dependency list, generate the rule node corresponding to each rule and the dependency node of the dependency item in the dependency list corresponding to the rule. Based on the dependency relationship between all rule nodes and all dependency nodes, construct dependency edges to obtain the dependency graph.

[0088] Understandably, before constructing the dependency graph, the graph structure needs to be designed first. The nodes in this graph structure include rule nodes and method nodes. For example, a rule node might be named `R_ruleID` (e.g., `R_RULE_001`), and a method node might be named `M_fully qualified method name_method signature` (e.g., `M_com.bsfit.utils.DateTool.getCurrentWeek__()`). Edges represent the dependencies between nodes, and the direction of the edge represents the caller pointing to the callee. Edge attributes include dependency type (direct dependency / indirect dependency), dependency strength (strong dependency / weak dependency), where a strong dependency indicates a necessary path in the execution path, and a weak dependency indicates a dependency under a specific branch (a dependency under a specific branch refers to a dependency required by the software project in a specific branch of the version control system), and dependency source (actual dependency from the rule execution simulator). Dependency nodes can also be called method nodes.

[0089] For example, for each rule, based on the complete metadata and dependency list, a corresponding node is created for each rule and each dependency in its dependency list. Then, edges are established based on the dependency relationships between rule nodes and dependency nodes. Furthermore, breadth-first search (BFS) is used to compute the transitive closure of each node, identify the indirect dependencies between nodes, and establish edges corresponding to the indirect dependencies to obtain the constructed dependency graph. For example, the complete metadata can be used as the node information for rule nodes, which may include rule identifiers.

[0090] Step 106: If an update to the rule source code file is detected, determine the incremental data of the rule source code file.

[0091] Updates to the rule source code file can be rule changes, method changes, changes affecting non-dependencies, or changes affecting strong dependencies. For rule changes, file creation, modification, and deletion events can be captured using file listeners (such as WatchService) or version control system hooks. Changes are confirmed by comparing file hashes or timestamps. For method changes, for Java class files, bytecode manipulation frameworks (such as ASM) are used for comparison to determine if the change affects interface compatibility. Changes affecting non-dependencies involve modifications to the internal implementation logic of the method, with the signature remaining unchanged. For example, optimizing the internal algorithm of getCurrentWeek. This type of change does not affect callers and does not require triggering dependency compilation. Changes affecting strong dependencies involve changes to the method signature, exception declaration, or return value type. For example, changing getCurrentWeek() to getCurrentWeek(String timezone). This type of change will break all callers.

[0092] Incremental data can be the differences resulting from changes to the rule source code file, including newly added, modified, or deleted rules and their metadata. Determining the incremental data in the rule source code file can, but is not limited to, comparing the old and new versions of the rule source code to identify the changed rule units and their specific content. Incremental data can be incremental data corresponding to newly added rules, incremental data corresponding to deleted rules, incremental data corresponding to method changes, etc.

[0093] In an exemplary embodiment, the rule source code file is monitored through file listening and code comparison to determine the change type of the rule source code file. Change types include rule changes, method changes, non-dependent impact changes (characterized by modifications to only the internal implementation logic of a method while the signature remains unchanged), and dependent impact changes (characterized by changes to the method signature, exception declaration, or return value type). Incremental data corresponding to the change type is then determined. This determination of incremental data can be achieved by parsing the change content.

[0094] Step 108: Determine the change nodes corresponding to the incremental data from the dependency graph, determine the target nodes affected by the change nodes from the dependency graph based on the change nodes, and determine the subset of rules to be compiled based on the target nodes and the incremental data.

[0095] For example, since rule nodes in the dependency graph have corresponding rule identifiers and method nodes in the dependency graph have corresponding method identifiers, the corresponding changed rule identifiers and / or method identifiers are determined based on the incremental data. Based on the changed rule identifiers and / or method identifiers, the changed nodes corresponding to the incremental data can be determined from the dependency graph. Based on the position of the changed node in the dependency graph, a forward traversal is performed to determine all rules that depend on this changed node, and the target node affected by the changed node is obtained. Based on the rules corresponding to the target node, or based on the rules corresponding to the target node and the newly added rules in the incremental data, a subset of rules to be compiled is determined.

[0096] Step 110: Compile the subset of rules to be compiled to obtain the compilation result, and merge the compilation result into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0097] It should be noted that the standard compilation process includes: preprocessing: converting the JavaDSL into standard Java source code; compilation: calling a compiler such as javac to compile the Java source code into bytecode (e.g., .class files); and output: updating the bytecode repository with the successfully compiled bytecode.

[0098] For example, based on the determined subset of rules to be compiled, only the subset of rules to be compiled is compiled to obtain the compilation result. For rules outside the subset, the historical compilation results are directly loaded from the bytecode cache, that is, the compilation results are merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file. This method greatly saves resources.

[0099] The aforementioned rule compilation optimization method extracts the complete meta-information and dependency list of each rule from the rule source code file. Based on the complete meta-information and dependency list of each rule, it defines the nodes and edges of the dependency graph to obtain a constructed dependency graph. When an update to the rule source code file is detected, the incremental data of the rule source code file is determined, and the changed nodes corresponding to the incremental data are identified from the dependency graph. Based on the changed nodes, the target nodes affected by the changed nodes are identified from the dependency graph. Based on the target nodes and the incremental data, a subset of rules to be compiled is determined. The subset of rules to be compiled is then compiled to obtain the compilation result, which is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file. This method determines the dependency scope based on the construction of the dependency graph and only compiles its dependency scope, avoiding full compilation and significantly improving compilation efficiency.

[0100] Optionally, in an exemplary embodiment, the rule source code file is obtained, and the complete meta-information and dependency list of each rule in the rule source code file are extracted, including:

[0101] The process involves: acquiring the rule source code file; performing lexical and syntactic analysis on the rule source code file to generate the corresponding abstract syntax tree (AST); traversing the AST to extract complete meta-information for each rule; the complete meta-information includes at least the rule identifier; performing static analysis on the AST to obtain static dependency data; and using a pre-defined lightweight rule execution simulator to simulate the execution process based on the AST to obtain actual dependency data; the static dependency data includes the fully qualified names and signatures of all referenced global methods, and the actual dependency data includes all other rules and global methods called at runtime; and determining the dependency list for each rule based on the static and actual dependency data.

[0102] The rule execution simulator is a tool used to simulate the rule execution process. The simulation process can include rule parsing, preparation of simulated input data, setting up the rule execution environment, rule execution simulation, and result output.

[0103] For example, using JavaDSL syntax rules defined by ANTLR (a powerful parser generation tool), lexical and syntactic analysis is performed on the rule source code files to generate an Abstract Syntax Tree (AST). The AST is traversed to extract complete meta-information for each rule, and static analysis is used to identify all import statements and global method call points, recording the fully qualified names and signatures of all referenced global methods to obtain static dependency data. For instance, if a call to `com.bsfit.utils.DateTool.getCurrentWeek()` is encountered in the rule code, then the node `M_com.bsfit.utils.DateTool.getCurrentWeek()_()` is recorded. For example, there is a financial risk control rule that checks for the risk of large transactions at night. The corresponding code includes some conditions, calls to a global utility method to determine whether it is nighttime, and calls to another global utility method to calculate the transaction fee rate. By parsing this code with tools such as ANTLR, a syntax tree (AST) is generated. Based on the analysis, it will be determined that com.bsfit.rules.util.TimeUtils.isNight(currentTime) and com.bsfit.rules.calc.FeeCalculator.getRate(transactionAmount,userLevel) are called.

[0104] Then logging (i.e., "marking") begins for the first call:

[0105] Fully qualified name: com.bsfit.rules.util.TimeUtils; Method signature: isNight(parameter type);

[0106] Here we need to analyze the type of the parameter currentTime. For example, if it is of type Date, the complete signature is: isNight(Date); the final recorded static dependency node is: M_com.bsfit.rules.util.TimeUtils.isNight(Date).

[0107] For the second call:

[0108] Fully qualified name: com.bsfit.rules.calc.FeeCalculator; Method signature: getRate(parameter1 type, parameter2 type); Analysis reveals that transactionAmount is Double and userLevel is String. The complete signature is: getRate(Double, String); The final recorded static dependency node is: M_com.bsfit.rules.calc.FeeCalculator.getRate(Double, String); Through static analysis, we can obtain two explicit static dependencies of this rule that are written in the code.

[0109] Building upon the static dependency data, since static analysis may fail to capture dynamic calls via reflection, string concatenation, or conditional branches, a lightweight rule execution simulator is designed to simulate the execution flow, intercepting all calls to other rules and global methods. This yields the actual dependency list for each rule, i.e., the actual dependency data, which is persisted to the dependency baseline library. It's important to understand that this simulator does not generate the final bytecode. For example, the actual dependency of RULE_001 is [RULE_002, M_com.bsfit.utils.DateTool.getCurrentWeek_()], meaning RULE_001 depends on the rule RULE_002 and the method M_com.bsfit.utils.DateTool.getCurrentWeek_().

[0110] It's important to note that ANTLR static analysis is the first step, forming the foundation for efficiently and quickly collecting "obvious dependencies." It resolves most common dependencies directly written in the code. However, for modern, complex business rule systems (especially highly dynamic scenarios like financial risk control), techniques such as reflection, dynamic loading, and conditional branching are widely used, resulting in a large number of "hidden" or "dynamic" dependencies. These dependencies are inherent blind spots for static analysis. Therefore, ANTLR (static analysis) is used first to collect all "white-box" and text-visible dependencies, serving as a draft dependency baseline. Then, dynamic analysis is performed, using a designed simulator to discover and complete all "gray-box" dependencies determined at runtime, and to verify dependency strength. The rule execution simulator determines the data required for simulation (i.e., simulated input) based on the requirements of the rules in the rule source code file. Then, through a closed loop of loading and listening, intercepting calls, recording and simulating returns, continuing execution, and generating a list, it dynamically captures dependencies to obtain the actual dependency list.

[0111] The actual dependency list can be represented as a structured list, including fields such as the precise identifier of the dependency target (fully qualified name + signature), dependency type (global method or other rules), dependency strength (key to determining whether recompilation is necessary), and call location (used for problem localization). Furthermore, this method of determining dependency data can clearly distinguish between dependencies determined by static analysis and those determined by dynamic analysis (e.g., reflection calls), and the "missing dependency" problem can be solved based on the actual dependency list.

[0112] In the above embodiments, the complete meta-information and dependency list of each rule in the rule source code file can be accurately determined through meta-information parsing, static dependency marking, and actual dependency collection, thereby ensuring the accuracy of the constructed dependency graph and avoiding the problem of missing dependencies.

[0113] In an exemplary embodiment, dependency edges are constructed based on the dependency relationships between all rule nodes and all dependency nodes to obtain a dependency graph, including:

[0114] For each rule node among all rule nodes, dependency edges are constructed based on their respective dependency nodes among all dependency nodes to obtain an initial dependency graph. For the rule nodes and / or dependency nodes in the initial dependency graph, a breadth-first search is used to compute the complete dependency chain of each node, identify indirect dependencies, construct the corresponding dependency edges, and obtain the dependency graph. Nodes are either rule nodes or dependency nodes. Among them, the dependency edges in the dependency graph are used to represent the dependency relationships between nodes, and the edge attributes include the dependency type, dependency strength, and dependency source of the dependency relationship.

[0115] In this context, a complete dependency chain can be called a transitive closure. It's important to note that a complete dependency chain ensures that when a method at the underlying level changes, the system can accurately and completely find all upstream rules that need to be recompiled, regardless of the chain's length, thus completely resolving dependency vulnerabilities. For example, rule A calls rule B, and rule B calls global method C. In diagram form, rule A directly depends on rule B, and rule B directly depends on method C. Without considering transitive closures, our dependency graph only records direct dependencies: A depends on [B], B depends on [C], and C depends on []. If method C changes (e.g., the interface changes), the system, by querying the graph, can only directly find the rule that depends on C, i.e., rule B. It will assume that only B needs to be recompiled, but this misses rule A. Because a change in B might affect A, it's necessary to find all direct and indirect dependencies of each rule, forming a complete dependency list.

[0116] The specific implementation of using breadth-first search to calculate the complete dependency chain of each node can be achieved through existing methods, and will not be elaborated here.

[0117] Furthermore, the graph has a corresponding real-time update mechanism. This mechanism can maintain a version number (such as MD5) and a last modification timestamp for each rule file and method class file in the rule source code. When a change is detected in a rule file or method class file, only a local update of the changed node and its associated edges is triggered, rather than rebuilding the entire graph, which greatly improves efficiency.

[0118] In one exemplary embodiment, such as Figure 2 The diagram shown illustrates the dependency graph structure. Rule node R_001 directly / strongly depends on rule node R_002; rule node R_002 indirectly / weakly depends on method node M_com.util.DateTool.getWeek; rule node R_001 directly / strongly depends on method node M_con.utils.MathUtil.calculate; rule node R_002 directly / strongly depends on method node M_con.utils.MathUtil.calculate; the input for rule node R_001 is userId (unique user identifier), and the output is riskLevel; the input for rule node R_002 is orderId (order ID), and the output is discount.

[0119] The aforementioned dependency graph construction, based on creating nodes and edges for each rule and each item in its dependency list, identifies indirect dependencies through indirect dependency calculation, ensuring that the scope to be compiled can be accurately determined when the rule source code file changes, thus avoiding omissions.

[0120] In an exemplary embodiment, the target node of the dependency change node is determined from the dependency graph based on the change node, and a subset of rules to be compiled is determined based on the target node and incremental data, including:

[0121] Based on the dependencies between nodes in the dependency graph, a forward traversal is performed based on the changed nodes to determine the target nodes that depend on the changed nodes; the changed nodes are rule nodes and / or dependency nodes; the subset of rules to be compiled is determined based on the target nodes and incremental data.

[0122] The target node that depends on the changed node can be a downstream node that directly and / or indirectly points to the changed node. For example, in the following way:

[0123] The function `downstream_rules = dependency_graph.get_all_nodes_that_depend_on(changed_node)` and `affected_rule_subset.update(downstream_rules)` finds all nodes that directly or indirectly depend on `changed_node` and returns them as a set, thus obtaining the downstream node set. `changed_node` represents a node that has undergone changes, such as rule modifications or changes to method implementations. Optionally, upstream dependency checks can be performed on the changed node by traversing backwards. This checks whether the upstream nodes it depends on are also included in the list of changes when a rule node changes, thus achieving integrity checks. It also sorts the nodes identified during forward traversal to determine the dependencies between target nodes.

[0124] Furthermore, to avoid wasting resources and filter out rules that do not need to be recompiled, in an exemplary embodiment, a subset of rules to be compiled is determined based on the target node and incremental data, including:

[0125] Based on the rules corresponding to the target node and the rules corresponding to the incremental data, a subset of candidate rules to be compiled is determined; the subset of candidate rules to be compiled is then filtered out, removing rules that only depend on non-dependent impactful changes, thus obtaining the subset of rules to be compiled.

[0126] Understandably, non-dependent impactful changes can refer to changes that alter only the internal implementation logic without changing the external "interface" or "contract." For example, a global method `calculateRisk(transaction)` might have an inefficient internal implementation that has been optimized, but its method name, input parameters, and return type remain unchanged. In this case, the rule does not need to be recompiled because the "interface contract" of its dependencies remains unchanged. The bytecode of rule X compiled before is still valid; continuing to compile it at this point would be a waste of resources.

[0127] For example, for a given subset of candidate rules to be compiled, the subset of candidate rules to be compiled is filtered out, and rules in the subset of candidate rules to be compiled that only depend on non-dependent impactful changes are filtered out, thus obtaining a subset of rules to be compiled, thereby obtaining the truly minimal compilation set.

[0128] In the above method, based on the dependency relationships between nodes in the dependency graph, a forward traversal is performed based on the changed nodes. On this basis, the resulting subset of candidate rules to be compiled is filtered out, and rules that only depend on non-dependent impact changes are removed from the subset of candidate rules to be compiled. This results in a subset of rules to be compiled, which further refines the scope of influence of the changed nodes, reduces unnecessary waste of resources, and improves compilation efficiency.

[0129] In one exemplary embodiment, such as Figure 3 As shown, a compilation method for a subset of rules to be compiled is provided, including the following steps:

[0130] Step 302: Segment the rules to be compiled according to their dependencies in the subset of rules to be compiled, and obtain multiple compilation units.

[0131] The dependencies between the rules in the subset of rules to be compiled can be determined based on a dependency graph; the specific determination method will not be elaborated here. The principle of the splitting is to divide the subset of rules to be compiled into multiple compilation units according to their dependencies, ensuring that there are no circular dependencies within each compilation unit, allowing for independent and parallel compilation.

[0132] Furthermore, in an exemplary embodiment, such as Figure 4 As shown, a method for partitioning the subset of rules to be compiled is provided, specifically including:

[0133] Step 402: Construct a task graph based on the compile-time dependencies between the rules in the subset of rules to be compiled; the nodes in the task graph are the rules to be compiled, and the edges connecting the nodes are the compile-time dependencies.

[0134] Step 404: Based on the compile-time dependencies between the rules to be compiled in the task graph, perform topological sorting on the rules to be compiled in the task graph to obtain the compilation order among the rules to be compiled.

[0135] Topological sorting can be based on compile-time dependencies in the task graph, ensuring that dependent rules precede rules that depend on them, forming a linear sequence that satisfies all dependency constraints. Based on topological sorting, rules are divided into multiple compilation units. The core principle of grouping is that rules within the same unit must be independent of each other, allowing for safe parallel compilation. The algorithm traverses rules in topological order, adding a rule to a unit only if it is independent of all other rules within that unit; otherwise, a new compilation unit is created.

[0136] Step 406: The compilation rules are divided according to their compilation order to obtain multiple compilation units; there are no dependencies between the compilation rules in each compilation unit.

[0137] The purpose of splitting the code into multiple compilation units is to group the rules that originally had to be compiled sequentially into as many groups as possible for parallel execution, thereby significantly improving compilation efficiency.

[0138] The above method of partitioning the rules to be compiled can group as many rules as possible that must be compiled serially so that they can be executed in parallel, thereby greatly improving compilation efficiency.

[0139] Step 304: Perform distributed compilation on each compilation unit to obtain the corresponding compilation results.

[0140] Step 306: Determine the compilation result based on each compilation result, merge the compilation result into the bytecode repository corresponding to the rule source code file, and complete the incremental compilation of the rule source code file.

[0141] For example, based on a master-slave architecture, the master node distributes compilation units to idle compilation nodes and obtains the compilation results from each node; each compilation node has a unified dependency library and environment image. That is, a master-slave architecture is adopted. The master node distributes compilation units to idle compilation nodes. The master node collects all successful compilation results and merges them into the bytecode repository. It should be noted that partial compilation failures do not affect the release of other successful results.

[0142] In the above embodiments, by introducing distributed compilation and build technology, the compilation tasks are distributed to multiple compilation nodes for parallel execution, which further reduces the pressure on a single node, shortens the compilation time, and ensures consistency in the distributed compilation process through unified dependency library versions and compilation environment images, avoiding silent errors caused by incompatible dependency versions.

[0143] In an exemplary embodiment, before compiling the subset of compilation rules to obtain the compilation result, the method further includes:

[0144] Dependency error detection is performed on the rule source code file based on the dependency graph to determine the error report of the dependency error; the error report includes the specific context of the erroneous dependency and the remediation strategy, and the dependency error detection includes at least one of the following: missing dependency detection, circular dependency detection, redundancy detection and version conflict detection;

[0145] Among them, missing dependency detection compares the actual dependency data in the dependency list with the dependencies declared in the rule source code file to detect whether there are any undeclared dependencies; circular dependency detection performs circular dependency detection on the subgraph of the dependency graph; and version conflict detection checks whether the global method version referenced by the rule is compatible with the version currently deployed on the platform.

[0146] Understandably, by running a Depth-First Search (DFS)-based cycle detection algorithm on the subgraphs of the dependency graph, it is possible to effectively detect whether circular dependencies exist between rules, thereby avoiding system problems caused by circular dependencies. Identifying circular dependencies through the Dependency Graph Cycle Detection (DFS) algorithm allows for prompting for repair during the compilation phase, preventing deadlocks during rule engine execution.

[0147] For example, before or during compilation, static analysis using a dependency graph is performed to detect dependencies, circular dependencies, and version conflicts, generating corresponding error reports. Each error report provides specific context and remediation suggestions, such as: "Rule RULE_005 calls the undeclared global method com.bsfit.old.LegacyTool.doSomething(). It is recommended to add import com.bsfit.old.LegacyTool to the DSL header or replace it with the new version com.bsfit.new.Tool.doSomethingNew()." For instance, if three missing dependency errors are detected and fixed during the compilation phase, runtime business interruptions are avoided.

[0148] Furthermore, based on the above embodiments, the dependency graph can be updated based on the compilation results and an effect feedback report can be generated. Specifically, if a new rule is introduced in this compilation, it is added to the dependency graph as a new node. If a rule is deleted, its corresponding node and associated edges are removed; and the attributes of the edges (such as dependency strength) are updated according to the actual dependencies collected in this study.

[0149] The system automatically records and compares key metrics, generating intuitive performance feedback reports. These reports can include data on compilation efficiency, resource consumption, and quality improvement. For example, regarding compilation efficiency: "This incremental compilation took 1.2 minutes, compiling only 105 rules (10.5% of the total 1000). Compared to the previous full compilation which took 10 minutes, this saved 8.8 minutes (88%)." Regarding resource consumption: "Peak CPU utilization was 9%, and memory consumption was 12GB, significantly lower than the full compilation (65% CPU, 30GB memory)." Regarding quality improvement: "Three missing dependency errors and one circular dependency were detected during the compilation phase, and repair suggestions have been provided, preventing potential runtime failures."

[0150] In the above embodiments, missing and redundant dependencies can be detected in advance, reducing the risk of runtime failures, and dependency error detection can be performed during the compilation stage, shortening the error troubleshooting time, such as reducing the error troubleshooting time from hours to minutes.

[0151] In one exemplary embodiment, such as Figure 5 As shown, an overall flowchart of incremental compilation and dependency error detection is provided, which includes:

[0152] If an update to the rule source code file is detected, i.e., a rule file change is detected, the incremental data of the rule source code file is determined. The change nodes corresponding to the incremental data are identified from the dependency graph. Based on the change nodes, the impact range is inferred from the dependency graph. By forward traversal of downstream influences, backward traversal of upstream dependencies, and range filtering, a subset of rules to be compiled is determined. Distributed compilation is performed on this subset of rules. This involves task partitioning, parallel compilation, and result merging. Specifically, the subset is divided according to the dependencies of the rules to be compiled, resulting in multiple compilation units. Each compilation unit is then compiled in a distributed manner to obtain its corresponding compilation result. The final compilation result is determined based on these results and merged into the bytecode repository corresponding to the rule source code file, completing the incremental compilation of the rule source code file.

[0153] Before or during compilation, dependency error detection is performed, including missing dependency detection, redundant dependency detection, circular dependency detection, and version conflict detection. If errors are found during dependency error detection, an error report with suggested fixes is generated. Then, the dependency graph is updated based on the compilation results, and an effect feedback report is generated. If no errors are found during dependency error detection, the dependency graph is updated based on the compilation results, and an effect feedback report is generated.

[0154] In the above embodiments, by combining file monitoring and AST difference analysis, and traversing the dependency graph in both forward and reverse directions, a minimum subset of rules to be compiled is generated. This enables accurate inference of the scope of influence and avoids the unnecessary resource consumption caused by full compilation. Based on the master-slave architecture, task scheduling divides compilation units according to dependencies, and parallel compilation and result merging ensure environmental consistency and support for parallel compilation of hundreds of rules. It also has horizontal scalability to adapt to the continuous growth of rule scale. In addition, by identifying missing dependencies, redundant dependencies, circular dependencies, and version conflicts in advance, dependency error detection is moved from runtime to the compilation stage, shortening error troubleshooting time. Furthermore, the prompts and repairs based on the compilation stage can prevent deadlocks during rule engine execution.

[0155] In an exemplary embodiment, an overall architecture diagram of the above-described rule compilation optimization method is provided, such as... Figure 6 As shown, it includes a rule metadata and dependency acquisition module, a dependency graph construction module, an incremental change monitoring and impact range inference module, an incremental compilation and dependency error detection module, a master node, and multiple compilation nodes (including compilation node 1, compilation node 2, ..., compilation node N), specifically including the following:

[0156] The rule metadata and dependency acquisition module extracts complete metadata and dependency lists for each rule from the original rule source code files, laying the data foundation for subsequent dependency graph construction. The dependency graph construction module, based on the extracted complete metadata and dependency lists, builds a global, queryable, and updatable graph data structure that intuitively displays the complex dependencies between all rules and methods, thus constructing the dependency graph.

[0157] The incremental change monitoring and impact range inference module is used to determine the change nodes corresponding to incremental data from the dependency graph, determine the target nodes affected by the change nodes from the dependency graph based on the change nodes, and determine the subset of rules to be compiled based on the target nodes and incremental data.

[0158] The master node is used to divide the rules to be compiled into multiple compilation units based on their dependencies within the subset of rules to be compiled. These units are then distributed to multiple compilation nodes. Each compilation node compiles its corresponding compilation unit. The master node then collects all successful compilation results, merges them into the bytecode repository, updates the dependency graph based on the compilation results, and stores the compilation results in the compilation cache. The compilation cache is a mechanism for storing and managing intermediate results or final output generated during the compilation process. It helps identify which files still have valid compilation results and which need to be recompiled, thus significantly reducing compilation time.

[0159] It should be noted that, based on Figure 6The rule compilation optimization method implemented by the overall architecture shown can be achieved in the manner described above, and will not be repeated here.

[0160] In the above embodiments, only a subset of rules to be compiled that have been modified and their impact scope is compiled, avoiding repeated compilation of unchanged rules and the unnecessary resource consumption caused by full compilation. Combined with distributed compilation and construction, the compilation task is parallelized, further shortening compilation time, improving compilation efficiency, and providing horizontal scalability to adapt to the continuous growth of rule scale. By comparing the dependency graph with the actual dependencies and statically detecting missing dependencies, redundant dependencies, circular dependencies, and version conflicts, dependency error detection is brought forward from runtime to the compilation stage. Corrections can be prompted during the compilation stage, avoiding deadlocks during rule engine execution and preventing dependency errors from being exposed at runtime, which requires log analysis and debugging, resulting in long processing times. Furthermore, it supports a minute-level closed loop of rule "modification-compilation-effectiveness," enabling rule changes to take effect promptly through incremental compilation and error detection, thus enhancing business agility. For example, in financial risk control scenarios, rule adjustments are shortened from hours to minutes, allowing for rapid responses to market changes.

[0161] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0162] Based on the same inventive concept, this application also provides a rule compilation optimization apparatus for implementing the rule compilation optimization method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more rule compilation optimization apparatus embodiments provided below can be found in the limitations of the rule compilation optimization method described above, and will not be repeated here.

[0163] In one exemplary embodiment, such as Figure 7 As shown, a rule compilation optimization device is provided, including: a data extraction module 702, a graph construction module 704, a subset determination module for rules to be compiled 706, and a compilation module 708, wherein:

[0164] The data extraction module 702 is used to obtain the rule source code file and extract the complete meta-information and dependency list of each rule in the rule source code file.

[0165] The graph construction module 704 is used to generate rule nodes and dependency nodes of the dependencies in the dependency list corresponding to each rule for each rule. Based on the dependency relationships between all rule nodes and all dependency nodes, dependency edges are constructed to obtain the dependency graph.

[0166] The module 706 for determining the subset of rules to be compiled is used to determine the incremental data of the rule source code file if an update is detected in the rule source code file; determine the change node corresponding to the incremental data from the dependency graph; determine the target node affected by the change node from the dependency graph based on the change node; and determine the subset of rules to be compiled based on the target node and the incremental data.

[0167] The compilation module 708 is used to compile a subset of rules to be compiled, obtain the compilation results, and merge the compilation results into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0168] The aforementioned rule compilation optimization device extracts the complete meta-information and dependency list of each rule from the rule source code file, defines the nodes and edges of the dependency graph based on the complete meta-information and dependency list of each rule, and obtains a constructed dependency graph. When an update to the rule source code file is detected, the device determines the incremental data of the rule source code file, identifies the changed nodes corresponding to the incremental data from the dependency graph, determines the target nodes affected by the changed nodes from the dependency graph based on the changed nodes, and determines the subset of rules to be compiled based on the target nodes and incremental data. The subset of rules to be compiled is then compiled to obtain the compilation result, which is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file. This method determines the dependency scope based on the construction of the dependency graph, compiles only the dependency scope, avoids full compilation, and significantly improves compilation efficiency.

[0169] In an exemplary embodiment, the data extraction module 702 is used to obtain the rule source code file, perform lexical analysis and syntactic analysis on the rule source code file, and generate the corresponding abstract syntax tree;

[0170] Traverse the abstract syntax tree to extract complete meta-information for each rule; complete meta-information includes at least the rule identifier.

[0171] Static dependency data is obtained by performing static analysis on the abstract syntax tree, and actual dependency data is obtained by simulating the execution process based on the abstract syntax tree using a preset lightweight rule execution simulator. The static dependency data includes the fully qualified names and signatures of all referenced global methods, and the actual dependency data includes all other rules and global methods called at runtime.

[0172] The dependency list corresponding to each rule is determined based on static dependency data and actual dependency data.

[0173] In an exemplary embodiment, the graph construction module 704 is used to construct dependency edges for each rule node among all rule nodes based on the corresponding dependency nodes among all dependency nodes, thereby obtaining an initial dependency graph.

[0174] For the rule nodes and / or dependency nodes in the initial dependency graph, a breadth-first search is used to calculate the complete dependency chain of each node, identify indirect dependencies and construct the corresponding dependency edges to obtain the dependency graph; the nodes are either rule nodes or dependency nodes.

[0175] In the dependency graph, dependency edges are used to represent the dependency relationships between nodes. The edge attributes include the dependency type, dependency strength, and dependency source.

[0176] In an exemplary embodiment, the rule subset determination module 706 is used to monitor the rule source code file through file listening and code comparison, and determine the change type of the rule source code file; the change type includes rule change, method change, non-dependent impact change that represents only the internal implementation logic of the method is modified and the signature remains unchanged, and dependent impact change that represents the change of the method signature, exception declaration or return value type; and determine the incremental data corresponding to the change type.

[0177] In an exemplary embodiment, the rule subset determination module 706 is used to determine the target node that depends on the changed node by performing a forward traversal based on the dependency relationship between nodes in the dependency graph; the changed node is a rule node and / or a dependency node; and to determine the rule subset to be compiled based on the target node and incremental data.

[0178] In an exemplary embodiment, the rule subset determination module 706 is used to determine a candidate rule subset to be compiled based on the rules corresponding to the target node and the rules corresponding to the incremental data; and to filter out the rules in the candidate rule subset that only depend on non-dependent impactful changes, thereby obtaining the rule subset to be compiled.

[0179] In an exemplary embodiment, the compilation module 708 is used to split the rules to be compiled in the subset of rules to be compiled to obtain multiple compilation units;

[0180] Distributed compilation is performed on each compilation unit to obtain its corresponding compilation result;

[0181] The compilation result is determined based on each compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

[0182] In an exemplary embodiment, the compilation module 708 includes a task segmentation module, which is used to construct a task graph based on the compile-time dependencies between the rules to be compiled in the subset of rules to be compiled; the nodes in the task graph are the rules to be compiled, and the edges connecting the nodes are the compile-time dependencies.

[0183] Based on the compile-time dependencies between the rules to be compiled in the task graph, the rules to be compiled in the task graph are topologically sorted to obtain the compilation order among the rules to be compiled.

[0184] The compilation is divided according to the compilation order of each rule to be compiled, resulting in multiple compilation units; there are no dependencies between the rules to be compiled in each compilation unit.

[0185] In an exemplary embodiment, the compilation module 708 is used to distribute each compilation unit to idle compilation nodes through the master node of the master-slave architecture, and obtain the compilation results of each compilation node; each compilation node has a unified dependency library and environment image.

[0186] In an exemplary embodiment, the rule compilation optimization apparatus includes a dependency error detection module, which is used to perform dependency error detection on the rule source code file according to the dependency graph and determine the error report of the dependency error; the error report includes the specific context of the erroneous dependency and the repair strategy, and the dependency error detection includes at least one of missing dependency detection, circular dependency detection and version conflict detection;

[0187] Among them, missing dependency detection compares the actual dependency data in the dependency list with the dependencies declared in the rule source code file to detect whether there are any undeclared dependencies; circular dependency detection performs circular dependency detection on the subgraph of the dependency graph; and version conflict detection checks whether the global method version referenced by the rule is compatible with the version currently deployed on the platform.

[0188] Each module in the aforementioned rule compilation and optimization device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0189] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a rule-based compilation optimization method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0190] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0191] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0192] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0193] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0194] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0195] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0196] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0197] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A rule compilation optimization method, characterized in that, The method includes: Obtain the rule source code file, and extract the complete meta-information and dependency list of each rule in the rule source code file; For each rule, based on the complete meta-information and the dependency list, a rule node corresponding to each rule and a dependency node of the dependency item in the dependency list corresponding to the rule are generated. Based on the dependency relationship between all the rule nodes and all the dependency nodes, dependency edges are constructed to obtain a dependency graph. If an update to the rule source code file is detected, the incremental data of the rule source code file is determined. From the dependency graph, determine the change node corresponding to the incremental data; based on the change node, determine the target node affected by the change node from the dependency graph; and determine the subset of rules to be compiled based on the target node and the incremental data. The subset of rules to be compiled is compiled to obtain the compilation result, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

2. The method according to claim 1, characterized in that, The process of obtaining the rule source code file involves extracting the complete metadata and dependency list of each rule from the rule source code file, including: Obtain the rule source code file, perform lexical and syntactic analysis on the rule source code file, and generate the corresponding abstract syntax tree; Traverse the abstract syntax tree to extract complete meta-information of each rule; the complete meta-information includes at least the rule identifier. Static dependency data is obtained by performing static analysis on the abstract syntax tree, and actual dependency data is obtained by simulating the execution process based on the abstract syntax tree using a preset lightweight rule execution simulator. The static dependency data includes the fully qualified names and signatures of all referenced global methods, and the actual dependency data includes all other rules and global methods called at runtime. The dependency list corresponding to each rule is determined based on the static dependency data and the actual dependency data.

3. The method according to claim 1, characterized in that, The step of constructing dependency edges based on the dependency relationships between all the rule nodes and all the dependency node to obtain a dependency graph includes: For each rule node among all the rule nodes, construct dependency edges based on the corresponding dependency nodes among all the dependency nodes to obtain an initial dependency graph; For the rule nodes and / or dependency nodes in the initial dependency graph, a breadth-first search is used to calculate the complete dependency chain of each node, identify indirect dependencies and construct the corresponding dependency edges to obtain the dependency graph; the nodes are rule nodes or dependency nodes. In the dependency graph, the dependency edges are used to represent the dependency relationships between nodes, and the edge attributes include the dependency type, dependency strength, and dependency source of the dependency relationship.

4. The method according to claim 1, characterized in that, If an update to the rule source code file is detected, the incremental data of the rule source code file is determined, including: The rule source code file is monitored by file listening and code comparison to determine the change type of the rule source code file; the change type includes rule change, method change, non-dependent impact change that indicates only the internal implementation logic of the method is modified and the signature remains unchanged, and dependent impact change that indicates that the method signature, exception declaration or return value type has changed; Determine the incremental data corresponding to the change type.

5. The method according to claim 1, characterized in that, The step of determining target nodes dependent on the changed nodes from the dependency graph, and determining a subset of rules to be compiled based on the target nodes and the incremental data, includes: Based on the dependency relationships between nodes in the dependency graph, a forward traversal is performed based on the changed node to determine the target node that depends on the changed node; the changed node is the rule node and / or the dependency node. The subset of rules to be compiled is determined based on the target node and the incremental data.

6. The method according to claim 5, characterized in that, The step of determining the subset of rules to be compiled based on the target node and the incremental data includes: A subset of candidate rules to be compiled is determined based on the rules corresponding to the target node and the rules corresponding to the incremental data. The candidate subset of rules to be compiled is filtered out, and rules that depend only on non-dependent impactful changes are removed, thus obtaining the subset of rules to be compiled.

7. The method according to claim 5, characterized in that, The process of compiling the subset of rules to be compiled to obtain a compilation result, and merging the compilation result into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file includes: The compilation units are obtained by segmenting the rules in the subset of rules to be compiled based on their dependencies. Distributed compilation is performed on each of the aforementioned compilation units to obtain their respective compilation results; The compilation result is determined based on the compilation results described above, and the compilation result is merged into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

8. The method according to claim 7, characterized in that, The step involves segmenting the rules into multiple compilation units based on their dependencies within the subset of rules to be compiled, including: A task graph is constructed based on the compile-time dependencies between the rules to be compiled in the subset of rules to be compiled; the nodes in the task graph are the rules to be compiled, and the edges connecting the nodes are the compile-time dependencies. Based on the compile-time dependencies between the rules to be compiled in the task graph, the rules to be compiled in the task graph are topologically sorted to obtain the compilation order among the rules to be compiled. The compilation units are divided according to the compilation order of the rules to be compiled, resulting in multiple compilation units; there is no dependency between the rules to be compiled in each compilation unit.

9. The method according to claim 7, characterized in that, The distributed compilation of each compilation unit to obtain its corresponding compilation result includes: Based on a master-slave architecture, the master node of the master-slave architecture distributes each compilation unit to an idle compilation node and obtains the compilation results of each compilation node; each compilation node has a unified dependency library and environment image.

10. The method according to claim 7, characterized in that, Before compiling the subset of rules to be compiled to obtain the compilation result, the method further includes: Based on the dependency graph, the source code file of the rule is subjected to dependency error detection to determine an error report of the dependency error; the error report includes the specific context and repair strategy of the erroneous dependency; the dependency error detection includes at least one of missing dependency detection, circular dependency detection and version conflict detection. Specifically, the missing dependency detection involves comparing the actual dependency data in the dependency list with the dependencies declared in the rule source code file to detect whether there are any undeclared dependencies; the circular dependency detection involves performing circular dependency detection on the subgraphs of the dependency graph; and the version conflict detection involves checking whether the global method version referenced by the rule is compatible with the version currently deployed on the platform.

11. A rule-based compilation optimization apparatus, characterized in that, The device includes: The data extraction module is used to obtain the rule source code file and extract the complete meta-information and dependency list of each rule in the rule source code file; The graph construction module is used to generate rule nodes corresponding to each rule and dependency nodes of the dependencies in the dependency list corresponding to the rule for each rule, and to construct dependency edges based on the dependency relationships between all rule nodes and all dependency nodes to obtain a dependency graph. The module for determining the subset of rules to be compiled is used to determine the incremental data of the rule source code file if an update is detected in the rule source code file; determine the change node corresponding to the incremental data from the dependency graph; determine the target node affected by the change node from the dependency graph based on the change node; and determine the subset of rules to be compiled based on the target node and the incremental data. The compilation module is used to compile the subset of rules to be compiled to obtain the compilation result, and merge the compilation result into the bytecode repository corresponding to the rule source code file to complete the incremental compilation of the rule source code file.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images