Method and system for realizing dynamic analysis and centralized management of cross-platform business rules based on GraalVM
By using a rule configuration center and distributed file system based on GraalVM, the system achieves isomorphic execution and centralized management of business rules across platforms, solving the problem of repeated coding of business rules on multiple platforms and improving the maintainability and consistency of the system.
Patent Information
- Application Number
- CN202511604905.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-05
- Publication Date
- 2026-01-16
AI Technical Summary
In modern distributed systems, the repeated encoding of business rules on multiple terminals and servers leads to logical duplication, maintenance difficulties, high risk of semantic inconsistency, and delayed updates. Furthermore, existing technologies have failed to effectively utilize GraalVM to achieve isomorphic execution and centralized management of cross-terminal business rules.
The rule configuration center generates business rule scripts in different code languages, which are stored in the MinIO distributed file system and relational database. GraalVM is used to create an isolated execution environment to achieve dynamic parsing and centralized management of cross-platform business rules. It supports visual configuration, multi-language script generation, centralized storage, dynamic distribution and isomorphic execution.
It achieves semantic consistency of rules across the entire chain, reduces development and maintenance costs, supports dynamic hot updates, has strong cross-platform compatibility, high security, and is suitable for business systems with complex rules and frequent changes.
Smart Images

Figure CN121349433A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application belongs to the technical field of computer software and system architecture, in particular to a method and system for realizing cross-platform business rule dynamic analysis and centralized management based on GraalVM. BACKGROUND
[0002] A modern distributed system is composed of multiple computers or computing terminal devices interconnected through a network, which cooperatively execute business rule verification to achieve common business goals and present a unified whole to users. In modern distributed systems, especially in rule-intensive scenarios such as tax declaration, business rules (such as form verification, permission judgment, data filtering, etc.) are complex and frequently changing, and usually need to be defined repeatedly in multiple terminals and server-side backend services. For example, rules such as age limit, email format, password strength when registering a user, regardless of creation or modification, need to be coded and implemented on different platforms such as business front-end, server back-end, and client.
[0003] The existing technology has the following problems:
[0004] (1) Logic duplication, maintenance difficulty: the same rule is repeatedly written on multiple ends, and is easy to miss when changing; high risk of semantic inconsistency: different platforms may have different understandings or implementations of rules;
[0005] (2) Update lag: rule changes need to be re-published to each end application, with a long response cycle;
[0006] (3) Lack of unified execution environment: traditional expression engines (such as JEXL, MVEL) only support unilateral execution, and cannot achieve true isomorphism.
[0007] In order to solve the above problems, existing technologies attempt to use JSONSchema or DSL to describe rules, but their expression ability is limited and it is difficult to support complex logic such as function calls, nested conditions, etc. If a scripting language is used, it has powerful expression ability, but it has been limited by the performance and security of the script engine for a long time. For example, JavaScript as a scripting language, its interpretation execution characteristics in the script engine of the Java platform at runtime, the performance is often not as good as the compiled language such as Java. In terms of security, the Java platform sets a strict sandbox environment for the script engine, limiting the ability of JavaScript to access system resources, although it protects the host environment, but also restricts the function of some scenarios.
[0008] GraalVM is a high-performance, multi-language virtual machine from Oracle that supports native execution of languages such as JavaScript, Python, Ruby, and R on the JVM. It provides: high-performance JIT compilation; a secure sandbox mechanism; seamless interoperability with Java objects; and support for Ahead-of-Time (AOT) compilation.
[0009] However, existing technologies have not yet effectively applied GraalVM to the isomorphic execution and centralized management of cross-platform business rules, especially in the area of sharing the same JavaScript validation script between the front-end and back-end, implementing a unified validation system that defines once and executes everywhere, which remains a gap. Summary of the Invention
[0010] This invention proposes a method and system for dynamic parsing and centralized management of cross-platform business rules based on GraalVM. It supports visual configuration, multi-language script generation, centralized storage, dynamic distribution, and isomorphic execution, solving problems such as logic duplication, maintenance difficulties, and delayed updates caused by repeated coding of business rules in the front end, back end, and various clients in existing business systems.
[0011] A method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM includes:
[0012] S1. Generate business rule scripts in different code languages through the rule configuration center, store them in the MinIO distributed file system as files, store them in the relational database as structured data, and establish metadata indexes; the business rule scripts are released after syntax validation and review for various terminals to call and execute;
[0013] S2. The business system front-end obtains business rule scripts compatible with the current terminal through the rule configuration center and metadata index, and performs local verification.
[0014] S3. When the front end persists data to the back end service, the server back end service creates an isolated and secure execution environment by integrating the GraalVM multi-language runtime engine, loads the same business rule script as the front end from the MinIO distributed file system, and performs same-origin rule verification.
[0015] S4. When business rules change, the rule configuration center updates the business rule script and stores it in the MinIO distributed file system as a file.
[0016] Furthermore, step S1 includes:
[0017] S101. In the rule configuration center, set the business that needs to be configured with verification rules, and configure the required verification indicator data items based on the logic of the business.
[0018] S102. Select the target code language through the visual configuration page of the rule configuration center, and construct the rule logic through graphical drag and drop;
[0019] S103. The rule configuration center generates language-independent rule expressions from the selected target code language, configured indicator data items, and constructed rule logic. Then, it calls the code generator corresponding to the target language and compiles the rule expressions into standardized business rule scripts that conform to the language specification based on the predefined syntax template.
[0020] Furthermore, the target code language is a code language that is commonly supported by all terminals in the current business scenario. If no such language is available, steps S102-S103 are executed repeatedly to configure business rule scripts in different code languages for different terminals.
[0021] Furthermore, step S3 specifically includes:
[0022] S301. The server backend service retrieves the corresponding business rule script from the MinIO distributed file system based on the current business scenario.
[0023] S302. Create an isolated execution context using the ContextAPI provided by GraalVM;
[0024] S303. Inject the user-submitted or saved data into the isolated execution context;
[0025] S304. Execute the business rule script and obtain the result, then determine whether the validation passes.
[0026] S305. Release resources and return the verification result. Based on the verification result, decide whether to continue the data persistence operation.
[0027] In another aspect, this invention proposes a cross-platform business rule dynamic parsing and centralized management system based on GraalVM, comprising:
[0028] Rule Configuration Center: The rule configuration center generates business rule scripts in different code languages, stores them as files in the MinIO distributed file system, stores them as structured data in a relational database, and establishes metadata indexes; the business rule scripts are released after syntax validation and review for various terminals to call and execute; when business rules change, the rule configuration center updates the business rule scripts and stores them as files in the MinIO distributed file system;
[0029] Front-end execution module: The business system front-end obtains business rule scripts compatible with the current terminal through the rule configuration center and metadata index, and performs local verification.
[0030] Backend validation module: When the frontend persists data to the backend service, the server backend service integrates the GraalVM multi-language runtime engine to create an isolated and secure execution environment, loads the same business rule script as the frontend from the MinIO distributed file system, and performs same-origin rule validation.
[0031] Furthermore, the rule configuration center includes:
[0032] Rule configuration module: Set the business that needs to configure verification rules, and configure the required verification metric data items based on the logic of the business;
[0033] Rule generation module: Select the target code language through the visual configuration page of the rule configuration center, and build the rule logic through graphical drag and drop; Based on the selected target code language, configured indicator data items and built rule logic, generate the visual rule into a language-independent rule expression; Then call the code generator corresponding to the target language, and compile the rule expression into a standardized business rule script that conforms to the language specification based on the predefined syntax template;
[0034] Rule storage module: Stores business rule scripts as files in the MinIO distributed file system and as structured data in a relational database, and establishes metadata indexes;
[0035] Rule distribution module: After the business rule scripts are grammatically validated and approved, they are published for various terminals to call and execute.
[0036] Furthermore, the target code language is a code language that is commonly supported by all terminals in the current business scenario. If no such language is available, steps S102-S103 are executed repeatedly to configure business rule scripts in different code languages for different terminals.
[0037] Furthermore, the backend verification module includes:
[0038] Acquisition Unit: The server backend service retrieves the corresponding business rule script from the MinIO distributed file system based on the current business scenario;
[0039] Creating a unit: An isolated execution context is created using the ContextAPI provided by GraalVM;
[0040] Injection Unit: Injects user-submitted or saved data into the isolated execution context;
[0041] Execution Unit: Executes the business rule script and obtains the result, then determines whether the validation passes.
[0042] Decision Unit: Releases resources and returns the verification result, and decides whether to continue the data persistence operation based on the verification result.
[0043] In another aspect, the present invention also proposes an electronic device, including a processor, a memory, and a communication interface. The memory stores a program that can be executed by the processor, and the processor implements the above-mentioned method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM by executing the program.
[0044] In another aspect, the present invention also proposes a storage medium storing a computer program for executing the above-described method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM.
[0045] Compared with the prior art, the present invention has the following beneficial effects:
[0046] 1. Achieve semantic consistency across the entire rule chain: By executing rule scripts from the same source on both the front-end and back-end, validation deviations caused by implementation differences are avoided;
[0047] 2. Reduced development and maintenance costs: Centralized rule configuration and management eliminate the need to modify code across multiple platforms, significantly reducing repetitive work;
[0048] 3. Supports dynamic hot updates: After the rules are published, they can be pushed to all terminals in real time without restarting the service or republishing the client;
[0049] 4. Strong cross-platform compatibility: Supports multiple environments such as Web front-end, Android / iOS mobile terminals, desktop applications, and Java back-end;
[0050] 5. High technological advancement: Utilizing GraalVM's high-performance JS / Python execution capabilities, it outperforms traditional Nashorn or expression engines;
[0051] 6. Strong security: GraalVM provides a sandbox mechanism that can restrict scripts' access to the file system, network, and Java objects;
[0052] 7. Excellent scalability: Supports multi-language script generation (JS / Python), and can be extended to languages such as Ruby and R in the future;
[0053] 8. Wide range of applicable scenarios: It is especially suitable for business systems with complex rules and frequent changes, such as tax declaration, financial risk control, and approval processes. Attached Figure Description
[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0055] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention;
[0056] Figure 2 This is a sequence diagram of the business rule script generation and execution process in Embodiment 1 of the present invention;
[0057] Figure 3 This is a schematic diagram of the system architecture of Embodiment 2 of the present invention;
[0058] Figure 4 This is a schematic diagram of the electronic device structure provided in Embodiment 3 of the present invention. Detailed Implementation
[0059] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0060] This invention relates to a method and system for dynamically parsing and executing business rules based on the GraalVM multi-language runtime engine. Specifically, it is used to uniformly execute the same semantic verification logic in heterogeneous environments such as Web front-end, mobile client, desktop application, and Java back-end service, thereby achieving homogeneous, centralized, and dynamic management of business rules across the entire chain and improving the maintainability, consistency, and cross-platform collaboration capabilities of the system.
[0061] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0062] Example 1:
[0063] like Figure 1 As shown in the figure, the method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM provided in this embodiment includes the following steps:
[0064] S110: Configure business functions and indicator data items.
[0065] The rule configuration specialist logs into the rule configuration center, which is a system platform used to configure business rule scripts. The specialist first browses the existing business function list in the system, selects the business function for which verification rules need to be configured, such as "Annual Individual Income Tax Settlement Declaration," and configures the required verification indicator data items based on the specific logic of that business function. For example, "Annual Individual Income Tax Settlement Declaration" requires verification of "Annual Income," "Total Special Additional Deductions," and "Children's Education Expenses."
[0066] If a new business function needs to be selected outside the existing list of business functions, the rule configuration officer adds the business function in the rule configuration center according to the business requirements of the new business function, the data verification items involved, and the expected verification rule logic, and configures the required verification indicator data items based on the specific logic of the business function.
[0067] After the above operations, the task is complete. Figure 2 Step 1 in the timing diagram.
[0068] S120: Select the language and configure the rule logic.
[0069] This step is... Figure 2 Step 2 in the timing diagram.
[0070] Rule configurators select the target code language format through the rule visualization configuration page in the rule configuration center. For example, they can select JavaScript or Python. The selected target code language should be a code language that is commonly supported by all terminals and backend services in the current business scenario. If there is no commonly supported code language, the following steps are executed repeatedly to configure business rule scripts in different code languages for different terminals.
[0071] After selecting the target code language, rule configurators construct rule logic through a graphical drag-and-drop interface. The rule configuration center provides this visual configuration interface, which supports drag-and-drop rule logic construction and complex expressions such as conditional statements, numerical comparisons, regular expression matching, and function calls. For example, to set: "If annual income > 120,000 yuan and total special additional deductions > annual income × 30%", first set the input data on the visual configuration page: Indicator Code 1: data.income, Indicator Name 1: Annual Income, Indicator Code 2: data.deduction, Indicator Name 2: Total Deductions. Then drag the relational operator '&' to identify the AND relationship and drag the relational operator '>' to identify the greater than relationship.
[0072] S130: Generate rule script.
[0073] This step is... Figure 2 Steps 3 and 4 in the timing diagram.
[0074] Based on the target code language selected by the rule configurator, the configured indicator data items, and the constructed rule logic, the rule configuration center first generates the rule logic into a language-independent rule expression; then, it calls the code generator corresponding to the target code language to compile the rule expression into a standardized script that conforms to the language specification.
[0075] For example: The generated rule expression is:
[0076] data.income>120000&data.deduction>data.income*0.3;
[0077] If the user selects JavaScript as the target language, the validation function generated based on the predefined JavaScript syntax template is as follows:
[0078] function validate(formData){
[0079] return! (formData.income>120000&&formData.deduction>formData.income*0.3)
[0080] };
[0081] If the user selects Python as the target language, the validation function generated based on the predefined Python syntax template is as follows:
[0082] defvalidate(formData):
[0083] returnnot(formData['income']>120000andformData['deduction']>formData['in come']*0.3);
[0084] The code generator mentioned is existing software; for example, it can call the code generation interface provided by "Tongyi Qianwen".
[0085] The business rule script is encapsulated as a pure function of the validation function. It accepts input data objects with a uniform structure, returns a boolean value or a validation result object, and embeds error messages and metadata. After the business rule script is generated, it is reviewed by the syntax validation and rule configuration personnel and then released for various terminals and backend services to call and execute.
[0086] S140: Get angry and store the rule script.
[0087] The published business rule scripts are uploaded to the MinIO distributed file system as files, completing the process. Figure 2 Step 5 in the sequence diagram; simultaneously, establish metadata indexes in relational databases such as MySQL, including rule ID, version number, business scenario, effective time, etc., to complete the process. Figure 2 Step 6 in the timing diagram.
[0088] After storing the business rule scripts, the rule configuration center notifies all endpoints to update, thus completing the process. Figure 2 Step 7 in the timing diagram.
[0089] S150: The terminal loads and parses the script.
[0090] During initialization, each business system (Web frontend, mobile app, desktop client) sends a rule retrieval request to the rule configuration center. This request carries the terminal type, business scenario identifier, and supported scripting language capabilities (such as "js", "python", etc.). Figure 2 Step 8 in the timing diagram.
[0091] Based on the business scenario identifier and the pre-stored rule metadata index (including rule ID, applicable terminal type, target language, scope, version number, etc.), the rule configuration center filters out business rule scripts or sets of business rule scripts compatible with the current terminal, and returns the corresponding script content through the REST API interface to complete the process. Figure 2 Step 9 in the timing diagram.
[0092] Specifically, the metadata index is generated by the configuration center and persistently stored in a relational database when a rule is published. For example, the metadata of a rule may include:
[0093] businessScene:"annual_tax_declaration"
[0094] targetLanguage:"javascript"
[0095] supportedPlatforms:["web","mobile","desktop"]
[0096] storagePath:"minio: / / rules / tax / validate_v2.js"
[0097] After receiving the rule script, the terminal performs real-time compilation and dynamic parsing of the script based on the local supported execution environment (such as the V8 engine of a web browser, Hermes / JSI of React Native, or the Node.js environment of Electron). Figure 2 Step 10 in the timing diagram.
[0098] If a terminal's local execution environment is incompatible with the language selected for the rule script (for example, the rule is generated in Python, but the mobile client only supports JavaScript), the rule management center will not return the incompatible script during the response phase, or will return an error message. To avoid this situation, the system verifies the target language and terminal support capabilities during the rule configuration phase.
[0099] S160: Terminal execution script feedback results.
[0100] When a user completes a transaction, the system passes the user's input data as a parameter to a rule function, performs local validation, and achieves [the desired result]. Figure 2 Steps 11 and 12 in the sequence diagram; and provide real-time feedback to the user, such as red warnings and pop-up notifications, to complete the process. Figure 2 Step 13 in the timing diagram.
[0101] S170: The backend executes scripts from the same source via GraaIVM.
[0102] Figure 2 In step 14 of the sequence diagram, when the user clicks the "Submit" or "Save" button to submit or save data for persistence, the backend service needs to perform server-side validation of the business data to prevent illegal requests that bypass the frontend validation. To this end, the backend service integrates the GraalVM multi-language runtime engine to create an isolated and secure JavaScript execution environment, loading and executing the same business rule scripts that are completely identical to those on the frontend, thus completing... Figure 2 Step 15 in the sequence diagram ensures the semantic consistency of the verification logic. Its specific execution process is as follows:
[0103] Step 1: Obtain the rule script content;
[0104] The backend service calls the rule configuration center service based on the current business scenario, such as "individual income tax annual settlement declaration" and the rule scope, such as user role and organization, and obtains the corresponding version of the business rule script through relational database and MinIO distributed file system.
[0105] Step 2: Initialize the GraalVM context;
[0106] The backend service creates an isolated execution context through the ContextAPI provided by GraalVM. For example, using JavaScript, key configurations include:
[0107] Specify the language: Set the execution language context according to the script parsing language used in the current business: Context.newBuilder("js"), to explicitly use the JavaScript language context;
[0108] Disable dangerous permissions: Call .allowAllAccess(false) to disable access to system resources such as Java classes, file systems, and networks;
[0109] Limit resource consumption: Optional configuration options include execution timeout (e.g., 100ms) and memory limit to prevent scripts from entering infinite loops or running out of resources;
[0110] Enable strict mode: Improve script security and execution consistency.
[0111] Example code is as follows:
[0112] Contextcontext=Context.newBuilder("js")
[0113] .allowAllAccess(false)
[0114] .option("engine.WarnInterpreterOnly","false")
[0115] .build().
[0116] Step 3: Inject the data object;
[0117] User-submitted business data (such as JSON-formatted form data) is converted into value objects that GraalVM can recognize and injected into the JavaScript global scope through bindings.
[0118] For example:
[0119] Valuebindings=context.getBindings("js");
[0120] bindings.putMember("formData",userInputData); / / userInputData is a Java object.
[0121] At this point, the input data can be accessed in the JavaScript script using methods such as formData.income.
[0122] Step 4: Execute the business rule script and obtain the results;
[0123] This is Figure 2 Step 16 in the timing diagram.
[0124] The obtained business rule script string (such as "function validate(formData){...}") is concatenated with the calling statement (such as "validate(formData)") and then executed using the context.eval() method:
[0125] Valueresult=context.eval("js","validate(formData)");
[0126] booleanisValid=result.asBoolean();
[0127] If the rule function returns a boolean value, it is used directly to determine whether the validation passed; if it returns an object containing error information, its fields are parsed to generate user prompts, thus completing the process. Figure 2 Step 17 in the timing diagram.
[0128] Step 5: Release resources and return the verification result;
[0129] After execution, the Context is explicitly closed to release underlying resources. Then, the backend decides whether to continue the data persistence operation based on the validation result. If validation fails, an error code and message are returned; if validation succeeds, the data is written to the database, completing the process. Figure 3 Step 18 in the timing diagram.
[0130] S180: The front-end and back-end achieve semantic consistency and dynamic updates based on the same source script.
[0131] By using rule scripts from the same source, the terminal and backend achieve semantic consistency of validation logic across platforms. When rules change, the configuration center updates the MinIO file and pushes a notification, and each terminal automatically pulls the new version of the script, achieving hot updates.
[0132] This embodiment supports visual configuration, multi-language script generation, centralized storage, dynamic distribution, and isomorphic execution, solving problems such as logic duplication, maintenance difficulties, and delayed updates caused by repeated coding of business rules in the front end, back end, and various clients in existing business systems.
[0133] Example 2:
[0134] This embodiment proposes a cross-platform business rule dynamic parsing and centralized management system based on GraalVM, such as... Figure 4 As shown, it includes:
[0135] Rule Configuration Center: The rule configuration center generates business rule scripts in different code languages, stores them as files in the MinIO distributed file system, stores them as structured data in a relational database, and establishes metadata indexes; the business rule scripts are released after syntax validation and review for various terminals to call and execute; when business rules change, the rule configuration center updates the business rule scripts and stores them as files in the MinIO distributed file system;
[0136] Front-end execution module: The business system front-end obtains business rule scripts compatible with the current terminal through the rule configuration center and metadata index, and performs local verification.
[0137] Backend validation module: When the frontend persists data to the backend service, the server backend service integrates the GraalVM multi-language runtime engine to create an isolated and secure execution environment, loads the same business rule script as the frontend from the MinIO distributed file system, and performs same-origin rule validation.
[0138] Furthermore, the rule configuration center includes:
[0139] Rule configuration module: Set the business that needs to configure verification rules, and configure the required verification metric data items based on the logic of the business;
[0140] Rule generation module: Select the target code language through the visual configuration page of the rule configuration center, and build the rule logic through graphical drag and drop; Based on the selected target code language, configured indicator data items and built rule logic, generate the visual rule into a language-independent rule expression; Then call the code generator corresponding to the target language, and compile the rule expression into a standardized business rule script that conforms to the language specification based on the predefined syntax template;
[0141] Rule storage module: Stores business rule scripts as files in the MinIO distributed file system and as structured data in a relational database, and establishes metadata indexes;
[0142] Rule distribution module: After the business rule scripts are grammatically validated and approved, they are published for various terminals to call and execute.
[0143] Furthermore, the target code language is a code language that is commonly supported by all terminals in the current business scenario. If no such language is available, steps S102-S103 are executed repeatedly to configure business rule scripts in different code languages for different terminals.
[0144] Furthermore, the backend verification module includes:
[0145] Acquisition Unit: The server backend service retrieves the corresponding business rule script from the MinIO distributed file system based on the current business scenario;
[0146] Creating a unit: An isolated execution context is created using the ContextAPI provided by GraalVM;
[0147] Injection Unit: Injects user-submitted or saved data into the isolated execution context;
[0148] Execution Unit: Executes the business rule script and obtains the result, then determines whether the validation passes.
[0149] Decision Unit: Releases resources and returns the verification result, and decides whether to continue the data persistence operation based on the verification result.
[0150] The GraalVM-based cross-platform business rule dynamic parsing and centralized management system proposed in this embodiment can achieve the GraalVM-based cross-platform business rule dynamic parsing and centralized management method proposed in Embodiment 1, and has the same technical effect as Embodiment 1.
[0151] Example 3:
[0152] This embodiment proposes an electronic device, such as... As shown, the electronic device includes a processor 100, a memory 300, and a communication interface for communicating with a communication network 200. The memory 300 stores programs that can be executed by the processor. The processor 100 implements the method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM proposed in Embodiment 1 by executing the program.
[0153] The above embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
Claims
1. A method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM, characterized in that, include: S1. Generate business rule scripts in different code languages through the rule configuration center, store them in the MinIO distributed file system as files, store them in the relational database as structured data, and establish metadata indexes; the business rule scripts are released after syntax validation and review for various terminals to call and execute; S2. The business system front-end obtains business rule scripts compatible with the current terminal through the rule configuration center and metadata index, and performs local verification. S3. When the front end persists data to the back end service, the server back end service creates an isolated and secure execution environment by integrating the GraalVM multi-language runtime engine, loads the same business rule script as the front end from the MinIO distributed file system, and performs same-origin rule verification. S4. When business rules change, the rule configuration center updates the business rule script and stores it in the MinIO distributed file system as a file.
2. The method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM according to claim 1, characterized in that, Step S1 includes: S101. In the rule configuration center, set the business that needs to be configured with verification rules, and configure the required verification indicator data items based on the logic of the business. S102. Select the target code language through the visual configuration page of the rule configuration center, and construct the rule logic through graphical drag and drop; S103. The rule configuration center generates language-independent rule expressions from the selected target code language, configured indicator data items, and constructed rule logic. Then, it calls the code generator corresponding to the target language and compiles the rule expressions into standardized business rule scripts that conform to the language specification based on the predefined syntax template.
3. The method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM according to claim 2, characterized in that, The target code language is a code language that is commonly supported by all terminals in the current business scenario. If no such language is found, steps S102-S103 are executed repeatedly to configure business rule scripts in different code languages for different terminals.
4. The method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM according to claim 1, characterized in that, Step S3 specifically includes: S301. The server backend service retrieves the corresponding business rule script from the MinIO distributed file system based on the current business scenario. S302. Create an isolated execution context using the ContextAPI provided by GraalVM; S303. Inject the user-submitted or saved data into the isolated execution context; S304. Execute the business rule script and obtain the result, then determine whether the validation passes. S305. Release resources and return the verification result. Based on the verification result, decide whether to continue the data persistence operation.
5. A cross-platform business rule dynamic parsing and centralized management system based on GraalVM, characterized in that, include: Rule Configuration Center: The rule configuration center generates business rule scripts in different code languages, stores them as files in the MinIO distributed file system, stores them as structured data in a relational database, and establishes metadata indexes; the business rule scripts are released after syntax validation and review for various terminals to call and execute; when business rules change, the rule configuration center updates the business rule scripts and stores them as files in the MinIO distributed file system; Front-end execution module: The business system front-end obtains business rule scripts compatible with the current terminal through the rule configuration center and metadata index, and performs local verification. Backend validation module: When the frontend persists data to the backend service, the server backend service integrates the GraalVM multi-language runtime engine to create an isolated and secure execution environment, loads the same business rule script as the frontend from the MinIO distributed file system, and performs same-origin rule validation.
6. The cross-platform business rule dynamic parsing and centralized management system based on GraalVM as described in claim 5, characterized in that, The rule configuration center includes: Rule configuration module: Set the business that needs to configure verification rules, and configure the required verification metric data items based on the logic of the business; Rule generation module: Select the target code language through the visual configuration page of the rule configuration center, and build the rule logic through graphical drag and drop; Based on the selected target code language, configured indicator data items and built rule logic, generate the visual rule into a language-independent rule expression; Then call the code generator corresponding to the target language, and compile the rule expression into a standardized business rule script that conforms to the language specification based on the predefined syntax template; Rule storage module: Stores business rule scripts as files in the MinIO distributed file system and as structured data in a relational database, and establishes metadata indexes; Rule distribution module: After the business rule scripts are grammatically validated and approved, they are published for various terminals to call and execute.
7. The cross-platform business rule dynamic parsing and centralized management system based on GraalVM as described in claim 6, characterized in that, The target code language is a code language that is commonly supported by all terminals in the current business scenario. If no such language is found, steps S102-S103 are executed repeatedly to configure business rule scripts in different code languages for different terminals.
8. The cross-platform business rule dynamic parsing and centralized management system based on GraalVM as described in claim 5, characterized in that, The backend verification module includes: Acquisition Unit: The server backend service retrieves the corresponding business rule script from the MinIO distributed file system based on the current business scenario; Creating a unit: An isolated execution context is created using the ContextAPI provided by GraalVM; Injection Unit: Injects user-submitted or saved data into the isolated execution context; Execution Unit: Executes the business rule script and obtains the result, then determines whether the validation passes. Decision Unit: Releases resources and returns the verification result, and decides whether to continue the data persistence operation based on the verification result.
9. An electronic device comprising a processor, a memory, and a communication interface, wherein the memory stores a program executable by the processor, characterized in that, The processor implements the method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM as described in any one of claims 1-4 by executing a program.
10. A storage medium storing a computer program, characterized in that, The computer program is used to execute the method for dynamic parsing and centralized management of cross-platform business rules based on GraalVM as described in any one of claims 1-4.
Citation Information
Cited By
Automatic construction method and device of application program and computer equipment
CN121764459A