Business rule visualization method and system based on low-code platform

Abstract

The invention relates to a business rule visualization method and system based on a low-code platform, and the method comprises the steps: recognizing the configuration operation information of a user on the low-code platform, carrying out the description object construction of the configuration operation information, and generating a target description object; extracting a component descriptor from the target description object, and constructing a rule execution graph based on the component descriptor; performing attribute verification and code construction on the rule execution graph based on a preset logic rule to obtain a rule code link; and filling the rule code link into a preset code template for source code compiling to obtain a target source code. According to the method, the problems that the conversion process is opaque and the code quality is uncontrollable due to the fact that an existing low-code platform lacks a structured description and verification mechanism for a complete logic link in a rule can be solved.

Description

Technical Field

[0001] This invention relates to the technical field of low-code platforms, and in particular to a method and system for visualizing business rules based on a low-code platform. Background Technology

[0002] In the current context of the widespread use of low-code platforms in enterprises to rapidly build information systems, a significant contradiction exists between the agile definition and correctness assurance of business rules and their efficient technical implementation. While existing mainstream low-code platforms offer visual drag-and-drop interfaces to simplify development, the business logic they generate is often a flat, fragmented combination of code. This approach lacks a structured description and verification mechanism for the complete logical chain within the rules, making the conversion process from visual rules to executable code less transparent and reliable. Summary of the Invention

[0003] The main objective of this invention is to provide a business rule visualization method and system based on a low-code platform, which can solve the problems of opaque conversion process and uncontrollable code quality caused by the lack of structured description and verification mechanism for the complete logical link inside the rule in existing low-code platforms.

[0004] To achieve the above objectives, the present invention provides a business rule visualization method based on a low-code platform, comprising: Identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object; Component descriptors are extracted from the target description object, and a rule execution graph is constructed based on the component descriptors; Based on preset logical rules, attribute verification and code construction are performed on the rule execution graph to obtain the rule code link; The rule code link is filled into a preset code template and the source code is compiled to obtain the target source code.

[0005] Preferably, the step of identifying user configuration operation information on the low-code platform, constructing a description object from the configuration operation information, and generating a target description object includes: Identify the component type identifier, attribute key-value pairs, and inter-component connection information in the configuration operation information; Traverse the attribute keys and attribute values ​​in the attribute key-value pairs, match each attribute key with a preset attribute description template, and if a match is successful, extract the attribute value and fill it into the attribute description template to generate an attribute description unit. Based on the component type identifier, the corresponding basic description framework is searched from the preset framework component library, and all the attribute description units are injected into the basic description framework to obtain the attribute description framework. When an indication to establish connection information is detected in the inter-component connection information, a connection node is created in the attribute description framework, and the inter-component connection information is filled into the connection node to obtain the target description object.

[0006] Preferably, the step of extracting component descriptors from the target description object and constructing a rule execution graph based on the component descriptors includes: The component descriptors are extracted from the target description object based on a preset node type mapping table, and each component descriptor is converted into a logical node. Traverse the directed edges in the target description object, and construct the directed connection relationship of the corresponding logical node based on the start node information and end node information of each directed edge; Based on the directed connection relationship, the number of times each logical node is pointed to by other nodes is counted, and all logical nodes that are pointed to zero times are integrated into a candidate root node set. Based on the directed connection relationship, a topological traversal and hierarchical allocation are performed on the candidate root node set to obtain the hierarchical relationship; Based on the hierarchical relationship and the candidate root node set, the root nodes are recursively connected to obtain the rule execution graph.

[0007] Preferably, the step of extracting the component descriptor from the target description object based on a preset node type mapping table and converting each component descriptor into a logical node includes: Parsing the component descriptor yields the component category code and configuration item set; Based on the node type mapping table, the component classification code is used to identify operations and obtain operation behavior information; Based on the operational behavior information, locate the corresponding node logical skeleton from the node type mapping table; Each assignment item in the configuration item set is matched with the assembly interface of the node logic skeleton. When the assignment item matches a certain assembly interface, the assignment item is filled into the assembly interface. After all the assembly interfaces have been filled with the assignment items, the node logic skeleton is instantiated and transformed to generate the logic node.

[0008] Preferably, the step of performing topological traversal and hierarchical allocation on the candidate root node set based on the directed connection relationship to obtain the hierarchical relationship includes: Candidate root nodes in the candidate root node set are selected sequentially as starting nodes, and the level of the starting node is marked as the initial level; According to the directed connection relationship, each downstream node connected to the starting node is traversed sequentially, and the downstream nodes are allocated hierarchically according to the preset hierarchical allocation rules and the initial hierarchical level to obtain the allocation level. When it is detected that the downstream node has been assigned a level, the original level value of the downstream node is compared with the new level value of the assigned level. If the new level value is less than the original level value, the level value of the downstream node is updated according to the new level value. When all downstream nodes reachable from the candidate root node set have been visited and the downstream nodes already have the allocation level, all downstream nodes and the allocation level are integrated to generate the hierarchy relationship.

[0009] Preferably, the step of performing attribute verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link includes: Each structural unit in the rule execution graph is accessed according to a predetermined structural order; Whenever a structural unit is accessed, the structural unit is validated according to the preset logic rules. When the structural unit passes the attribute verification, a basic code framework matching the structural unit is obtained based on a preset code mapping table, and the structural unit is filled into the basic code framework to generate a unit code block; All the unit code blocks are connected according to the inter-unit connection relationship in the rule execution graph to generate the rule code link.

[0010] Preferably, the step of performing attribute verification on the structural unit according to the preset logic rules whenever a structural unit is accessed includes: Read the type identifier of the structural unit, and extract the type rule entries, attribute rule entries, and numerical range constraint set from the preset logical rules based on the type identifier; The multiple port data types of the structural unit are matched one by one with the type rule entries. If any port data type does not match, the structural unit is marked as an invalid unit. If the type rule entry is verified, the attribute rule entry is used to detect whether there are missing configuration values ​​in the attribute configuration of the structural unit. If there are missing attribute values, the structural unit is marked as an invalid unit. If no attribute value is missing, the configuration value is identified within a range according to the numerical range constraint set. If any configuration value does not belong to the numerical range constraint set, the structural unit is marked as an invalid unit. If all the configuration values ​​belong to the numerical range constraint set, the structural unit is determined to have passed the attribute verification.

[0011] Preferably, the step of connecting all the unit code blocks according to the inter-unit connection relationship in the rule execution graph to generate the rule code link includes: According to the connection relationship between the units, the unit code block corresponding to each structural unit is obtained in sequence, and the output data identifier list and input data requirement list of the structural unit are extracted. The first obtained unit code block is used as the starting block, and all the unit code blocks are placed into a preset ordered code block set; Identify the successor unit of the starting block in the rule execution graph, and match the output data identifier list of the starting block with the input data requirement list of the successor unit; If the match is successful, the unit code block of the successor unit is appended to the starting block; If the match fails, a data bridging code is generated based on the preset data completion mapping table, and the data bridging code and the unit code block of the subsequent unit are sequentially appended to the ordered code block set; Once all the structural units have been processed, all the code blocks in the ordered code block set are sequentially merged into the rule code link.

[0012] Preferably, the step of filling the rule code link into a preset code template and compiling the source code to obtain the target source code includes: Identify the reserved rule code insertion positions in the code template; The rule code chain is embedded at the rule code insertion point to form the initial source code; Extract variable identifiers and external dependency interfaces from the initial source code, perform configuration analysis on the variable identifiers and external dependency interfaces according to the code template, and generate compilation configuration information; Based on the compilation configuration information, the initial source code is compiled and linked to output the target source code.

[0013] The present invention also provides a business rule visualization system based on a low-code platform, applied to any of the above-described business rule visualization methods based on a low-code platform, comprising: The acquisition module is used to identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object. An analysis module is used to extract component descriptors from the target description object and construct a rule execution graph based on the component descriptors; The association module is used to perform compliance verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link; The processing module is used to fill the rule code link into a preset code template for source code compilation to obtain the target source code.

[0014] The present invention provides a business rule visualization method and system based on a low-code platform, which has the following beneficial effects: By constructing a rule execution graph as a structured intermediate representation of business logic and performing attribute validation and code building on it, this effectively solves the problems of opaque transformation processes and uncontrollable code quality in existing low-code platforms, which suffer from a lack of structured description and verification mechanisms for the complete logical links within rules. It transforms fragmented visual configurations into a verifiable and traceable logical whole, ensuring that business intents are accurately and automatically mapped to high-quality source code. This significantly enhances the reliability, maintainability, and responsiveness to business changes of the generated code while improving development efficiency. Attached Figure Description

[0015] Figure 1 This invention also provides a flowchart of a business rule visualization method based on a low-code platform; Figure 2 This invention also provides a business rule visualization system architecture diagram based on a low-code platform.

[0016] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0018] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0019] Reference Figure 1 As shown, this invention provides a business rule visualization method based on a low-code platform, comprising: Step S1: Identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object; Step S2: Extract component descriptors from the target description object and construct a rule execution graph based on the component descriptors; Step S3: Perform attribute verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link; Step S4: Fill the rule code link into the preset code template and compile the source code to obtain the target source code.

[0020] Based on the steps described above, the detailed process is as follows: Step S1: By monitoring the event bus of the low-code platform's graphical interface, real-time information is captured from user drag-and-drop, attribute input, and component connection configurations. This configuration information includes operation type, component ID, and parameter values. Based on predefined semantic mapping rules, the raw events are compiled into an intermediate description language. Each component placed on the canvas is instantiated as a description object node, containing a metadata area (recording component type, position, and ID) and a payload area (storing configured attribute key-value pairs). For each connection line drawn by the user, its starting and ending components and ports are parsed to generate a connection relationship record containing the source component, source port, target component, and target port. All description object nodes and connection relationship records of all components within the canvas are integrated and encapsulated into a target description object using a hierarchical data format (such as JSON / XML).

[0021] Step S2: The target description object is parsed, and each component description object node is traversed to extract its type identifier and configuration attribute set, which are then encapsulated into a component descriptor. Using a pre-maintained node type mapping table, different types of component descriptors are instantiated into logical nodes with clear semantics (e.g., conditional judgment components are mapped to branch logical nodes). Each logical node inherits the specific configuration parameters of the descriptor. All connection relationship records stored in the target description object are parsed, and the same connection topology is reproduced between these logical nodes, constructing an initial logical graph in memory with logical nodes as vertices and directed connections as edges.

[0022] By analyzing the topology of the directed graph and calculating the in-degree of each node, nodes with an in-degree of zero are identified as candidate execution starting points. Starting from these root nodes, a topology traversal is performed based on the connection relationships, assigning execution order or logical level numbers to nodes, handling special cases such as circular dependencies, and finally forming a structured rule execution graph.

[0023] Step S3: The rule execution graph is traversed and reviewed according to preset logical rules. The verification process focuses on the compliance of the internal attributes of each logical node, loading the rule set associated with the node type (including data type constraints, required attribute validation, and parameter value range definitions). Each node is accessed one by one, and its configured attribute values ​​are matched with the corresponding rules; any verification failure is immediately marked, and a diagnostic report containing the node location and violation details is generated and fed back to the user interface, preventing the process from proceeding to the next stage.

[0024] Validated nodes proceed to the code construction phase: Based on a predefined code mapping table, different types of logical nodes are mapped to corresponding parameterized basic code frameworks (i.e., templates containing fixed syntax structures and variable parameter placeholders). Validated configuration values ​​are extracted from the nodes and populated into the corresponding placeholders in the template, thus instantiating a unit code block. According to the execution order and data flow defined by the directed connections between nodes in the rule execution graph, all unit code blocks are sequentially chained together. During connection processing, data interface compatibility between preceding and following code blocks is checked, and data transformation code is automatically inserted when necessary to generate rule code chains.

[0025] Step S4: Select the corresponding preset code template based on the target deployment environment (e.g., Java Spring Boot, Python Flask). This template is a source file framework with a fixed structure (e.g., import declarations, main class framework) and reserved insertion points for rule code. The rule code chain is treated as a whole module and precisely embedded into this reserved location. Before and after embedding, the rule code chain is analyzed to extract all declared variables, function calls, and external dependencies. Based on this, necessary dependency library references and variable definitions are automatically added to the template's import / declaration section. The complete source code file integrating the business logic is submitted to a standard compilation toolchain matching the target environment for processing (including lexical and syntax analysis, semantic checking, optimization, and linking).

[0026] If errors occur during compilation due to logical mistakes or missing dependencies, the error information will be captured and the corresponding node in the visualization will be located for correction. Successful compilation will output the target source code file.

[0027] This invention provides a business rule visualization method based on a low-code platform. By constructing a rule execution graph as a structured intermediate representation of business logic and performing attribute verification and code construction, it effectively solves the problems of opaque conversion processes and uncontrollable code quality in existing low-code platforms due to the lack of a structured description and verification mechanism for the complete logical links within rules. It transforms fragmented visualization configurations into a verifiable and traceable logical whole, ensuring that business intents are accurately and automatically mapped to high-quality source code. This improves development efficiency while enhancing the reliability, maintainability, and responsiveness to business changes in the generated code.

[0028] In some embodiments, identifying user configuration operation information on the low-code platform, constructing a description object from the configuration operation information, and generating a target description object includes: Identify the component type identifier, attribute key-value pairs, and inter-component connection information in the configuration operation information; The component type identifier is a unique type code for pre-defined business components (such as conditional statements or HTTP request boxes), and this type code is bound to the core logic function of the component. Attribute key-value pairs are sets of parameters configured by the user through the component's attribute panel, where the key corresponds to the parameter name and the value corresponds to the input parameter data.

[0029] Traverse the attribute keys and attribute values ​​in the attribute key-value pairs, match each attribute key with a preset attribute description template, and if a match is successful, extract the attribute value and fill it into the attribute description template to generate an attribute description unit. Specifically, for each attribute key, a lookup is performed in a pre-defined attribute-template mapping library. This library defines the correspondence between all configurable attribute keys supported by the platform and their corresponding code templates. The matching operation is based on the attribute key name. Upon successful matching, the associated attribute description template is retrieved. Syntax compliance processing is performed on the original attribute value, such as adding quotes to string values, escaping special characters, or converting user-input text (yes / no) to boolean values ​​(true / false). The processed attribute value is injected into a specific placeholder in the template, replacing the placeholder and generating an attribute description unit. All successfully matched attribute keys generate their corresponding attribute description units according to this process; unmatched attribute keys are recorded as exceptions or ignored.

[0030] Based on the component type identifier, the corresponding basic description framework is searched from the preset framework component library, and all the attribute description units are injected into the basic description framework to obtain the attribute description framework. When an indication to establish connection information is detected in the inter-component connection information, a connection node is created in the attribute description framework, and the inter-component connection information is filled into the connection node to obtain the target description object.

[0031] Specifically, the property description frame is checked to determine if the corresponding component has parsed the connection information. If a connection record exists, a connection node is created in a specific area of ​​the property description frame (usually the connection relationship area predefined in the frame template). For each connection record, a substructure is generated within the connection node. This substructure contains two core fields: source port identifier and target component reference. The source port identifier is directly taken from the source port name in the connection record, used to indicate which output end of this component initiated the connection; the target component reference is a pointer or identifier pointing to the target component (identified by the target component ID in the connection record). The information from the connection record is completely filled into this substructure. After embedding all its own connection nodes, each component's property description frame becomes a target description object.

[0032] The method provided in this embodiment directly converts user-input parameter values ​​into grammatically compliant code snippets by matching and filling attribute keys with predefined code templates, ensuring consistency from configuration to code semantics and eliminating syntax errors introduced by manual coding. By extracting the corresponding framework based on component type identifiers and injecting specific attribute units, it can quickly construct executable code prototypes that combine standard structure with specific business parameters, significantly improving the efficiency and standardization of the conversion from business logic design to code framework generation. By automatically integrating the connection relationships between components and forming a complete description object during processing, the visually defined business logic dependencies and data flows are fully preserved and mapped to the code structure, ensuring the correctness of the business logic and the integrity of the execution chain in the final generated source code.

[0033] In some embodiments, component descriptors are extracted from the target description object, and a rule execution graph is constructed based on the component descriptors, including: The component descriptors are extracted from the target description object based on a preset node type mapping table, and each component descriptor is converted into a logical node. Specifically, a pre-defined node type mapping table is loaded. The target description object is traversed, and for each component instance data within the target description object, its type identifier and attribute configuration set are extracted. Using the extracted type identifier as the key, the node type mapping table is queried to obtain the corresponding abstract logical node category (e.g., ConditionJudge maps to DecisionNode). Based on the mapped logical node category, a corresponding logical node object is instantiated. The instantiation process includes assigning a unique in-graph identifier to the logical node object and fully loading the attribute configuration set from the component descriptor into the logical node's parameter storage area. Each visual component corresponds to one logical node.

[0034] Traverse the directed edges in the target description object, and construct the directed connection relationship of the corresponding logical node based on the start node information and end node information of each directed edge; Specifically, all connection edge records in the target description object are accessed sequentially or iteratively. For each connection edge record, its starting component ID, starting port name, ending component ID, and ending port name are parsed. Based on the starting and ending component IDs, the corresponding source and target logical node objects are located in the logical node set. A directed connection is established between the source and target logical nodes. This connection is typically established by adding a reference to the target logical node to the outgoing edge set of the source logical node and a reference from the source logical node to the incoming edge set of the target logical node. The port information in the connection edge record is attached to this relationship as metadata, indicating the specific interface for data transmission.

[0035] Based on the directed connection relationship, the number of times each logical node is pointed to by other nodes is counted, and all logical nodes that are pointed to zero times are integrated into a candidate root node set. Based on the directed connection relationship, a topological traversal and hierarchical allocation are performed on the candidate root node set to obtain the hierarchical relationship; Among them, the hierarchical relationship is a data structure that records the mapping relationship between each logical node and its assigned hierarchy.

[0036] Specifically, starting with the set of candidate root nodes, initialize a queue or stack, add all nodes from the candidate root node set to it, and assign an initial level (e.g., level 0). Proceed with a loop: remove a node from the queue and visit it. Based on directed connections, find all direct successor nodes of this logical node (i.e., all target nodes pointed to by this node). For each successor node, consider the access status of all its predecessor nodes.

[0037] A successor node is added to the processing queue and its level is set to the maximum level value among all its predecessor nodes plus one, only if all its predecessor nodes have been visited and assigned a level. This process continues until the queue is empty and all nodes reachable from the root node have been visited and assigned a unique level value. A hierarchy is generated that records the correspondence between each node ID and its corresponding level.

[0038] Based on the hierarchical relationship and the candidate root node set, the root nodes are recursively connected to obtain the rule execution graph.

[0039] Specifically, nodes in the candidate root node set are used as the top-level starting point for construction. Construction follows the hierarchy determined by the hierarchical relationship. For each root node, it is used as the root of a subtree. The recursive connection process involves searching for all connections in the directed connection relationship where the target node's level is exactly equal to the current node's level plus one, and for any logical node at the current level. The target nodes pointed to by these connections are identified as direct children of the current node, and parent-child links are established in the data structure. This operation is applied to each newly identified child node until a node has no outgoing edges that satisfy the hierarchical progression relationship, at which point the branch terminates. This ensures that the generated tree structure strictly follows the hierarchical progression, and nodes at the same level represent logical units that can be executed in parallel or sequentially according to a specific strategy. For cases where a node in the original graph has multiple parent nodes (i.e., multiple sources pointing to the same target), an independent copy node is created under each parent node for the target node, thus expanding a directed acyclic graph into a tree or a forest. All subtrees recursively constructed from the root nodes are integrated to form a rule execution graph.

[0040] The method provided in this embodiment ensures an accurate correspondence between visual components and underlying execution semantics by converting component descriptors in the target description object into standardized logical nodes using a mapping table. By analyzing and establishing directed connections between logical nodes and automatically identifying all candidate execution root nodes based on in-degree statistics, the triggering starting point and initial state of business rules can be automatically clarified. A rule execution graph is generated by performing topological traversal and hierarchical allocation of candidate root nodes based on directed connections and executing recursive connections according to the hierarchical relationships.

[0041] In some embodiments, the step of extracting component descriptors from the target description object based on a preset node type mapping table and converting each component descriptor into a logical node includes: Parsing the component descriptor yields the component category code and configuration item set; Based on the node type mapping table, the component classification code is used to identify operations and obtain operation behavior information; Based on the operational behavior information, locate the corresponding node logical skeleton from the node type mapping table; Specifically, in addition to storing the mapping from component classification codes to operation behavior information, the node type mapping table also stores the node logical skeleton corresponding to each type of operation behavior. After obtaining the operation behavior information, it is used as a secondary query key to retrieve data within the same mapping table or its associated skeleton resource library. The retrieval operation locates the node logical skeleton template bound to that operation behavior. The node logical skeleton template is a code string with specific placeholders, a class structure prototype defining attributes and methods, or a structured data object with standard input / output slots.

[0042] Each assignment item in the configuration item set is matched with the assembly interface of the node logic skeleton. When the assignment item matches a certain assembly interface, the assignment item is filled into the assembly interface. Here, an assignment item refers to the smallest unit in the configuration item set, that is, a pair consisting of a parameter name (key) and a user input value (value). An assembly interface is a predefined structured access point in the node logic skeleton, and each assembly interface has a unique identifier name and a fixed position in the skeleton.

[0043] Specifically, each assignment item in the configuration item set is traversed, and its parameter name is extracted. The node logic skeleton is parsed synchronously to obtain the names and type constraints of all its assembly interfaces, forming an interface directory. The parameter name of each assignment item is matched against the interface directory; the matching mechanism supports precise comparison and can perform compatibility resolution based on preset alias mapping rules.

[0044] When the parameter name of an assignment item successfully matches an assembly interface, compliance preprocessing for that assignment item's value is triggered. This process, based on the expected data type and syntax context defined in the interface, includes: adding appropriate quotes to string values; converting natural language descriptions such as / no, on / off, etc., into Boolean constants; performing safety escaping on input values ​​containing codes or special symbols; and verifying whether the value is within the legal value range defined by the interface. The processed value is deemed a valid parameter value and is subsequently filled into or bound to the corresponding assembly interface. The processed compliant value is filled into the placeholder or attribute field associated with the corresponding interface within the skeleton. After the iteration is complete, assignment items that do not match any interface in the configuration items are recorded as unused items; interfaces declared as required in the skeleton but not assigned a value are marked as incomplete; and optional interfaces are filled using predefined default values.

[0045] After all the assembly interfaces have been filled with the assignment items, the node logic skeleton is instantiated and transformed to generate the logic node.

[0046] Specifically, after all predefined assembly interfaces have been successfully matched and filled with the corresponding parameter values, the assembled node logic skeleton is read—at this point, the skeleton has transformed from a parameterized template into a complete logical description containing specific values. Based on the skeleton type, the corresponding constructor or generation algorithm is called, independent memory space is allocated, and a new logical node object is created. During creation, all specific parameter values ​​assembled into the skeleton are copied or mapped to the internal state or attributes of the newly generated logical node. Finally, a complete logical node is generated.

[0047] The method provided in this embodiment automatically identifies operational behaviors and locates the corresponding node logic skeleton based on component classification codes, thereby mapping diverse visual components to standardized, structured processing templates. By precisely matching and filling user-configured assignment items with predefined assembly interfaces of the node logic skeleton, it achieves automatic adaptation and injection of specific business parameters into the abstract logic template, ensuring that user intent is accurately and losslessly transformed into the internal logic of the node, while effectively filtering out illegal or redundant configuration items. By triggering instantiation after all assembly interfaces are filled, logical nodes that can directly participate in graph computation can be quickly generated based on a unified, parameter-complete skeleton.

[0048] In some embodiments, the step of performing topological traversal and hierarchical allocation on the candidate root node set based on directed connection relationships to obtain hierarchical relationships includes: Candidate root nodes in the candidate root node set are selected sequentially as starting nodes, and the level of the starting node is marked as the initial level; According to the directed connection relationship, each downstream node connected to the starting node is traversed sequentially, and the downstream nodes are allocated hierarchically according to the preset hierarchical allocation rules and the initial hierarchical level to obtain the allocation level. Specifically, after determining a starting node and its initial level, the directed connection dataset is queried to retrieve all connection information originating from that starting node. The target nodes recorded in the connection information constitute the set of downstream nodes to be processed. Each node in the downstream node set is traversed. For the downstream node being processed, the level value of its predecessor node (i.e., the starting node of the current round) is obtained; this value is recorded in the level mapping table. The level value of this predecessor node is used as input and substituted into a preset level allocation rule for calculation. If the rule is defined as the child node level equals the parent node level plus one, then the allocation level of this downstream node is calculated as the predecessor node's level value plus one. After calculation, a result pair consisting of the downstream node identifier and its corresponding allocation level is generated. This result pair indicates that the downstream node has obtained a suggested level value derived from the current path, but this value needs to be coordinated with values ​​derived from other paths before final confirmation. This traversal and calculation process is repeated on all direct downstream nodes of the starting node, generating an initial allocation level for each downstream node.

[0049] When it is detected that the downstream node has been assigned a level, the original level value of the downstream node is compared with the new level value of the assigned level. If the new level value is less than the original level value, the level value of the downstream node is updated according to the new level value. Using the downstream node as the index key, query the hierarchy mapping table. If the query result shows that there is no corresponding entry for this identifier in the mapping table, it indicates that the node is being accessed for the first time, and the node identifier-new hierarchy value pair is inserted as a new record into the hierarchy mapping table. If the query finds that a corresponding entry already exists for this identifier, the stored value is extracted as the original hierarchy value.

[0050] The newly calculated hierarchical value is compared with the original hierarchical value. An update operation is triggered only if the new hierarchical value is numerically less than the original hierarchical value. The new hierarchical value overwrites the original value corresponding to the node identifier in the hierarchical mapping table. If the new hierarchical value is greater than or equal to the original hierarchical value, the original record is retained without modification.

[0051] When all downstream nodes reachable from the candidate root node set have been visited and the downstream nodes already have the allocation level, all downstream nodes and the allocation level are integrated to generate the hierarchy relationship.

[0052] The method provided in this embodiment automates and standardizes the execution depth marking by traversing the graph from a set of candidate root nodes and assigning an initial level. This provides a definite starting point for level calculation for each node, starting the process from the initial set of candidate root nodes and assigning an initial level. When a downstream node is detected to have been assigned a level, the method automatically compares and selects a smaller new level value for updating, ensuring that each node is assigned the earliest trigger level among all possible execution paths. This automatically optimizes the depth of the overall logical chain, avoiding logical timing conflicts or redundant waiting caused by path differences.

[0053] In some embodiments, the step of performing attribute verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link includes: Each structural unit in the rule execution graph is accessed according to a predetermined structural order; Whenever a structural unit is accessed, the structural unit is validated according to the preset logic rules. When the structural unit passes the attribute verification, a basic code framework matching the structural unit is obtained based on a preset code mapping table, and the structural unit is filled into the basic code framework to generate a unit code block; Extract the type identifier of the structural unit. Using this type identifier as the lookup key, access the predefined code map table. The code map table performs a retrieval operation, returning the underlying code framework associated with that type identifier. Identify all predefined parameter placeholders in the underlying code framework, each placeholder associated with an expected parameter name. Iterate through the set of configuration properties of the structural unit. For each property with a corresponding placeholder in the framework, extract its value. Perform code-level serialization or formatting operations on the property value, such as adding quotes to a string value, converting a boolean value to true or false, converting a list or object to a JSON string, or calling the corresponding constructor. Replace the text of the corresponding parameter placeholder in the framework with the formatted value. Properties configured in the structural unit but without a corresponding placeholder in the framework are ignored. For properties existing in the framework but not configured in the structural unit, if the placeholder defines a default value, fill it with the default value; otherwise, leave it blank or issue a warning. Once all matching placeholders have been processed, generate a unit code block.

[0054] All the unit code blocks are connected according to the inter-unit connection relationship in the rule execution graph to generate the rule code link.

[0055] The method provided in this embodiment accesses structural units in the rule execution graph sequentially according to a predetermined structural order, ensuring that the verification and generation process of business logic strictly follows its inherent dependencies. By performing comprehensive attribute verification based on preset logical rules in real time when accessing each structural unit, configuration errors such as parameter type mismatch, out-of-bounds values, or missing required fields can be proactively intercepted before the code generation stage. Once a structural unit passes verification, it is automatically matched and filled into the corresponding basic code framework to generate unit code blocks based on the code mapping table, ensuring a high degree of consistency between visual configuration and underlying code implementation. All independent unit code blocks are organized and connected into a complete rule code chain according to the clearly defined inter-unit connection relationships in the rule execution graph.

[0056] In some embodiments, the step of verifying the attributes of a structural unit according to preset logical rules whenever a structural unit is accessed includes: Read the type identifier of the structural unit, and extract the type rule entries, attribute rule entries, and numerical range constraint set from the preset logical rules based on the type identifier; The type rule entries are a set of constraints for the general interface of the structural unit, mainly defining the data type standards that its input and output ports should follow. The attribute rule entries define the metadata of all configurable attributes of the structural unit, including attribute name, whether it is required, and the expected data type. The numerical range constraint set is the set of valid values ​​specified for attribute values ​​that are numeric or enumerable.

[0057] The multiple port data types of the structural unit are matched one by one with the type rule entries. If any port data type does not match, the structural unit is marked as an invalid unit. Specifically, the standard port configuration list for the type of unit is obtained from the type rule entries. This list specifies the port name, direction (input / output), and mandatory data type. A list of all port information is extracted from the structure unit object to be verified. The matching process iterates based on the port list defined in the type rule entries. For each port definition in the baseline list, a port with the same name and direction is searched in the actual port list of the structure unit. If no corresponding port is found, it is considered a structural missing, triggering a mismatch. If a corresponding port is found, the values ​​of the data type fields of the two are compared. The data type comparison requires complete consistency or satisfaction of preset inheritance and compatibility rules (e.g., the numeric type actually declared by the unit is compatible with the integer type required by the rules). The matching process immediately terminates if any port search or comparison fails, whether due to a missing port or a data type mismatch. The global validity status of the structure unit is set to invalid, and an error record is created in the verification log, clearly indicating the specific port where the mismatch occurred and the reason.

[0058] If the type rule entry is verified, the attribute rule entry is used to detect whether there are missing configuration values ​​in the attribute configuration of the structural unit. If there are missing attribute values, the structural unit is marked as an invalid unit. Specifically, the attribute rule entries are traversed, and for each entry, its entry flag is checked. If the entry flag indicates that the current attribute is not required, the check of that attribute is skipped, and the process continues to the next entry. If the entry flag indicates that the entry is required, the process switches to the attribute configuration set carried by the structural unit instance and searches for the attribute name of the current entry as the key. The search may fail in two ways: either the key does not exist in the configuration set, or the key exists, but its associated value, after parsing, conforms to the predefined semantics of null values. Either failure is considered a missing attribute value. When a missing attribute value is found, subsequent attribute entry traversal stops. The global validity status of the structural unit is updated to invalid, and a new error record is created in the verification log, clearly indicating which required attribute is missing its configuration value.

[0059] If no attribute value is missing, the configuration value is identified within a range according to the numerical range constraint set. If any configuration value does not belong to the numerical range constraint set, the structural unit is marked as an invalid unit. Specifically, each entry in the numerical range constraint set is traversed. Each entry contains an attribute name and its corresponding constraint. For each entry, the specific configuration value corresponding to the attribute name is retrieved from the attribute configuration set of the structural unit instance. The corresponding recognition logic is executed based on the type of constraint: if the constraint is a numerical range, it is determined whether the configuration value is greater than or equal to the minimum value and less than or equal to the maximum value; if the constraint is an enumerated list, it is determined whether the string representation of the configuration value is strictly equal to an item in the list; if the constraint is a regular expression, the expression is used to perform a pattern matching test on the configuration value (string). If, during the recognition of any attribute, the configuration value fails to meet its corresponding constraint, it is determined to be outside the numerical range constraint set. The checking of subsequent entries is stopped, the global validity status of the structural unit is set to invalid, and the attribute name, its configuration value, and the specific constraint violated are recorded in the verification log.

[0060] If all the configuration values ​​belong to the numerical range constraint set, the structural unit is determined to have passed the attribute verification.

[0061] The method provided in this embodiment automatically extracts specific types, attributes, and numerical range rules based on type identifiers. By matching the port data types of structural units one by one with the type rule entries, structural errors caused by interface definition mismatches can be detected and intercepted in the initial verification stage, preventing incorrect configurations from flowing into subsequent stages. Based on attribute rule entries, the method detects missing configuration values ​​for required attributes, forcibly ensuring the completeness of business logic parameter inputs and avoiding runtime logic interruptions or anomalies caused by missing critical parameters. By using numerical range constraint sets to strictly identify ranges or enumerations of configured values, the method achieves fine-grained verification of the rationality of parameter business operations, eliminating data processing risks caused by parameters exceeding limits or being invalid.

[0062] In some embodiments, connecting all unit code blocks according to the inter-unit connection relationships in the rule execution graph to generate a rule code chain includes: According to the connection relationship between the units, the unit code block corresponding to each structural unit is obtained in sequence, and the output data identifier list and input data requirement list of the structural unit are extracted. Specifically, a hierarchical traversal is performed based on the connections between units to generate an ordered access sequence for structural units. This sequence ensures that when a structural unit is accessed, all its logical predecessor units have been visited. Each structural unit is processed sequentially according to this sequence. For the current unit in the sequence, its unique identifier is used as the key to retrieve the corresponding unit code block from the rule execution graph. After obtaining the unit code block, the parameter positions explicitly marked as outputs and inputs in the template are located based on the structural features used to generate the code block. Specific variable names or parameter identifiers are extracted from these positions. These identifiers extracted from output positions are organized into an output data identifier list. The identifiers extracted from input positions are organized into an input data requirement list. These two lists, as metadata, are bound and stored with the unit code block itself, forming an enhanced code block object.

[0063] The first obtained unit code block is used as the starting block, and all the unit code blocks are placed into a preset ordered code block set; Identify the successor unit of the starting block in the rule execution graph, and match the output data identifier list of the starting block with the input data requirement list of the successor unit; Specifically, based on the identifier of the successor unit, the corresponding enhanced code block object is located from the pre-ordered code block set, and its input data requirement list is extracted from it. The output data identifier list of the current starting block is obtained. The matching program iterates through each requirement identifier in the input data requirement list. For each requirement identifier, an identifier with the exact same name is searched in the output data identifier list. If no identifier with the same name is found, the match fails. If an identifier with the same name is found, further data type compatibility is determined. Data type information is appended to the identifier as metadata or deduced from the template type of the generated code block. For example, if the requirement identifier expects an integer type, while the output identifier provides a floating-point type, it may be considered incompatible in strict mode but allowed in lenient mode. The requirement match is considered successful only when all identifiers in the input requirement list successfully find output identifiers with the same name and compatible types.

[0064] If the match is successful, the unit code block of the successor unit is appended to the starting block; If the match fails, a data bridging code is generated based on the preset data completion mapping table, and the data bridging code and the unit code block of the subsequent unit are sequentially appended to the ordered code block set; Specifically, when a match fails, the specific reasons for the failure are analyzed to identify which output identifiers differ from the input requirement identifiers in name or type. This difference information is used as the basis for querying a pre-defined data completion mapping table. This table returns the corresponding parameterized code template based on the difference pattern (e.g., "integer to string," "field renaming," "object destructuring"). The current variable name is substituted into the placeholder in the template to generate a data bridging code. After generating the bridging code, this newly generated bridging code text is added to the end of the current link code; then, the original unit code block text of the subsequent unit is added after the bridging code.

[0065] Once all the structural units have been processed, all the code blocks in the ordered code block set are sequentially merged into the rule code link.

[0066] The method provided in this embodiment sequentially acquires code blocks and extracts their input / output interface information based on the connection relationships between units, ensuring the structured and traceable nature of the code link construction process. By matching the input / output lists of the starting block with those of subsequent units according to requirements, the compatibility of data interfaces between code blocks can be automatically verified, preventing runtime errors caused by data format or name mismatches during the generation stage. When a match fails, bridging code is automatically generated based on the data completion mapping table, enabling seamless connection between code modules with interface differences, enhancing the flexibility of visual orchestration and the ability to handle compatibility with different components. By merging all units in the ordered code block set in logical order, a regular code link is automatically constructed, achieving automated conversion from visual business logic to runnable code.

[0067] In some embodiments, the step of filling the rule code links into a preset code template for source code compilation to obtain the target source code includes: Identify the reserved rule code insertion positions in the code template; The rule code chain is embedded at the rule code insertion point to form the initial source code; Extract variable identifiers and external dependency interfaces from the initial source code, perform configuration analysis on the variable identifiers and external dependency interfaces according to the code template, and generate compilation configuration information; Based on the compilation configuration information, the initial source code is compiled and linked to output the target source code.

[0068] Reference Figure 2 As shown, the present invention also provides a business rule visualization system based on a low-code platform, and a business rule visualization method based on a low-code platform applied to any of the above-mentioned methods, comprising: The data collection module is used to identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object. The analysis module is used to extract component descriptors from the target description object and construct a rule execution graph based on the component descriptors; The association module is used to perform compliance verification and code construction on the rule execution graph based on preset logical rules, so as to obtain the rule code link; The processing module is used to fill the rule code links into a preset code template for source code compilation to obtain the target source code.

[0069] This invention provides a business rule visualization system based on a low-code platform. By constructing a rule execution graph as a structured intermediate representation of business logic and performing attribute verification and code construction, it effectively solves the problems of opaque conversion processes and uncontrollable code quality in existing low-code platforms due to the lack of a structured description and verification mechanism for the complete logical chain within the rules. It transforms fragmented visualization configurations into a verifiable and traceable logical whole, ensuring that business intents are accurately and automatically mapped to high-quality source code. This significantly enhances the reliability, maintainability, and responsiveness to business changes of the generated code while improving development efficiency.

[0070] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the system and each module described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0071] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for visualizing business rules based on a low-code platform, characterized in that, include: Identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object; Component descriptors are extracted from the target description object, and a rule execution graph is constructed based on the component descriptors; Based on preset logical rules, attribute verification and code construction are performed on the rule execution graph to obtain the rule code link; The rule code link is filled into a preset code template and the source code is compiled to obtain the target source code.

2. The business rule visualization method based on a low-code platform according to claim 1, characterized in that, The process of identifying user configuration operation information on the low-code platform, constructing a description object from the configuration operation information, and generating a target description object includes: Identify the component type identifier, attribute key-value pairs, and inter-component connection information in the configuration operation information; Traverse the attribute keys and attribute values ​​in the attribute key-value pairs, match each attribute key with a preset attribute description template, and if a match is successful, extract the attribute value and fill it into the attribute description template to generate an attribute description unit. Based on the component type identifier, the corresponding basic description framework is searched from the preset framework component library, and all the attribute description units are injected into the basic description framework to obtain the attribute description framework. When an indication to establish connection information is detected in the inter-component connection information, a connection node is created in the attribute description framework, and the inter-component connection information is filled into the connection node to obtain the target description object.

3. The business rule visualization method based on a low-code platform according to claim 1, characterized in that, The step of extracting component descriptors from the target description object and constructing a rule execution graph based on the component descriptors includes: The component descriptors are extracted from the target description object based on a preset node type mapping table, and each component descriptor is converted into a logical node. Traverse the directed edges in the target description object, and construct the directed connection relationship of the corresponding logical node based on the start node information and end node information of each directed edge; Based on the directed connection relationship, the number of times each logical node is pointed to by other nodes is counted, and all logical nodes that are pointed to zero times are integrated into a candidate root node set. Based on the directed connection relationship, a topological traversal and hierarchical allocation are performed on the candidate root node set to obtain the hierarchical relationship; Based on the hierarchical relationship and the candidate root node set, the root nodes are recursively connected to obtain the rule execution graph.

4. The business rule visualization method based on a low-code platform according to claim 3, characterized in that, The process of extracting the component descriptor from the target description object based on a preset node type mapping table and converting each component descriptor into a logical node includes: Parsing the component descriptor yields the component category code and configuration item set; Based on the node type mapping table, the component classification code is used to identify operations and obtain operation behavior information; Based on the operational behavior information, locate the corresponding node logical skeleton from the node type mapping table; Each assignment item in the configuration item set is matched with the assembly interface of the node logic skeleton. When the assignment item matches a certain assembly interface, the assignment item is filled into the assembly interface. After all the assembly interfaces have been filled with the assignment items, the node logic skeleton is instantiated and transformed to generate the logic node.

5. The business rule visualization method based on a low-code platform according to claim 3, characterized in that, The step of performing topological traversal and hierarchical allocation on the candidate root node set based on the directed connection relationship to obtain the hierarchical relationship includes: Candidate root nodes in the candidate root node set are selected sequentially as starting nodes, and the level of the starting node is marked as the initial level. According to the directed connection relationship, each downstream node connected to the starting node is traversed sequentially, and the downstream nodes are allocated hierarchically according to the preset hierarchical allocation rules and the initial hierarchical level to obtain the allocation level. When it is detected that the downstream node has been assigned a level, the original level value of the downstream node is compared with the new level value of the assigned level. If the new level value is less than the original level value, the level value of the downstream node is updated according to the new level value. When all downstream nodes reachable from the candidate root node set have been visited and the downstream nodes already have the allocation level, all downstream nodes and the allocation level are integrated to generate the hierarchy relationship.

6. The business rule visualization method based on a low-code platform according to claim 1, characterized in that, The step of performing attribute verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link includes: Each structural unit in the rule execution graph is accessed according to a predetermined structural order; Whenever a structural unit is accessed, the structural unit is attribute-verified according to the preset logic rules; When the structural unit passes the attribute verification, a basic code framework matching the structural unit is obtained based on a preset code mapping table, and the structural unit is filled into the basic code framework to generate a unit code block; All the unit code blocks are connected according to the inter-unit connection relationship in the rule execution graph to generate the rule code link.

7. The business rule visualization method based on a low-code platform according to claim 6, characterized in that, Whenever a structural unit is accessed, attribute verification is performed on the structural unit according to the preset logic rules, including: Read the type identifier of the structural unit, and extract the type rule entries, attribute rule entries, and numerical range constraint set from the preset logical rules based on the type identifier; The multiple port data types of the structural unit are matched one by one with the type rule entries. If any port data type does not match, the structural unit is marked as an invalid unit. If the type rule entry is verified, the attribute rule entry is used to detect whether there are missing configuration values ​​in the attribute configuration of the structural unit. If there are missing attribute values, the structural unit is marked as an invalid unit. If no attribute value is missing, the configuration value is identified within a range according to the numerical range constraint set. If any configuration value does not belong to the numerical range constraint set, the structural unit is marked as an invalid unit. If all the configuration values ​​belong to the numerical range constraint set, the structural unit is determined to have passed the attribute verification.

8. The business rule visualization method based on a low-code platform according to claim 6, characterized in that, The step of connecting all the unit code blocks according to the inter-unit connection relationship in the rule execution graph to generate the rule code link includes: According to the connection relationship between the units, the unit code block corresponding to each structural unit is obtained in sequence, and the output data identifier list and input data requirement list of the structural unit are extracted. The first obtained unit code block is used as the starting block, and all the unit code blocks are placed into a preset ordered code block set; Identify the successor unit of the starting block in the rule execution graph, and match the output data identifier list of the starting block with the input data requirement list of the successor unit; If the match is successful, the unit code block of the successor unit is appended to the starting block; If the match fails, a data bridging code is generated based on the preset data completion mapping table, and the data bridging code and the unit code block of the subsequent unit are sequentially appended to the ordered code block set; Once all the structural units have been processed, all the code blocks in the ordered code block set are sequentially merged into the rule code link.

9. The business rule visualization method based on a low-code platform according to claim 1, characterized in that, The step of filling the rule code link into a preset code template and compiling the source code to obtain the target source code includes: Identify the reserved rule code insertion positions in the code template; The rule code chain is embedded at the rule code insertion point to form the initial source code; Extract variable identifiers and external dependency interfaces from the initial source code, perform configuration analysis on the variable identifiers and external dependency interfaces according to the code template, and generate compilation configuration information; Based on the compilation configuration information, the initial source code is compiled and linked to output the target source code.

10. A business rule visualization system based on a low-code platform, characterized in that, The business rule visualization method based on a low-code platform, applied to any one of claims 1-9, includes: The acquisition module is used to identify the user's configuration operation information on the low-code platform, construct a description object for the configuration operation information, and generate a target description object. An analysis module is used to extract component descriptors from the target description object and construct a rule execution graph based on the component descriptors; The association module is used to perform compliance verification and code construction on the rule execution graph based on preset logical rules to obtain the rule code link; The processing module is used to fill the rule code link into a preset code template for source code compilation to obtain the target source code.

Images