Rule engine verification publishing method and device, terminal equipment and medium
By validating the rule engine file before publishing it and performing hot updates of the rule object when the validation is successful, the problem of low efficiency in the validation and publishing of rule engine files in the existing technology is solved, and efficient rule engine file publishing is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- WEBANK (CHINA)
- Filing Date
- 2021-06-29
- Publication Date
- 2026-06-12
AI Technical Summary
In the existing technology, during the verification and publishing process of rule engine files, the entire process of editing, publishing, and verifying needs to be re-executed every time verification fails, resulting in wasted resources and low publishing efficiency.
The rule engine file is validated before it is published. The rule engine file is only generated and published when the validation is successful. The default object mapping table is updated using rule objects for publishing, avoiding invalid publishing operations.
This reduces the cost of validation failures, improves the efficiency of publishing rule engine files, and ensures the effectiveness and efficiency of the publishing process.
Smart Images
Figure CN113326049B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial technology (Fintech), and in particular to a method, apparatus, terminal device, and computer storage medium for verifying and publishing rules engines. Background Technology
[0002] With the development of computer technology, more and more technologies (big data, distributed systems, artificial intelligence, etc.) are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology (Fintech). However, due to the security and universality requirements of the financial industry, higher demands are also being placed on computer technology.
[0003] For rule engine files, each file must go through the stages of rule editing, publishing, and verification. When an existing rule engine file needs to be modified, the rules must be edited again, published, and a new rule engine file generated. The new rule engine file is then reloaded to update the original file. After the new rule engine file is loaded, it is run to verify the modified rules. If verification fails, the rules must be edited again, and then published and verified again. Each time verification fails, the entire editing, publishing, and verification process must be repeated. In real-world applications, rule verification and publishing can be time-consuming. If the entire process must be re-executed every time verification fails, it undoubtedly incurs significant verification costs, wastes resources, and negatively impacts the efficiency of rule engine file publishing. Summary of the Invention
[0004] The main objective of this invention is to propose a method, apparatus, terminal device, and medium for verifying and publishing a rule engine, aiming to provide a set of verification and publishing schemes for rule engines, reduce the verification cost of rule engine files, and thereby improve the verification and publishing efficiency of rule engines.
[0005] To achieve the above objectives, the present invention provides a verification and publishing method for a rule engine, the method comprising the following steps:
[0006] Obtain rule editing instructions and generate target rules based on the rule editing instructions;
[0007] Receive a verification instruction and create a test set according to the verification instruction, wherein the test set includes test cases and expected decision results;
[0008] The target rule is compiled into a first rule object, and the test cases in the test set are executed according to the first rule object to obtain the test decision result;
[0009] The test decision result is compared with the expected decision result. The target rule is verified based on the comparison result. If the verification fails, the process returns to and executes the steps of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes. Then, a rule engine file is generated based on the target rule.
[0010] Receive a publish request instruction, and parse the rule engine file into a second rule object according to the publish request instruction;
[0011] The second rule object is used to hot update the preset object mapping table to complete the publication of the rule engine file.
[0012] Optionally, the step of hot-updating the preset object mapping table using the second rule object includes:
[0013] Obtain the application identifier information of the second rule object and create a copy of the preset object mapping table;
[0014] Traverse each rule object in the replica information to determine whether there is a third rule object in the replica information that has the same application identifier information as the second rule object;
[0015] If it exists, replace the third rule object with the second rule object to update the copy information;
[0016] If it does not exist, the second rule object is added to the replica information to update the replica information;
[0017] The object mapping table is updated by replacing it with the updated copy information.
[0018] Optionally, the object mapping table includes multiple rule arrays, and the step of creating a copy of the preset object mapping table includes:
[0019] Determine the first index variable of each rule array in a preset object mapping table, wherein the first index variable represents the position of each rule array in the object mapping table;
[0020] Calculate the second index variable based on the first index variable, and create a target rule array at the position indicated by the second index variable;
[0021] The contents of each rule array are copied into the target rule array to obtain the copy information of the object mapping table, wherein the second index variable represents the position of the target rule array in the object mapping table.
[0022] Optionally, after the step of receiving the publish request instruction, the method further includes:
[0023] Create a child node under the lock node in ZooKeeper according to the published request instruction;
[0024] The publishing result of the rule engine file is obtained based on the arrangement order of the child nodes.
[0025] Optionally, the step of obtaining the publishing result of the rule engine file according to the arrangement order of the child nodes includes:
[0026] The target child node that is first in the order of the child nodes is controlled to acquire the lock;
[0027] After the target child node acquires the lock, the publication result of the rule engine file corresponding to the target child node is obtained;
[0028] When the publication result of the rule engine file corresponding to the target child node is obtained, the target child node is deleted to release the lock, and the process returns to and executes the step of controlling the target child node ranked first to acquire the lock according to the arrangement order of the child nodes, until the target child node is the last child node.
[0029] Optionally, the verification and publishing method of the rule engine further includes:
[0030] Create a publish node and a publish result directory in ZooKeeper, and start listening to the publish node and the publish result directory;
[0031] Based on the monitoring results, obtain the publication information and publication results of the rule engine file, wherein the publication information includes the publication time, file name, and rule version.
[0032] Optionally, the rule engine management system includes multiple rule engine management consoles and multiple rule engine applications. After the step of using the second rule object to hot-update the preset object mapping table and complete the publication of the rule engine file, the system further includes:
[0033] When each rule engine application completes the publication of the rule engine file, it writes the publication result of the rule engine file into the publication result directory;
[0034] When the modification of the published results directory is detected, the target rule engine management console corresponding to the target sub-node is determined;
[0035] The target rule engine management console is controlled to read and output the publication results in the publication results directory.
[0036] Furthermore, to achieve the above objectives, the present invention also provides a verification and publishing device for a rule engine, the verification and publishing device for the rule engine comprising:
[0037] The rule creation module is used to obtain rule editing instructions and generate target rules based on the rule editing instructions;
[0038] A test set creation module is used to receive verification instructions and create test sets according to the verification instructions, wherein the test set includes test cases and expected decision results;
[0039] The rule compilation module is used to compile the target rule into a first rule object, and execute the test cases in the test set according to the first rule object to obtain the test decision result;
[0040] The rule verification module is used to compare the test decision result with the expected decision result, verify the target rule according to the comparison result, and if the verification fails, return and execute the step of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes, and then generate a rule engine file according to the target rule.
[0041] The rule parsing module is used to receive a publishing request instruction and parse the rule engine file into a second rule object according to the publishing request instruction;
[0042] The rule publishing module is used to publish the rule engine file by hot-updating the preset object mapping table using the second rule object.
[0043] In addition, to achieve the above objectives, the present invention also provides a terminal device, the terminal device comprising: a memory, a processor, and a rule engine verification and publishing program stored in the memory and executable on the processor, wherein when the rule engine verification and publishing program is executed by the processor, it implements the steps of the rule engine verification and publishing method as described above.
[0044] In addition, to achieve the above objectives, the present invention also provides a computer storage medium storing a verification and release program for a rule engine, wherein the verification and release program for the rule engine, when executed by a processor, implements the steps of the verification and release method for the rule engine as described above.
[0045] This invention obtains rule editing instructions and generates target rules based on those instructions; verifies the target rules; if the verification passes, generates a rule engine file based on the target rules; publishes the rule engine file, and obtains and outputs the publication result. Compared with the prior art, which requires re-executing the entire process of editing, publishing, and verifying every time verification fails, this invention verifies the generated rules before publishing and generating the rule engine file, and only performs the publishing operation when the verification passes. This avoids invalid publishing operations, reduces the cost of verification failures, and improves the publishing efficiency of the rule engine file. Attached Figure Description
[0046] Figure 1 This is a schematic diagram of the terminal device structure of the hardware operating environment involved in the embodiments of the present invention;
[0047] Figure 2 This is a flowchart illustrating the first embodiment of the verification and release method of the rule engine of the present invention;
[0048] Figure 3 This is a schematic diagram of the editing, verification, and publishing process of the rule engine in the first embodiment of the rule engine verification and publishing method of the present invention;
[0049] Figure 4 This is a schematic diagram of a hot update process in the second embodiment of the verification and release method of the rule engine of the present invention;
[0050] Figure 5 This is a schematic diagram of the functional modules of the verification device of the rule engine of the present invention.
[0051] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0052] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
[0053] like Figure 1 As shown, Figure 1 This is a schematic diagram of the terminal device structure of the hardware operating environment involved in the embodiments of the present invention.
[0054] In this embodiment of the invention, the terminal device can be a PC or a server device, on which a virtual machine runs.
[0055] like Figure 1As shown, the terminal device may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.
[0056] Those skilled in the art will understand that Figure 1 The terminal device structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0057] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a verification and publishing program for a rules engine.
[0058] exist Figure 1 In the terminal device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the client (user end) and communicate with the client; and the processor 1001 can be used to call the rule engine verification and release program stored in the memory 1005 and execute the operations in the rule engine verification and release method described below.
[0059] Based on the above hardware structure, an embodiment of the verification and release method of the rule engine of the present invention is proposed.
[0060] In the various embodiments of this invention, the key terms used mainly include:
[0061] A rules engine is a component embedded in an application that separates business decisions from application code and uses predefined semantic modules to write those decisions. It accepts data input, interprets business rules, and makes business decisions based on those rules.
[0062] Rule engine file: A file that describes the content of business rules. Whenever a rule changes, you only need to modify the rule engine file and then reload it to make the new rule take effect.
[0063] Rule Engine IDE: An Integrated Development Environment (IDE) is used to develop rule content and generate rule engine files after development is complete.
[0064] Zookeeper: Zookeeper is a distributed application coordination service that provides consistency services for distributed applications. Its main functions include configuration maintenance, domain name service, distributed synchronization, and group services.
[0065] agent thread: also known as agent process. agent means agent, which refers to a software or hardware entity that can act and run independently.
[0066] worker process: Used to run the rule objects corresponding to the rule engine file.
[0067] It should be noted that the rule engine file publishing and verification method provided by this invention can be applied to a rule engine management system. This system may include multiple rule engine management consoles, multiple rule engine applications, and ZooKeeper, etc. There are communication connections between each rule engine management console, each rule engine application, and ZooKeeper. The rule engine management console can be used to edit rules, send verification instructions to the rule engine applications and receive verification results, and generate rule engine files. The rule engine applications can be used to verify the rules generated in the rule engine management console, send verification results to the rule engine management console, receive the rule engine files sent by the rule engine management console and perform hot updates, and then publish the received rule engine files. ZooKeeper can be used to subscribe to, notify, and publish information.
[0068] Based on the aforementioned rule engine file management system, the following details each step of the rule engine file publishing and verification method of the present invention.
[0069] Reference Figure 2 , Figure 2 This is a flowchart illustrating a first embodiment of a rule engine verification and publishing method, which includes:
[0070] Step S10: Obtain rule editing instructions and generate target rules according to the rule editing instructions;
[0071] The verification and release method of the rule engine in this embodiment is applied to the terminal device that implements the verification and release program of the rule engine. The terminal device can be a robot or a PC, or a server with a virtual machine installed.
[0072] In existing technologies, the verification method for rule engines is as follows: After a rule is created, a rule engine file is generated and published based on the created rule. After the rule engine file is published, a testing tool sends a test message to the rule engine application via a network call. Then, the rule engine receives the business decision sent by the rule engine application and compares it with the expected decision result. If they match, it means the business rule has met expectations, and the rule change is complete. If they do not match, it means there is a deviation in the implementation of the business rule, and the rule content needs to be re-edited. Rule verification needs to be performed after the rule is published. If verification fails, the entire process of editing, publishing, and verifying the rule engine file needs to be re-executed. Therefore, there are many invalid publications, resulting in high costs when verification fails, thus affecting the publishing efficiency of the rule engine.
[0073] Based on this, this embodiment provides a verification and release scheme for rule engine files. Before the rules are released, the generated rules are verified. Only when the rules are verified and released, the rule engine file is generated and released, thereby reducing invalid releases and improving the release efficiency of the rule engine.
[0074] Specifically, in this embodiment, the rules used to generate the rule engine file are generated in the rule engine management console. Specifically, when a rule engine file needs to be changed, the user edits the rules in the rule engine IDE of the rule engine management console, triggering the corresponding editing command. The rule engine management console obtains the user's editing command and generates the corresponding target rule based on the obtained editing command. Changes to the rule engine file include adding and modifying rules.
[0075] Furthermore, in this embodiment, the verification and publication method of the rule engine may also include:
[0076] Step S01: Create a publishing node and a publishing result directory in ZooKeeper, and start listening to the publishing node and the publishing result directory;
[0077] Step S02: Obtain the publication information and publication result of the rule engine file based on the monitoring results, wherein the publication information includes the publication time, file name and rule version.
[0078] Before a rule triggers a file publication, some preliminary work is performed, such as creating a publication node and a publication results directory. Specifically, after the rule engine application starts, it creates a publication node and a publication results directory containing its own IP information in ZooKeeper. The publication node is used to register instances, notifying the rule engine management console which application instances are available for publication. The publication results directory is used to report the publication results of the rule engine file. The rule engine application listens to the publication node it created in ZooKeeper. When it detects that the publication node has been modified, it retrieves the publication information written to the publication node, obtains the rule engine file to be published based on this information, and performs the publication operation. The rule engine publication information includes the file name, rule version, publication time, and publication ID, etc. Upon completion of the publication of the rule engine file, the publication results are written to the publication results directory created in ZooKeeper.
[0079] After the rule engine management console starts, it monitors the publishing nodes and publishing result directory in ZooKeeper, and obtains the publishing results and application instances that can be used for publishing based on the monitoring results. Specifically, based on the monitoring results of the publishing nodes, it obtains which application instances can be used for publishing. When a rule engine file needs to be published, it writes the publishing information of the rule engine file into the publishing node. At the same time, based on the monitoring results of the publishing result directory, it obtains the publishing results of the rule engine file. When it detects that the publishing result directory has been modified, it reads the publishing results written to the publishing result directory.
[0080] Furthermore, when a node created in ZooKeeper is modified, ZooKeeper sends a notification to the listening object, indicating that the node it is listening to has been modified. Upon receiving the notification from ZooKeeper, the listening object reads the written information from the node it is listening to. For example, the rules engine management console listens to the publication results directory created by the rules engine application in ZooKeeper. When the rules engine application writes publication results to the publication results directory, ZooKeeper notifies the rules engine management console that the publication results directory has been modified. After receiving the notification from ZooKeeper, the rules engine management console reads the publication results from the publication results directory and outputs the publication results to the user.
[0081] Step S201: Verify the target rule. If the verification fails, return to and execute the step of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes. Then, generate a rule engine file according to the target rule.
[0082] When the editing of the target rule is completed, the rule engine management console packages the generated target rule and sends it to the rule engine application for verification. After receiving the target rule sent by the rule engine management console, the rule engine application verifies it and obtains the decision result of the test corresponding to the target rule. The decision result of the test is the verification result.
[0083] The verification result is returned to the rule engine management console, which determines whether the target rule verification passes based on the returned test decision. If the verification fails, the process returns to and executes the steps of obtaining the rule editing instruction and generating the target rule according to the instruction, outputting a prompt message to remind the user to modify the rule. The user's editing instruction is then obtained again and the corresponding rule is generated, until the verification passes. When the target rule verification passes, a rule engine file is generated based on the generated target rule.
[0084] Furthermore, during verification, the rule engine management console determines whether the generated target rule passes verification based on the returned test decision results and outputs a verification result prompt. It can be seen that the output prompt can include the test decision results for users to refer to when modifying rules. Simultaneously, when verification passes, corresponding prompts can also be output to inform users of the current progress of rule engine changes. The detailed process for verifying the generated target rule includes:
[0085] Step S20: Receive a verification instruction and create a test set according to the verification instruction, wherein the test set includes test cases and expected decision results;
[0086] Step S30: Compile the target rule into a first rule object, and execute the test cases in the test set according to the first rule object to obtain the test decision result;
[0087] Step S40: Compare the test decision result with the expected decision result, and verify the target rule according to the comparison result. If the verification fails, return and execute the step of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes, and then generate the rule engine file according to the target rule.
[0088] It should be noted that the existing rule verification method is as follows: After the rule engine file is published, a testing tool sends a test message to the rule engine application via network call. Then, the rule engine makes a business decision upon receiving the decision from the application, and compares it with the expected decision. If they match, the business rule has met expectations, and the rule change is complete. If they do not match, the implementation of the business rule has deviated, and the rule content needs to be re-edited. Rule verification needs to be performed after the rule is published. If verification fails, the entire process of editing, publishing, and verifying the rule engine file needs to be re-executed. Therefore, there are many invalid publications, resulting in high costs when verification fails.
[0089] Based on this, in this embodiment, the generated rules are verified before the rule engine file is published. When the verification is successful, it means that the generated rules have met expectations. Then, the rule engine file is generated and published to ensure the validity of the publication, reduce invalid publications, and thus reduce the cost of verification failures.
[0090] During verification, the user selects the rule to be verified and published in the rule engine management console and triggers the verification and publication commands. When the rule engine management console detects the verification command, it creates a test set based on the user's editing instructions. This test set includes test cases and expected decision results. It should be noted that a rule can include multiple test sets, and a test set can include multiple test cases and expected decision results.
[0091] After creating the test set, the rule engine management console sends a verification message to the rule engine application. This message includes the target rule to be verified and the test set. Upon receiving the verification message, the rule engine application compiles the target rule into a rule object and executes each test case in the test set according to the compiled rule object, obtaining the test decision result. This result is then sent to the rule engine management console. The management console, upon receiving the test decision result, compares it with the expected result to verify the target rule. If the test decision result matches the expected result, the verification passes; otherwise, it fails, and the target rule needs to be modified.
[0092] Furthermore, after determining the verification results through comparison, the rule engine management console outputs and displays the verification results to the user. The verification results may include the decision results of the test on the target rule for the user's reference.
[0093] In this embodiment, by verifying the target rules, the usability of the published rule engine file is ensured, which reduces the operational and time costs of the publication phase and improves the verification and publication efficiency of the rule engine. Furthermore, in this embodiment, the target rules are verified directly using the rule engine application, rather than through testing tools, reducing communication and time costs during the verification phase and further improving verification efficiency.
[0094] Furthermore, after the generated target rules pass verification, the generated rule engine file needs to be published. The specific process of publishing the rule engine file may include:
[0095] Step S50: Receive a release request instruction and parse the rule engine file into a second rule object according to the release request instruction;
[0096] Step S60: Use the second rule object to hot update the preset object mapping table to complete the publication of the rule engine file.
[0097] After generating the rule engine file, it needs to be published. Currently, the common publishing method is to copy the rule engine file to a specified directory of the rule engine application, then restart the rule engine application to load the new rule engine file. After the new rule engine file is loaded, a dedicated testing tool is used to verify the rules in the new rule engine file. If the verification fails, the rules must be re-edited, and the entire process of editing, publishing, and verifying must be repeated. The cost of verification failure is high, and it also affects the efficiency of publishing the rule engine file.
[0098] In this embodiment, after the rules are validated, a rule engine file is generated and then published. Specifically, refer to... Figure 3 , Figure 3 This is a schematic diagram illustrating the editing, verification, and publishing process of the rules engine in this embodiment. Figure 3 In the process, the rule engine management console packages the generated rule engine file and sends it to the rule engine application for verification. The rule engine application returns the test decision results to the rule engine management console. The rule engine management console compares the test decision results with the expected decision results to determine whether the results are consistent. If they are consistent, the rule engine file is generated and published according to the generated target rules. If they are inconsistent, the rules are re-edited until the verification is passed.
[0099] Furthermore, when publishing a rule engine file, the rule engine application listens to the publishing node it created in ZooKeeper. When the rule engine management console needs to publish a rule engine file, it writes the publishing information of the rule engine file to be published into ZooKeeper and triggers a publishing request instruction. This publishing request instruction includes the IP information of the rule engine application used to execute the publishing, which is used to notify the corresponding rule engine application that there is a rule engine file to be published. At the same time, it listens for the publishing result in ZooKeeper. The rule engine application listens to the publishing node. When the publishing node is modified, it reads the publishing information in the publishing node and, based on this publishing information, pulls the rule engine file to be published from the corresponding rule engine management console. After pulling the rule engine file, it executes the publishing operation.
[0100] The rule engine application in each embodiment of this invention is a multi-threaded (or process) model, including an agent thread, a worker thread group, and a verification thread. The agent thread is used to interact with ZooKeeper, pull rule engine files, etc.; the worker thread group provides services for business programs to call, receives input data, interprets business rules, and makes business decisions based on the business rules; the verification thread is used to verify the correctness of the rules. After parsing the rule engine file into rule objects, the parsed rule objects are updated in a preset object mapping table shared with the worker thread group. Each time the worker thread group processes a business decision, it reads the corresponding rule engine object from this object mapping table. Therefore, successful updating of the object mapping table indicates successful publication of the rule engine file.
[0101] The rules engine application uses a multi-process model, with one agent process and a set of worker processes, each maintaining its own rules engine object. (See reference...) Figure 4 , Figure 4 This is a schematic diagram of a hot update process. Figure 4 In the process, after the agent process obtains the new rule engine file, it saves the file in the system directory. The agent process then executes a system call to start a new set of worker processes. These new worker processes load the new rule engine file, meaning two sets of worker processes are running simultaneously: one running the old rules and the other running the new rules. Finally, the agent process executes a system call to shut down the old worker process group, keeping only the group running the new rules active, thus completing the hot update of the rule engine file. However... Figure 5 The hot update scheme shown is time-consuming and often fails to complete the deployment task within the expected timeframe. Moreover, each step of the process requires system calls, making the execution complex and prone to failure.
[0102] Therefore, in this embodiment, the hot update method is optimized. Specifically, an object mapping table is established between the agent process and the worker process group. When the rule engine application receives a business rule request instruction, it indexes the rule object to be executed from this object mapping table. Updating the rule engine file is actually updating this object mapping table. When the rule engine management console receives a user's publish request instruction, it publishes the rule engine file indicated by the instruction. Specifically, the user's publish request instruction contains the IP address of the rule engine application, thus indicating the rule engine application used to publish the rule engine file. After receiving the user's publish request instruction, the rule engine application parses the rule engine file into rule objects. Using the parsed rule objects, it performs a hot update on the preset object mapping table. When the hot update of the object mapping table is completed, the publication of the rule engine file is completed. Here, hot update refers to an instant update performed when the application starts, which takes effect without restarting the application. Hot update can reduce publication costs and further improve the publication efficiency of rule engine files.
[0103] After the rule engine file is published, the rule engine application writes the publication results to the publication results directory. The rule engine management console listens to the publication results directory. When the publication results directory is modified, it reads the publication results in the publication results directory and outputs them to the user to indicate that the rule engine file has been published.
[0104] In this embodiment, a rule editing instruction is obtained and a target rule is generated based on the instruction. The target rule is then validated. If the validation fails, the process returns to and executes the steps of obtaining the rule editing instruction and generating the target rule based on the instruction again until the validation passes. Finally, a rule engine file is generated based on the target rule, and the rule engine file is published. By validating the generated rules before publishing and generating the rule engine file, and only performing the publishing operation when the validation passes, invalid publishing operations are avoided, the cost of validation failures is reduced, and the efficiency of publishing the rule engine file is improved, achieving efficient publishing of the rule engine file.
[0105] Furthermore, based on the first embodiment described above, a second embodiment of the verification and release method of the rule engine of the present invention is proposed. This embodiment is a refinement of the step of hot-updating the preset object mapping table in step S60 of the first embodiment. The step of hot-updating the preset object mapping table using the second rule object in step S60 may include:
[0106] Step A1: Obtain the application identifier information of the second rule object and create a copy of the preset object mapping table;
[0107] Step A2: Traverse each rule object in the replica information to determine whether there is a third rule object in the replica information that has the same application identifier information as the second rule object;
[0108] Step A3: If it exists, replace the third rule object with the second rule object to update the copy information;
[0109] Step A4: If it does not exist, add the second rule object to the replica information to update the replica information;
[0110] Step A5: Replace the object mapping table with the updated copy information to update the object mapping table.
[0111] When hot-updating the preset object mapping table, the agent first reads the publication information of the rule engine file to determine the application identification information of the rule object in the rule engine file to be published. This application identification information includes the values of `appid` (application identification) and `cmd`. `appid` is a subkey of COM (Component Object Model), which stores parameters such as the object location and filename set when the agent starts a remote object. After obtaining the application identification information of the second rule object, a copy of the preset object mapping table is created. The process of creating the copy information may specifically include:
[0112] Step A6: Determine the first index variable of each rule array in the preset object mapping table, wherein the first index variable represents the position of each rule array in the object mapping table;
[0113] Step A7: Calculate the second index variable based on the first index variable, and create a target rule array at the position indicated by the second index variable;
[0114] Step A8: Copy the contents of each rule array to the target rule array to obtain the copy information of the object mapping table, wherein the second index variable represents the position of the target rule array in the object mapping table.
[0115] When creating a copy of the object map, the index variable for each rule array is first determined. This index variable can be the subscript of the rule array, representing its position in the object map, such as the row and column it belongs to. Then, based on this index variable, the next index variable corresponding to each rule array is calculated, thereby determining the position of each rule array in the copy. A new rule array is created at the position indicated by the calculated index variable, and the contents of each rule array in the object map are copied into the newly created rule array, resulting in the copy of the object map. The calculated index variable represents the position of each newly created rule array in the object map.
[0116] Specifically, the object mapping table contains multiple rule arrays, such as map<(appid,cmd),RuleObject>, where RuleObject = rules[index][(appid,cmd)], and index is the index variable of the rule array in the current object mapping table. In the object mapping table, the rule object is one of the constituent elements of the rule array, and the index variable is associated with the rule array through the rule object. After the agent thread receives a new rule engine file, it obtains the values of appid and cmd of the rule engine file, compiles the rule engine file into a new rule object newRuleObject, and calculates the index variable of the rule array in the corresponding replica information, i.e., the second index variable, based on the index variables of each rule array in the current object mapping table. The calculation method of the second index variable nextIndex can refer to the following formula 1:
[0117] nextIndex = (index + 1) % 2 (1)
[0118] Here, `index` represents the index variable of the rule array in the object mapping table, and `nextIndex` is the index variable of the rule array in the replica information of the object mapping table. There is a one-to-one correspondence between the object mapping table and the rule array in its replica information. It can be seen that the calculation method of the index variable of each rule array in the replica information is not limited to this. A new rule array `rules` is created based on the calculated index variable, and the content of the array at index `index` in the object mapping table is copied to the array at index `nextIndex`, thereby creating the replica information of the object mapping table.
[0119] Furthermore, after creating the replica information, the rule objects in the replica information are traversed to determine whether a third rule object with the same appid and cmd values as the second rule object to be published exists in the created replica information. If it exists, the third rule object is directly replaced by the second rule object to be published. If it does not exist, the rule object <(appid,cmd),RuleObjectnew> is added to the replica information in the object mapping table. In the replica information of the object mapping table, rules[nextIndex][(appid,cmd)] = RuleObjectnew, and the index variable of the new rule object is nextIndex, thus completing the update of the replica information in the object mapping table.
[0120] Then, the updated copy information is used to replace the original object mapping table, thus completing the update. Further, when replacing the original object mapping table with the updated copy information, the current index variable `index` is assigned the new index variable `nextIndex`, thereby completing the update. It should be noted that when assigning a value to the index variable, it is necessary to determine whether the rule object corresponding to the index variable has a running worker process. If it does, the replacement is performed after the worker process has finished running. If the rule object does not currently have a running worker process, the assignment operation can proceed. After the object mapping table is updated, when a new business request is received, the rule engine application only needs to obtain the `appid` and `cmd` values to index the corresponding updated rule object in the object mapping table. Furthermore, hot updates do not affect the execution of existing old rules.
[0121] It is known that ZooKeeper can be used to notify the release information during the release phase. The rule engine application can periodically pull the rule engine file to be released from the rule engine application platform. If the rule engine file to be released is obtained, the release operation is performed.
[0122] After the agent process in the rule engine application completes the deployment of the rule engine application, it modifies the deployment result directory in ZooKeeper and reports the deployment results. When the rule engine management console detects that the deployment node has been modified, it reads the deployment results in the deployment node and displays them to the user. The deployment results include deployment success and deployment failure. When deployment fails, the displayed deployment results may include the reason for the deployment failure or error message.
[0123] In this embodiment, the rule engine file is published via hot update, eliminating the need to copy files or restart the rule engine application, thus reducing publication costs and improving efficiency. Furthermore, by optimizing the traditional hot update method for replacement processes, the rule objects are updated using an object mapping table to complete the hot update of the rule engine file. This achieves rapid hot updates without affecting existing running rules, improving system availability and stability.
[0124] Based on the first and / or second embodiments described above, a third embodiment of the verification and publishing method for the rule engine of the present invention is proposed. This embodiment is the step after step S60 in the above embodiments. In step S60, after the publishing of the rule engine file is completed, the rule engine management console needs to obtain the publishing result of the rule engine application on the rule engine file.
[0125] Specifically, in various embodiments of the present invention, there can be multiple rule engine management consoles and rule engine applications. Each rule engine application needs to listen to the publishing node in ZooKeeper because each rule engine application needs to respond to publishing events. Furthermore, each rule engine management console needs to listen to the publishing result directory of the rule engine application to obtain the publishing results after the rule engine file is published. If there are multiple rule engine management consoles, only one console needs to listen to the publishing results reported by the rule engine application and then save the publishing results to the database. Therefore, a distributed lock scheme based on ZooKeeper needs to be designed, allowing multiple management consoles to compete for the lock, and the console that obtains the lock listens to the publishing result directory.
[0126] The existing distributed lock scheme works as follows: a ZooKeeper node is designated as the lock node. Each rule engine management console waits for the lock to be released and then acquires it. When the lock is released, each rule engine management console competes to acquire it. The rule engine management console that wins the competition creates a lock node to hold the lock. Once the rule engine management console holding the lock reads the publication result, it exits the publication process and releases the lock. If the lock node does not exist or lock node creation fails, the rule engine management console needs to release the lock and wait for the next lock release so that other rule engine management consoles can acquire the lock.
[0127] This solution is simple to implement, but when multiple client rule engine management consoles are waiting for the lock, once the lock is released, all the rule engine management consoles waiting for the lock will compete for the lock at the same time, triggering the thundering herd effect, which can easily cause congestion or anomalies.
[0128] Therefore, in this embodiment, the distributed lock scheme has been improved. Specifically, in step S50 above, after receiving the user's publish request instruction, it may further include:
[0129] Step B1: Create a child node under the lock node in ZooKeeper according to the published request instruction;
[0130] Step B2: Obtain the publishing result of the rule engine file according to the arrangement order of the child nodes.
[0131] In this embodiment, a persistent lock is first created in ZooKeeper. When the rule engine management console wants to publish a rule engine file, a child node is created under the lock node. Each rule engine management console acquires the lock in turn according to the order of its own child nodes and listens to the publication result directory in ZooKeeper, thereby obtaining the publication result of the rule engine file.
[0132] Furthermore, after the rule engine file is published, the rule engine management console acquires locks sequentially based on the child nodes, which mainly includes:
[0133] Step C1: Control the target child node that is ranked first to acquire the lock according to the arrangement order of the child nodes;
[0134] Step C2: After the target child node acquires the lock, obtain the publication result of the rule engine file corresponding to the target child node;
[0135] Step C3: When the publication result of the rule engine file corresponding to the target child node is obtained, delete the target child node to release the lock, return and execute the step of controlling the target child node ranked first to acquire the lock according to the arrangement order of the child nodes, until the target child node is the last child node.
[0136] In this embodiment, when the rule engine management console needs to publish a rule engine file, it needs to create temporary sequential child nodes under the lock node. The first child node in the sequence acquires and holds the lock. After acquiring the lock, the rule engine management console corresponding to this child node executes the task of obtaining the publication result. Upon reading the publication result, it deletes its own created child node, releases the lock, and the next child node becomes the first node in the sequence, thus acquiring the lock. Each child node determines whether it is the first child node by listening to its predecessor. Specifically, when a child node detects that its predecessor has been deleted, it can determine that it has become the first child node in the sequence, and thus can acquire and hold the lock.
[0137] After acquiring the lock, the rule engine management console retrieves the publication results of the rule engine files, mainly including:
[0138] Step C01: When each rule engine application completes the publication of the rule engine file, it writes the publication result of the rule engine file into the publication result directory.
[0139] Step C02: When it is detected that the published result directory has been modified, determine the target rule engine management console corresponding to the target sub-node;
[0140] Step C03: Control the target rule engine management console to read and output the publication results in the publication results directory.
[0141] When each rule engine application completes the publication of the rule engine file, it writes the publication result to the publication result directory in ZooKeeper. When the rule engine management console detects that the publication result directory has been modified, it listens for the publication result according to the order of the child nodes it created. Each rule engine management console determines whether its own child node is in the first position based on the order of the child nodes it created. If it is, it acquires the lock and listens for the publication result; otherwise, it continues to wait for the lock.
[0142] Specifically, before acquiring the lock, each client's rule engine management console creates a child node under the lock, i.e., a temporary sequential node. For example, client 1's rule engine management console creates a sequential node "0001", and client 2's rule engine management console creates a sequential node "0002", thus forming a waiting queue of sequential nodes. Each rule engine management console reads all sequential nodes under the lock node and determines whether its own created sequential node is the first node in the queue. If not, it needs to wait for the lock to be released and listen to the previous sequential node in the lock waiting queue. For example, if the node "0001" created by client 1's rule engine management console is the first in the queue, it means that client 1's rule engine management console has acquired the lock. However, the node "0002" created by client 2's rule engine management console is the second in the queue, so client 2's rule engine management console needs to wait for the lock and listen to the "0001" node.
[0143] Once the rule engine file of the client that acquired the lock is published, it releases the lock by deleting the sequential node it created. At this point, the rule engine management console of another client listening to that node detects that its previous node has been deleted, meaning the rule engine management console of the previous node has released the lock. This client's rule engine management console can then acquire the lock. For example, if client 1's rule engine management console deletes the node "0001", when client 2's rule engine management console detects the notification of the deletion of node "0001", it can determine that it is the first node in the child node queue and therefore can acquire the lock. This process continues, and the rule engine management console that acquires the lock can then listen to the publication results. The client's rule engine management console can acquire the lock sequentially based on the order in which it created its temporary sequential nodes, preventing multiple clients from competing for the lock.
[0144] In this embodiment, by optimizing the distributed lock scheme and adopting a queue mechanism, the rule engine management console that needs to publish rule engine files creates child nodes under the pre-created persistent lock node. The rule engine management console acquires the lock sequentially according to the created child nodes and listens for the publishing results. This avoids the thundering herd effect caused by multiple rule engine management consoles competing for the lock when it is released, which is common in traditional distributed lock schemes. This can reduce system congestion and further improve system stability.
[0145] The present invention also provides a verification and publishing device for a rule engine, referring to... Figure 5 The verification and publishing device of the rule engine includes:
[0146] Rule creation module 10 is used to obtain rule editing instructions and generate target rules according to the rule editing instructions;
[0147] The test set creation module 20 is used to receive verification instructions and create a test set according to the verification instructions, wherein the test set includes test cases and expected decision results;
[0148] The rule compilation module 30 is used to compile the target rule into a first rule object, and execute the test cases in the test set according to the first rule object to obtain the test decision result;
[0149] The rule verification module 40 is used to compare the test decision result with the expected decision result, verify the target rule according to the comparison result, and if the verification fails, return and execute the step of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes, and then generate a rule engine file according to the target rule.
[0150] The rule parsing module 50 is used to receive a publishing request instruction and parse the rule engine file into a second rule object according to the publishing request instruction;
[0151] The rule publishing module 60 is used to publish the rule engine file by hot-updating the preset object mapping table using the second rule object.
[0152] Optionally, the rule publishing module 60 is further configured to:
[0153] Obtain the application identifier information of the second rule object and create a copy of the preset object mapping table;
[0154] Traverse each rule object in the replica information to determine whether there is a third rule object in the replica information that has the same application identifier information as the second rule object;
[0155] If it exists, replace the third rule object with the second rule object to update the copy information;
[0156] If it does not exist, the second rule object is added to the replica information to update the replica information;
[0157] The object mapping table is updated by replacing it with the updated copy information.
[0158] Optionally, the rule publishing module 60 is further configured to:
[0159] Determine the first index variable of each rule array in a preset object mapping table, wherein the first index variable represents the position of each rule array in the object mapping table;
[0160] Calculate the second index variable based on the first index variable, and create a target rule array at the position indicated by the second index variable;
[0161] The contents of each rule array are copied into the target rule array to obtain the copy information of the object mapping table, wherein the second index variable represents the position of the target rule array in the object mapping table.
[0162] Optionally, the rule parsing module 50 is further configured to:
[0163] Create a child node under the lock node in ZooKeeper according to the published request instruction;
[0164] The publishing result of the rule engine file is obtained based on the arrangement order of the child nodes.
[0165] Optionally, the rule parsing module 50 is further configured to:
[0166] The target child node that is first in the order of the child nodes is controlled to acquire the lock;
[0167] After the target child node acquires the lock, the publication result of the rule engine file corresponding to the target child node is obtained;
[0168] When the publication result of the rule engine file corresponding to the target child node is obtained, the target child node is deleted to release the lock, and the process returns to and executes the step of controlling the target child node ranked first to acquire the lock according to the arrangement order of the child nodes, until the target child node is the last child node.
[0169] Optionally, the verification and publishing device of the rule engine further includes a node creation module, used for:
[0170] Create a publish node and a publish result directory in ZooKeeper, and start listening to the publish node and the publish result directory;
[0171] Based on the monitoring results, obtain the publication information and publication results of the rule engine file, wherein the publication information includes the publication time, file name, and rule version.
[0172] Optionally, the verification and publishing device of the rule engine further includes a result publishing module, used for:
[0173] When each rule engine application completes the publication of the rule engine file, it writes the publication result of the rule engine file into the publication result directory;
[0174] When the modification of the published results directory is detected, the target rule engine management console corresponding to the target sub-node is determined;
[0175] The target rule engine management console is controlled to read and output the publication results in the publication results directory.
[0176] The methods executed by the above-mentioned program units can be referred to in the various embodiments of the verification and release method of the rule engine of the present invention, and will not be repeated here.
[0177] The present invention also provides a terminal device, which includes: a memory, a processor, and a verification and publishing program for a rule engine stored in the memory and executable on the processor. The method implemented by the verification and publishing program for the rule engine when executed by the processor can be referred to various embodiments of the verification and publishing method for the rule engine of the present invention, which will not be repeated here.
[0178] The present invention also provides a computer storage medium.
[0179] The present invention stores a verification and publishing program for a rule engine on a computer storage medium. When the verification and publishing program for the rule engine is executed by a processor, it implements the steps of the verification and publishing method for the rule engine as described above.
[0180] The method implemented when the verification and publishing program of the rule engine running on the processor is executed can be referred to in various embodiments of the verification and publishing method of the rule engine of the present invention, and will not be repeated here.
[0181] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0182] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0183] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0184] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.
Claims
1. A method for verifying and publishing rules in a rules engine, characterized in that, The verification and deployment method of the rule engine is applied to the rule engine management system, and the verification and deployment method of the rule engine includes the following steps: Obtain rule editing instructions and generate target rules based on the rule editing instructions; Receive a verification instruction and create a test set according to the verification instruction, wherein the test set includes test cases and expected decision results; The target rule is compiled into a first rule object, and the test cases in the test set are executed according to the first rule object to obtain the test decision result; The test decision result is compared with the expected decision result. The target rule is verified based on the comparison result. If the verification fails, the process returns to and executes the steps of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes. Then, a rule engine file is generated based on the target rule. Receive a publish request instruction, and parse the rule engine file into a second rule object according to the publish request instruction; The second rule object is used to hot update the preset object mapping table to complete the publication of the rule engine file; The step of using the second rule object to hot update the preset object mapping table includes: Obtain the application identifier information of the second rule object and create a copy of the preset object mapping table; Traverse each rule object in the replica information to determine whether there is a third rule object in the replica information that has the same application identifier information as the second rule object; If it exists, replace the third rule object with the second rule object to update the copy information; If it does not exist, the second rule object is added to the replica information to update the replica information; The object mapping table is updated by replacing it with the updated copy information.
2. The verification and publishing method of the rule engine as described in claim 1, characterized in that, The object mapping table includes multiple rule arrays, and the step of creating a copy of the preset object mapping table includes: Determine the first index variable of each rule array in a preset object mapping table, wherein the first index variable represents the position of each rule array in the object mapping table; Calculate the second index variable based on the first index variable, and create a target rule array at the position indicated by the second index variable; The contents of each rule array are copied into the target rule array to obtain the copy information of the object mapping table, wherein the second index variable represents the position of the target rule array in the object mapping table.
3. The verification and publishing method of the rule engine as described in claim 1, characterized in that, Following the step of receiving the publish request instruction, the method further includes: Create a child node under the lock node in ZooKeeper according to the published request instruction; The publishing result of the rule engine file is obtained based on the arrangement order of the child nodes.
4. The verification and publishing method of the rule engine as described in claim 3, characterized in that, The step of obtaining the publishing result of the rule engine file according to the arrangement order of the child nodes includes: The target child node that is first in the order of the child nodes is controlled to acquire the lock; After the target child node acquires the lock, the publication result of the rule engine file corresponding to the target child node is obtained; When the publication result of the rule engine file corresponding to the target child node is obtained, the target child node is deleted to release the lock, and the process returns to and executes the step of controlling the target child node ranked first to acquire the lock according to the arrangement order of the child nodes, until the target child node is the last child node.
5. The verification and publishing method of the rule engine as described in claim 1, characterized in that, The verification and publishing method of the rule engine also includes: Create a publish node and a publish result directory in ZooKeeper, and start listening to the publish node and the publish result directory; Based on the monitoring results, obtain the publication information and publication results of the rule engine file, wherein the publication information includes the publication time, file name, and rule version.
6. The verification and publishing method of the rule engine as described in any one of claims 1 to 5, characterized in that, The rule engine management system includes multiple rule engine management consoles and multiple rule engine applications. After the step of using the second rule object to hot-update the preset object mapping table and complete the publication of the rule engine file, it further includes: When each rule engine application completes the publication of the rule engine file, it writes the publication result of the rule engine file into the publication result directory; When the published results directory is detected to have been modified, the target rule engine management console corresponding to the target sub-node is determined. The target rule engine management console is controlled to read and output the publication results in the publication results directory.
7. A verification and publishing device for a rules engine, characterized in that, The verification and publishing system of the rule engine includes: The rule creation module is used to obtain rule editing instructions and generate target rules based on the rule editing instructions; A test set creation module is used to receive verification instructions and create test sets according to the verification instructions, wherein the test set includes test cases and expected decision results; The rule compilation module is used to compile the target rule into a first rule object, and execute the test cases in the test set according to the first rule object to obtain the test decision result; The rule verification module is used to compare the test decision result with the expected decision result, verify the target rule according to the comparison result, and if the verification fails, return and execute the step of obtaining the rule editing instruction and generating the target rule according to the rule editing instruction until the verification passes, and then generate a rule engine file according to the target rule. The rule parsing module is used to receive a publishing request instruction and parse the rule engine file into a second rule object according to the publishing request instruction; The rule publishing module is used to publish the rule engine file by hot-updating the preset object mapping table using the second rule object; The step of using the second rule object to hot update the preset object mapping table includes: Obtain the application identifier information of the second rule object and create a copy of the preset object mapping table; Traverse each rule object in the replica information to determine whether there is a third rule object in the replica information that has the same application identifier information as the second rule object; If it exists, replace the third rule object with the second rule object to update the copy information; If it does not exist, the second rule object is added to the replica information to update the replica information; The object mapping table is updated by replacing it with the updated copy information.
8. A terminal device, characterized in that, The terminal device includes: a memory, a processor, and a rule engine verification and publishing program stored in the memory and executable on the processor. When the rule engine verification and publishing program is executed by the processor, it implements the steps of the rule engine verification and publishing method as described in any one of claims 1 to 6.
9. A computer storage medium, characterized in that, The computer storage medium stores a verification and publishing program for the rule engine, which, when executed by a processor, implements the steps of the verification and publishing method for the rule engine as described in any one of claims 1 to 6.