A low-code platform data modeling method and system based on Dataset technology

Abstract

This application provides a low-code platform data modeling method and system based on Dataset technology, relating to the field of low-code technology. The method acquires configuration information of a target business object, generates structured metadata based on the configuration information, and generates an application component including a strategy evaluation engine. During the operation of the application component, the engine monitors the data status in real time and dynamically adjusts the behavior or relational structure of the application component when the policy rule conditions are met, without modifying the generated source code. To improve the efficiency of large-scale rule processing, the method extracts conditional expressions and adjustment instructions from the policy rules, identifies dependencies, calculates structural and temporal correlation weights accordingly, generates predictive hybrid weights, and performs clustering. This solution improves strategy evaluation performance, supports dynamic business adaptive modeling, and is suitable for digital transformation scenarios.

Description

Technical Field

[0001] This application relates to the field of low-code technology, and more specifically, to a low-code platform data modeling method and system based on Dataset technology. Background Technology

[0002] Low-code platforms, as efficient development tools, are widely used in building enterprise applications. Dataset technology, a data model framework based on declarative configuration, is commonly used in low-code platforms to achieve unified management of data attributes, actions, and relationships. Low-code platforms achieve data modeling through declarative configuration information, allowing users to generate application components without writing extensive code, thereby accelerating the development and deployment of business objects. However, existing low-code platforms have limitations in handling policy rules. Traditional methods typically rely on statically generated application components, requiring the evaluation and adjustment of policy rules to be achieved by modifying source code or recompiling. This not only increases maintenance costs but also fails to cope with real-time business changes. Furthermore, as business scales up, the number of rules increases dramatically. Existing platform evaluation mechanisms often employ global scanning or simple dependency analysis, which cannot efficiently handle the dynamic adjustment of large-scale rules, causing performance bottlenecks and response delays. This problem is further exacerbated by the interdependencies and temporal changes between rules in complex business scenarios, making runtime adaptive optimization impossible. Therefore, how to efficiently evaluate and dynamically adjust policy rules at runtime during data modeling on a low-code platform without modifying the generated source code, in order to adapt to large-scale business changes, has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this application provides a low-code platform data modeling method and system based on Dataset technology.

[0004] Firstly, this application provides a low-code platform data modeling method based on Dataset technology, including:

[0005] Obtain configuration information for the target business object, the configuration information including action attributes, relationship attributes, and strategy attributes; wherein, the strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met, the strategy rules including conditional expressions and dynamic adjustment instructions;

[0006] Based on the configuration information, structured metadata is generated; based on the structured metadata, an application component for executing the policy rules is generated, including: extracting the conditional expression and dynamic adjustment instructions, identifying the dependency relationship between the policy rules and the configuration information; calculating the structural association weight and temporal association weight between the policy rules based on the dependency relationship, and generating predictive hybrid association weight; performing clustering operations on the policy rules based on the predictive hybrid association weight to optimize the rule execution efficiency of the policy evaluation engine;

[0007] During the operation of the application component, the strategy evaluation engine monitors the data status of the target business object in real time;

[0008] In response to the data state satisfying the conditions in the policy rules, the policy evaluation engine dynamically adjusts the behavior or relational structure of the application components; wherein the dynamic adjustment is performed without modifying the generated source code.

[0009] Optionally, the configuration information further includes: data attributes; the application components for generating the policy evaluation engine for executing the policy rules include:

[0010] The structured metadata is parsed to extract the conditional expressions and dynamic adjustment instructions in the policy rules, and the data attributes referenced in the conditional expressions are analyzed to identify the dependency relationship between the policy rules and the data attributes.

[0011] Based on the dependency relationship, a mapping operation is performed on the data attribute, the conditional expression, and the dynamic adjustment instruction to generate a dependency graph from the data attribute to the strategy rule;

[0012] Based on the dependency graph, a data interceptor is generated for monitoring the target business object;

[0013] The data interceptor is integrated into the application component to generate an application component that includes the policy evaluation engine;

[0014] The data interceptor is configured as follows:

[0015] In response to a change in the value of the data attribute, a query operation is performed on the dependency graph to obtain the conditional expression and dynamic adjustment instruction associated with the changed data attribute, and the strategy evaluation engine is triggered only to evaluate the associated conditional expression and execute the dynamic adjustment instruction.

[0016] Optionally, generating the dependency graph from the data attributes to the policy rules includes:

[0017] The conditional expression of each policy rule is parsed to identify the conditional dependency of the policy rule on the data attribute;

[0018] The dynamic adjustment instructions for each policy rule are parsed to identify the policy rule's dependency on the data attribute adjustment.

[0019] Based on the conditional dependencies and the adjustment dependencies, mapping operations are performed on the data attributes and the policy rules to construct the dependency graph.

[0020] Optionally, constructing the dependency graph includes:

[0021] Iterate through the set of policy rules;

[0022] Each policy rule pair in the set is examined, wherein the policy rule pair includes a first policy rule and a second policy rule in the set, and the data attribute associated with the adjustment dependency of the first policy rule and the data attribute associated with the condition dependency of the second policy rule are compared.

[0023] In response to the fact that the data attribute associated with the adjustment dependency of the first policy rule is the same as the data attribute associated with the conditional dependency of the second policy rule, a cascading dependency path is established in the dependency graph from the first policy rule to the second policy rule. The cascading dependency path is used to propagate the adjustment effect.

[0024] Optionally, establishing a cascading dependency path in the dependency graph from the first policy rule to the second policy rule includes:

[0025] Based on the conditional dependency and the adjustment dependency, the policy rules are clustered to generate one or more policy rule groups, wherein the clustering operation calculates the correlation between the policy rules based on the overlap between the conditional dependency and the adjustment dependency.

[0026] Based on the dependencies between the policy rule groups, a mapping operation is performed on the policy rule groups to construct a coarse-grained dependency grid that includes the policy rule groups as nodes.

[0027] The coarse-grained dependency grid and the dependency graph are combined to form a hierarchical multi-dependency structure, wherein the cascading dependency paths run through the coarse-grained dependency grid and the dependency graph.

[0028] Optionally, the policy evaluation engine is configured as follows:

[0029] In response to the detection of a change in the data state of the target business object, an initial evaluation operation is performed on the coarse-grained dependency grid to identify the affected policy rule groups;

[0030] Based on the results of the initial evaluation operation, a query operation is performed on the dependency graph within the affected policy rule group to determine the associated policy rules.

[0031] The associated policy rules are evaluated for conditions, and the corresponding dynamic adjustment instructions are executed.

[0032] Optionally, the formation of a hierarchical multi-dependency structure includes:

[0033] For each policy rule group in the coarse-grained dependency grid, establish an extension path pointing to the policy rules included in the policy rule group in the dependency graph;

[0034] For each policy rule in the dependency graph, establish a backtracking path pointing to the policy rule group to which the policy rule belongs;

[0035] Based on the extended path and the backtracking path, a mapping operation is performed on the coarse-grained dependency grid and the dependency graph to construct the hierarchical multi-dependency structure, wherein the extended path and the backtracking path form a bidirectional connection.

[0036] Optionally, the step of dynamically adjusting the behavior or relational structure of the application component by the policy evaluation engine in response to the data state satisfying the conditions in the policy rules includes:

[0037] In response to the policy evaluation engine's evaluation result of the conditional expression of the policy rule being satisfied, an undoable command object is generated, which includes forward execution logic and reverse undo logic, wherein the forward execution logic corresponds to dynamic adjustment;

[0038] The behavior or relational structure of the application component prior to the dynamic adjustment is captured, and the behavior or relational structure is associated with the reversible command object as a state memo, wherein the reverse reversal logic uses the state memo to restore the behavior or relational structure.

[0039] Execute the forward execution logic of the revocable command object to adjust the behavior or relational structure of the application component;

[0040] The revocable command object is recorded in the transaction history stack to achieve the atomic revocation of the dynamic adjustment.

[0041] Optionally, the clustering operation includes:

[0042] Extract the conditional dependency and the adjustment dependency as feature vectors for any two policy rules;

[0043] The structural association weight between any two policy rules is calculated based on the feature vector. The calculation of the structural association weight includes asymmetric weighting of the type differences between the conditional dependency and the adjustment dependency, and normalization of the structural association weight according to the frequency of occurrence of data attributes in the conditional dependency and the adjustment dependency.

[0044] Record the runtime behavior logs of the policy evaluation engine executing each policy rule, and divide the logs by time windows;

[0045] Calculate the temporal correlation weight between any two policy rules based on the partitioned logs, and calculate the trend factor of the temporal correlation weight.

[0046] The structural correlation weight, the temporal correlation weight, and the trend factor are combined to generate a predictive hybrid correlation weight between any two policy rules.

[0047] Based on the predictive hybrid association weights, an association graph is constructed with the policy rules as nodes, and a community detection algorithm is applied to the association graph to divide the policy rules into different policy rule groups.

[0048] Secondly, this application provides a low-code platform data modeling system based on Dataset technology, including:

[0049] The acquisition module is used to acquire configuration information for a target business object. The configuration information includes action attributes, relationship attributes, and strategy attributes. The strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met. The strategy rules include conditional expressions and dynamic adjustment instructions.

[0050] The processing module is configured to generate structured metadata based on the configuration information; and based on the structured metadata, generate application components for a policy evaluation engine to execute the policy rules, including: extracting the conditional expressions and dynamic adjustment instructions, identifying the dependencies of the policy rules on the configuration information; calculating the structural association weights and temporal association weights between the policy rules based on the dependencies, and generating predictive hybrid association weights; and performing clustering operations on the policy rules based on the predictive hybrid association weights to optimize the rule execution efficiency of the policy evaluation engine.

[0051] An adjustment module is configured to, during the operation of the application component, have the policy evaluation engine monitor the data status of the target business object in real time; and, in response to the data status satisfying the conditions in the policy rules, have the policy evaluation engine dynamically adjust the behavior or relationship structure of the application component; wherein the dynamic adjustment is performed without modifying the generated source code.

[0052] Compared to existing technologies, this application introduces a clustering mechanism based on predictive hybrid association weights into a low-code platform, achieving efficient runtime evaluation and dynamic adjustment of policy rules. This significantly improves the system's scalability and responsiveness without modifying the generated source code. This method automatically extracts rule dependencies and combines static structures and dynamic logs to calculate hybrid weights, thereby optimizing rule grouping and evaluation paths, reducing unnecessary computational overhead, and making rule execution smoother under large-scale business changes. Simultaneously, this invention enhances application robustness, ensures stable and reliable dynamic adjustment processes, reduces maintenance difficulty, and improves overall development efficiency and system performance. Attached Figure Description

[0053] Figure 1 A flowchart illustrating a low-code platform data modeling method based on Dataset technology, provided in this application embodiment;

[0054] Figure 2 A flowchart illustrating a method for generating application components provided in this application embodiment;

[0055] Figure 3 A flowchart illustrating a method for generating a dependency graph provided in an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of a low-code platform data modeling system based on Dataset technology, provided as an embodiment of this application. Detailed Implementation

[0057] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0058] See Figure 1 The diagram shows a flowchart of a low-code platform data modeling method based on Dataset technology provided in an embodiment of this application. The method includes steps S101 to S105, wherein:

[0059] S101: Obtain configuration information for the target business object, the configuration information including action attributes, relationship attributes and strategy attributes; wherein, the strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met, the strategy rules include conditional expressions and dynamic adjustment instructions;

[0060] S102: Generate structured metadata based on the configuration information;

[0061] S103: Based on the structured metadata, generate an application component for a policy evaluation engine to execute the policy rules, including: extracting the conditional expression and dynamic adjustment instructions, identifying the dependency relationship between the policy rules and the configuration information; calculating the structural association weight and temporal association weight between the policy rules based on the dependency relationship, and generating predictive hybrid association weights; performing clustering operations on the policy rules based on the predictive hybrid association weights to optimize the rule execution efficiency of the policy evaluation engine;

[0062] S104: During the operation of the application component, the strategy evaluation engine monitors the data status of the target business object in real time;

[0063] S105: In response to the data state satisfying the conditions in the policy rules, the policy evaluation engine dynamically adjusts the behavior or relational structure of the application component; wherein the dynamic adjustment is performed without modifying the generated source code.

[0064] Regarding the above S101:

[0065] In practice, it is implemented through the user interface or application programming interface of the low-code platform. The platform adopts Dataset technology as the core data model framework. This technology is a declarative configuration mechanism used to uniformly manage various attributes of business objects, ensuring integrated processing of data, actions and relationships without the need for traditional coding.

[0066] For example, after logging into the low-code platform, a user selects or creates a target business object, such as a business object named "Order Management," which is used to handle order-related business processes. The platform provides a configuration editor where users can input configuration information by dragging and dropping components or filling out forms. This information will be automatically encapsulated into a unified internal representation by the Dataset model, such as storing a collection of attributes as object instances.

[0067] The action attribute defines the operations that the target business object can perform.

[0068] For example, a user adds an action item in the configuration editor, such as the "Create Order" action. This action includes input parameters such as order number and amount, and output results such as a success flag. The platform uses the declarative mechanism of Dataset technology to dynamically bind these action attributes to business objects and automatically store them as key-value pairs, for example, using JSON format: {"actionName": "createOrder", "parameters": ["orderId", "amount"], "output": "success"}. Users can select predefined action templates through drop-down menus or define new custom actions. The Dataset model verifies action compatibility in real time to ensure flexible and consistent configuration.

[0069] For relationship attributes, this attribute defines the association between the target business object and other business objects.

[0070] For example, users specify the relationship type in the editor, such as a "one-to-many" relationship, associating the order management object with the user object. Users can connect the two object icons using a graphical connection tool and set relationship fields such as userId. The platform uses Dataset technology to record the relationship attributes as part of the model in an association table, for example in JSON format: {"relationType": "oneToMany", "relatedObject": "User", "keyField": "userId"}, thereby enabling data referencing and automatic synchronization between objects.

[0071] For the strategy attribute, this attribute includes strategy rules for dynamically adjusting action attributes or relationship attributes when conditions are met, where the strategy rule consists of a condition expression and a dynamic adjustment instruction.

[0072] For example, a user adds rules in the strategy panel of the configuration editor. First, they define a conditional expression, such as using Boolean logic to combine field values, like "if the order amount is greater than 1000 and the user level is VIP". The user can use the platform's logic builder to select fields, operators, and values ​​to assemble the expression, which the platform will then convert into an internal representation, such as the string "amount > 1000 && userLevel == 'VIP'". Then, the user defines dynamic adjustment instructions, such as "adjust the permission for the create order action to allowed" or "modify the relationship attribute to add a discount field", specified by selecting the target attribute and adjustment type. Dataset technology plays a crucial role here, unifying strategy attributes with action and relationship attributes, ensuring that rules are declaratively embedded in the model and stored as structured data, such as JSON format: {"ruleId": "rule1", "condition": "amount > 1000 && userLevel == 'VIP'", "adjustment": {"target": "createOrder", "type": "enablePermission"}}. The entire acquisition process verifies the integrity of the configuration through the platform's backend service and saves it to the database, ensuring that subsequent steps can directly access the unified configuration in the Dataset model.

[0073] Regarding S102 above:

[0074] This step involves converting user-provided declarative configurations into a machine-readable, standardized format to facilitate the automatic generation and execution of subsequent application components. Specifically, this step is implemented through the backend processing engine of a low-code platform. This engine utilizes an integrated framework based on Dataset technology to organize scattered configuration attributes into a hierarchical data structure, ensuring the integrity and scalability of metadata.

[0075] In practice, the platform backend service first reads the configuration information obtained in step S101 from the database or memory cache. This information is stored in the form of key-value pairs or objects.

[0076] For example, for the "Order Management" business object, the configuration information might include action attributes such as parameter definitions for "Create Order," relationship attributes such as association fields with the "User" object, and strategy attributes such as adjustment rules for conditional triggering. The platform launches a parsing module that iterates through each part of the configuration information and standardizes each attribute. Specifically, for action attributes, the parsing module extracts the action name and input / output parameters, and converts them into a nested object structure. For example, the original key-value pairs are reorganized into {"actions":[{"name": "createOrder", "inputs": ["orderId","amount"], "outputs": ["success"]}]}; for relation attributes, the relation type and key field are extracted and converted into an array, such as {"relations":[{"type": "oneToMany", "target": "User", "key": "userId"}]}; for policy attributes, the conditional expression and adjustment instructions are extracted and converted into a list of rules, such as {"policies":[{"id": "rule1", "condition": "amount>1000&&userLevel == 'VIP'", "action": {"target": "createOrder", "type": "enablePermission"}}]}. Dataset technology plays a central role here. It provides a predefined metadata template framework, and user configurations are mapped to the corresponding slots in the framework, ensuring that all attributes conform to a unified specification. For example, template fields are automatically populated through reflection mechanisms to avoid manual coding errors.

[0077] Next, the platform performs a verification sub-step to ensure the consistency and integrity of the generated metadata. Specifically, the verification module checks whether the parameter types of the action attributes match, for example, ensuring that "amount" is numeric, that the key field of the relation attribute exists in the relevant object, and that the syntax of the conditional expression of the strategy attribute is correct, such as using the built-in expression parser to check the validity of Boolean logic. If inconsistencies are found, such as a conditional expression referencing an undefined data field, the platform will return an error message, requiring the user to correct the configuration. Here, "amount" is the order amount field, a data attribute, of type numeric (decimal fixed point or smallest integer currency unit), with the unit depending on the platform's currency context, and precision retained to two decimal places; values ​​less than zero are invalid.

[0078] After successful verification, the platform merges these standardized attributes into a single structured metadata document, such as a tree structure in XML or JSON format, where the root node is the business object name, and the subordinate nodes correspond to the actions, relationships, and policies, respectively. An example metadata output is a JSON document: {"objectName": "OrderManagement", "actions": [...], "relations": [...], "policies": [...]}. This document is serialized and stored in the platform's metadata repository for easy retrieval in subsequent steps.

[0079] The entire generation process is automated through the declarative mechanism of Dataset technology, requiring no user intervention in coding and ensuring efficient and consistent metadata generation. The output of this step serves as a bridge, supporting the construction of application components while maintaining configuration flexibility.

[0080] Regarding the above S103:

[0081] This step transforms metadata into runnable components. Its core is the automated construction of an engine capable of interpreting and executing policy rules while optimizing rule processing efficiency. Specifically, this step is handled by the build engine of a low-code platform. This engine utilizes the declarative model of Dataset technology to transform the configuration logic in the metadata into an executable internal structure, ensuring that the generated components support dynamic runtime behavior without manual coding intervention. The entire process is divided into several sub-stages, including extracting key elements, identifying dependencies, calculating association weights, generating mixed weights, and clustering optimization. These sub-stages are progressively layered to achieve efficient rule execution.

[0082] First, the platform reads relevant content from the structured metadata document generated in step S102. For example, it loads the "policies" section of the document using a JSON parser, which contains multiple policy rule objects. The specific method for extracting the conditional expressions and dynamic adjustment instructions is to traverse each rule object, separating the conditional part and the adjustment part. Specifically, for a rule object such as {"condition": "amount>1000&&userLevel == 'VIP'", "adjustment": {"target": "createOrder", "type": "enablePermission"}}, the platform uses string splitting and pattern matching tools to parse the user-configured rule statements, structurally separating the conditional expression part from the dynamic adjustment instruction part. The conditional expression is usually composed of Boolean logic, which the platform extracts into a recognizable string format; while the dynamic adjustment instruction consists of the target object and adjustment type, which the platform extracts into a key-value pair mapping structure, storing the target field and operation method respectively.

[0083] In this process, the platform introduces Dataset technology as a template support tool for rule parsing. User-configured rules are automatically mapped to multiple pre-defined slots in the Dataset template. Slots storing conditional expressions retain the logical judgment structure in string format, while slots storing adjustment instructions retain the target and operation information in key-value mapping, thus ensuring the accuracy and stability of the entire rule parsing process.

[0084] When there are many rules, the platform can perform parsing tasks on multiple rule objects in parallel, thereby improving the overall processing efficiency and ensuring good response performance and structure extraction capabilities even in large-scale rule scenarios.

[0085] Next, the dependencies of the policy rules on the configuration information are identified. Specifically, the platform analyzes the extracted conditional expressions and dynamic adjustment instructions to find the configuration elements referenced within them. For example, for the conditional expression "amount>1000&&userLevel == 'VIP'", the platform uses a keyword scanning tool to identify "amount" and "userLevel" as dependent attributes, which may come from the action or relation part of the configuration information; for the dynamic adjustment instruction {"target": "createOrder", "type": "enablePermission"}, "createOrder" is identified as a dependent action attribute. The identification process is accomplished by constructing a temporary mapping table, for example, assigning a dependency list to each rule: {"rule1": {"conditions": ["amount", "userLevel"], "adjustments": ["createOrder"]}}. The unified model of Dataset technology ensures consistency in dependency identification across attributes, for example, automatically checking whether the referenced attribute exists in the model, and issuing a warning if it does not exist.

[0086] Based on the identified rule dependencies, the platform quantifies the structural correlation between various policy rules and generates structural correlation weights. In practice, the system compares the dependency lists of any two policy rules. For example, when rule 1 depends on the fields "amount" and "createOrder", and rule 2 depends on the fields "amount" and "updateOrder", the system identifies the intersection of the dependent fields, extracts the commonly dependent elements, and determines the correlation strength between the two rules accordingly.

[0087] The system's weight calculation method includes two aspects: first, counting the number of overlapping dependency fields between two rules; and second, weighting based on the type of each dependency field. The weight setting for dependency type can be as follows: if a field belongs to a conditional judgment dependency, the weighting coefficient is 1; if it belongs to an adjustment operation dependency, the weighting coefficient is 0.8. During the calculation process, the platform sums the weighted values ​​of all overlapping fields and normalizes them with the total number of dependencies involved in the rule, thereby controlling the final structural association weight within the range of 0 to 1.

[0088] For example, in a rule pair, there are two fields that are shared dependencies between the two rules, with a total of four dependent fields. Both overlapping fields are conditional dependencies. Therefore, the structural association weight of this rule pair is 0.5, which is obtained by dividing the weight of the two fields (2) by the total weight (4). The platform iterates through all rule pairs, calculating and filling the structural association weight matrix sequentially to provide support data for subsequent rule clustering and execution optimization. Here, "weight 2" refers to the fact that the two overlapping dependent fields shared by the two policy rules are both conditional dependencies, each weighted at 1.0, and 1.0 + 1.0 sums to 2; "total weight 4" is the cardinality of the union of the dependent fields of the two rules.

[0089] The platform further calculates the temporal correlation weights between policy rules to capture the co-occurrence relationships and execution order characteristics of rules during actual operation. In specific implementation, the system records the actual trigger time information of each policy rule by monitoring the runtime logs during rule execution. For example, when rule 1 is executed at time T1, and rule 2 is executed immediately afterward at time T2, the platform includes this sequence in the temporal statistics data.

[0090] The system divides the timeline into fixed-length sliding windows, each with a preset length of five minutes, to count the co-occurrence frequency of rules within the same time period. The platform counts the number of times any two rules co-occur in all windows and uses this co-occurrence frequency as the basic metric for temporal association weight. For example, if rule 1 and rule 2 co-occur 8 times in a total of 10 time windows, their basic temporal association weight is 0.8. This weight can also be adjusted based on the execution order of the rules: if one rule consistently executes before another rule in all co-occurrences, the system can introduce a sequence factor to appropriately increase the original weight to reflect the potential causal relationship.

[0091] After calculating the structural association weights and temporal association weights, the platform generates predictive hybrid association weights. This process is achieved by weighted fusion of the two types of weights. For example, the structural association weights and temporal association weights can be weighted and averaged separately according to their respective proportions. The hybrid weight can be set to 60% for structural weights and 40% for temporal weights. The above weighting ratios can be adjusted according to specific business scenario requirements. For example, in scenarios where it is necessary to emphasize the static dependency structure of rules, the platform can increase the proportion of structural weights to over 60%. The hybrid association weights generated after fusion are represented in matrix form to comprehensively reflect the overall degree of association between rules.

[0092] Based on the generated mixed weight matrix, the platform performs clustering operations on the policy rules. The clustering process takes the mixed weight values ​​as input and uses a clustering algorithm to group rules with higher weights into the same group. Specifically, the system traverses the weight matrix and identifies rule pairs whose weight values ​​exceed a set threshold; for example, a weight value exceeding 0.5 is considered to indicate a close relationship, and these pairs are then grouped into the same cluster.

[0093] This clustering method can effectively optimize the structure of policy rules, integrating highly related rules into the same logical execution path.

[0094] The optimized policy rule structure will be integrated into the platform's policy evaluation engine. The platform generates a loadable module file based on the clustering results, containing the clustering group structure and its corresponding execution logic definition. This module can be dynamically invoked by the policy evaluation engine at runtime, thereby prioritizing the evaluation of associated clusters during the rule execution phase, avoiding a full scan of the entire rule set, and significantly improving the execution efficiency of rule evaluation.

[0095] The above-mentioned optimization and integration process is achieved through the template-based construction mechanism provided by Dataset technology. The system automatically updates modules based on changes in the rule structure, supports rapid version iteration and flexible deployment, and ensures that the strategy engine can continue to operate efficiently.

[0096] Regarding S104 above:

[0097] This step is a critical process to ensure the system is sensitive to business changes. Through continuous monitoring by the engine, it enables real-time capture of data status without external intervention.

[0098] Specifically, this step is activated immediately after the application component starts. The platform utilizes the runtime model framework of Dataset technology, which allows the engine to dynamically bind to business objects and supports non-intrusive state tracking.

[0099] In practical implementation, firstly, the application component starts within the platform's environment, for example, by loading a generated component file through a JavaScript runtime or server container. This file contains the execution logic of the strategy evaluation engine. During engine initialization, the configuration of the target business object is loaded from metadata. For example, for the "Order Management" object, the engine registers with the object's state change events. Specifically, the engine uses an event listening mechanism, such as inserting hook functions into the setter methods of business object properties—callback functions automatically invoked when properties change. Whenever the data state changes, such as an order amount changing from 900 to 1200, the hook function immediately notifies the engine. The platform provides a state management module that maintains an internal state table, for example, using a key-value store structure: {"orderId": "001", "amount": 1200, "userLevel": "VIP"}. The engine subscribes to update notifications from this table to achieve real-time monitoring. The monitoring process is low-overhead; for example, it employs the observer pattern, where the engine only activates when the state changes, rather than continuously polling, to avoid performance consumption. If a business object involves multiple attributes, the engine will prioritize monitoring the key attributes referenced in the strategy rules, such as only subscribing to change events for "amount" and "userLevel", thereby focusing on the relevant data state.

[0100] In addition, the engine records monitoring logs, such as checking the change queue every second and pausing if no changes are found, to optimize resource usage. Dataset technology here ensures declarative monitoring, for example, automatically discovering the attributes to be monitored through model reflection, without the need for hard-coded listeners. The output of this step is real-time captured data state change events, which are passed as input to subsequent response logic, ensuring the system responds promptly to business changes.

[0101] Regarding the above S105:

[0102] This step is the core of achieving adaptive adjustment, ensuring a safe and efficient adjustment process through condition evaluation and command execution. Specifically, this step is triggered immediately upon detecting a change. The platform utilizes the runtime dynamic binding mechanism of Dataset technology to apply the adjustment to the component configuration, rather than modifying the underlying code.

[0103] In practice, the engine first extracts the current value from the data state change event captured in step S104. For example, for the "Order Management" object, it obtains the updated state: amount is 1200, user level is VIP. The engine loads the policy rule list, for example, by traversing the rule objects in the metadata. For each rule, it performs condition evaluation. Specifically, it uses the built-in expression evaluator to process the condition expression. For example, for "amount > 1000 && userLevel == 'VIP'", the engine substitutes the current state value into the expression and determines whether it is satisfied through string parsing and value comparison. For example, it compares whether 1200 is greater than 1000 and whether "VIP" matches. If the condition is satisfied, the engine extracts the corresponding dynamic adjustment instruction, such as {"target":"createOrder", "type": "enablePermission"}.

[0104] Then, adjustments are performed. Specifically, the engine locates the target component; for example, for behavior adjustments, it looks up the permission configuration for the action attribute "createOrder" and switches it from disabled to allowed. This is achieved by updating the configuration table in runtime memory, for example, modifying the key-value pair {"createOrder_permission": "allow"}, rather than changing the source code file. For relationship adjustments, such as adding a "discount" field to a relationship attribute, the engine dynamically expands the relationship table, such as inserting a new field {"discount": "10%"} into {"relations": [{"type": "oneToMany", "target": "User", "key": "userId"}]}. This is done through the model extension interface of Dataset technology, which supports hot configuration updates without restarting the application. The adjustment process is atomic; for example, locking mechanisms are used to ensure concurrency safety. If multiple changes occur simultaneously, the engine queues them for processing.

[0105] The entire response process utilizes declarative execution via Dataset technology, ensuring no code modification is required. For example, adjustments only affect the runtime state, while the source code remains unchanged. The output of this step is an updated component structure, ensuring that business objects adapt to the new state while maintaining system stability.

[0106] Optionally, the configuration information may also include: data attributes; see [link to documentation]. Figure 2 The flowchart of a method for generating application components provided in this application embodiment includes steps S201 to S204, wherein:

[0107] S201: Parse the structured metadata, extract the conditional expressions and dynamic adjustment instructions in the policy rules, analyze the data attributes referenced in the conditional expressions, and identify the dependency relationship between the policy rules and the data attributes;

[0108] S202: Based on the dependency relationship, perform mapping operations on the data attribute, the conditional expression, and the dynamic adjustment instruction to generate a dependency graph from the data attribute to the strategy rule;

[0109] S203: Based on the dependency graph, generate a data interceptor for monitoring the target business object;

[0110] S204: Integrate the data interceptor into the application component to generate an application component that includes the policy evaluation engine.

[0111] The data interceptor is configured as follows:

[0112] In response to a change in the value of the data attribute, a query operation is performed on the dependency graph to obtain the conditional expression and dynamic adjustment instruction associated with the changed data attribute, and the strategy evaluation engine is triggered only to evaluate the associated conditional expression and execute the dynamic adjustment instruction.

[0113] This application introduces data attributes as an extension of configuration information, explicitly associating policy rules with data dependencies. By utilizing dependency mapping and interception mechanisms, it achieves targeted optimization of rule evaluation, avoids performance waste caused by global scanning, and maintains the dynamic nature of the adjustment process and the characteristics of no-code intervention.

[0114] Specifically, data attributes provide fine-grained anchors for rule execution, while the dependency graph acts as a bridge, transforming static configurations into runtime monitoring paths to ensure that the engine only processes relevant changes, thereby improving overall execution efficiency.

[0115] In a specific implementation, this optional implementation extends the generation process of step S103 by first introducing data attributes as a supplement to the configuration information.

[0116] For example, when obtaining the configuration in step S101, the user adds data attributes in the editor, such as order amount and user level. These attributes are defined as field types and default values, for example, in JSON format: {"dataProperties": [{"name": "amount", "type": "number", "default": 0}, {"name": "userLevel", "type": "string", "default": "normal"}]}. The platform utilizes the Dataset technology's model extension interface to store data attributes along with action, relationship, and strategy attributes in a unified manner, ensuring the integrity of the configuration.

[0117] The process of generating the application components for the policy evaluation engine used to execute the policy rules includes the following sub-steps. First, the structured metadata is parsed. Specifically, the platform reads the "policies" section from the metadata document in step S102 and processes each rule object using a recursive traversal method. For example, for the rule {"condition": "amount>1000&&userLevel == 'VIP'", "adjustment": {"target": "createOrder", "type": "enable"}}, the parser extracts the conditional expression "amount>1000&&userLevel == 'VIP'" and the dynamic adjustment instruction {"target": "createOrder", "type": "enable"} through string scanning. Then, the data attributes referenced in the conditional expression are analyzed. The platform uses a keyword matching tool to scan the expression, identifies "amount" and "userLevel" as referenced fields, and compares them with the data attribute list in the configuration to confirm their existence.

[0118] If an undefined attribute is referenced, the platform throws a validation error. Identifying the dependency relationship between the policy rule and the data attribute is achieved by constructing an association list, for example, generating a dependency mapping for the rule: {"rule1": {"referencedData": ["amount", "userLevel"]}}. The principle is that dependency identification ensures data availability when the rule is executed, avoiding runtime exceptions.

[0119] Next, an empty graph structure is created, using data attributes as start nodes and policy rules as end nodes. By traversing the dependency list of all rules, edges are added to each data attribute pointing to the rules that reference it; for example, the "amount" node is connected to the edges referencing rules 1 and 2. The mapping operation utilizes key-value indexes to accelerate queries; for example, a hash table is used to store {"amount": ["rule1", "rule2"]}, ensuring efficient graph generation.

[0120] The generated dependency graph is stored in the form of an adjacency list, such as JSON: {"amount": {"rules": ["rule1"], "type": "condition"}}, for subsequent monitoring.

[0121] Furthermore, create an interceptor module, which is a collection of lightweight functions that are bound to property change events of business objects.

[0122] For example, for the "Order Management" object, the interceptor is registered in the setter method of the "amount" property, and is automatically invoked when the value changes. The generation principle utilizes the proxy pattern, using the interceptor as an intermediate layer to wrap the object's properties, ensuring that changes are captured without affecting the original logic. The interceptor code is generated through template population, and the platform dynamically injects relevant properties based on the nodes in the graph.

[0123] Furthermore, during the component construction phase, interceptor modules are linked to the engine's input interface, for example, by using dependency injection to make interceptors listener components for the engine. The integration principle is modular assembly, ensuring that the engine loads interceptors at startup for seamless collaboration. The final generated component is a deployable package, such as a ZIP file, containing engine logic and interceptor hooks.

[0124] The data interceptor is configured to query the dependency graph in response to a change in the value of the data attribute, obtain the conditional expression and dynamic adjustment instruction associated with the changed data attribute, and only trigger the policy evaluation engine to evaluate the associated conditional expression and execute the dynamic adjustment instruction. Specifically, when "amount" changes, the interceptor queries the rule list connected to the "amount" node in the graph, obtains the expression and instruction for rule 1, and only notifies the engine to evaluate this rule, not all rules. The query operation is implemented through hash lookup, based on the principle that the key-value structure of the graph ensures O(1) time complexity, and triggering is limited to the associated parts, thus improving efficiency.

[0125] For example, in "Order Management," changes in amount only trigger VIP-related rules, avoiding irrelevant calculations. This configuration is implemented through event-driven mechanisms, ensuring real-time performance and low overhead.

[0126] Optional, see Figure 3 The flowchart below illustrates a method for generating a dependency graph according to an embodiment of this application, including steps S301 to S303, wherein:

[0127] S301: Parse the conditional expression of each policy rule to identify the conditional dependency of the policy rule on the data attribute;

[0128] S302: Parse the dynamic adjustment instruction of each policy rule to identify the adjustment dependency of the policy rule on the data attribute;

[0129] S303: Based on the conditional dependency and the adjustment dependency, perform mapping operations on the data attributes and the strategy rules to construct the dependency graph.

[0130] This implementation aims to address the challenge of accurately distinguishing the dependency types of different parts of policy rules during the dependency graph generation stage in low-code platform data modeling. This improves the accuracy of the graph and the efficiency of association analysis, thereby avoiding ambiguity and redundancy in rule parsing. This application identifies the specific dependency methods of rules on data attributes through the separate parsing of conditional expressions and dynamic adjustment instructions. Based on these typified dependencies, a mapping is constructed, ensuring a more refined and reliable dependency graph. This enhances the targeting of subsequent monitoring and adjustments while reducing the computational burden on the system when processing complex rules.

[0131] In practice, the rule list is read from structured metadata. For each rule's conditional expression, such as "amount > 1000 && userLevel == 'VIP'", a string parsing tool is used for processing. For example, regular expression matching is used to scan for identifiers in the expression to extract the variable names "amount" and "userLevel". Then, the platform compares these variables with the list of data attributes in the configuration information to confirm that they are valid reference fields and marks them as conditional dependencies. For example, a dependency record table is created: {"rule1_condition": ["amount", "userLevel"]}. The principle of the parsing process is to use keyword extraction and context analysis to ensure that only the attributes used for judgment in the expression are recognized, while constants or operators are ignored, thereby avoiding irrelevant interference.

[0132] For example, in the "Order Management" business object, if an expression references "discountRate" but this property is not defined in the configuration, the platform will mark it as an invalid dependency and prompt the user to add it.

[0133] Next, for rule adjustment instructions, such as {"target": "createOrder", "type": "enablePermission", "field": "discount"}, the platform uses a key-value traversal tool to extract fields such as "target" and "field", identifying "createOrder" as an action attribute dependency and "discount" as a possible data attribute dependency. Then, the platform cross-validates these fields with attributes in the configuration information, confirming that "createOrder" exists in the action attribute list and marking it as an adjustment dependency, for example, in the dependency record table: {"rule1_adjustment": ["createOrder", "discount"]}. The principle of the parsing process is to focus on the target and affected fields of the instruction, ensuring that the attributes that the adjustment operation may modify are identified, thus distinguishing it from conditional dependencies. For example, in "Order Management", if the instruction involves modifying the "userId" field of the relationship attribute, the platform will mark it as an adjustment dependency, not a conditional dependency.

[0134] Furthermore, a graph structure is created, using data attributes as source nodes and policy rules as target nodes. For each identified conditional dependency, labeled edges are added, such as adding an edge labeled "condition" from "amount" to "rule1"; for adjustment dependencies, adding an edge labeled "adjustment" from "discount" to "rule1". The mapping operation is implemented using an adjacency list for storage, for example, in JSON format: {"amount": [{"rule": "rule1", "type": "condition"}], "discount": [{"rule": "rule1", "type": "adjustment"}]}, ensuring the graph supports fast lookups. The construction process iterates through all dependency records, adding nodes and edges one by one; if a node already exists, the edge list is updated.

[0135] For example, in "Order Management," the "amount" node may connect to multiple rules, forming a fan-out structure. This structure is stored in memory or a database for subsequent change monitoring and evaluation.

[0136] Optionally, by traversing the rule set and comparing dependency attributes, a cascading path can be established to ensure that adjustments propagate from one rule to another related rule, providing an ordered execution chain, improving the stability of the system under complex dependencies, while reducing redundant evaluations and improving the overall response speed.

[0137] In a specific implementation, this alternative implementation extends the process of constructing the dependency graph by first traversing the set of policy rules.

[0138] Specifically, the platform reads all policy rules from the rule list extracted in step S103. For example, for the "order management" business object, the rule set may include 10 rules, such as rule 1 (condition: amount > 1000, adjustment: enable order creation) and rule 2 (condition: user level = VIP, adjustment: add discount field).

[0139] The traversal operation uses a loop structure to process each rule in the collection. For example, a for loop is used to access each rule object one by one, recording the conditional dependencies of each rule, such as rule 1 depending on "amount"; adjusting dependencies, such as rule 1 adjusting "create order", and generating a temporary array for subsequent comparisons. The principle of this traversal is to ensure that all rules are checked and to avoid missing potential relationships.

[0140] Next, a relevance check is performed on each pair of policy rules in the set. Each pair of policy rules consists of a first policy rule and a second policy rule in the set. The platform generates all possible policy rule pairs by combining them, for example, by using nested loops to sequentially select any two different policy rules to form a group, such as the first policy rule being rule 1 and the second policy rule being rule 2.

[0141] During the inspection process, the platform compares the data attributes involved in the adjustment dependency of the first strategy rule with the data attributes involved in the conditional dependency of the second strategy rule.

[0142] For example, if the adjustment dependency of the first strategy rule is "create order" and its associated data attribute is "amount", and the condition dependency of the second strategy rule is "user level" and its associated data attribute is also "amount", the platform will extract the dependency attribute lists of the two rules respectively and compare them through a string matching mechanism or equivalence judgment tool.

[0143] Specifically, the platform converts each list of dependent attributes into a set data structure and performs a set intersection operation. If the resulting intersection is not empty, it determines that the policy rule pair has a relationship at the data attribute level and marks it. This comparison process covers all rule pair combinations. With n policy rules, the theoretical maximum number of combinations is n(n-1) / 2. For example, with 10 policy rules, 45 combinations may be generated. However, to avoid unnecessary computational resource consumption, the platform can introduce a pre-filtering mechanism to check only rule pairs with potential correlation, thereby effectively improving comparison efficiency and system performance.

[0144] In response to the data attributes associated with the adjustment dependency of the first policy rule being identical to those associated with the conditional dependency of the second policy rule, a cascading dependency path is established in the dependency graph, pointing from the first policy rule to the second policy rule. Specifically, if the comparison results match, such as rule 1 adjusting the "amount" and rule 2 conditionally depending on the "amount", the platform adds a directional edge to the graph, pointing from the rule 1 node to the rule 2 node, and labels it as "cascading," for example, updating the adjacency list: {"rule1": [{"to": "rule2", "type": "cascade"}]}. The principle behind establishing the path is to simulate the propagation of influence. For example, the adjustment of rule 1 changing the "amount" value may trigger a re-evaluation of the condition of rule 2, thus forming a chain. This path is used to propagate the adjustment influence; for example, during runtime, after rule 1 is executed, the platform notifies rule 2 to re-examine along the path. In the example, if rule 1 adjusts to enable the order creation influence of the amount field, the path ensures that the VIP condition of rule 2 responds promptly, avoiding delays. After the graph is constructed, the platform stores the updated graph structure, supporting subsequent queries and propagation.

[0145] Optionally, rules can be grouped by clustering and combined with a hierarchical combination of coarse-grained grids and fine-grained graphs to achieve hierarchical propagation of adjustment effects, improve the manageability and execution efficiency of the system under multi-layered dependencies, and reduce the resource consumption of full graph traversal.

[0146] In a specific implementation, this optional implementation extends the process of establishing cascading dependency paths. First, based on the conditional dependency and the adjustment dependency, the policy rules are clustered to generate one or more policy rule groups. The clustering operation calculates the correlation between the policy rules based on the overlap of the dependencies.

[0147] Specifically, based on the identified dependencies, the platform extracts the conditional dependencies and adjustment dependencies from each policy rule, forming corresponding dependency attribute lists. For example, the conditional dependency of policy rule 1 is "amount," and the adjustment dependency is "create order"; the conditional dependency of policy rule 2 is "user level," and the adjustment dependency is "update order."

[0148] To assess the correlation between policy rules, the platform compares the dependency attribute lists of any two policy rules and calculates their dependency overlap. The overlap is calculated as follows: first, the number of intersection elements of the dependency attribute lists of the two policy rules is obtained as the intersection size; then, this intersection size is divided by the total number of unique attributes after merging the two dependency attribute lists to obtain the correlation value.

[0149] For example, if the dependency lists of Rule 1 and Rule 2 both contain the attribute "amount", the intersection size is 1. If there are 4 unique attributes among all the dependency attributes of the two rules, the calculated association degree is 0.25.

[0150] Based on the aforementioned correlation, the platform performs clustering operations, grouping highly correlated policy rules into the same group. The clustering process employs an iterative merging strategy. Initially, each policy rule forms its own independent group. Subsequently, policy rule pairs with correlation exceeding a preset correlation threshold are merged round by round until the grouping structure no longer changes, forming a stable policy rule group.

[0151] Ultimately, each generated policy rule group can serve as a node unit for subsequently building the grid structure. For example, in one implementation, policy rule group 1 contains rule 1 and rule 2, which are grouped together because they share a dependency on the "amount" attribute, thus becoming an entity in the grid node.

[0152] Based on the dependencies between the policy rule groups, a mapping operation is performed on the policy rule groups to construct a coarse-grained dependency grid containing the policy rule groups as nodes. Specifically, the platform checks the associations between groups. For example, if the rules of group 1 depend on "amount" and the rules of group 2 depend on "user level", if an adjustment in group 1 affects "amount" and group 2 conditionally depends on "amount", then an edge is added from group 1 to group 2. The principle of the mapping operation is similar to a fine-grained graph, but it is done on a group-by-group basis, for example, using an adjacency list: {"group1": [{"to": "group2", "type": "dependency"}]}, constructing a grid as a coarse-grained view to ensure a high-level overview of rule associations. For example, in "Order Management", group 1 (order creation related rules) and group 2 (user verification related rules) form grid edges by sharing "amount".

[0153] The coarse-grained dependency grid and the dependency graph are combined to form a hierarchical multi-dependency structure, wherein the cascading dependency paths traverse both the coarse-grained dependency grid and the dependency graph. Specifically, the platform creates a hierarchical graph, with grid nodes (groups) at the upper level and fine-grained nodes (rules) at the lower level, and adds cross-level edges, such as edges from group 1 to the edge containing rule 1.

[0154] The principle of the combination operation is recursive merging. For example, iterates through the grid edges; if an edge exists between group 1 and group 2, the path between rules is copied at the lower level to ensure cascading continuity. Cascading paths traverse the grid and graph; for example, a path from group 1 to rule 1 to rule 2 to group 2 is used to propagate the impact of adjustments. This structure is stored as nested JSON, such as {"grid": {"group1": {"subGraph": {"rule1": [...]}}}, supporting hierarchical queries. For example, in "Order Management," new adjustments propagate from group 1 to group 2, preventing system-wide diffusion.

[0155] Optionally, to address the issue of implementing a layered evaluation mechanism during the strategy evaluation engine configuration phase in low-code platform data modeling to handle performance bottlenecks under large-scale rules and avoid latency and resource waste caused by full-map scanning, an initial evaluation using a coarse-grained grid can quickly locate affected groups. Then, fine-grained queries and evaluations can be performed within each group, ensuring the engine only processes relevant parts. This improves the system's response speed and efficiency in dynamic business environments while maintaining the accuracy of adjustments.

[0156] In a specific implementation, this optional approach extends the configuration process of the policy evaluation engine. First, in response to the data state satisfying the condition, an initial evaluation operation is performed on the coarse-grained dependency grid to identify the affected policy rule groups. Specifically, when a data state change triggers a condition, the engine first accesses the grid structure, which uses rule groups as nodes.

[0157] Furthermore, the initial evaluation operation checks group-level dependencies by traversing grid nodes. For example, for changing the attribute "Amount," the engine searches for group nodes connected to "Amount" in the grid, such as group 1 (which includes order-related rules), and identifies the affected group by matching node labels. The principle of the evaluation operation is to utilize the simplified topology of the grid, checking only group-level edges instead of all rules, thus reducing computational load. For example, in "Order Management," changing "Amount" only evaluates group 1 associated with "Amount," ignoring irrelevant groups.

[0158] Based on the results of the initial evaluation operation, a query operation is performed on the dependency graph within the affected policy rule group to determine the associated policy rules.

[0159] Specifically, for the identified group 1, the engine switches to a fine-grained dependency graph within the group and performs query operations, such as traversing along the edges from the changed attribute node to the rule node. For example, querying the connection between rule 1 and rule 2 from the "amount" node. The query operation is based on depth-first search or breadth-first search, limiting it to the group boundaries to avoid global traversal. For example, in group 1, the query returns rule 1 (conditionally dependent on "amount") as the association rule.

[0160] The associated strategy rules undergo detailed condition evaluation, and corresponding dynamic adjustment instructions are executed. Specifically, for the queried rule 1, the engine substitutes the current data state evaluation condition expression, such as checking whether "amount > 1000" is true. After confirming that the condition is met through string parsing and value comparison, adjustment instructions are executed, such as enabling the "create order" action. The principle of the evaluation operation is to execute rules one by one, while the execution instructions update the runtime configuration, such as modifying permission flags.

[0161] Optionally, this application further establishes bidirectional connections by creating extension and backtracking paths to ensure smooth information flow from coarse to fine granularity, improve the maintainability of the structure and query efficiency, while reducing the overhead of level switching and enhancing the overall stability of the system during dynamic adjustments.

[0162] In specific implementation, firstly, for each policy rule group in the coarse-grained dependency grid, an extension path is established pointing to the policy rules included in the policy rule group in the dependency graph.

[0163] Specifically, the platform traverses each group node in the grid. For example, for group 1, which includes rule 1 and rule 2, edges pointing to rule 1 and rule 2 are added from the group 1 node. The operation of establishing extension paths is implemented by iterating through the list of rules within the group. For example, a for loop is used to access the member rules of the group, and a directional edge is added to each member, such as the edge from "group1" to "rule1", labeled "extension". The principle of the path is to simulate the expansion from the abstract layer (group) down to the concrete layer (rule), ensuring that information flows downward from a higher level, such as quickly locating rules from the group during a query. This path is stored in the grid's extension properties, for example, in JSON format: {"group1": {"extensions": [{"to": "rule1"}, {"to": "rule2"}]}}. For example, in the "Order Management" business object, group 1 (related to order creation) extends to rule 1 (amount check) and rule 2 (permission adjustment), and the path ensures that group-level changes propagate downwards.

[0164] Next, for each policy rule in the dependency graph, a backtrace path is established pointing to the policy rule group to which the policy rule belongs. Specifically, the platform traverses each rule node in the graph; for example, for rule 1 (belonging to group 1), an edge pointing to group 1 is added from the rule 1 node. The operation of establishing the backtrace path is implemented through reverse mapping, for example, using a key-value table to record the relationship between rules and groups, and adding a directional edge from "rule1" to "group1", labeled "backtrace". The principle of the path is to support backtracking from fine-grained to the abstract layer, ensuring that updates aggregate effects upwards from the rules, such as tracing group-level states from rules during evaluation. This path is stored in the graph's backtrace attribute, for example, in JSON format: {"rule1": {"backtrace": "group1"}}. For example, in "Order Management", rule 1 backtracks to group 1; the path ensures that rule changes are notified upwards to the group, avoiding isolated updates. In this application, a backtrace refers to a directed edge in the dependency graph from a "strategy rule node" to its "strategy rule group node", used for uplink references and influence aggregation from fine-grained to coarse-grained.

[0165] Based on the extended path and the backtrace path, a mapping operation is performed on the coarse-grained dependency grid and the dependency graph to construct the hierarchical multi-dependency structure, wherein the extended path and the backtrace path form a bidirectional connection. Specifically, the platform creates a composite graph structure with a grid at the top and a dependency graph at the bottom, achieving connections by merging paths. For example, traversing all extended and backtrace edges and adding them as cross-layer links to the overall graph ensures bidirectional traversal is possible, such as extending from group 1 to rule 1 and then backtraceing back to group 1. The mapping operation utilizes pointer references to connect levels, for example, embedding a lower-level subgraph reference in the grid node and an upper-level parent reference in the graph node. The construction process verifies the integrity of the connections, for example, checking that each rule has a backtrace path. The final structure is stored as nested data, for example, JSON: {"grid": {"group1": {"subGraph": {"rule1": {"backtrace": "group1"}}}}}. For example, in "Order Management", this structure supports querying rule 1 changes from group 1 and retroactively affecting group 2, achieving bidirectional propagation.

[0166] Optionally, by generating revocable command objects and combining them with a state memorandum mechanism, it can be ensured that every adjustment has the ability to be executed forward and undone backward, providing a safety net, improving the fault tolerance and stability of the system, and reducing debugging costs.

[0167] In practice, based on the met conditions, a revocable command object is generated, including forward execution logic and reverse reversal logic, where the forward execution logic corresponds to dynamic adjustments. Specifically, when the condition is met, such as order amount > 1000, the platform creates a command object instance. This object is a structure that encapsulates the logic, for example, creating a class instance using object-oriented programming, including two methods: one method implements the forward logic, such as updating the permission configuration from "disabled" to "allowed"; the other method implements the reverse logic, such as restoring the original permissions. The generation process is implemented through template instantiation, for example, copying from a predefined command template and filling in specific adjustment details, such as the target attribute "createOrder" and the operation "enablePermission".

[0168] The principle behind command objects is to encapsulate and adjust them into independent units, making them easier to manage and rollback. For example, in the "Order Management" business object, command objects are generated for permission adjustments and stored as memory objects: {"forward": function enable(), "reverse": function disable()}.

[0169] Next, the behavior or relationship structure of the application component prior to the dynamic adjustment is captured, and the behavior or relationship structure is associated with the reversible command object as a state memo, wherein the reverse reversal logic uses the state memo to restore the behavior or relationship structure.

[0170] Specifically, the platform copies the current structure before execution. For example, for a behavior structure, it copies all key-value pairs from the permission configuration table, such as {"createOrder_permission": "disable"}; for a relational structure, it copies the list of associated fields, such as {"relations": [{"key": "userId"}]}. The capture process is implemented using a serialization tool, which converts the structure into a storable format, such as a JSON string, and associates it with the properties of the command object. For example, the command object is expanded to {"stateMemento": JSON.stringify(currentStructure)}.

[0171] The principle behind reverse logic is to deserialize and apply the memo. For example, upon reversal, the JSON is parsed and the current structure is overwritten to ensure restoration to the original state. For instance, in "Order Management," the permission was "disable" before capture, the memo recorded this value, and it was directly replaced with "disable" upon reversal.

[0172] Then, the forward methods of the command object are called, such as executing the enable() function, to update the runtime configuration table, such as changing {"createOrder_permission": "disable"} to "allow". The principle behind the execution process is direct modification of memory, rather than file modification, ensuring no impact on the source code.

[0173] Finally, the revocable command object is recorded in the transaction history stack, achieving atomic revocation of the dynamic adjustment. Specifically, the platform maintains a stack structure (such as an array), and after execution, the command object is pushed onto the top of the stack, for example, stack.push(commandObj). The recording process follows the principle of last-in, first-out (LIFO) stack, supporting the popping of objects and invoking reverse logic during revocation. Atomic revocation is implemented through transaction wrapping, for example, locking the structure when popping from the stack and unlocking it after revocation, ensuring consistency. For example, in "order management," if an error is found after adjustment, the user triggers revocation, the command is popped from the stack, and reverse logic is invoked to restore the original structure without restarting the application.

[0174] Optionally, the clustering operation includes:

[0175] Extract the conditional dependency and the adjustment dependency as feature vectors for any two policy rules;

[0176] The structural association weight between any two policy rules is calculated based on the feature vector. The calculation of the structural association weight includes asymmetric weighting of the type differences between the conditional dependency and the adjustment dependency, and normalization of the structural association weight according to the frequency of occurrence of data attributes in the conditional dependency and the adjustment dependency.

[0177] Record the runtime behavior logs of the policy evaluation engine executing each policy rule, and divide the logs by time windows;

[0178] Calculate the temporal correlation weight between any two policy rules based on the partitioned logs, and calculate the trend factor of the temporal correlation weight.

[0179] The structural correlation weight, the temporal correlation weight, and the trend factor are combined to generate a predictive hybrid correlation weight between any two policy rules.

[0180] Based on the predictive hybrid association weights, an association graph is constructed with the policy rules as nodes, and a community detection algorithm is applied to the association graph to divide the policy rules into different policy rule groups.

[0181] This optional embodiment generates predictive hybrid association weights by combining static dependency extraction and runtime log analysis, thereby achieving forward-looking optimization of rule clustering. This ensures that grouping more accurately reflects future changes, improves the engine's adaptability in changing business environments, and reduces the resource consumption of frequent clustering.

[0182] In specific implementation, the conditional dependency and the adjustment dependency are extracted as feature vectors for any two policy rules.

[0183] Specifically, the records of two rules are read from the dependency graph. For example, the conditional dependency of rule 1 is "amount" and "user level", and the adjustment dependency is "create order"; the conditional dependency of rule 2 is "user level" and "order status", and the adjustment dependency is "update order".

[0184] The extraction operation is implemented by traversing the edge list of the graph, converting the dependencies of each rule into vector form. For example, the vector for rule 1 is a list: ["condition:amount", "condition:userLevel", "adjustment:createOrder"], where each item is composed of a dependency type and an attribute name. The principle of this extraction is to standardize dependencies into comparable elements, ensuring that the vector captures the complete association pattern of the rules. For example, in the "Order Management" business object, after extraction, the vector length of rule 1 is 3, and that of rule 2 is 4, facilitating subsequent comparison.

[0185] Furthermore, the common terms of the two vectors are compared; for example, Rule 1 and Rule 2 share "userLevel" as a conditional dependency. Asymmetric weighting is performed to handle type differences using preset coefficients, such as a conditional dependency coefficient of 1.0 and an adjusted dependency coefficient of 0.8. Then, a weighted sum of the shared terms is calculated. Frequency is calculated by counting the number of times a data attribute appears in all rule dependencies; for example, "userLevel" appears 3 times, and the total number of attributes is 10, resulting in a frequency of 0.3. This frequency is used to multiply the weighted sum for normalization: weight = weighted sum / maximum possible sum. The calculation process iterates through all rule pairs to generate a weight matrix. The principle behind this weighting is to emphasize the stability of conditional dependencies, while normalization ensures that the weights are standardized for easy comparison.

[0186] Furthermore, the engine writes to a log file during rule execution, such as recording the execution timestamp T1 of rule 1 and the context, such as the trigger attribute "amount". This logging is implemented through hook functions, appending entries after each evaluation, such as {"ruleId": "rule1", "timestamp": "2025-07-29T10:00:00", "trigger": "amount"}. Dividing the logs into time windows involves grouping them at fixed intervals, such as every 5 minutes, by sorting the timestamps and slicing the list. For example, window 1 contains all logs from T1 to T1+5 minutes. The principle behind this logging is to capture the temporal pattern of the rules, ensuring that the logs cover the execution history.

[0187] Furthermore, for any two rules, the number of times they co-occur within the same window is counted. For example, if rule 1 and rule 2 co-occur 6 times in 10 windows, the association weight is 6 / 10 = 0.6. This calculation is performed using nested loop windows and rule pairs. The trend factor is calculated by comparing the association changes in consecutive windows. For example, if the current window's association is 0.6 and the previous one was 0.4, the trend factor is 0.6 - 0.4 = 0.2, indicating an increase. The principle behind this weight is to quantify time-series patterns; the trend factor predicts future changes.

[0188] Furthermore, weighted summation, such as mixed weights, can be used. Structural weights Time series weights Trend factors, with coefficients based on scenario presets. The combination operation iterates through all rule pairs to generate the final matrix. The principle behind this combination is to integrate multi-dimensional information to provide predictive indicators.

[0189] Furthermore, the graph construction uses weights as edge values; for example, the edge weight from node "rule1" to "rule2" is 0.55. The community detection algorithm is implemented by iteratively grouping nodes with high-weight connections, for example, starting with random grouping and adjusting to maximize the weight within each group. The partitioning operation generates a list of groups, such as group 1 containing rule 1 and rule 2. The principle behind this algorithm is to detect natural clusters, thus improving grouping accuracy.

[0190] Based on the same inventive concept, this application also provides a low-code platform data modeling system based on Dataset technology, corresponding to a low-code platform data modeling method based on Dataset technology. Since the principle of the system in this application is similar to the aforementioned low-code platform data modeling method based on Dataset technology in this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0191] Reference Figure 4The diagram shown is a schematic of a low-code platform data modeling system based on Dataset technology provided in an embodiment of this application. The system includes:

[0192] The acquisition module 10 is used to acquire configuration information for a target business object. The configuration information includes action attributes, relationship attributes, and strategy attributes. The strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met. The strategy rules include conditional expressions and dynamic adjustment instructions.

[0193] Processing module 20 is configured to generate structured metadata based on the configuration information; and based on the structured metadata, generate application components for a policy evaluation engine to execute the policy rules, including: extracting the conditional expressions and dynamic adjustment instructions, identifying the dependency relationship between the policy rules and the configuration information; calculating the structural association weights and temporal association weights between the policy rules based on the dependency relationship, and generating predictive hybrid association weights; and performing clustering operations on the policy rules based on the predictive hybrid association weights to optimize the rule execution efficiency of the policy evaluation engine.

[0194] The adjustment module 30 is configured to, during the operation of the application component, have the strategy evaluation engine monitor the data status of the target business object in real time; and, in response to the data status satisfying the conditions in the strategy rules, dynamically adjust the behavior or relationship structure of the application component by the strategy evaluation engine; wherein the dynamic adjustment is performed without modifying the generated source code.

[0195] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

Claims

1. A low-code platform data modeling method based on Dataset technology, characterized in that, include: Obtain configuration information for the target business object, the configuration information including action attributes, relationship attributes, and strategy attributes; wherein, the strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met, the strategy rules including conditional expressions and dynamic adjustment instructions; Based on the configuration information, structured metadata is generated; based on the structured metadata, an application component for executing the policy rules is generated, including: extracting the conditional expression and dynamic adjustment instructions, identifying the dependency relationship between the policy rules and the configuration information; calculating the structural association weight and temporal association weight between the policy rules based on the dependency relationship, and generating predictive hybrid association weight; performing clustering operations on the policy rules based on the predictive hybrid association weight to optimize the rule execution efficiency of the policy evaluation engine; During the operation of the application component, the strategy evaluation engine monitors the data status of the target business object in real time; In response to the data state satisfying the conditions in the policy rules, the policy evaluation engine dynamically adjusts the behavior or relational structure of the application components; wherein, the dynamic adjustment is performed without modifying the generated source code; The clustering operation includes: Extract the conditional dependency and adjustment dependency as feature vectors for any two of the aforementioned strategy rules; The structural association weight between any two policy rules is calculated based on the feature vector. The calculation of the structural association weight includes asymmetric weighting of the type differences between the conditional dependency and the adjustment dependency, and normalization of the structural association weight according to the frequency of occurrence of data attributes in the conditional dependency and the adjustment dependency. Record the runtime behavior logs of the policy evaluation engine executing each policy rule, and divide the logs by time windows; Calculate the temporal correlation weight between any two policy rules based on the partitioned logs, and calculate the trend factor of the temporal correlation weight. The structural correlation weight, the temporal correlation weight, and the trend factor are combined to generate a predictive hybrid correlation weight between any two policy rules. Based on the predictive hybrid association weights, an association graph is constructed with the policy rules as nodes, and a community detection algorithm is applied to the association graph to divide the policy rules into different policy rule groups.

2. The low-code platform data modeling method based on Dataset technology according to claim 1, characterized in that, The configuration information also includes: data attributes; the application components for generating the policy evaluation engine to execute the policy rules include: The structured metadata is parsed to extract the conditional expressions and dynamic adjustment instructions in the policy rules, and the data attributes referenced in the conditional expressions are analyzed to identify the dependency relationship between the policy rules and the data attributes. Based on the dependency relationship, a mapping operation is performed on the data attribute, the conditional expression, and the dynamic adjustment instruction to generate a dependency graph from the data attribute to the strategy rule; Based on the dependency graph, a data interceptor is generated for monitoring the target business object; The data interceptor is integrated into the application component to generate an application component that includes the policy evaluation engine; The data interceptor is configured as follows: In response to a change in the value of the data attribute, a query operation is performed on the dependency graph to obtain the conditional expression and dynamic adjustment instruction associated with the changed data attribute, and the strategy evaluation engine is triggered only to evaluate the associated conditional expression and execute the dynamic adjustment instruction.

3. The low-code platform data modeling method based on Dataset technology according to claim 2, characterized in that, The process of generating the dependency graph from the data attributes to the policy rules includes: The conditional expression of each policy rule is parsed to identify the conditional dependency of the policy rule on the data attribute; The dynamic adjustment instructions for each policy rule are parsed to identify the policy rule's dependency on the data attribute adjustment. Based on the conditional dependencies and the adjustment dependencies, mapping operations are performed on the data attributes and the policy rules to construct the dependency graph.

4. The low-code platform data modeling method based on Dataset technology according to claim 3, characterized in that, The construction of the dependency graph includes: Iterate through the set of policy rules; Each policy rule pair in the set is examined, wherein the policy rule pair includes a first policy rule and a second policy rule in the set, and the data attribute associated with the adjustment dependency of the first policy rule and the data attribute associated with the condition dependency of the second policy rule are compared. In response to the fact that the data attribute associated with the adjustment dependency of the first policy rule is the same as the data attribute associated with the conditional dependency of the second policy rule, a cascading dependency path is established in the dependency graph from the first policy rule to the second policy rule. The cascading dependency path is used to propagate the adjustment effect.

5. A low-code platform data modeling method based on Dataset technology according to claim 4, characterized in that, The step of establishing a cascading dependency path in the dependency graph from the first policy rule to the second policy rule includes: Based on the conditional dependency and the adjustment dependency, the policy rules are clustered to generate one or more policy rule groups, wherein the clustering operation calculates the correlation between the policy rules based on the overlap between the conditional dependency and the adjustment dependency. Based on the dependencies between the policy rule groups, a mapping operation is performed on the policy rule groups to construct a coarse-grained dependency grid that includes the policy rule groups as nodes. The coarse-grained dependency grid and the dependency graph are combined to form a hierarchical multi-dependency structure, wherein the cascading dependency paths run through the coarse-grained dependency grid and the dependency graph.

6. A low-code platform data modeling method based on Dataset technology according to claim 5, characterized in that, The policy evaluation engine is configured as follows: In response to the detection of a change in the data state of the target business object, an initial evaluation operation is performed on the coarse-grained dependency grid to identify the affected policy rule groups; Based on the results of the initial evaluation operation, a query operation is performed on the dependency graph within the affected policy rule group to determine the associated policy rules. The associated policy rules are evaluated for conditions, and the corresponding dynamic adjustment instructions are executed.

7. A low-code platform data modeling method based on Dataset technology according to claim 6, characterized in that, The hierarchical multi-dependency structure includes: For each policy rule group in the coarse-grained dependency grid, establish an extension path pointing to the policy rules included in the policy rule group in the dependency graph; For each policy rule in the dependency graph, establish a backtracking path pointing to the policy rule group to which the policy rule belongs; Based on the extended path and the backtracking path, a mapping operation is performed on the coarse-grained dependency grid and the dependency graph to construct the hierarchical multi-dependency structure, wherein the extended path and the backtracking path form a bidirectional connection.

8. A low-code platform data modeling method based on Dataset technology according to claim 1, characterized in that, The step of dynamically adjusting the behavior or relational structure of the application component by the policy evaluation engine in response to the data state satisfying the conditions in the policy rules includes: In response to the policy evaluation engine's evaluation result of the conditional expression of the policy rule being satisfied, an undoable command object is generated, which includes forward execution logic and reverse undo logic, wherein the forward execution logic corresponds to dynamic adjustment; The behavior or relational structure of the application component prior to the dynamic adjustment is captured, and the behavior or relational structure is associated with the reversible command object as a state memo, wherein the reverse reversal logic uses the state memo to restore the behavior or relational structure. Execute the forward execution logic of the revocable command object to adjust the behavior or relational structure of the application component; The revocable command object is recorded in the transaction history stack to achieve the atomic revocation of the dynamic adjustment.

9. A low-code platform data modeling system based on Dataset technology, characterized in that, include: The acquisition module is used to acquire configuration information for a target business object. The configuration information includes action attributes, relationship attributes, and strategy attributes. The strategy attributes include strategy rules for dynamically adjusting the action attributes or relationship attributes when conditions are met. The strategy rules include conditional expressions and dynamic adjustment instructions. The processing module is configured to generate structured metadata based on the configuration information; and based on the structured metadata, generate application components for a policy evaluation engine to execute the policy rules, including: extracting the conditional expressions and dynamic adjustment instructions, identifying the dependencies of the policy rules on the configuration information; calculating the structural association weights and temporal association weights between the policy rules based on the dependencies, and generating predictive hybrid association weights; and performing clustering operations on the policy rules based on the predictive hybrid association weights to optimize the rule execution efficiency of the policy evaluation engine. An adjustment module is configured to, during the operation of the application component, have the strategy evaluation engine monitor the data status of the target business object in real time; and, in response to the data status satisfying the conditions in the strategy rules, have the strategy evaluation engine dynamically adjust the behavior or relationship structure of the application component; wherein, the dynamic adjustment is performed without modifying the generated source code; The clustering operation includes: Extract the conditional dependency and adjustment dependency as feature vectors for any two of the aforementioned strategy rules; The structural association weight between any two policy rules is calculated based on the feature vector. The calculation of the structural association weight includes asymmetric weighting of the type differences between the conditional dependency and the adjustment dependency, and normalization of the structural association weight according to the frequency of occurrence of data attributes in the conditional dependency and the adjustment dependency. Record the runtime behavior logs of the policy evaluation engine executing each policy rule, and divide the logs by time windows; Calculate the temporal correlation weight between any two policy rules based on the partitioned logs, and calculate the trend factor of the temporal correlation weight. The structural correlation weight, the temporal correlation weight, and the trend factor are combined to generate a predictive hybrid correlation weight between any two policy rules. Based on the predictive hybrid association weights, an association graph is constructed with the policy rules as nodes, and a community detection algorithm is applied to the association graph to divide the policy rules into different policy rule groups.

Images