A method and system for running software rules using a runner

Abstract

This invention discloses a method and system for running software rules using a runner, belonging to the field of software development technology. The method includes steps 1: business decomposition and rule configuration item generation; step 2: business operation rule configuration and persistence; step 3: runner parsing and structured query statement concatenation; step 4: database execution and result set generation; and step 5: status code determination and feedback display. This invention solves the technical problems in existing technologies, such as the hard coupling between business rules and execution code leading to the need for recompilation and deployment after rule changes; the lack of persistent intermediate representation of configuration results leading to configuration loss after system restart; and the static and fixed structured query statements unable to dynamically adjust their structure based on runtime context. It achieves the technical effects of business rule changes taking effect immediately without recompilation and deployment, persistent reuse of business rules across components and systems, and dynamic adjustment of statement structure and execution path based on runtime context.

Description

Technical Field

[0001] This invention belongs to the field of software development technology, specifically relating to a method and system for running software rules using a runner. Background Technology

[0002] With the accelerating pace of enterprise informatization and digitalization, the demand for various business systems, such as data query systems, report management systems, and business process approval systems, has increased dramatically. Traditional software development models are no longer sufficient to meet the rapidly iterating business needs. Under this model, the implementation of business requirements typically follows this process: business personnel and programmers communicate repeatedly to compile each functional point into a requirements document; after understanding the requirements, programmers write program code line by line using development tools, ultimately generating an application system that meets specific business scenarios. This model relies heavily on the deep involvement of professional software developers, and each system is built from scratch or based on a limited codebase for reuse.

[0003] While some visual configuration tools exist that allow users to generate structured query statements by dragging and dropping fields or selecting options, reducing coding workload to some extent, they still suffer from the following drawbacks: The configuration logic of existing visual configuration tools is embedded in the front-end page code, essentially remaining a form of code-level coupling. Changes to business rules still require modification of the source code and recompilation and deployment, resulting in long rule change response cycles. Furthermore, configuration results in existing technologies are stored as temporary parameters in memory or permanently stored in the front-end code, leading to configuration loss upon system restart. This prevents cross-page and cross-system reuse of business rules, necessitating repeated configuration of the same business rule in different scenarios and compromising configuration consistency. Finally, structured query statements in existing technologies are pre-assembled upon configuration or before execution, lacking the flexibility to dynamically adjust the statement structure and execution path based on runtime context information such as user permissions, data status, and time conditions. These shortcomings result in delayed responses to business requirements, high software development and maintenance costs, and an inability to meet the rapid iteration needs of enterprise information systems. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention aims to provide a method and system for running software rules using a runner. This solves the technical problems in existing technologies, such as the hard coupling between business rules and execution code leading to recompilation and deployment upon rule changes, the lack of persistent intermediate representations of configuration results resulting in configuration loss after system restarts, and the static and fixed structured query statements unable to dynamically adjust their structure based on runtime context. The specific solution is as follows: In a first aspect, embodiments of this application provide a method for running software rules using a runner, comprising the following steps: The business is categorized according to the operation type of the structured query statement. Based on the syntax structure and standard format template corresponding to each operation type, the categorized business is decomposed to obtain rule configuration items. Configure rule configuration items into the rule attribute field of the component to form business operation rules, call the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language format data, and embed the Extensible Markup Language format data as the component's persistent attribute value; When running a component, Extensible Markup Language format data is extracted from the component's persistent attribute values. The Document Object Model parser is called to parse the key-value pairs of each rule configuration item. Based on the standard format template corresponding to each operation type, the business operation rules are concatenated into a structured query statement, and the structured query statement is sent to the database. The structured query statement is parsed to obtain a syntax tree. Based on the syntax tree, business operation rules are identified. Based on the business operation rules, business data operations are performed in the database to generate a result set containing a set of data records and operation status codes. The operation status code is parsed to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If it fails, the operation status code is converted into an error message and displayed in the message area of ​​the business interface.

[0005] In one embodiment, the categorized business operations are decomposed according to the syntax structure corresponding to each operation type to obtain rule configuration items, including: The business logic of query operations is broken down into field rule configuration items and table name rule configuration items; The business logic for adding operation types is broken down into field rule configuration items and table name rule configuration items; The business logic of update operations is broken down into field rule configuration items and table name rule configuration items; The business logic of delete operations is broken down into table name rule configuration items.

[0006] In one embodiment, the categorized business operations are decomposed according to the syntax structure corresponding to each operation type to obtain rule configuration items, including: The business logic of query operations is broken down into field rule configuration items, table name rule configuration items, filter condition rule configuration items, grouping rule configuration items, and sorting rule configuration items; The business logic for adding operation types is broken down into field rule configuration items and table name rule configuration items; The update operation type is decomposed into field rule configuration items, table name rule configuration items, and filter condition rule configuration items; The business logic of delete operations is broken down into table name rule configuration items and filter condition rule configuration items.

[0007] In one embodiment, the components include a control component and a data source component; The control components include rule object units, component event units, component behavior units, output data units, and state units; The rule object unit stores a collection of key-value pairs for rule configuration items; The component event unit stores the mapping relationship between trigger condition identifiers and action identifiers; The component behavior unit stores the mapping relationship between action identifiers and task scripts; The output data unit stores the data output format identifier and the target address identifier; The state unit stores the current state code and state transition conditions; The data source components include input units, functional units, and output units; The input unit extracts the target field data from the data stream; The functional unit performs operations on the target field data to generate the processing result data; The output unit sends the processing result data to the downstream node.

[0008] In one embodiment, the Extensible Markup Language (Extreme Markup Language) format data includes rule configuration nodes, operation type nodes, field item nodes, table name nodes, filter condition nodes, grouping nodes, and sorting nodes.

[0009] In one embodiment, the business operation rules are concatenated into a structured query statement based on the standard format template corresponding to each operation type and sent to the database, including: Based on the standard format template corresponding to the query operation type, the business operation rules are combined to generate a structured query statement for the query type; Based on the standard format template corresponding to the add operation type, the business operation rules are combined to generate a structured query statement for the add type; Based on the standard format template corresponding to the update operation type, the business operation rules are combined to generate a structured query statement for the update type; The system generates a structured query statement for the deletion type by combining the standard format template corresponding to the deletion operation type with the business operation rules.

[0010] In one embodiment, performing business data operations in the database according to business operation rules includes: performing business data query, add, update or delete operations in the database according to business operation rules.

[0011] Secondly, embodiments of this application provide a system that uses a runner to execute software rules, including: The business decomposition module is used to categorize and classify business according to the operation type of structured query statements. Based on the syntax structure and standard format template corresponding to each operation type, the categorized business is decomposed to obtain rule configuration items. The configuration module is used to configure rule configuration items into the rule attribute field of the component to form business operation rules, call the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language (XML) format data, and embed the XML format data as the component's persistent attribute value. The statement concatenation module is used to extract Extensible Markup Language format data from the persistent attribute values ​​of the component when the component is running, call the Document Object Model parser to parse the key-value pairs of each rule configuration item, concatenate the business operation rules into a structured query statement according to the standard format template corresponding to each operation type, and send the structured query statement to the database. The rule execution module is used to parse structured query statements to obtain a syntax tree, identify business operation rules based on the syntax tree, perform business data operations in the database according to the business operation rules, and generate a result set containing a set of data records and operation status codes. The result processing module is used to parse the operation status code to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If unsuccessful, the operation status code is converted into an error message and displayed in the message area of ​​the business interface. Beneficial effects

[0012] (1) This invention categorizes business operations according to the operation types of structured query statements, decomposes the categorized business operations according to the corresponding syntax structure of each operation type, obtains rule configuration items, configures the rule configuration items into the component rule attribute domain to form business operation rules, calls the serialization engine to serialize the content of the rule attribute domain into Extensible Markup Language format data, embeds the data as the component persistent attribute value into the component, and extracts the data from the component persistent attribute value at runtime. It calls the document object model parser to parse the key-value pairs of each rule configuration item, and dynamically splices the business operation rules into structured query statements according to the standard format templates corresponding to each operation type. This invention solves the technical problems in the prior art where hard coupling between business rules and execution code leads to recompilation and deployment for rule changes, lack of persistent intermediate representation of configuration results leads to configuration loss after system restart, and static fixed structured query statements cannot dynamically adjust the statement structure according to the runtime context. It achieves the technical effects of business rule changes taking effect immediately without recompilation and deployment, business rules being persistently reused across components and systems, and dynamically adjusting the statement structure and execution path according to the runtime context. (2) This invention separates the interface interaction logic and data operation and processing logic into independent configuration units through the dual component system of control components and data source components and unitized decomposition. The control components focus on interface event response and display rendering, while the data source components focus on data acquisition and operation and processing. The two are coupled through a standard interface, which solves the technical problem in the prior art that the interface logic and data logic are mixed and cannot be independently developed and replaced. It achieves the technical effect of independently developing and replacing complex business logic, interface logic and data logic through unit configuration combination without writing code. (3) This invention establishes a closed-loop feedback mechanism for data operation by parsing the operation status code. It distinguishes between success and failure states based on the status code identifier type and performs data format conversion display or error prompt information output respectively. At the same time, it triggers the state transition of the state unit, which solves the technical problems of untimely feedback of data operation results and lack of state management in error handling in the prior art. It achieves the technical effect of real-time perception of data operation status and synchronous update of interface status, and timely prompting of operation abnormalities. Attached Figure Description

[0013] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0014] Figure 1 This is a flowchart provided for the present invention; Figure 2 This is a schematic diagram of the structure provided by the present invention; Figure 3 This is a schematic diagram illustrating the interaction between the control component and the data source component provided by the present invention. Figure 4 This is a schematic diagram of the node structure of the Extensible Markup Language (Extreme Markup Language) format data provided by the present invention. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0016] First, it must be stated that after analyzing the practical application of existing software development models, it was found that: traditional development models generally suffer from the problem of hard coupling between business rules and executable code. Rule changes require recompilation and deployment, with response cycles lasting several days to weeks; existing visual configuration tools lack persistent intermediate representations of configuration results, leading to configuration loss after system restarts and hindering rule reuse across components and systems; structured query statements are statically fixed before runtime, making it impossible to dynamically adjust the statement structure and execution path based on runtime context, resulting in a severe lack of flexibility; business personnel cannot directly participate in system construction, and any rule adjustments rely on programmers' scheduling, leading to delayed responses to business needs and high software development and maintenance costs. These combined problems make rapid iteration of enterprise information systems difficult to achieve and fail to meet the actual needs of market changes.

[0017] This invention constructs a method for running software rules using a runner. The method takes five steps as the main execution line: business decomposition, rule configuration and persistence, runner parsing and statement concatenation, database execution, and status feedback. It achieves physical separation of interface logic and data logic through a dual-component system of control components and data source components. The specific implementation of each step is described in detail below with reference to the embodiments.

[0018] refer to Figure 1 This document illustrates the execution flowchart of the method for running software rules using a runner provided in Embodiment 1. The method includes step 1: business decomposition and rule configuration item generation; step 2: business operation rule configuration and persistence; step 3: runner parsing and structured query statement concatenation; step 4: database execution and result set generation; and step 5: status code determination and feedback display. Each step works together to achieve code-free configuration and dynamic operation of business rules. The specific implementation method is as follows.

[0019] Step 1 involves categorizing the business operations according to the operation types of structured query statements. Based on the syntax structure and standard format templates corresponding to each operation type, the categorized business operations are decomposed to obtain rule configuration items, providing a standardized rule foundation for subsequent steps.

[0020] It should be noted that enterprise information systems involve a wide variety of business operations, but based on the standard syntax of structured query statements, all data operations can be summarized into four basic types: query, add, update, and delete. Different operation types correspond to different syntax structures and standard format templates. For example, query operations involve field selection, table name specification, filter condition setting, grouping and aggregation, and sorting rules; add operations involve mapping target tables to field values; update operations involve field assignment and condition constraints; and delete operations involve target tables and filter conditions. Without decomposing the business operations, rule configuration will suffer from coarse granularity and difficulty in reuse. Therefore, this step requires addressing these issues through categorized indexing and decomposition.

[0021] For various business operations within the enterprise information system, Step 1 first establishes a unified operation type classification index. This index includes four categories: query index, add index, update index, and delete index. When a business operation needs to be categorized into a specific operation type, it is marked under the corresponding classification index. For example, to categorize student grade queries into the query operation type, it is marked under the query index; similarly, to categorize material information entry into the add operation type, it is marked under the add index.

[0022] The categorized business operations are decomposed according to the corresponding syntax structure and standard format templates for each operation type, forming rule configuration items. As a simplified decomposition method, query operations are decomposed into two rule configuration items: field rule configuration items and table name rule configuration items; add operations are also decomposed into two rule configuration items: field rule configuration items and table name rule configuration items; update operations are also decomposed into two rule configuration items: field rule configuration items and table name rule configuration items; and delete operations are decomposed into one rule configuration item: table name rule configuration item. This simplified decomposition method is suitable for business scenarios with small data volumes and simple logic, allowing for rapid rule configuration.

[0023] As a complete decomposition method, query operations are broken down into five rule configuration items: field rule configuration, table name rule configuration, filter condition rule configuration, grouping rule configuration, and sorting rule configuration. Add operations are broken down into two rule configuration items: field rule configuration and table name rule configuration. Update operations are broken down into three rule configuration items: field rule configuration, table name rule configuration, and filter condition rule configuration. Delete operations are broken down into two rule configuration items: table name rule configuration and filter condition rule configuration. This complete decomposition method is suitable for business scenarios with large data volumes and complex filtering conditions, reducing the amount of data filtered by the database and improving the speed of data retrieval or entry.

[0024] The decomposition process follows the principle of minimum granularity, with each rule configuration item carrying only a single syntactic element. Rule configuration items are associated with each other through fixed syntactic positions in a standard format template. Let the business set be B, the operation type set be O, and O contain four types of elements: query, add, update, and delete. Let the decomposition mapping function be f. Then the rule configuration item set R satisfies: R = f(B, O). For query operation types, the number of rule configuration items n1 in simplified decomposition mode satisfies: n1=2; In the complete decomposition mode, the number n2 of rule configuration items satisfies: n2=5; For the addition operation type, the number of rule configuration items n3 satisfies: n3=2; For update operation types, the number of rule configuration items n4 in simplified decomposition mode satisfies: n4=2; In the complete decomposition mode, the number of rule configuration items n5 satisfies: n5=3; For deletion operation types, the number of rule configuration items n6 in simplified decomposition mode satisfies: n6=1; In the complete decomposition mode, the number of rule configuration items n7 satisfies: n7=2; The above values ​​are determined based on the minimum set of required syntax elements for each operation type in the standard syntax of structured query statements. Query operations require at least the field and table name to be specified, add operations require at least the field and table name to be specified, update operations require at least the field, table name and filter conditions to be specified, delete operations require at least the table name to be specified, and complete decomposition covers all optional syntax elements.

[0025] Taking the simplified decomposition method as an example, to query a student's final exam score, the field rule configuration item is set to student ID, student name, and total score, and the table name rule configuration item is set to "Final Exam Score Table". Similarly, to delete content from table A, the table name rule configuration item is set to "Table A".

[0026] Taking the complete decomposition method as an example, to query the final exam scores of students in a specific grade, the field rule configuration items are set to student ID, student name, and total score; the table name rule configuration item is set to "Final Exam Scores Table"; the filter condition rule configuration item is set to "Grade"; the sorting rule configuration item is set to "Student ID"; and the grouping rule configuration item is set to "Student ID". Similarly, to update the final exam score of a specific student in a specific grade, the field rule configuration items are set to student ID, student name, and total score; the table name rule configuration item is set to "Final Exam Scores Table"; and the filter condition rule configuration item is set to "Specific Grade, Specific Student".

[0027] Step 2 involves configuring each rule configuration item into the rule attribute field of the component on the business interface to form business operation rules, calling the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language (XML) format data, and embedding the XML format data as the component's persistent attribute value to achieve persistent storage and cross-scenario reuse of business rules.

[0028] It should be noted that all components on the business interface have rule attribute fields. When a business user selects a component, an attribute configuration window will appear in the upper right corner of the business interface. The business user configures the component's rule attribute fields one by one in the attribute configuration window, according to the rule configuration items decomposed in step 1. After configuration, the business operation rules are formed. The component calls the built-in serialization engine to serialize the content in the rule attribute fields according to the Extensible Markup Language (XML) syntax specification, generating XML format data, and embedding this data as the component's persistent attribute values ​​into the component's internal storage. After a system restart, the component reads the persistent attribute values ​​from its internal storage, thus restoring the business operation rules without reconfiguration.

[0029] The components include control components and data source components. The dual-component system achieves physical separation between interface logic and data logic.

[0030] The control components include rule object units, component event units, component behavior units, output data units, and state units. The rule object unit stores a set of key-value pairs for each rule configuration item of the control component, and the key-value pair set is persisted in the form of Extensible Markup Language (XML) nodes. The component event unit stores a mapping table of trigger condition identifiers and corresponding action identifiers. Trigger condition identifiers include click event identifiers, double-click event identifiers, mouse hover event identifiers, and timed trigger event identifiers. Action identifiers include data query action identifiers, data add action identifiers, data update action identifiers, and data delete action identifiers. The component behavior unit stores a mapping table of action identifiers and task script identifiers. When the trigger condition corresponding to the trigger condition identifier stored in the component event unit is met, the task script pointed to by the corresponding task script identifier stored in the component behavior unit is executed. The output data unit stores data output format identifiers and target address identifiers. Data output format identifiers include table format identifiers, chart format identifiers, text format identifiers, and file export format identifiers. Target address identifiers include current page display identifiers, pop-up display identifiers, and downstream component transfer identifiers. The status unit stores the current status code and status transition conditions of the control component. The current status code includes initialization status code, data loading status code, data loading completed status code, and error status code.

[0031] By configuring the above units, business definition personnel can customize the control components, allowing their functionality to be tailored to the software development needs. The five-unit breakdown of the control components is based on breaking down the required interface development functions into five minimum functional atoms: attribute configuration, event response, behavior execution, data output, and state management. Each unit can be configured and reused independently.

[0032] The data source component includes an input unit, a functional unit, and an output unit. The input unit receives external data streams and extracts target field data from the data streams according to preset field matching rules in the input unit. The functional unit reads the preset processing script identifier in the functional unit, calls the corresponding processing script to perform calculations on the target field data, and generates processing result data. The output unit receives the processing result data and sends the processing result data to downstream nodes according to the preset downstream address identifier in the output unit.

[0033] Let the external data stream be D. in The field matching rule is M, and the target field data is D. target The processing script is identified as P id The processing script is P, and the processing result data is D. result If the downstream address is identified as A, then the data processing flow of the data source component satisfies: D target =Extract(D in ,M); D result =Execute(P,D target ); Send(D result A); Extract is the field extraction function, which filters target fields from the data stream based on field matching rules; Execute is the script execution function, which calls the processing script to perform operations on the target field data; Send is the data sending function, which transmits the processing result data to the specified node based on the downstream address identifier.

[0034] For example, if a business user needs a data transformation component to replace field B1 in table A1 with field D1 in table C1 in memory, the user only needs to configure it as follows: First, in the input unit, configure the received parameters as follows: Source field: field B1 from table A1; Target field: field D1 from table C1. Second, in the functional unit, the user selects the data transformation component. The functional unit parses the component and generates corresponding computer code. After execution, this code leaves the data in field B1 of table A1 unchanged, only changing the data identifier. The data with the identifier "field D1 from table C1" is then placed in a cache pool. When the output unit receives a call command, it retrieves the data with the identifier "field D1 from table C1" from the cache pool and then transmits it according to the call command.

[0035] The node structure of Extensible Markup Language (XML) formatted data follows a hierarchical design principle. The root node is RuleConfig, and the first-level child nodes include OperationType, FieldItems, TableName, FilterCondition, GroupBy, and OrderBy. FieldItems has second-level child nodes Field, which store specific field information. The node depth d satisfies: d=3. The root node RuleConfig has a depth of 1, the first-level child nodes have a depth of 2, and the Field nodes have a depth of 3. The reason for a node depth of 3 is that a shallower level cannot distinguish between operation types and field details, while a deeper level will increase parsing overhead. The 3-layer structure ensures semantic clarity while also taking parsing efficiency into account.

[0036] Let the content of the rule attribute field be C, and the serialization engine be S. Then the Extensible Markup Language (XML) format data satisfies: XML = S(C); The serialization process maps the set of key-value pairs in the regular attribute domain to Extensible Markup Language (XML) node attributes, and the mapping relationship satisfies: Node attribute =Map(Key,Value); The Key is the name of the rule configuration item, and the Value is the content of the rule configuration item.

[0037] refer to Figure 4 This diagram illustrates the node structure of Extensible Markup Language (XML) formatted data. The root node RuleConfig extends downwards to six first-level branches: OperationType, FieldItems, TableName, FilterCondition, GroupBy, and OrderBy. The FieldItems branch contains second-level Field nodes, and each node stores key-value pairs of the corresponding rule configuration items.

[0038] Step 3 involves extracting Extensible Markup Language (XML) format data from the persistent attribute values ​​of the component during component execution, calling the Document Object Model (DOM) parser to parse the key-value pairs of each rule configuration item, concatenating the business operation rules into a structured query statement based on the standard format template corresponding to each operation type, and sending the structured query statement to the database to achieve dynamic parsing of business rules and statement generation.

[0039] It's important to note that the runner, as an independent execution engine, is physically separated from the configuration interface. When running a component, the business interface is first loaded into the runner. The runner extracts Extensible Markup Language (XML) format data from the component's persistent attribute values, calls the Document Object Model (DOM) parser to parse the XML format data node by node, and extracts the key-value pairs for each rule configuration item. After the key-value pairs are extracted, the runner, based on the standard format template corresponding to each operation type, fills the various rule configuration items in the business operation rules into the corresponding syntax positions in the standard format template, concatenates them to generate a complete structured query statement, and sends the concatenated structured query statement to the database.

[0040] Let the Extensible Markup Language (XML) format data extracted from the persistent attribute values ​​of a component be XML, the Document Object Model (DOM) parser be D, and the set of key-value pairs obtained after parsing be K. Then the parsing process satisfies: K = D(XML). Let the set of key-value pairs be K, the standard format template be T, the operation type be O, and the structured query statement generated by concatenation be SQL. Then the concatenation process satisfies: SQL=T(O,K); The standard format templates for each operation type are as follows: The standard format template for query operation types is as follows: SOL select =SELECT F FROM T WHERE W GROUP BY G ORDER BY O sort ; Where F represents the field rule configuration item, T represents the table name rule configuration item, W represents the filter condition rule configuration item, G represents the grouping rule configuration item, and O represents the grouping rule configuration item. sort Configure the sorting rules.

[0041] The standard format template for adding operation types is: SOL insert =INSERT INTO T(F1,F2,...,F n VALUES(V1,V2,...,V) n ); Where T represents the table name rule configuration item, F1 to F... n Configure field rule items, V1 to V n To retrieve the corresponding value for the field.

[0042] The standard format template for update operation types is: SQL update =UPDATE T SET F1=V1,F2=V2,...WHERE W; Where T is the table name rule configuration item, F1 and F2 are the field rule configuration items, V1 and V2 are the corresponding values ​​of the fields, and W is the filter condition rule configuration item.

[0043] The standard format template for the delete operation type is: SQL delete =DELETE FROM T WHERE W; Where T represents the table name rule configuration item, and W represents the filter condition rule configuration item.

[0044] Taking the query operation type as an example, after the runner extracts the Extensible Markup Language (XML) format data from the component, it calls the Document Object Model (DOM) parser to parse the data. The field rule configuration items are: student ID, student name, and total score; the table name rule configuration item is: final exam score table; the filter condition rule configuration item is: third grade; the grouping rule configuration item is: student ID; and the sorting rule configuration item is: student ID. The structured query statement generated by concatenating the standard format template for the query operation type is as follows: SELECT student_id, student_name, total_score FROM final_grade_table WHERE third_grade_group BY student_id ORDER BY student_id; Among them, filtering conditions, grouping, and sorting are non-essential rule configuration items. If the query business operation rules do not include the above rule configuration items, the corresponding syntax positions should be left blank when concatenating, and only the core syntax of SELECT and FROM should be retained.

[0045] Taking the "Add Operation Type" as an example, the field rule configuration items are student ID and total score, and the table name rule configuration item is "Final Exam Total Score Table," with values ​​of 1240 and 420 respectively. The structured query statement generated based on the standard format template for the "Add Operation Type" is as follows: INSERT INTO Final Exam Grade Sheet (Student ID, Total Score) VALUES (1240, 420); Taking the update operation type as an example, the field rule configuration items are name, student ID, and total score; the table name rule configuration item is "final exam total score table"; and the filter condition rule configuration item is "fifth grade". The structured query statement generated by concatenating the standard format template of the update operation type is: UPDATE Final Exam Grades SET Name=Huang xx, Student ID=1203, Total Score=521 WHERE Grade 5; The filter condition is a non-essential rule configuration item. If the update business operation rule does not include the filter condition rule configuration item, leave the WHERE syntax blank, and all records in the table will be updated.

[0046] Taking the delete operation type as an example, the table name rule configuration item is "final exam total grades table", the filter condition rule configuration item is "Grade 2 Zhang xx", and the structured query statement generated by concatenating the standard format template of the delete operation type is: DELETE FROM Final Exam Results Sheet WHERE Grade 2 Zhang xx; The filter condition is a non-essential rule configuration item. If the business operation rule does not contain a filter condition rule configuration item, leave the WHERE syntax blank, and all content in the table will be deleted.

[0047] Step 4 involves parsing the structured query statement to obtain a syntax tree, identifying business operation rules based on the syntax tree, executing business data operations in the database according to the business operation rules, and generating a result set containing a set of data records and operation status codes, thus realizing the execution and result encapsulation of data operations.

[0048] It should be noted that after receiving a complete structured query statement, the database first performs lexical and syntactic analysis on the query statement to obtain a syntax tree. The syntax tree represents the hierarchical syntactic relationship of the structured query statement in a tree structure, with the root node being the statement type identifier and the child nodes being the various syntactic element nodes. After identifying the corresponding business operation rules based on the syntax tree, the database retrieves or deletes relevant business data from the database, or enters or updates relevant business data into the database according to the business operation rules, and generates a result set after execution.

[0049] Let the received structured query statement be SQL, the lexical analyzer be L, and the syntax analyzer be P. Then the syntax tree Tree satisfies: Tree = P(L(SQL)); Let the syntax tree be Tree, the business operation rule recognition function be I, and the recognized business operation rule be R, then: R = I(Tree); After the database executes data operations according to the business operation rules, it generates a result set Result. The result set consists of two parts: a set of data records Data and an operation status code S. The result set is constructed in a way that satisfies the following conditions: Result = {Data,,S}; The operation status code S follows the database operation return code design convention: S equals 0 to indicate successful execution, and S not equal to 0 indicates an execution error. The reason for S being 0 is that a value of 0 indicates no error return in the computer system, facilitating unified Boolean judgments by the components. When S takes a non-zero value, different values ​​indicate different types of errors; for example, 1 indicates a syntax error, 2 indicates insufficient permissions, and 3 indicates a connection timeout.

[0050] Taking a query operation as an example, after the database receives the query statement, it retrieves the data with a total score of 600 from the final grade table, the operation status code S equals 0, and the data record set contains the grade record.

[0051] Taking the update operation as an example, after the database receives the update statement, it updates the corresponding data in the project's total cost table. The operation status code S equals 0, and the data record set is empty.

[0052] If the database connection times out, the operation status code S equals 3, and the data record set is empty.

[0053] Step 5 is to parse the operation status code to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If it fails, the operation status code is converted into an error message and displayed in the message area of ​​the business interface, thus realizing closed-loop feedback of data operation.

[0054] It should be noted that after receiving the result set, the component parses the operation status code S to determine whether the data operation was successful. Let the data record set be Data, the data output format identifier be F, the business interface display area be Display, the error message be Error, the message area be Message, and the current status code of the status unit be State. Then the status determination and feedback process satisfies: When S = 0, Display = Convert(Data, F); When S≠0, Message = Transform(S), State = Error State; Convert is a data format conversion function that converts a set of data records into a table, chart, text, or file export format based on the data output format identifier; Transform is an error code conversion function that maps operation status codes to preset error message information; Error State is an error status code used to trigger the state transition of the state unit.

[0055] Taking a query operation as an example, after the database receives the query statement, it retrieves the data with a total score of 600 from the final grade table. The operation status code S equals 0. The component converts the data record set according to the table format identifier and displays the query results in the data display area of ​​the business interface in a table format.

[0056] Taking the update operation as an example, after the database receives the update statement, it updates the corresponding data in the project's total cost table, the operation status code S equals 0, and the component writes the update success message into the message area of ​​the business interface.

[0057] If the database connection times out, the operation status code S equals 3. The component will convert the operation status code into an error message: "Database connection timed out. Please check network configuration." This message will be written in red in the message area of ​​the business interface. At the same time, the current status code of the status unit will be updated to the error status code, and the border of the corresponding component on the business interface will turn red to notify the user.

[0058] refer to Figure 2 Based on the same inventive concept, this application also provides a system that uses a runner to execute software rules, comprising: The business decomposition module is used to categorize and classify business according to the operation type of structured query statements. Based on the syntax structure and standard format template corresponding to each operation type, the categorized business is decomposed to obtain rule configuration items. The configuration module is used to configure rule configuration items into the rule attribute field of the component to form business operation rules, call the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language (XML) format data, and embed the XML format data as the component's persistent attribute value. The statement concatenation module is used to extract Extensible Markup Language format data from the persistent attribute values ​​of the component when the component is running, call the Document Object Model parser to parse the key-value pairs of each rule configuration item, concatenate the business operation rules into a structured query statement according to the standard format template corresponding to each operation type, and send the structured query statement to the database. The rule execution module is used to parse structured query statements to obtain a syntax tree, identify business operation rules based on the syntax tree, perform business data operations in the database according to the business operation rules, and generate a result set containing a set of data records and operation status codes. The result processing module is used to parse the operation status code to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If unsuccessful, the operation status code is converted into an error message and displayed in the message area of ​​the business interface.

[0059] Finally, it should be noted that the above experimental examples are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred experimental examples, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method of running software rules with a runner, characterized by, Includes the following steps: The business is categorized according to the operation type of the structured query statement. Based on the syntax structure and standard format template corresponding to each operation type, the categorized business is decomposed to obtain rule configuration items. Configure rule configuration items into the rule attribute field of the component to form business operation rules, call the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language format data, and embed the Extensible Markup Language format data as the component's persistent attribute value; When running a component, Extensible Markup Language format data is extracted from the component's persistent attribute values. The Document Object Model parser is called to parse the key-value pairs of each rule configuration item. Based on the standard format template corresponding to each operation type, the business operation rules are concatenated into a structured query statement, and the structured query statement is sent to the database. The structured query statement is parsed to obtain a syntax tree. Based on the syntax tree, business operation rules are identified. Based on the business operation rules, business data operations are performed in the database to generate a result set containing a set of data records and operation status codes. The operation status code is parsed to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If it fails, the operation status code is converted into an error message and displayed in the message area of ​​the business interface.

2. The method of claim 1 for running software rules with a runner, wherein, Based on the syntax structure corresponding to each operation type, the categorized business logic is decomposed to obtain rule configuration items, including: The business logic of query operations is broken down into field rule configuration items and table name rule configuration items; The business logic for adding operation types is broken down into field rule configuration items and table name rule configuration items; The business logic of update operations is broken down into field rule configuration items and table name rule configuration items; The business logic of delete operations is broken down into table name rule configuration items.

3. The method of claim 2 for running software rules with a runner, wherein, Based on the syntax structure corresponding to each operation type, the categorized business logic is decomposed to obtain rule configuration items, including: The business logic of query operations is broken down into field rule configuration items, table name rule configuration items, filter condition rule configuration items, grouping rule configuration items, and sorting rule configuration items; The business logic for adding operation types is broken down into field rule configuration items and table name rule configuration items; The update operation type is decomposed into field rule configuration items, table name rule configuration items, and filter condition rule configuration items; The business logic of delete operations is broken down into table name rule configuration items and filter condition rule configuration items.

4. The method for running a software rule with a runner of claim 1, wherein, The components include control components and data source components; The control components include rule object units, component event units, component behavior units, output data units, and state units; The rule object unit stores a collection of key-value pairs for rule configuration items; The component event unit stores the mapping relationship between trigger condition identifiers and action identifiers; The component behavior unit stores the mapping relationship between action identifiers and task scripts; The output data unit stores the data output format identifier and the target address identifier; The state unit stores the current state code and state transition conditions; The data source components include input units, functional units, and output units; The input unit extracts the target field data from the data stream; The functional unit performs operations on the target field data to generate the processing result data; The output unit sends the processing result data to the downstream node.

5. The method for running a software rule with a runner of claim 1, wherein, Extensible Markup Language (XML) format data includes rule configuration nodes, operation type nodes, field item nodes, table name nodes, filter condition nodes, grouping nodes, and sorting nodes.

6. The method for running a software rule with a runner of claim 3, wherein, Based on the standard format templates corresponding to each operation type, the business operation rules are concatenated into structured query statements and sent to the database, including: Based on the standard format template corresponding to the query operation type, the business operation rules are combined to generate a structured query statement for the query type; Based on the standard format template corresponding to the add operation type, the business operation rules are combined to generate a structured query statement for the add type; Based on the standard format template corresponding to the update operation type, the business operation rules are combined to generate a structured query statement for the update type; The system generates a structured query statement for the deletion type by combining the standard format template corresponding to the deletion operation type with the business operation rules.

7. The method for running a software rule with a runner of claim 1, wherein, Perform business data operations in the database according to business operation rules, including: performing business data query, add, update or delete operations in the database according to business operation rules.

8. A system that uses a runner to execute software rules, characterized in that, include: The business decomposition module is used to categorize and classify business according to the operation type of structured query statements. Based on the syntax structure and standard format template corresponding to each operation type, the categorized business is decomposed to obtain rule configuration items. The configuration module is used to configure rule configuration items into the rule attribute field of the component to form business operation rules, call the serialization engine to serialize the content of the rule attribute field into Extensible Markup Language (XML) format data, and embed the XML format data as the component's persistent attribute value. The statement concatenation module is used to extract Extensible Markup Language format data from the persistent attribute values ​​of the component when the component is running, call the Document Object Model parser to parse the key-value pairs of each rule configuration item, concatenate the business operation rules into a structured query statement according to the standard format template corresponding to each operation type, and send the structured query statement to the database. The rule execution module is used to parse structured query statements to obtain a syntax tree, identify business operation rules based on the syntax tree, perform business data operations in the database according to the business operation rules, and generate a result set containing a set of data records and operation status codes. The result processing module is used to parse the operation status code to determine whether the data operation was successful. If successful, the data record set is converted according to the data output format identifier and displayed on the business interface. If unsuccessful, the operation status code is converted into an error message and displayed in the message area of ​​the business interface.

Images