A rule analysis method and a rule analyzer

Abstract

The application relates to the field of Fintech, and discloses a rule analysis method and a rule analyzer. The rule analyzer extracts variables from a webpage request received in front end based on user triggering. If the rule analyzer determines that a first to-be-verified variable is extracted, the rule analyzer matches a target rule with the same name as the first to-be-verified variable from a rule library, and obtains first to-be-verified data of the first to-be-verified variable in the webpage request. The rule library is obtained by configuring each to-be-verified variable set, and the rule library includes multiple rules. Any rule includes a to-be-verified variable and a compliance syntax specification for defining a variable value of the to-be-verified variable. The rule analyzer verifies the first to-be-verified data based on the target rule. The scheme can verify the compliance of various types of data entering various business systems without writing rules in a declarative manner in business code.

Description

Technical Field

[0001] This application relates to the field of financial technology (Fintech), and more particularly to a rule parsing method and a rule parser. Background Technology

[0002] With the development of computer technology, more and more technologies (such as cloud computing, big data, and blockchain) are being applied in the financial sector, and the traditional financial industry is gradually transforming into fintech. In the context of fintech, various business systems are constantly emerging, such as decision-making systems and intelligent marketing systems. During user interaction with these systems, the systems monitor whether user information meets certain rules they have set. Only when these rules are met can the systems better understand and manage user information, thereby providing a better user experience.

[0003] Currently, each business system has its own rule engine. For any given business system, technical personnel pre-define certain specifications, or rules, for the data it requires within the rule engine; these rules are declaratively recorded in the business code. Furthermore, current rule engines can only validate character-based data using regular expressions.

[0004] The rule engine of the business system described above has the following disadvantages:

[0005] 1. Due to the different business systems, technical personnel need to manually configure a completely new rule engine, meaning that the current rule engine is not universally applicable. In addition, when it is necessary to update the rules in the rule engine that is in use, technical personnel are required to suspend the use of the business system and re-modify the business code to define the new rules, which is obviously not convenient for the normal use of the business system.

[0006] 2. Since the current rule engine can only validate character data and cannot be extended to validate other types of data, its data validation settings are not perfect.

[0007] In summary, there is an urgent need for a rule engine that is highly universal, consistent, and capable of more comprehensive data verification, in order to make reasonable and efficient judgments on the data. Summary of the Invention

[0008] This application provides a rule parsing method and a rule parser, which can perform compliance verification on various types of data entering various business systems without having to write the rules in a declarative manner in the business code.

[0009] In a first aspect, embodiments of this application provide a rule parsing method, the method comprising: a rule parser extracting variables from a user-triggered webpage request received by a front-end; if the rule parser determines that a first variable to be verified has been extracted, it matches a target rule with the same name as the first variable to be verified from a rule base, and obtains the first data to be verified of the first variable to be verified in the webpage request; the rule base is obtained by configuring various variables to be verified, and the rule base includes multiple rules, each rule including the variable to be verified and a compliant syntax specification for defining the variable value of the variable to be verified; the rule parser verifies the first data to be verified based on the target rule.

[0010] For applications written in JavaScript, parsing syntax using a parser is a standard procedure. Therefore, in this embodiment, various rules are pre-configured in a rule base. Each rule includes a variable to be validated and a compliant syntax specification defining the variable's value. Thus, when a user-triggered webpage request enters the front end, the rule parser in the front end can parse the request, including extracting variables, determining the data to be validated and the target rule used to validate the data, and then using the target rule to validate the data to determine whether the webpage request conforms to the application's original development intent. This approach uses rules for data validation configured in a rule base and a rule parser to validate those rules. This eliminates the need to set up separate rule engines for different business systems. Furthermore, because the business system is written in JavaScript, data validation doesn't require repeatedly setting up new rule engines for different business systems. When rules need updating, the business system doesn't need to be stopped; only the rules in the rule base need to be updated. Finally, the data validation in this application is diverse, requiring only the definition of compliant syntax for validating variable values, rather than being limited to validating character data.

[0011] In one possible implementation, the set variables to be verified include static variables transmitted based on a first set style and dynamic variables transmitted based on a second set style; the rule parser extracts variables from the user-triggered webpage requests received by the front end, including: the rule parser extracts variables from the received user-triggered webpage requests based on a first regular expression and a second regular expression, respectively; the first regular expression is used to match the variables to be verified based on the first set style in the webpage request, and the second regular expression is used to match the variables to be verified based on the second set style in the request.

[0012] In the above solution, for scenarios where the business system may require users to actively input personal information (i.e., form filling scenarios), the required information can be entered manually by the user (e.g., entering an ID number), or the user can manually insert a link to retrieve that information (e.g., when filling in personal experience information, if the user has already set up a webpage for their personal experience, they can directly enter the link to that webpage). For the information entered by the user in a certain field, the business system needs to determine whether the information is compliant; that is, the business system needs to validate the information entered by the user. In this application embodiment, for scenarios where the user manually inputs the required information for a certain field, the field can be defined as a static variable to be validated in the business system. However, for scenarios where the user obtains the required information for a certain field by introducing a related link, the field can be defined as a dynamic variable to be validated in the business system. In this application embodiment, the static and dynamic variables to be validated behave differently when the user triggers a webpage request and the request is transmitted to the front-end rule parser. The static variable to be validated can be transmitted using a first preset style, while the dynamic variable to be validated can be transmitted using a second preset style. The data is transmitted in rows, so that when the rule parser receives a webpage request triggered by a user, it can extract variables from the webpage request using a first regular expression and a second regular expression. If the webpage request contains static variables to be verified, it can be matched using the first regular expression, and if the webpage request contains dynamic variables to be verified, it can be matched using the second regular expression. This allows for the subsequent matching of a verification rule named after the matched variable from the rule base, and then the verification rule is used to perform compliance verification on the data to be verified in the webpage request for the matched variable.

[0013] In one possible implementation, the first variable to be verified includes a first static variable to be verified; if the rule parser determines that the first variable to be verified has been extracted, it obtains the first data to be verified of the first static variable in the web page request, including: if the rule parser determines that the first static variable to be verified has been extracted, it obtains data with the same name as the first static variable to be verified from the business data, and uses it as the first data to be verified of the first static variable in the web page request.

[0014] In the above scheme, after the rule parser matches the static variable to be verified (i.e., the first static variable to be verified) from the web page request by using the first regular expression, it can obtain data with the same name as the static variable to be verified from the business data, and use the obtained data as the data to be verified for the static variable to be verified in the web page request. Then, the rule parser can use the compliance syntax specification defined by the variable value of the static variable to be verified in the verification rule named after the static variable to be verified in the rule base to verify the data to be verified, so as to determine the compliance of the web page request.

[0015] In one possible implementation, the first variable to be verified includes a first dynamic variable to be verified; if the rule parser determines that the first variable to be verified has been extracted, it obtains the first data to be verified for the first variable in the webpage request, including: if the rule parser determines that the first dynamic variable to be verified has been extracted, it obtains the address information pointed to by the first dynamic variable to be verified from the webpage request based on the target rule; the rule parser constructs an HTTP request based on the address information and sends it; the rule parser uses the data returned by the HTTP request as the first data to be verified.

[0016] In the above scheme, after the rule parser matches the dynamic variable to be verified (i.e., the first dynamic variable to be verified) from the web page request using the second regular expression, it can obtain the address information pointed to by the dynamic variable to be verified from the web page request according to the target rule. Then, the rule parser can construct an HTTP request based on the address information and send it. Finally, the rule parser can use the data returned for the HTTP request as the data to be verified for the dynamic variable to be verified in the web page request. Thus, the rule parser can use the compliance syntax specification made by the variable value of the dynamic variable to be verified in the verification rule named after the dynamic variable in the rule base to verify the data to be verified, so as to determine the compliance of the web page request.

[0017] In one possible implementation, the rule parser verifies the first data to be verified based on the target rule, including: the rule parser parses the target rule based on a configured rule execution function to determine the first compliant syntax specification corresponding to the first variable to be verified; the rule parser verifies the first data to be verified according to the first compliant syntax specification.

[0018] In the above scheme, by pre-configuring the rule execution function, when the rule parser obtains the target rule for verifying the first data to be verified in the web page request for the first variable to be verified, the rule parser can use the configured rule execution function to parse the target rule, thereby obtaining the first compliance syntax specification corresponding to the first variable to be verified. Finally, the rule parser can verify the first data to be verified according to the obtained first compliance syntax specification to determine the compliance of the web page request.

[0019] In one possible implementation method, the plurality of rules includes static rules and dynamic rules; the rule base is obtained by configuring each set variable to be verified, including: for any variable to be verified among the set variables to be verified, if it is determined that the variable to be verified satisfies the static rule, then the variable to be verified and the method having the variable to be verified are configured in the rule base; if it is determined that the variable to be verified satisfies the dynamic rule, then the variable to be verified and the method for dynamically obtaining the data to be verified corresponding to the variable to be verified are configured in the rule base.

[0020] The above scheme describes the formation process of the rule base, which involves configuring rules for each variable to be validated. These rules are the compliant syntax specifications used to validate the values ​​of the variables to be validated. Finally, the centralized management of each variable to be validated and its corresponding rules constitutes the rule base. The rule base includes rules configured for variables to be validated that satisfy static rules (static rules) and rules configured for variables to be validated that satisfy dynamic rules (dynamic rules). Specifically, for a variable to be validated that satisfies static rules, the variable and its corresponding methods can be configured in the rule base. For a variable to be validated that satisfies dynamic rules, the variable and the method for dynamically obtaining the corresponding data to be validated can be configured in the rule base. This method uses a rule base to configure the compliant syntax specifications for the data to be validated corresponding to the variables required by the business system. Subsequently, the rule parser can perform compliance validation on received requests based on the configured rule base.

[0021] In one possible implementation, the method further includes: the rule parser validating external access requests; wherein the external access request is an access request sent via API received by the backend server, and the rule parser obtains it by configuring com.eclipsesource.j2v8 in maven pom.xml.

[0022] In the above solution, for some webpage requests that are not initiated by the user but sent via API (i.e., external access requests), when they reach the backend server, since com.eclipsesource.j2v8 has been configured in the Maven pom.xml file beforehand, the backend server can load the frontend rule parser and validate the external access requests based on the rule parser. This method achieves compliance validation for cross-platform access requests.

[0023] Secondly, embodiments of this application provide a rule parser, which includes: a variable extraction unit, used to extract variables from a user-triggered webpage request received by the front end; a processing unit, used to, if it is determined that a first variable to be verified has been extracted, match a target rule with the same name as the first variable to be verified from a rule base, and obtain the first data to be verified of the first variable to be verified in the webpage request; the rule base is obtained by configuring each set variable to be verified, and the rule base includes multiple rules, each rule including the variable to be verified and a compliant syntax specification for defining the variable value of the variable to be verified; and a verification unit, used to verify the first data to be verified based on the target rule.

[0024] Thirdly, embodiments of this application provide a computing device, including:

[0025] Memory, used to store program instructions;

[0026] A processor is configured to invoke program instructions stored in the memory and execute any implementation method of the first aspect according to the obtained program.

[0027] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform any implementation method as described in the first aspect. Attached Figure Description

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

[0029] Figure 1 A schematic diagram illustrating a rule parsing method provided in an embodiment of this application;

[0030] Figure 2 A schematic diagram of a rule parser provided in an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] For some currently deployed business systems, technical personnel are often required to declaratively record rules in the business code to form a rule engine. Furthermore, rule engines developed in this way are mostly used for character data validation in backend scenarios. Therefore, different business systems require the development of a corresponding rule engine, which obviously requires a significant workload. In addition, because the current rule engine is tightly coupled with the business code, updating existing rules requires suspending the use of the business system, which obviously hinders its normal operation. Finally, the current rule engine cannot validate a wide range of data.

[0034] To address the aforementioned technical problems, embodiments of this application provide a rule parsing method. For example... Figure 1 The diagram shown is a schematic representation of a rule parsing method provided in an embodiment of this application. The method includes the following steps:

[0035] Step 101: The rule parser extracts variables from the web page requests triggered by the user received by the front end.

[0036] In this step, for user operations on the business system, such as form filling, when a user fills in relevant information in a field of the form, the business system (specifically, the rule parser within the business system) can validate the information entered by the user to determine whether the information meets the constraints and specifications established by the business system during development regarding the values ​​that can be entered in that field. Therefore, this scenario of a user filling in relevant information in a form field triggers a web page request, which can be received by the front-end rule parser after being triggered. After receiving the web page request, the rule parser can extract variables from the web page request.

[0037] It should be noted that the business system involved in this application embodiment is written and developed using the JavaScript language; as an example, the rule parser can be rule-engineer.js, which, as the front-end rule parsing engine, will follow the JavaScript language specification.

[0038] Step 102: If the rule parser determines that the first variable to be verified has been extracted, it matches the target rule with the same name as the first variable to be verified from the rule base, and obtains the first data to be verified of the first variable to be verified in the web page request.

[0039] The rule base is configured by setting each variable to be verified. The rule base includes multiple rules, and each rule includes the variable to be verified and a compliant syntax specification for defining the variable value of the variable to be verified.

[0040] In this step, for a business system, technical personnel can pre-configure which data in the system needs to be validated and which data does not. The data requiring validation are the variables to be validated. For each variable to be validated, technical personnel also need to configure the compliance syntax for validating its value. Through these two configuration steps, a corresponding rule can be formed for any data in the business system that needs to be validated. Based on these rules, a rule base can be formed. Each rule in the rule base can be named using the variable name of the corresponding variable to be validated. This allows the rule parser to directly match the validation rule with the same name from the rule base to perform data compliance verification.

[0041] During the process of the rule parser extracting variables from web page requests, the following two types of variable extraction results may occur:

[0042] Scenario 1: No variable to be validated was retrieved. This means that the variable to be validated does not exist in the current webpage request.

[0043] Scenario 2: The variable to be validated can be extracted. This indicates that there is a variable in the current webpage request that needs to be validated, and this variable is the first variable to be validated. In this case, the rule parser can confirm that it needs to validate the extracted first variable to be validated. To validate the first variable to be validated, the rule parser can match a validation rule with the same name as the first variable to be validated from the rule base. At the same time, it also needs to obtain the data to be validated for the first variable to be validated in the current webpage request. The validation rule is the target rule, and the data to be validated is the first data to be validated.

[0044] Step 103: The rule parser verifies the first data to be verified based on the target rule.

[0045] In this step, once the rule parser confirms that it can extract the variable to be verified, i.e. the first variable to be verified, from the web page request, and matches the target rule with the same name as the first variable to be verified from the rule base and obtains the first data to be verified of the first variable to be verified in the web page request, the rule parser can verify the first data to be verified based on the matched target rule to determine the compliance of the first data to be verified.

[0046] For applications written in JavaScript, parsing syntax using a parser is a standard procedure. Therefore, in this embodiment, various rules are pre-configured in a rule base. Each rule includes a variable to be validated and a compliant syntax specification defining the variable's value. Thus, when a user-triggered webpage request enters the front end, the rule parser in the front end can parse the request, including extracting variables, determining the data to be validated and the target rule used to validate the data, and then using the target rule to validate the data to determine whether the webpage request conforms to the application's original development intent. This approach uses rules for data validation configured in a rule base and a rule parser to validate those rules. This eliminates the need to set up separate rule engines for different business systems. Furthermore, because the business system is written in JavaScript, data validation doesn't require repeatedly setting up new rule engines for different business systems. When rules need updating, the business system doesn't need to be stopped; only the rules in the rule base need to be updated. Finally, the data validation in this application is diverse, requiring only the definition of compliant syntax for validating variable values, rather than being limited to validating character data.

[0047] The following will provide a detailed explanation of some of the steps mentioned above, with examples.

[0048] In one implementation of step 102 above, the plurality of rules includes static rules and dynamic rules; the rule base is obtained by configuring each set variable to be verified, including: for any variable to be verified among the set variables to be verified, if it is determined that the variable to be verified satisfies the static rule, then the variable to be verified and the method of the variable to be verified are configured in the rule base; if it is determined that the variable to be verified satisfies the dynamic rule, then the variable to be verified and the method of dynamically obtaining the data to be verified corresponding to the variable to be verified are configured in the rule base.

[0049] In some embodiments of this application, the set variables to be verified include static variables to be verified transmitted based on a first set style and dynamic variables to be verified transmitted based on a second set style.

[0050] For example, in scenarios where a business system requires users to actively input some personal information, i.e., form filling scenarios, the required information can be entered manually by the user, such as their name and ID number, or the user can manually insert a link to obtain that information. For example, when filling in information about personal experience, if the user has already set up a webpage for their personal experience, then the user can directly enter the link to the webpage containing their personal experience when filling in the information about their personal experience.

[0051] For the two information filling scenarios described above, assuming that the ID number field and the personal experience field are two variables to be verified that need to be pre-configured by the technicians and need to be verified for data compliance, then for the ID number variable to be verified, in this application embodiment, it can be considered to conform to the static rule, that is, the variable to be verified is a static variable to be verified. Therefore, it is necessary to configure the variable to be verified and the method that the variable to be verified has into a rule. Furthermore, multiple rules can constitute a set of rules.

[0052] For example, a static variable to be validated can be defined as [%key%], where key is the field name defined in the business logic. The type of key in the business logic determines which methods it has. For example, array-type variables can use the include method, and character-type variables can use the replace method, etc.

[0053] The following is a standard example:

[0054] [%key1%].include([%key2%])&&([%key3%]===="1")

[0055] Application examples are as follows:

[0056] For example, suppose the business system needs to identify whether the "data type" entered by the user matches the "sensitive information":

[0057] The validation rule can be configured as follows: [%dataclass%] == "details" && [%sensitiveLevel%] == "3"

[0058] The rule verification prompt is: In most cases, detailed data will contain first-level / second-level sensitive information. Please check whether the "data type" or "sensitive information" is filled in correctly.

[0059] For the variable to be verified, personal experience, in this embodiment, it can be considered to conform to dynamic rules, that is, the variable to be verified is a dynamic variable to be verified. Therefore, the variable to be verified and the method for dynamically obtaining the data to be verified corresponding to the variable to be verified need to be configured into a rule.

[0060] For example, unlike static rules, the definition method for dynamic variables to be verified in this embodiment differs from that for static variables. Dynamic variables to be verified can be defined as {{key}}, where key is the field name defined in the business logic. Furthermore, it is necessary to define how to dynamically obtain the data required for rule verification under this mode, i.e., to meet the scenario of dynamic information verification in actual applications. Defining the method for obtaining dynamic variable information includes defining the variable name and the method for obtaining the variable value. For example:

[0061] httpRequestUrl::METHOD=httpRequestUrlMethos? param1=value1¶m2=value1

[0062] Here, httpRequestUrl represents the HTTP request address for dynamically retrieving data; METHOD represents the HTTP request method for dynamically retrieving data, typically GET, POST, PUT, etc.; param1 and param2 represent the HTTP request parameters, and multiple param1 and param2 are supported; value1 and value2 represent the values ​​of the corresponding HTTP request parameters, and multiple value1 and value2 are supported.

[0063] Application examples:

[0064] For example, when identifying risks in marketing products, the verification rules can be configured as follows:

[0065] ([%usageScene%]=='11')&&(([%marketingProduct%].sort().toString()==[%products%].sort().toString())||([%products%].length>0&&[%products%].every(i=>['product1','product2','product3','product4'].includes(i))&&[%marketingProduct%].length>0&&[%marketingProduct%].every(i=>['product1','product2','product3','product4'].includes(i))))&&('{{selfMsgProducts}}'!=")

[0066] selfMsgProducts:getSelfMsgProducts::METHOD=post? scope=1

[0067] In one implementation of step 101 above, the rule parser extracts variables from the user-triggered webpage request received by the front end, including: the rule parser extracts variables from the received user-triggered webpage request based on a first regular expression and a second regular expression, respectively; the first regular expression is used to match the variable to be verified in the webpage request based on the first set style, and the second regular expression is used to match the variable to be verified in the request based on the second set style.

[0068] Based on the aforementioned example, the static and dynamic variables to be verified are defined as [%key%] and {{key}}, respectively, which are the first and second setting styles. Therefore, after receiving a webpage request, the rule parser can use regular expressions to match the key of the static rule and the key of the dynamic rule.

[0069] For example, in this embodiment, the regular expression `staticKeys=rules.match( / (?<=\[%)(.*?)(?=\%]) / g)` can be used to match the key of a static rule, and the regular expression `dynamicKeys=rules.match( / (?<=\{\{)(.*?)(?=\}\}) / g)` can be used to match the key of a dynamic rule. Here, `staticKeys=rules.match( / (?<=\[%)(.*?)(?=\%]) / g)` is the first regular expression, and `dynamicKeys=rules.match( / (?<=\{\{)(.*?)(?=\}\}) / g)` is the second regular expression.

[0070] In some embodiments of this application, the first variable to be verified includes a first static variable to be verified; if the rule parser determines that the first variable to be verified has been extracted, it obtains the first data to be verified of the first variable to be verified in the web page request, including: if the rule parser determines that the first static variable to be verified has been extracted, it obtains data with the same name as the first static variable to be verified from the business data, and uses it as the first data to be verified of the first static variable to be verified in the web page request.

[0071] In some embodiments of this application, the first variable to be verified includes a first dynamic variable to be verified; if the rule parser determines that the first variable to be verified has been extracted, it obtains the first data to be verified of the first variable to be verified in the web page request, including: if the rule parser determines that the first dynamic variable to be verified has been extracted, it obtains the address information pointed to by the first dynamic variable to be verified from the web page request based on the target rule; the rule parser constructs an HTTP request based on the address information and sends it; the rule parser uses the data returned by the HTTP request as the first data to be verified.

[0072] Based on the aforementioned example, when the rule parser obtains the variable to be verified from the webpage request based on regular expressions, if the obtained variable to be verified is matched by the first regular expression, it indicates that the variable to be verified is a static variable to be verified. Furthermore, it is necessary to obtain the variable value corresponding to this static variable to be verified; this variable value is the first data to be verified. Specifically, the rule parser can obtain the value corresponding to the key in `staticKeys` from the business data through key-value mapping and use it as the data to be verified.

[0073] Based on the aforementioned example, when the rule parser obtains the variable to be validated from the webpage request based on regular expressions, if the obtained variable to be validated is matched by the second regular expression, it indicates that the variable to be validated is a dynamic variable to be validated. Furthermore, it is also necessary to obtain the variable value corresponding to this dynamic variable to be validated; this variable value is the first data to be validated. The rule parser can parse dynamicKeys...

[0074] By using `httpRequestUrl::METHOD = httpRequestUrlMethos? param1 = value1` and `m2 = value1`, the address information pointed to by the dynamic variable to be verified is obtained. Then, the rule parser can construct an HTTP request based on the obtained address information and send it. Finally, the rule parser can obtain the dynamic value, that is, the rule parser can use the data returned for this HTTP request as the data that needs to be verified.

[0075] In one implementation of step 103 above, the rule parser verifies the first data to be verified based on the target rule, including: the rule parser parses the target rule based on the configured rule execution function to determine the first compliant syntax specification corresponding to the first variable to be verified; the rule parser verifies the first data to be verified according to the first compliant syntax specification.

[0076] For example, after the rule parser obtains the data to be verified for the variable to be verified in the web page request, the rule parser can map the corresponding value (i.e. the data to be verified) to the key in the rule through key mapping. The rule after mapping is as follows: value1.include(value1).

[0077] The technicians also predefined the following rule execution functions:

[0078] checkRule=ruleLogic=>new Function('dataObj',`return${ruleLogic}`);

[0079] Here, ruleLogic represents the validation rules pre-configured for the variable to be validated, and 'dataObj' represents the data to be validated corresponding to the variable to be validated.

[0080] Finally, the rule parser runs the rule execution function `checkRule` and returns a boolean value of `true` or `false`. A `true` value indicates that the rule parser confirms the data to be verified in the webpage request is compliant; a `false` value indicates that the rule parser confirms the data to be verified in the webpage request is non-compliant, in which case the rule parser can send an error message to the user.

[0081] Specifically: First, the checkRule source code is parsed by the parser into an AST (Abstract Syntax Tree), which is to structure the code into a tree-like representation. This is done so that the compiler or interpreter can better understand it. Then, the interpreter parses the AST into bytecode. Bytecode is an abstraction of machine code and can be seen as small building blocks. These building blocks are combined to form any JavaScript function. Bytecode takes up less memory than machine code, but bytecode cannot be run directly on the processor. It needs to be converted into machine code by the interpreter before it can be executed.

[0082] In some embodiments of this application, the rule parser verifies external access requests; wherein, the external access request is an access request sent via API received by the backend server, and the rule parser obtains it by configuring com.eclipsesource.j2v8 (extension library) into the maven pom.xml (project object model).

[0083] In practical applications, there are numerous scenarios where external applications directly request and submit data to local Java-based applications via APIs. Since these requests are initiated directly via HTTP and not through a webpage, they do not trigger user interaction and therefore cannot activate the front-end rule parser. To address this, this embodiment of the application designs the following computational process so that Java applications can also execute the complete rule parsing process and obtain accurate verification results:

[0084] 1. Include com.eclipsesource.j2v8 in the maven pom.xml file;

[0085] 2. Read rule-enginer.js:readFileToString("rule-enginer.js");

[0086] 3. Obtain the rule validation method checkRule:(V8Function)v8.getObject("checkRule");

[0087] 4. Prepare the data to be validated: data:V8Object, rules:V8Arrange;

[0088] 5. Perform rule validation: checkRule.call(null,data,rules) and return the validation result.

[0089] This process requires Java applications to use the V8 engine as their rule parser on the front end.

[0090] For example, suppose the business system needs to identify whether the "data type" entered by the user matches the "sensitive information":

[0091] The validation rule can be configured as follows: [%dataclass%] == "details" && [%sensitiveLevel%] == "3"

[0092] If external application A submits data `data: {dataclass: "summary", sensitiveLevel: "2"}` directly to application B's backend server via HTTP, application B's backend server needs to verify whether the submitted data `data` is true or false. In this case, application B's backend server directly loads application B's frontend rule parser, namely `rule-engineer.js`. The process by which `rule-engineer.js` performs compliance verification on the submitted data is the same as the request processing method described above, and will not be repeated here.

[0093] Based on the same concept, embodiments of this application provide a rule parser, such as... Figure 2 The diagram shown is a schematic of a rule parser provided in an embodiment of this application. The rule parser includes a variable extraction unit 201, a processing unit 202, and a verification unit 203.

[0094] The variable extraction unit 201 is used to extract variables from the web page request triggered by the user received by the front end.

[0095] The processing unit 202 is configured to, if it is determined that a first variable to be verified has been extracted, match a target rule with the same name as the first variable to be verified from the rule base, and obtain the first data to be verified of the first variable to be verified in the web page request; the rule base is obtained by configuring each set variable to be verified, and the rule base includes multiple rules, each rule including the variable to be verified and a compliant syntax specification for defining the variable value of the variable to be verified;

[0096] The verification unit 203 is used to verify the first data to be verified based on the target rule.

[0097] Furthermore, for the rule parser, the set variables to be verified include static variables transmitted based on a first set style and dynamic variables transmitted based on a second set style; the variable extraction unit 201 is specifically used to: extract variables from the received user-triggered web page requests based on a first regular expression and a second regular expression respectively; the first regular expression is used to match the variables to be verified based on the first set style in the web page request, and the second regular expression is used to match the variables to be verified based on the second set style in the request.

[0098] Furthermore, for the rule parser, the first variable to be verified includes a first static variable to be verified; the processing unit 202 is specifically used to: if it is determined that the first static variable to be verified has been extracted, then obtain data with the same name as the first static variable to be verified from the business data, and use it as the first data to be verified of the first static variable to be verified in the web page request.

[0099] Furthermore, for the rule parser, the first variable to be verified includes a first dynamic variable to be verified; the processing unit 202 is specifically used for: if it is determined that the first dynamic variable to be verified has been extracted, then obtaining the address information pointed to by the first dynamic variable to be verified from the web page request based on the target rule; constructing an HTTP request based on the address information and sending it; and using the data returned for the HTTP request as the first data to be verified.

[0100] Furthermore, for this rule parser, the verification unit 203 is specifically used to: parse the target rule based on the configured rule execution function to determine the first compliant syntax specification corresponding to the first variable to be verified; and verify the first data to be verified according to the first compliant syntax specification.

[0101] Furthermore, the rule parser also includes a rule configuration unit 204; the plurality of rules include static rules and dynamic rules; the rule configuration unit 204 is used to: for any variable to be verified among the set variables to be verified, if it is determined that the variable to be verified satisfies the static rule, then configure the variable to be verified and the method having the variable to be verified in the rule base; if it is determined that the variable to be verified satisfies the dynamic rule, then configure the variable to be verified and the method for dynamically obtaining the data to be verified corresponding to the variable to be verified in the rule base.

[0102] Furthermore, for this rule parser, the verification unit 203 is also used to verify external access requests; wherein, the external access request is an access request sent via API received by the backend server, and the rule parser obtains it by configuring com.eclipsesource.j2v8 in maven pom.xml.

[0103] This application also provides a computing device, which may specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), etc. The computing device may include a central processing unit (CPU), memory, input / output devices, etc. Input devices may include a keyboard, mouse, touchscreen, etc., and output devices may include display devices, such as liquid crystal displays (LCDs) and cathode ray tubes (CRTs).

[0104] The memory may include read-only memory (ROM) and random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In the embodiments of this application, the memory may be used to store program instructions for the rule parsing method;

[0105] The processor is used to call program instructions stored in the memory and parse them according to the obtained program execution rules.

[0106] like Figure 3 The diagram shown is a schematic representation of a computing device provided in an embodiment of this application. The computing device includes:

[0107] The processor 301, memory 302, transceiver 303, and bus interface 304 are included; wherein the processor 301, memory 302, and transceiver 303 are connected via bus 305.

[0108] The processor 301 is used to read the program in the memory 302 and execute the above rule parsing method;

[0109] Processor 301 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. It can also be a hardware chip. The aforementioned hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0110] The memory 302 is used to store one or more executable programs and can store data used by the processor 301 when performing operations.

[0111] Specifically, the program may include program code, which includes computer operation instructions. Memory 302 may include volatile memory, such as random-access memory (RAM); memory 302 may also include non-volatile memory, such as flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 302 may also include combinations of the above types of memory.

[0112] Memory 302 stores the following elements: executable modules or data structures, or subsets thereof, or extended sets thereof:

[0113] Operation instructions: This includes various operation instructions used to perform various operations.

[0114] Operating system: includes various system programs used to implement various basic business functions and handle hardware-based tasks.

[0115] Bus 305 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0116] Bus interface 304 can be a wired communication interface, a wireless bus interface, or a combination thereof. The wired bus interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless bus interface can be a WLAN interface.

[0117] This application also provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute a rule parsing method.

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

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

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

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

[0122] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0123] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A rule parsing method, characterized in that, include: The rule parser extracts variables from the user-triggered web page requests received by the front end; If the rule parser determines that a first variable to be verified has been extracted, it matches a target rule with the same name as the first variable to be verified from the rule base and obtains the first data to be verified of the first variable to be verified in the web page request. The rule base is obtained by configuring each set variable to be verified. The rule base includes multiple rules. Each rule includes a variable to be verified and a compliant syntax specification that defines the variable value of the variable to be verified. The rule parser verifies the first data to be verified based on the target rule; The variables to be verified include static variables transmitted based on a first set style and dynamic variables transmitted based on a second set style. The rule parser extracts variables from the user-triggered webpage requests received by the front end, including: The rule parser extracts variables from the received user-triggered web page requests based on a first regular expression and a second regular expression, respectively. The first regular expression is used to match the variables to be verified in the web page request based on the first set style, and the second regular expression is used to match the variables to be verified in the request based on the second set style. The rule parser verifies the first data to be verified based on the target rule, including: The rule parser parses the target rule based on the configured rule execution function to determine the first compliant syntax specification corresponding to the first variable to be verified. The rule parser verifies the first data to be verified according to the first compliance syntax specification; The rules include static rules and dynamic rules; The rule base is obtained by configuring the set variables to be verified, including: For any of the set variables to be verified, if it is determined that the variable to be verified satisfies the static rule, then the variable to be verified and the method that the variable to be verified has are configured in the rule base. If it is determined that the variable to be verified satisfies the dynamic rules, then the variable to be verified and the method for dynamically obtaining the data to be verified corresponding to the variable to be verified are configured in the rule base.

2. The method as described in claim 1, characterized in that, The first variable to be verified includes the first static variable to be verified; If the rule parser determines that a first variable to be verified has been extracted, it obtains the first data to be verified for the first variable in the webpage request, including: If the rule parser determines that the first static variable to be verified has been extracted, it obtains data with the same name as the first static variable to be verified from the business data and uses it as the first data to be verified for the first static variable to be verified in the web page request.

3. The method as described in claim 1, characterized in that, The first variable to be verified includes the first dynamic variable to be verified; If the rule parser determines that a first variable to be verified has been extracted, it obtains the first data to be verified for the first variable in the webpage request, including: If the rule parser determines that the first dynamic variable to be verified has been extracted, it obtains the address information pointed to by the first dynamic variable to be verified from the web page request based on the target rule. The rule parser constructs and sends an HTTP request based on the address information; The rule parser uses the data returned by the HTTP request as the first data to be verified.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: The rule parser verifies external access requests; wherein, the external access request is an access request sent via API received by the backend server, and the rule parser obtains it by configuring com.eclipsesource.j2v8 in the maven pom.xml.

5. A rule parser, characterized in that, include: The variable extraction unit is used to extract variables from the web page requests triggered by the user received by the front end. The processing unit is configured to, if it is determined that a first variable to be verified has been extracted, match a target rule with the same name as the first variable to be verified from the rule base, and obtain the first data to be verified of the first variable to be verified in the web page request; the rule base is obtained by configuring each set variable to be verified, and the rule base includes multiple rules, each rule including the variable to be verified and a compliant syntax specification for defining the variable value of the variable to be verified; A verification unit is used to verify the first data to be verified based on the target rule; The variables to be verified include static variables transmitted based on a first set style and dynamic variables transmitted based on a second set style. The variable extraction unit is specifically used to extract variables from the received user-triggered web page request based on a first regular expression and a second regular expression, respectively; the first regular expression is used to match the variable to be verified based on the first set style in the web page request, and the second regular expression is used to match the variable to be verified based on the second set style in the request. The verification unit is specifically used to parse the target rule based on the configured rule execution function to determine the first compliant syntax specification corresponding to the first variable to be verified. The first data to be verified is verified according to the first compliant syntax specification; The rules include static rules and dynamic rules; The rule configuration unit is used to configure the variable to be verified and the method it has in the rule base if it is determined that the variable to be verified satisfies the static rule for any of the set variables to be verified. If it is determined that the variable to be verified satisfies the dynamic rules, then the variable to be verified and the method for dynamically obtaining the data to be verified corresponding to the variable to be verified are configured in the rule base.

6. A computer device, characterized in that, include: Memory, used to store computer programs; A processor is configured to invoke a computer program stored in the memory and execute the method as described in any one of claims 1-4 according to the obtained program.

7. A computer-readable storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to perform the method as described in any one of claims 1-4.

Images