A low-code change impact analysis method and system

Abstract

This invention discloses a low-code change impact analysis method and system, belonging to the field of software engineering technology. The invention collects low-code metadata files; performs structured semantic parsing based on schema templates to extract entity nodes and dependency triples; stores entity nodes and dependencies in a relational database to construct an accurate dependency graph, and simultaneously encodes multi-source semantic information into semantic vectors and stores them in a vector database to construct a semantic vector index; starting from the changed node, it performs parallel recursive cascading queries in the relational database and semantic similarity retrieval in the vector database, marking semantically similar nodes not covered by the precisely affected nodes as semantic risk nodes, and merging them to generate a change impact report. This invention achieves accurate dependency tracing and hidden risk discovery through dual-database joint modeling, and improves the completeness and efficiency of change impact analysis by combining incremental update mechanisms and automated testing loops.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and specifically to a method and system for analyzing the impact of low-code changes. Background Technology

[0002] Low-Code Development Platforms (LCDPs) significantly improve the development efficiency of enterprise applications through model-driven and visual orchestration technologies. In real-world production environments, LCDPs accumulate a large number of server-side service assets, including HTTP API interfaces, Enterprise Service Bus (ESB) calls, database SQL definitions, business logic flows, and dataset definitions. These heterogeneous assets have complex dependencies that cross language, protocol, and system boundaries. When an asset changes, its impact on upstream and downstream services and the overall system must be accurately assessed.

[0003] In the prior art, there are already impact analysis methods for low-code platforms. For example, Chinese invention patent CN118585459B discloses an impact analysis method for low-code development platforms. This method performs change analysis on the subsystems (model designer, model converter, platform subsystem) and artifacts (metamodel, model, runtime model) of the low-code development platform, collects the differences between subsystems or artifacts, and derives impact observations based on this to assist developers in making engineering decisions. This approach describes the constituent elements and analysis process of low-code platform impact analysis at the framework level, providing a conceptual foundation for subsequent research.

[0004] However, the aforementioned existing technologies still have the following shortcomings: First, the proposed solution only provides a framework description for impact analysis at a macro level, without disclosing how to specifically and practically extract fine-grained dependencies between heterogeneous server-side assets (especially APIs, logic flows, databases, ESBs, and datasets) in low-code platforms. Since server-side assets in low-code platforms exist as metadata files in formats such as JSON and XML, rather than traditional source code, their dependencies span different protocols and data formats. Existing technologies lack specific technical means to uniformly parse these multi-format metadata and automatically extract dependencies.

[0005] Second, this solution only identifies explicit, direct dependencies and cannot uncover implicit risks between modules that do not have direct code-level calls but share similar semantic functions. In complex business scenarios such as finance and government affairs, two modules may not have direct dependencies but may be semantically coupled due to implementing similar business logic. That is, when one module is modified due to changes in business rules, the other is very likely to have the same potential defects. Existing technology cannot identify such implicit relationships, resulting in a systematic blind spot in the analysis of the impact of changes.

[0006] Third, this solution only outputs impact observation results and does not automatically connect change impact analysis with the regression testing process. In a real production environment, the ultimate goal of change impact analysis is to guide testers to accurately determine the test scope. However, existing technologies lack the ability to automatically convert impact analysis results into executable regression test cases. There is a gap in manual connection between impact analysis and test verification, which reduces the efficiency and security of change release.

[0007] In summary, how to achieve unified dependency resolution for low-code heterogeneous metadata files, automatic identification of implicit semantic risks, and an effective closed loop for change impact analysis and test execution has become a pressing technical problem to be solved in this field. Summary of the Invention

[0008] To address the aforementioned problems in existing low-code change impact analysis techniques, this invention provides a low-code change impact analysis method and system.

[0009] This invention provides a method for analyzing the impact of low-code changes, comprising the following steps: Step 1: Collect metadata of all service assets Collect a set of server-side service asset metadata files for the target application from the application asset export interface of the version control system or low-code platform. The metadata files include HTTP API interface definition files, business logic flow definition files, database access definition files, dataset definition files, and enterprise service bus call definition files. During collection, record the version identifier and file path corresponding to each metadata file to achieve precise binding between metadata and version.

[0010] Step 2: Structured semantic parsing based on schema template The metadata file is subjected to structured semantic parsing based on a predefined schema template, which extracts entity nodes and the dependencies between entity nodes and outputs them in a standardized triple form. The schema template declares a list of entity identifier field paths, entity type tag field paths, and reference relationship field paths.

[0011] The parsing is performed through the template adapter submodule: determining the format of the metadata file to be parsed, loading the corresponding parsing plugin based on the recognition result, and implementing a unified interface specification for each parsing plugin to parse the content of files of different formats into a unified structure object, which is then passed to the rule engine to extract reference relationships.

[0012] Exceptions encountered during parsing are handled according to their type: for missing field exceptions, the parsing process is determined based on the required field attributes to decide whether to continue parsing or mark the structure as incomplete; for data type mismatch exceptions, type conversion or stringification storage is performed; for multi-level nested reference exceptions, unresolved references are written to a buffer table for later completion.

[0013] Step 3: Joint Modeling of Two Databases The entity nodes and dependency triples are stored in a relational database to construct an accurate dependency graph. At the same time, the multi-source semantic information of the entity nodes is encoded into semantic vectors through a text embedding model and stored in a vector database to construct a semantic vector index. The relational database and the vector database constitute a dual-database joint graph.

[0014] The multi-source semantic information includes original source code fragments, code comments, interface documentation, and multi-source concatenated text formed by concatenating the above information in priority order; the multi-source concatenated text serves as the input source for the text embedding model and is encoded to generate the main semantic vector; the original source code, code comments, and interface documentation are stored as supplementary fields for fine-grained reordering and interpretability display of retrieval results.

[0015] Step 4: Incremental Update Mechanism Incremental updates are triggered via version control system hooks or CI / CD pipelines to obtain a list of changed files, compare the change history table to determine the set of differing files, re-execute the structured semantic parsing only on the changed files, and perform partial update operations on the dual databases; at the same time, a scheduled task is set as a compensation mechanism to ensure the eventual consistency of the map data.

[0016] Step 5: Generate the scope of impact of the dual-engine change Starting with the changed node, recursive cascading queries of relational databases and semantic similarity retrieval of vector databases are executed in parallel: the direct and indirect dependent nodes of the changed node are obtained through recursive cascading queries to form a set of precisely affected nodes; a set of candidate nodes that are semantically similar to the changed node is obtained through semantic similarity retrieval, and nodes in this set that are not covered by the set of precisely affected nodes are marked as semantic risk nodes.

[0017] After the semantic similarity retrieval returns candidate nodes, a multi-stage fine ranking is performed: an additional score is calculated based on the textual relevance of the supplementary fields and the changed nodes, the additional score is weighted and merged with the vector similarity score, and consistency filtering is performed according to the entity type to output the final list of semantic risk nodes.

[0018] Merge the precise set of impact nodes with the semantic risk nodes to generate a change impact report.

[0019] Step Six: Automatic Generation of Regression Test Cases Based on the affected entity nodes in the change impact report, the corresponding test case templates are matched: first, a list of candidate templates is retrieved based on the entity type; when multiple candidate templates exist, the entity parameter field set is further compared with the matching fields declared in the template, and the template with the highest coverage is selected.

[0020] The system retrieves a set of pre-bound test case IDs based on the selected template, and then uses the test management platform's open API to call these test case IDs in batches, triggering the execution of regression test cases. The linked call chain is equipped with a fault tolerance mechanism, including request retry, partial failure isolation, and degradation output when the platform is unavailable.

[0021] Collect test execution results and code coverage data, and integrate them into the change impact report.

[0022] This invention also provides a low-code change impact analysis system, comprising: The metadata collection module is used to collect a set of server-side service asset metadata files of the target application from the application asset export interface of the version control system or low-code platform. The semantic parsing module is used to perform structured semantic parsing on the metadata file based on a predefined schema template, and to extract entity nodes and the dependencies between entity nodes; A dual-database storage module is used to store the entity nodes and their dependencies in a relational database to construct an accurate dependency graph, and to encode and store the multi-source semantic information of the entity nodes in a vector database to construct a semantic vector index. The incremental update module is used to trigger incremental updates through version control system hooks or CI / CD pipelines, obtain a list of changed files, and drive the semantic parsing module to update the dual databases only after re-parsed the changed files. The impact analysis module is used to execute recursive cascading queries of relational databases and semantic similarity retrieval of vector databases in parallel, starting from the change nodes, to generate a change impact report containing precise impact nodes and semantic risk nodes. The test integration module is used to match the corresponding test case templates according to the affected entity nodes in the change impact report, call the pre-bound test case ID set in the test management platform, trigger the execution of regression test cases, and output the execution results.

[0023] Compared with the prior art, the present invention has the following beneficial effects.

[0024] I. Results of Unified Parsing of Heterogeneous Metadata Based on Schema Templates and Adapter Architecture This invention employs a schema-template-based structured semantic parsing engine, which uses a template adapter submodule to achieve unified parsing of low-code metadata files in multiple formats such as XML, JSON, and YAML. This technical solution differs substantially from existing technologies that only describe the components of influence analysis at a macro-framework level without providing any specific parsing methods.

[0025] Specifically, this invention automatically determines the format of the file to be parsed through a format recognizer, loads the corresponding parsing plugin, and each plugin implements a unified interface specification. After parsing the content of files with different formats into a unified structure object, it is handed over to the rule engine for processing. Simultaneously, this invention designs classification and handling mechanisms for three types of anomalies that may occur during the parsing process: missing fields, data type mismatches, and multi-level nested references, ensuring the robustness of the parsing process.

[0026] The beneficial effects of the synergistic effect of the above-mentioned technical features are as follows: First, it enables the automatic extraction of six types of dependencies among five types of server-side assets (API, LogicFlow, Database, DataSet, ESB) in low-code platforms, solving the technical problem that existing technologies cannot uniformly model triple heterogeneous dependencies; Second, the plug-in adapter architecture allows adding support for other low-code platform formats only requires developing new parsing plugins without modifying the core parsing logic, demonstrating good scalability; Third, the exception classification and handling mechanism ensures that the parsing process can continue even when metadata is incomplete or the format is non-standard, avoiding the interruption of the overall parsing due to problems with individual files.

[0027] II. Complementary Analysis Effects of Dual-Track Modeling Using Relational and Vector Databases This invention employs a dual-track co-storage architecture combining relational and vector databases in the field of low-code server-side change impact analysis. This technical solution is not simply a matter of stacking two databases, but rather a complementary architecture designed based on a deep understanding of the two different natures of change impact analysis requirements.

[0028] The relational database is based on a real service asset repository structure, constructing a dual-mainline dependency graph around the two core entities of API and LogicFlow. It achieves precise storage of multi-dimensional asset reference relationships through intermediate dependency tables and supports recursive CTE queries to achieve multi-level cascading dependency tracing. The vector database encodes the multi-source semantic information of entity nodes (source code, code comments, interface documentation, and multi-source concatenated text) into semantic vectors and supports approximate nearest neighbor retrieval based on cosine similarity.

[0029] The two types of databases mentioned above complement each other functionally: relational databases solve the problem of precisely tracing "who depends on whom," while vector databases solve the problem of discovering implicit risks such as "who is semantically similar to whom." This invention further designs a fusion logic for the two analysis results, which involves removing nodes already covered by precise dependency tracing in the semantic similarity search results, and marking the remaining nodes as semantic risk nodes. The synergistic effect of this removal logic is to avoid repeatedly reporting nodes that are clearly reachable through dependency paths to users, while highlighting implicit risks that cannot be discovered solely based on the dependency graph structure, making the change impact report both complete and concise.

[0030] Compared with existing technologies that only output differences at the subsystem or workpiece level and fail to discover implicit risks of semantic similarity, this invention significantly reduces the risk of systematic omissions in change impact analysis through dual-library joint modeling and result fusion logic. Especially in scenarios with high requirements for system reliability, such as finance and government affairs, it can effectively identify implicitly coupled modules due to similar business logic.

[0031] III. The interpretability effect of the semantic vector storage strategy combining the main vector and supplementary fields This invention adopts a hybrid storage architecture of "main vector + supplementary fields" in vector database modeling, and this technical solution has the following synergistic effects.

[0032] Multi-source concatenated text is encoded using a text embedding model to generate a main vector for approximate nearest neighbor retrieval, ensuring retrieval efficiency. Meanwhile, original source code fragments, code comments, and interface documentation are stored as supplementary fields, which do not participate in vector retrieval but are used for two-stage fine ranking after the results are returned: In the first stage, the text relevance score between the supplementary fields and the changed nodes is calculated based on the BM25 algorithm, and then weighted and merged with the vector similarity score before re-ranking; in the second stage, consistency filtering is performed based on entity type.

[0033] The synergistic effect of the above technical features produces the following beneficial results: First, the main vector ensures the recall rate of semantic retrieval, while the fine-ranking mechanism supported by the supplementary fields improves the accuracy; together, they optimize the precision of the retrieval results. Second, the semantic original text in the supplementary fields can be directly displayed in the change impact report, providing users with an explainable basis for judging why a certain node is identified as a semantic risk, thus improving the credibility and usability of the system. Third, the multi-source concatenated text is generated and persistently stored when it is entered into the database. The text embedding model, as a deterministic mathematical function, ensures that the same input produces the same output, avoiding the uncertainty of vector generation and ensuring the reproducibility of the technical solution.

[0034] IV. The Dual Improvement in Real-Time Performance and Consistency Brought About by the Incremental Update Mechanism This invention designs a version control system hook and a CI / CD pipeline-driven incremental update mechanism, supplemented by a timed task as a compensation mechanism, forming a multi-layered triggering guarantee system.

[0035] The technical advantages of this solution are as follows: First, incremental updates are automatically triggered during code merging via VCS hooks. The time cost of graph maintenance is linearly related to the number of files involved in a single change, and is essentially decoupled from the overall size of the service asset library, achieving near real-time maintenance of the graph in typical development scenarios. Second, database writes use precise update operations based on primary key indexes. The update cost is linearly related to the scope of changes and does not increase significantly with the size of the asset library, effectively avoiding performance degradation caused by the expansion of the asset library under the full reconstruction method. Third, the scheduled task compensation mechanism serves as a fallback guarantee, ensuring the eventual consistency of graph data in the event of a missed trigger of VCS hooks, thus balancing real-time performance and reliability.

[0036] Compared with existing technologies, the incremental update scheme of the present invention significantly reduces the computational resource consumption for map maintenance and improves the response speed of change impact analysis in production environments where low-code platform service assets change frequently, demonstrating outstanding technical advantages.

[0037] V. The dual improvement in efficiency and safety resulting from the automated closed loop that impacts testing This invention deeply integrates change impact analysis with automatic generation of regression test cases, forming a complete automated closed loop of change perception, graph update, impact analysis, and test response.

[0038] This closed loop is achieved through the synergy of the following technical features: First, a template matching mechanism based on entity type further performs parameter field integrity matching for API type entities, prioritizing the selection of the test template with the highest coverage; Second, test case IDs and execution parameters are pre-bound in the test management platform, allowing the system to directly call the case ID to execute tests via the open API without dynamically generating test parameters; Third, a three-level fault tolerance mechanism ensures that the main process of change impact analysis remains unaffected when the test platform is unavailable or some test cases execute abnormally.

[0039] The beneficial effects of the above-mentioned features include: First, upgrading the traditional "manual evaluation-manual testing-manual judgment" process to a one-stop closed loop of "automatic analysis-automatic testing-intelligent decision-making" significantly shortens the verification cycle before change release; Second, the case ID pre-binding mechanism avoids the complexity of dynamically generating test parameters and reduces the difficulty of system implementation; Third, the three-level fault tolerance mechanism (retry, isolation, and degradation) ensures the loose coupling of the system to the external testing platform. Even if the testing platform fails, the core function of change impact analysis can still output results normally, meeting the requirements of high-reliability production environments such as finance and government.

[0040] VI. Overall Technical Effect of Synergistic Effect of Various Technical Features In summary, the technical features of this invention are not simply superimposed, but rather form a complete change impact analysis technology system through organic synergy: schema parsing provides the data foundation for dual-database modeling, dual-database collaboration provides dual capability support for impact analysis, incremental updates ensure the timeliness of the graph data, and the closed-loop testing transforms the analysis results into practical engineering value. Each step is interconnected, and the data flow is seamless, collectively solving the technical problem of inaccurate and automated analysis of low-code change impacts. This achieves intelligent support throughout the entire process from change occurrence to testing and verification, representing a substantial technological advancement compared to existing technologies. Attached Figure Description

[0041] Figure 1 This is a flowchart illustrating the overall method of an embodiment of the present invention; Figure 2 This is a schematic diagram of the structured semantic parsing process based on a schema template according to an embodiment of the present invention; Figure 3 This is a diagram of the dual-database joint modeling architecture according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating the triggering and execution process of the incremental update mechanism in this embodiment of the invention. Figure 5 This is a flowchart illustrating the process of generating the scope of impact of dual-engine changes according to an embodiment of the present invention. Figure 6 This is a system module architecture diagram of an embodiment of the present invention. Detailed Implementation

[0042] 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 specific embodiments. It should be noted that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention.

[0043] In this invention, unless otherwise specified, the following terms have the following meanings: Server-side service assets: refer to resource entities described by various metadata definition files that run on the server side in the low-code platform and support the operation of applications, including but not limited to HTTP API interface definitions, business logic flow definitions, database access definitions, dataset definitions, and enterprise service bus call definitions.

[0044] Metadata files: Low-code platform service asset configuration files stored in structured data formats (including JSON, XML, YAML) describe the attribute definitions, input and output specifications, business processing logic, and reference relationships with other assets of server-side entities.

[0045] Schema Template: A set of parsing rules declared in JSON format, used to guide the parsing engine in extracting entity identifiers, type tags, and reference relationships from metadata files. The Schema Template declares field path expressions for various formats (XML, JSON, YAML), ensuring that the semantic meaning of fields remains consistent across formats.

[0046] Entity node: refers to a server-side asset instance extracted from the metadata file. It has a unique identifier, type attributes, and business attribute descriptions and is the basic building block in the dependency graph.

[0047] Dependency triples: Directed dependency descriptions in the format of (source entity, relation type, target entity), used to characterize reference or invocation relationships between server assets.

[0048] Dual-database joint graph: A joint data structure consisting of an exact dependency graph stored in a relational database and a semantic vector index stored in a vector database, supporting both exact query and semantic retrieval capabilities.

[0049] Precise dependency path: The complete call chain from the changed node to the affected node is obtained by recursively tracing along the directed dependency edges between server assets.

[0050] Semantic similarity: The degree of semantic closeness is represented by the cosine distance between the semantic vectors of two entity nodes. The higher the cosine similarity, the closer the business semantics of the two entities are.

[0051] Hidden risk nodes: In the change impact analysis, there is no direct or indirect dependency relationship with the change node, but due to similar business semantics, there may be the same potential defects or the need for synchronous change of the entity node.

[0052] Incremental update: An update mechanism that only re-parses and updates the dependency graph on the changed metadata files, rather than rebuilding the entire graph.

[0053] Multi-source concatenated text: The complete semantic description text obtained by concatenating the entity's function signature, interface documentation, and code comments in a predetermined priority order serves as the core input source for the text embedding model.

[0054] Example 1 (Method Example) like Figure 1 As shown in the figure, this embodiment provides a low-code change impact analysis method. This method achieves automated analysis and test response to server-side change impacts by deploying corresponding collection and parsing services in the version control system and CI / CD pipeline of the low-code platform.

[0055] Step S1: Collect and bind metadata for all service assets The system automatically retrieves the full set of service asset metadata files for the current version of the target application by calling the API interface of the version control system or the application asset export interface of the low-code platform.

[0056] The collected metadata covers the following five types of core server-side asset files: The first type is the HTTP API interface definition file, which describes the input and output specifications of the service interface exposed to the outside world, including information such as request path, HTTP method, parameter description, and return type.

[0057] The second category is business logic flow definition files, which are used to describe the logical flow configuration of the business processing flow, including input parameters, output parameters, temporary variables, and sub-process call relationships.

[0058] The third category is database access definition files, which contain SQL resource definitions and describe database table operations (including querying, adding, modifying, and deleting) and relationships.

[0059] The fourth category is the dataset definition file, which is used to define the data structure and its mapping relationship with the backend service, including attributes such as field names, types, and descriptions.

[0060] The fifth category is the Enterprise Service Bus (ESB) call definition file, which records the integration call definition with the Enterprise Service Bus, including information such as ESB service code, transaction code, and request-response structure.

[0061] During the data collection process, the system records the submission identifier, version number, and file path of each metadata file, enabling precise binding between metadata versions and change history, thus providing a foundation for subsequent incremental updates.

[0062] Step S2: Structured semantic parsing based on schema template This invention proposes a structured semantic parsing engine based on a predefined schema template. This parsing engine uses the structured attribute fields of metadata files as parsing objects and achieves unified dependency recognition across platforms and languages ​​through schema template matching and entity relationship extraction. It can adapt to the metadata formats of low-code platforms from different vendors.

[0063] like Figure 2 As shown, the explanation is based on low-code platform metadata in XML format.

[0064] The parsing principle of the schema template is independent of any specific file format. For low-code metadata files in different formats such as JSON and YAML, the parsing engine maintains consistency in the following three core steps: First, the file is parsed into a unified in-memory object model using the corresponding format parser; second, the field path declarations in the schema template only need to be replaced with the path expression syntax of the corresponding format, and the semantic meaning of the paths remains exactly the same; third, the extraction logic of entity identifiers, type tags, and reference relationship fields corresponds one-to-one across formats and does not change due to format differences. The schema template itself uses JSON format to declare a unified parsing rule structure, and the path expressions for each format are stored in the fieldPaths field.

[0065] The parsing engine may encounter the following three types of parsing exceptions during execution, and the system has designed a clear technical handling strategy for each type of exception.

[0066] The first type is the field missing anomaly. When the path of a required field declared in the schema template of the target metadata file does not exist, the parsing engine will split the parsing based on the required attribute of the field: if it is a required field, the entity node will be marked as incomplete and written to the anomaly record table, and a warning log will be output to prompt the operation and maintenance personnel to complete the metadata and re-enter it into the database; if it is an optional field, the field will be skipped and the parsing will continue without affecting the normal extraction of other fields.

[0067] The second type is data type mismatch exceptions. When the type of the extracted field value does not match the expected type declared in the schema template, the parsing engine calls the data type forced conversion logic: if it can be converted, it continues processing after conversion; if it cannot be converted, the original value is stored as a string to ensure that the entity node can still be entered into the database, and the exception information is written to the exception record table for manual review.

[0068] The third type is multi-level nested reference exceptions. When the target entity pointed to by the reference relationship field does not exist in the current asset package, the parsing engine does not immediately discard the reference, but writes it into the reference buffer table to be parsed. After the subsequent asset packages are added to the database, an incremental parsing task is triggered to complete the reference relationship, avoiding reference breakage caused by asset package boundary issues.

[0069] To achieve the aforementioned multi-format parsing capabilities, the adapter workflow within the parsing engine is as follows: After receiving the metadata file to be parsed, the template adapter first determines the file format using a format recognizer. Secondly, based on the recognition result, it loads the corresponding format's schema parsing plugin. Each plugin implements a unified interface specification, including two core interfaces: the `parse` method (used to parse the file content into a unified AssetNode object) and the `validate` method (used to perform schema validation on the parsing result). Thirdly, the `parse` method is called to parse the file content into AssetNode objects, which contain four standard attributes: entityId, entityName, entityType, and rawFields. Finally, the AssetNode object is passed to the rule engine, which loads the corresponding reference rules based on the entityType, extracts the reference relationships field by field, and constructs triples for output.

[0070] Specifically, the system predefines a corresponding schema template for each type of metadata file, and the following parsing rules are declared in the schema template.

[0071] The entity identifier field path, such as id, name, path, etc. in the JSON path, is used to extract the unique identifier of the entity.

[0072] The entity type marker field path, such as type, kind, etc., is used to determine the category to which the entity belongs (including API, LogicFlow, ESB, Database, DataSet).

[0073] The reference relationship field path list is used to declare which field values ​​represent references to other entities. For example: if the parameters field value in the API file references the name of the DataSet, it is identified as an input parameter dependency reference from the DataSet to the API; if the returns field value in the API file references the name of the DataSet, it is identified as an output parameter dependency reference from the DataSet to the API; if the request_entity and biz_entity fields in the LogicFlow file reference the name of the DataSet, they are identified as references from the DataSet to the LogicFlow; if the sonBusinessId field in the LogicFlow file references the id of another LogicFlow, it is identified as a sub-logic flow call reference from one LogicFlow to another; if the SQLId field in the LogicFlow file references the SQL resource ID of the Database, it is identified as a reference from the LogicFlow to the Database; if the esb_service_id field in the LogicFlow file references the ESB's service code, it is identified as a reference from the LogicFlow to the ESB.

[0074] The parsing engine scans each metadata file field-by-field according to the corresponding schema template, extracting entity nodes and directed relationship edges, and outputting a standardized list of (source entity, relationship type, target entity) triples. The system supports five types of server-side entity types and six types of dependency relationships. The six dependency relationship types are: DataSet to API reference, DataSet to LogicFlow reference, LogicFlow to LogicFlow reference, LogicFlow to Database reference, LogicFlow to ESB reference, and API to ESB reference.

[0075] Step S3: Joint Modeling of Two Databases like Figure 3 As shown, this invention adopts a dual-track joint storage architecture of relational database and vector database in the field of low-code platform-dependent graphs. The two serve different query targets respectively, forming a complementary combination of precise query and semantic retrieval capabilities.

[0076] (I) Relational Database Modeling The relational database design of this invention is based on a real-world service asset repository within a low-code platform. It constructs a dual-mainline dependency graph around two core entities: services (APIs) and business logic (logic flows). An intermediate dependency table enables precise storage of multi-dimensional asset reference relationships and multi-level cascading queries. The database as a whole consists of the following two sets of core tables and auxiliary tables.

[0077] The first group is the service (API) asset mainline.

[0078] The main service table, `service_assets`, records complete information about all API interfaces in the low-code platform and is the core node table for service dependency analysis. This table contains the following fields: `id` is the primary key, used for unique API identification; `name` is the API name; `path` is the API request path; `bizpath` is the business request path; `httpMethod` is the HTTP request method; `description` is the API function description; `appid` is the application ID, associated with the `t_eos_application` table; `appInstGrp` is the application instance group ID; `esb_service_id` is the ESB service transaction code, used to identify ESB protocol class dependencies; `deployed_scope` is the deployment scope, including four values: local, business gateway, ESB business gateway, and mobile gateway; `parameters` are the input parameters, associated with the `source_dataset` dataset table; `returns` are the output parameters, associated with the `source_dataset` dataset table; `version` and `state` are the service version number and service status, respectively; `auth_type` is the security authentication method; `biz_code` and `service_type` are the product code and transaction type, respectively; and `EXTENDINFO` is an extended field.

[0079] The service dependency intermediate table `service_dependency_list` records all downstream assets referenced by a service (API) and is the key join table for resolving API dependencies. This table contains the following fields: `service_id` is the primary key and foreign key, relating to the `id` field of the `service_assets` table; `SQLId` references SQL resource IDs, relating to the `source_database` table; `primitive_quote_id` references primitive IDs, relating to the `source_primitive_quote` table; `source_dataset_id` references dataset IDs, relating to the `source_dataset` table; `service_list_id` references vertical service list IDs, relating to the `source_service_list` table; `component_id` references service component IDs, relating to the `source_component` table; and `preservice_id` references horizontal service list IDs, relating to the `source_pre_service_list` table.

[0080] The second group is the main asset line of business logic (logic flow).

[0081] The main table `source_bussiness_logic` records complete metadata for all levels of logical flows in the low-code platform and is the core node table for business logic dependency analysis. This table contains the following fields: `id` is the primary key and a unique identifier for the logical flow; `path` is the full path of the logical flow, used for hierarchical location; `description` is the functional description of the logical flow; `app_name` is the name of the application to which it belongs; `request_entity` is the inflow parameter of the logical flow, associated with the `source_dataset` table; `response_entity` is the outflow parameter of the logical flow, associated with the `source_dataset` table; `biz_entity` is the temporary variable parameter, associated with the `source_dataset` table; `auth` is the author of the logical flow; and `create_time` is the creation time.

[0082] The business logic dependency intermediate table `source_business_dependency` records all downstream assets and sub-logic flows referenced by the logic flow, supporting recursive nested queries of the logic flow. This table contains the following fields: `business_id` is the ID of the current logic flow, associated with the `id` field of the `source_bussiness_logic` table; `sonbusiness_id` is the ID of the sub-logic flow, a self-referencing `id` field of the `source_bussiness_logic` table, supporting multi-level nested recursive queries; `component_id` is the component ID, associated with the `source_component` table; `primitive_quote_id` is the primitive ID, associated with the `source_primitive_quote` table; `source_dataset_id` is the dataset ID, associated with the `source_dataset` table; and `SQLId` is the SQL resource ID, associated with the `source_database` table.

[0083] The auxiliary table group provides supplementary information on node details for the dependency graph, enriching node attributes in change impact analysis. The `source_service_desc` table is associated with the `id` field of the `service_assets` table, storing service name, service details, and application name for quick service summary retrieval. The `source_component` table is associated with two intermediate tables via the `component_id` field, storing information about components referenced by service or logical flows. The `source_database` table is associated with two intermediate tables via the `SQLId` field, storing SQL resource information, including SQL identifier, table name, and complete SQL statement, used to identify read / write dependencies of services or logical flows on database tables. The `source_dataset` table is associated with multiple locations via the `source_dataset_id` field, storing all dataset definitions and referenced by the `service_assets` table, `source_bussiness_logic` table, and two intermediate tables; it is a core auxiliary table for identifying data model dependencies. The `dataset_property` table is associated with the `id` field of the `source_dataset` table, storing field name, Chinese field name, field type, etc., for precise tracking of the impact of field-level data dependency changes. The `t_eos_application` table is associated with the `appid` field of the `service_assets` table, storing the application code and application name for cross-application dependency analysis.

[0084] Based on the aforementioned dual-mainline table structure, the system implements two types of recursive cascading queries to support change impact analysis.

[0085] The first type of query is for multi-level dependency tracing of services (APIs). Starting with a service in the `service_assets` table, by joining the intermediate `service_dependency_list` table, all SQL resources, datasets, components, and logical flows directly referenced by that service can be retrieved at once. Further association with the `source_service_list` (a list of logical flow services) using the `service_list_id` field allows the retrieval of the lower-level logical flows called by that service. This process then recursively enters the second query chain, thus achieving a complete multi-level cascading tracing from API to the logical flow list, to the logical flow itself, to sub-logical flows, and finally to SQL, components, or datasets.

[0086] The second query type involves recursive tracing of nested sub-flows within a logical flow. Starting with a logical flow in the `source_bussiness_logic` table, a recursive self-join query is performed through the `sonbusiness_id` field of the intermediate `source_business_dependency` table to completely reconstruct the multi-level nested call tree of the logical flow. Simultaneously, for each logical flow node, the underlying assets it references, such as SQLId, component_id, and source_dataset_id, can be retrieved through fields like SQLId, component_id, and source_dataset_id, enabling analysis of the impact range of the entire logical flow call chain. The system uses recursive common table expressions to implement this query, supporting recursive expansion up to 10 levels of nesting depth, balancing query completeness with preventing the risk of infinite loops caused by circular references.

[0087] (II) Vector Database Modeling This invention employs a multi-source fusion semantic encoding strategy, using the concatenated text of interface documents, code comments, and function signatures as the main vector information source. Semantic vectors are directly generated through text embedding model encoding, with auxiliary information such as source code and code comments stored as supplementary fields. Together, they constitute the entity semantic vector representation, achieving accurate method-level semantic modeling of various service assets in low-code platforms.

[0088] The system collects the following four types of semantic information sources for each method-level entity node.

[0089] The first category is source code, that is, the complete implementation code of a method, which is the most basic source of information for semantic understanding.

[0090] The second category is code comments, which are the comment text inside and around a method, reflecting the developer's original design intent and usage constraints.

[0091] The third category is interface documentation, which is the interface documentation description corresponding to the method, providing standardized functional descriptions and parameter semantics.

[0092] The fourth type is multi-source concatenated text, which is a complete semantic description text obtained by concatenating the entity's function signature, interface documentation, and inline comments in order of priority. This text serves as the core input source for the text embedding model. The concatenation format is: entity type identifier followed by entity name, then function signature, then interface documentation, and then code comments, with each field separated by double vertical bars. This concatenated text is generated when the entity is added to the database and persistently stored in the semantic text field, serving as the interpretable information source for the main vector.

[0093] Multi-source concatenated text is generated using an asset ingestion trigger mechanism. Each service asset node, upon parsing and ingesting via a schema template, synchronously triggers the multi-source concatenated text generation process. Function signatures, API documentation, and code comments are combined according to concatenation rules and stored in a semantic text field. Simultaneously, a text embedding model is invoked to encode the concatenated text into a semantic vector, which is then stored in the main vector field. This process guarantees atomicity with the asset ingestion transaction, requires no independent caching layer, and ensures that the vector library and asset library remain consistent at all times.

[0094] In this embodiment, the text embedding model adopts the open-source BAAI / bge-large-zh-v1.5 model, which encodes the input text into a 1024-dimensional semantic vector. It should be noted that those skilled in the art can choose other text embedding models (such as OpenAI's text-embedding-ada-002 model or the Sentence-BERT model) according to the actual application scenario, and this invention does not limit this choice.

[0095] Based on multi-source information, this invention adopts a hybrid storage architecture of main vector plus supplementary fields. The text embedding vector of multi-source concatenated text is used as the main vector for approximate nearest neighbor retrieval, and other semantic information is used as supplementary fields for fine-grained filtering and interpretability display of results.

[0096] The main vector field directly inputs the multi-source concatenated text into the text embedding model, encodes it into a fixed-dimensional vector (1024 dimensions in this embodiment), serves as the main retrieval vector for this method node, and is stored in the pgvector extended vector column of PostgreSQL.

[0097] The supplementary text fields include original source code snippets, code comments, and interface documentation content. These are stored as text fields and do not participate in vector retrieval, but are used for the following three purposes after the results are returned: First, fine-grained ranking: Based on the relevance score between the supplementary text and the query, the near-nearest neighbor retrieval results are re-ranked to improve the accuracy of the final returned results. Second, interpretability of results: The supplementary text is returned along with the main vector retrieval results. Users can view the complete semantic context of each semantically similar node in the change impact report, understanding why the system identifies it as a potential latent risk, thus improving the credibility and usability of the results. Third, deterministic guarantee of vector generation: The text embedding model is a deterministic mathematical function; the same concatenated text input will necessarily output the same vector, requiring no additional caching layer or version control. In the event of a temporary unavailability of the vector database service, the system will temporarily store the concatenated text in the semantic text field of a relational database, automatically re-encoding it after the service is restored, without manual intervention.

[0098] The vector database table structure is illustrated using PostgreSQL and the pgvector extension as an example. The table contains the following fields: id is an auto-incrementing primary key; method_id is a unique identifier for the method-level entity, uniquely combined with app_id; app_id is the application ID; entity_type is the entity type (including API, LogicFlow, ESB, SQL, DataSet, etc.); entity_name is the entity name; primary_vector is the primary vector (multi-source concatenated text embedding vector), indexed using ivfflat cosine; source_code is the original source code snippet; code_comments are the code comments; javadoc_text is the interface documentation content; semantic_text is the original multi-source concatenated semantic text, used for BM25 reordering; generated_at is the vector generation time, defaulting to the current timestamp.

[0099] When a method-level entity changes, the system's semantic risk warning process is as follows.

[0100] The first step is to extract the primary_vector of the change method from the PostgreSQL vector table, which will be used as the query vector for semantic retrieval.

[0101] The second step is to perform cosine similarity approximate nearest neighbor search. In the vector table, the top-K (default K is 20) similar method nodes with a cosine similarity higher than the threshold (default threshold is 0.85) are searched. At the same time, the entity_type field is used to limit the return to entities of the same type as the changed method to avoid cross-type mismatch.

[0102] The third step is to exclude directly dependent nodes from the search results that have been covered by exact dependency queries in relational databases, and mark the remaining nodes as potential hidden risk nodes.

[0103] The fourth step is to attach the semantic text field content of the latent risk nodes and their principal vector similarity scores to the change impact report, along with source code snippets as a basis for manual verification, so that the release reviewers can determine whether the relevant nodes need to be included in the regression test scope.

[0104] The default similarity threshold of 0.85 is determined based on publicly available literature and industry consensus in the semantic retrieval field. The system allows operations personnel to dynamically adjust the threshold in the management interface according to business scenarios, with an effective range of 0.70 to 0.95. After adjustment, the system automatically re-executes nearest neighbor retrieval with the new threshold and updates the impact report, without needing to rebuild the vector index. For scenarios with strong consistency (such as core financial systems), it is recommended to lower the threshold to 0.80 to improve recall; for frequently changing non-core scenarios, the threshold can be raised to 0.90 to reduce false positive noise.

[0105] The Top-K candidate nodes returned by the near nearest neighbor retrieval are then processed through the following two-stage fine ranking process before the final list of semantic risk nodes is output.

[0106] The first stage is text relevance reordering. For each candidate node, the system extracts the semantic text, code comments, and API documentation content from its supplementary fields, and calculates the BM25 term frequency relevance score for each of these fields along with the corresponding fields of the changed method. The BM25 score and the principal vector cosine similarity score are then linearly weighted according to their respective weights (default principal vector weight 0.7, BM25 weight 0.3) to obtain a comprehensive relevance score. The Top-K results are then reordered based on the comprehensive relevance score, and nodes with a comprehensive score higher than the ranking threshold (default 0.75) are retained for the second stage.

[0107] The second stage is entity type consistency filtering. This ensures that the candidate nodes after fine-tuning are consistent with the `entity_type` field of the changed method. For example, if the changed method is of type LogicFlow, only similar nodes of type LogicFlow are retained, avoiding low-quality warnings caused by cross-type mismatches. The final semantic risk node list output after these two stages of fine-tuning is significantly more accurate than the initial results of pure vector approximate nearest neighbor retrieval, effectively reducing false positives and improving the usability of impact reports.

[0108] Step S4: Incremental Update Mechanism Driven by VCS Hook and CI / CD Integration like Figure 4 As shown, this invention designs three complementary triggering mechanisms to achieve incremental real-time updates of the change map, avoiding the performance overhead caused by full reconstruction.

[0109] The first triggering mechanism is VCS hook triggering, which enables incremental updates at the PR level. A post-receive hook is pre-configured in the version control system. When a developer submits a Pull Request and the code is merged by reviewers, the Git server automatically triggers the hook to call the incremental update API interface provided by this system, passing in the PR number. The system queries the VCS using the PR number to obtain a list of commit identifiers for all changed files in this PR. Based on the commit identifiers, it compares them with the change history table to determine the set of difference file paths (containing only newly added, modified, and deleted files). The system only re-executes the schema semantic parsing in step S2 on the difference file set, performing partial updates to the asset node table and asset edge table to achieve precise incremental updates.

[0110] The second triggering mechanism is CI / CD pipeline integration triggering. A custom plugin is integrated during the build and packaging phase of the CI / CD pipeline. Once the artifact package is built, the plugin automatically transfers it to a designated directory. The system asset library listens to this directory, and upon receiving the new artifact package, extracts and parses the metadata files within the package to complete the graph update operation.

[0111] The third triggering mechanism is the scheduled task compensation mechanism. The system also maintains a scheduled task (executed daily at 10:00 and 16:00 by default) to perform a full comparison scan on changes that were not captured by the VCS hook in the previous period, as a compensation mechanism to ensure the final consistency of the map data.

[0112] Suppose a low-code platform service asset repository contains n metadata files, and the number of files involved in a single change is Δn. A full rebuild solution requires traversing all n files, sequentially performing file reading, schema parsing, entity extraction, dependency extraction, and database writing. For a medium-sized low-code platform (n is 5000 to 50000 metadata files), the time taken for a full rebuild triggered by each change is in the minutes range, which cannot meet the real-time update requirements after PR merging. The incremental update of this invention only performs parsing and local graph updates on the set of differing files (Δn files). In typical development scenarios, the number of files involved in a single PR change, Δn, is usually 1 to 20. Incremental updates only perform insertion, update, or deletion operations on the affected asset nodes and edges. The time complexity of insertion or update operations based on primary key indexes in relational databases is logarithmic. The local vector update complexity of vector databases is linearly related to the number of changed files and the vector dimension, while the overall database update cost is linearly related to Δn and does not increase significantly with increasing n. In rare cases where VCS hooks are missed, the system performs a full comparison scan via a scheduled task, but the trigger frequency is extremely low (no more than twice a day) and it only executes during off-peak business hours, thus not affecting real-time change response capabilities. In summary, the incremental update mechanism of this invention controls the time cost of graph maintenance to a level only related to the number of changed files in average scenarios, enabling real-time dynamic maintenance of the low-code platform service asset graph.

[0113] Step S5: Generate the scope of impact of the dual-engine change like Figure 5 As shown, after receiving a change impact query request, the system starts a dual-engine parallel analysis process, starting from the change node identifier.

[0114] The first engine performs precise dependency path queries, based on a relational database. The system executes a recursive common table expression SQL query defined in step S3, expanding layer by layer from the asset edge table along the directed dependency edges to obtain a list of all entities that directly and indirectly depend on the change node (the impact depth is limited to 10 levels). The output is a precise list of affected entities, including entity type, entity name, impact depth, dependency path, and other information.

[0115] The second engine is semantic similarity risk retrieval, which is performed based on a vector database. The system retrieves the vector identifiers corresponding to the changed nodes from the asset node table, calls the vector database to perform nearest neighbor retrieval, and returns the Top-K similar entity nodes with a cosine similarity higher than the threshold θ. After excluding the exact dependent nodes already covered by the first engine, the remaining nodes are marked as semantically related risk nodes.

[0116] After merging the analysis results from the two engines, a change impact report is generated, which includes the following: basic information of the change node (including entity type, entity name, and change type); a precise list of affected entities (displayed hierarchically by impact depth, with dependent paths marked); a semantic risk warning list (marked with similarity scores and potential risk descriptions); key path highlighting (highlighting strong impact paths with a depth of no more than 2 levels); and an impact assessment summary (including the total number of affected entities, the levels involved, and risk level assessment).

[0117] Step S6: Visualization, Report Output, and Automatic Test Case Generation This invention deeply integrates the results of change impact analysis with the ability to automatically generate regression test cases, forming a complete closed loop from change perception to test response.

[0118] In terms of visualization, the system displays the server-side change relationship graph through a graphical interface, supporting various visualization formats such as topology graphs, tree diagrams, and heatmaps. It provides the following interactive operations: clicking on a node to view entity details and associated metadata; path tracing to view the complete dependency chain from the changed node to the affected node; highlighting the scope of influence, distinguishing precisely affected nodes and semantically risky nodes with different colors; and expanding or collapsing the scope of influence, supporting the expansion or collapse of dependency chains by level.

[0119] Regarding the output of structured impact reports, the system exports the change impact analysis results in a structured data format (JSON or Excel format) for the operations team to assess and release risks, and for the monitoring team to establish early warning indicators.

[0120] Regarding the automatic generation of regression test cases, the system automatically generates a list of suggested regression test cases based on the list of affected entities. For each affected entity node, the system matches the corresponding test case template from a pre-set test case template library.

[0121] Each template in the test case template library consists of three core fields: `template_id`, a unique identifier for the template used to index the corresponding set of pre-built test cases in the test management platform; `entity_type`, the entity type to which the template applies (including API, LogicFlow, Database, DataSet, and ESB); and `match_fields`, a list of matching parameter fields, declaring the list of affected entity standard attribute field names to be compared during template matching. For example, an API type interface test template declares `match_fields` as `http_method`, `request_path`, `parameters`, and `response_status`, which the system uses to retrieve pre-built test cases with bound parameters and identical parameter fields from the test management platform. The template also includes a `condition_rules` field, used to specify the set of test case IDs to be executed under specific change types (such as DELETE).

[0122] The system uses a two-stage full matching mode to complete template selection and obtain test case IDs.

[0123] The first stage is exact matching of entity types. Based on the `entity_type` field of the affected entity, the system searches the template library for a list of templates whose `template.entity_type` is equal to that type. If the search result is unique, that template is selected directly.

[0124] The second phase is API full parameter field matching (triggered only when entity_type is API and multiple candidate templates are matched in the first phase). The system extracts the complete set of standard parameter fields for the affected API entity, including http_method, request_path, parameters, response_status, etc., and compares them one by one with the match_fields fields of each candidate template, prioritizing the template with the most complete match_fields coverage of parameter fields. If multiple candidate templates with the same coverage still exist, the one with the smallest template_id in lexicographical order is selected. For other entity types such as LogicFlow, Database, and ESB, template matching achieves a unique match in the first phase.

[0125] After template matching is complete, the system obtains the set of test case IDs corresponding to the selected template. Based on the change type (add, modify, delete), it selects the corresponding list of case IDs from the condition_rules and executes the test directly by calling the corresponding case ID through the test management platform's open API. The execution parameters of the test cases are pre-bound to the case IDs in the test management platform, and no additional parameters need to be injected into this system.

[0126] Test case IDs and execution parameters are pre-bound in the test management platform. After template matching is complete, the system invokes test cases according to the following steps: First, obtain the case ID set: Query the corresponding pre-set test case list from the test management platform based on the selected template_id, and extract the case IDs of each test case. Second, filter by change type: Based on the current change type (add, modify, delete), find the matching case ID append list from condition_rules, merge the basic case ID set with the append list to form the complete set of case IDs required for this change. Third, batch API call: The system uses the test management platform's open API (e.g., REST API), with the affected entity's entity_type plus entity_name as the associated index field, to batch input the case ID list, triggering the execution of test cases. Fourth, monitor execution status: The system polls the test management platform's execution status query interface to obtain the execution results (including pass, fail, skip), execution time, and error logs for each case, and writes the results into the test execution results section of the change impact report for release reviewers to determine whether to approve the release.

[0127] Regarding the linkage of automated testing platforms, this invention designs a standardized linkage interface that directly drives the execution of automated tests and generates verification reports based on the results of change impact analysis.

[0128] This invention designs a three-level fault tolerance mechanism in the automated testing platform linkage call chain to ensure that the change impact analysis process can still be completed normally and output usable results when the testing platform is unavailable or some test cases are executed abnormally.

[0129] The first level is the API call retry strategy. When the system sends a batch trigger request for case IDs to the automated testing platform, if the platform returns a network timeout or an HTTP 5xx error, the system automatically retryes using an exponential backoff strategy, with a maximum of 3 retries and retry intervals of 2 seconds, 4 seconds, and 8 seconds respectively. If all 3 retries fail, the failure status of this call is recorded, and the system proceeds to the second level of degradation processing.

[0130] The second level is a partial failure isolation strategy. When some cases in the batch case ID list fail (for example, a single case ID has been archived or has restricted permissions on the platform side), the system adopts a failure isolation strategy: the failed case ID is removed from the current execution set, and the normal execution of the remaining cases continues; the failed case ID is recorded in the test execution anomaly list of the change impact report, with a failure reason code attached, for manual confirmation, so that the overall test task is not interrupted by the failure of individual cases.

[0131] The third level is the degraded output when the platform is completely unavailable. When the automated testing platform is completely unreachable (three consecutive API calls time out), the system does not block the generation of reports that affect changes. Instead, it outputs the report in degraded mode: the test execution results section is marked "Test platform is temporarily unavailable, it is recommended to manually trigger regression testing", and the complete set of case IDs is attached to the end of the report as a structured list (JSON format) for testers to manually import and execute in batches after the platform is restored.

[0132] The aforementioned three-level fault tolerance mechanism ensures the loose coupling dependency of the change impact analysis system on the external testing platform. Even if the testing platform fails, the availability of the main change impact analysis process remains unaffected, and the overall stability of the system meets the requirements of high-reliability production environments such as finance and government.

[0133] During automated test execution, the system collects test coverage data in real time through integrated code coverage tools (such as JaCoCo, Istanbul, and Coverage.py). These coverage tools use affected entities as entry points to statistically analyze the degree to which test cases cover the changed code paths. The coverage metrics collected by the system include: line coverage, branch coverage, and function or method coverage. Coverage data is sent back to the system along with the test execution results.

[0134] After receiving the execution results from the automated testing platform, the system integrates the change impact analysis and test verification results to generate a unified, one-stop impact analysis and verification report. The report includes the following core contents: Change Overview (including change entity information, change type, submitter, and submission time); Impact Analysis Results (including a precise list of affected nodes and dependency chain diagram, a list of semantic risk nodes and similarity scores, and impact scope statistics); Test Execution Results (including total number of test cases executed, number of passes, number of failures, number of skips, and execution time); Coverage Statistics (including overall coverage, change code coverage, and detailed coverage for each affected entity); Risk Rating and Recommendations (calculating the risk level based on the impact scope and test coverage, and providing release recommendations and supplementary testing suggestions).

[0135] Example 2 (System Example) This embodiment provides a low-code change impact analysis system, which is used to perform the method described in Embodiment 1.

[0136] like Figure 6 As shown, the system includes the following modules: The metadata collection module is used to collect a set of server-side service asset metadata files for the target application from the application asset export interface of version control systems or low-code platforms. This module interfaces with external data sources such as the CC system (Alliance Master Resource Manager) and code repositories, and pulls development task sheets and metadata files via REST API calls.

[0137] The semantic parsing module is used to perform structured semantic parsing on the metadata file based on a predefined schema template, extracting entity nodes and the dependencies between them. This module internally encapsulates a template adapter submodule and a rule engine, supports parsing XML, JSON, and YAML formats, and includes an anomaly classification and handling mechanism (missing fields, data type mismatches, multi-level nested references).

[0138] A dual-database storage module is used to store the entity nodes and their dependencies in a relational database to construct an accurate dependency graph, and to encode and store the multi-source semantic information of the entity nodes in a vector database to construct a semantic vector index. In this embodiment, the relational database uses PostgreSQL, the vector database uses the pgvector extension of PostgreSQL, and Elasticsearch is reserved as an optional vector storage solution.

[0139] The incremental update module is used to trigger incremental updates through version control system hooks or CI / CD pipelines, obtain a list of changed files, and drive the semantic parsing module to update the dual databases only after re-parseing the changed files. In this embodiment, the module includes a VCSpost-receive hook trigger, a CI / CD pipeline plugin, and a scheduled task compensation scheduler (executed by default at 10:00 and 16:00 daily).

[0140] The impact analysis module is used to execute recursive cascading queries in a relational database and semantic similarity retrieval in a vector database in parallel, starting from the change node, to generate a change impact report containing precise impact nodes and semantic risk nodes. This module calls the query interface provided by the dual database storage module to execute recursive CTE queries and ANN retrieval, and performs two-stage fine ranking (BM25 weighting + entity type filtering).

[0141] The test integration module is used to match the corresponding test case templates based on the affected entity nodes in the change impact report, call the pre-bound test case ID set in the test management platform, trigger the execution of regression test cases, and output the execution results. This module includes a template matching engine (two-phase matching: entity type matching + API full parameter field matching), a three-level fault tolerance submodule (retry, isolation, degradation), and a report generation submodule.

[0142] System architecture layering: The above modules can be divided into five layers during deployment: external data source layer, task collection and scheduling layer, core processing engine layer, data storage and AI access layer, and output push and consumption layer. Each layer communicates with the others through REST API or message queue.

[0143] The external data source layer includes the CC system, code repository, asset repository, and vector database. The CC system serves as a unified enterprise-level R&D resource management platform, integrating functional modules such as code repository management, development task tracking, and production batch scheduling.

[0144] The task acquisition and scheduling layer includes a production date selection module, a CC task order retrieval module, a task classification and routing module, and a scheduled task scheduler. Release control personnel select the target production date through the front-end interface. The system then initiates a REST API call to the CC system based on the selected date, retrieving a set of all development task orders planned for production that day. Development task orders are automatically routed to two parallel processing branches based on change type: a regular code change analysis branch (handling development tasks involving changes to low-code logic flow XML files) and a database change analysis branch (handling database change orders involving changes to SQL scripts).

[0145] The core processing engine layer includes a regular code change analysis engine and a database change analysis engine. The regular code change analysis engine performs the following operations: it structurally splits the XML file containing the logic flow involved in the change according to a predefined template, extracting key information fields (including unique identifiers for the logic flow, logic flow names, subsystem identifiers, interface path mappings, a list of called relationships, SQL resource reference identifiers, message queue interface references, and a list of component references); it sends the extracted key information to the asset repository service module in the form of a structured JSON message; the asset repository service module queries pre-stored hierarchical relationship data, recursively traces back the complete impact chain of the change's logic flow, analyzes and determines the entire set of interfaces, logic flows, SQL resource identifiers, message queue interfaces, and components affected by the change, and returns the analysis results in a standardized JSON response message.

[0146] The data storage and AI access layer includes a PostgreSQL relational database, an Elasticsearch vector database, a reserved interface for large AI models, and local file storage. The PostgreSQL relational database stores the main storage table, the logical flow main table, and various intermediate dependency tables. The Elasticsearch vector database stores the semantic vectors and supplementary fields of multi-source concatenated text. The reserved interface for large AI models is for future integration of intelligent change impact analysis capabilities.

[0147] The output push and consumption layer includes modules for pushing data to the security testing group, pushing attachments to regular test task sheets, pushing attachments to database change orders, and retrieving Excel reports from the release control group. The system extracts corresponding field data from JSON messages based on pre-configured dimension rules for each group, organizes it by group, and pre-stores it in the memory cache. The security testing group pushes the change impact analysis file in Excel format to the entire security testing group via the enterprise communication platform's group robot interface. The regular testing group uploads the analysis file as an attachment to the attachment list of each development task sheet via the CC system's open API. The SQL analysis conclusion document generated by the database change analysis branch is uploaded to the attachment area of ​​the corresponding database change order via the CC system's open API.

[0148] The database change analysis branch performs the following operations: The system extracts the SQL script to be executed from the database change order and calls the SQL parser to perform a comprehensive analysis of the script. The SQL parser performs lexical and syntactic analysis on the SQL statements, generates an abstract syntax tree, and performs analysis based on the abstract syntax tree in the following five dimensions.

[0149] The first step is semantic interpretation. The parser traverses the nodes of the abstract syntax tree, infers the business semantics of the SQL statement based on the SQL operation type (including SELECT, INSERT, UPDATE, DELETE, ALTER, CREATE, DROP) and the operation object, and outputs a semantic description according to a pre-configured text template.

[0150] The second step is key field extraction. This involves precisely extracting the SQL operation type, the set of affected table names, the set of modified field names (for UPDATE and ALTER statements), and field references in conditional expressions from the abstract syntax tree.

[0151] The third step is business impact analysis. Based on the extracted affected table and field names, the mapping relationship between the SQL resource identifiers defined in the application and the business logic flow is obtained by requesting the asset database query module. By analyzing which logic flows reference the affected SQL identifiers, the scope of the impact of this database change on the upper-layer business function modules can be inferred.

[0152] The fourth step is table relationship impact analysis. The system further analyzes the relationships between the affected table and other tables in the database, including foreign key dependencies, trigger references, stored procedure calls, and view definition references, identifying all other tables and their associated fields that are directly or indirectly related to the affected table.

[0153] The fifth step is SQL compliance analysis. The parser performs compliance checks on the SQL scripts according to the company's predefined SQL coding standards, detecting any non-compliant usage, including but not limited to: full table scans of large tables without using indexes, implicit type conversions, SELECT wildcard queries, UPDATE and DELETE statements without WHERE conditions, and batch operations lacking transaction control. Non-compliant SQL statements will be marked and recorded, and included in the compliance check section of the analysis report.

[0154] The analysis results from the above five dimensions are organized and stored according to preset data structure rules, forming a complete SQL analysis detail record. The system stores the SQL analysis details in an Elasticsearch vector database according to a structured data model. Each SQL analysis record contains the following core fields: change order number, SQL operation type, list of affected table names, list of modified fields, semantic explanation text, list of related logical flows, list of related functional modules, table association analysis results, and standardization check results. This structured storage is designed to provide standardized input data for subsequent integration with large AI models for intelligent change analysis.

[0155] The system generates an SQL analysis conclusion document from the SQL analysis data temporarily stored in memory according to a pre-configured template. The template content structure includes: a change overview (including change order number, person making the change, and change time), SQL semantic description, a list of affected tables and fields, business impact analysis (including affected logical flow and functional modules), table relationship impact analysis, SQL standardization check results, and risk assessment recommendations. After the analysis conclusion document is generated in Excel format, it is uploaded to the attachment area of ​​the corresponding database change order via the CC system's open API.

[0156] Example 3 (Production Application Example in Financial Scenarios) This embodiment uses the production application practice of a low-code development platform of a financial institution as an example to specifically explain the overall business process, dual-branch parallel analysis mechanism, group push strategy, and historical data statistics function of the system. In this embodiment, the low-code platform adopts an implementation based on the Flowable process engine and a self-developed metadata-driven architecture. The logic flow definition file is stored in XML format and follows the platform's custom LogicFlowSchema specification. The system connects to the Alliance General Resource Manager (hereinafter referred to as the CC system). The CC system, as an enterprise-level unified management platform for R&D resources, integrates functional modules such as code repository management, development task tracking (including development tasks, additional rollback tasks, and requirement orders), and production batch scheduling.

[0157] I. Overall Business Process Release control personnel select the target production date through the front-end interface. The system then initiates a REST API call to the CC system based on the selected date, retrieving a set of all development task orders planned for production that day. These development task orders are automatically routed to two parallel processing branches based on their change type: a regular code change analysis branch (handling development tasks involving changes to low-code logic flow XML files) and a database change analysis branch (handling database change orders involving changes to SQL scripts). The analysis results from both branches are pushed to their respective test groups. Simultaneously, the system periodically executes historical data statistics tasks, providing the release control team with change trend analysis reports for key interfaces.

[0158] II. Analysis of Common Code Changes When the development task sheet returned by the CC system involves changes to the low-code logic flow XML file, the system automatically routes such tasks to the regular code change analysis branch. This branch is suitable for non-database code-level change scenarios, covering operation types such as adding, modifying, and deleting in the low-code platform logic flow.

[0159] Since this embodiment is based on a low-code development platform, the change files are not traditional Java source code files, but rather low-code logic flow XML configuration files. The system first structurally splits the logic flow XML files involved in this change according to a predefined template, extracting the following key information fields: unique identifier for the logic flow, logic flow name, subsystem identifier, interface path mapping, list of called relationships, SQL resource reference identifier, message queue interface reference, and component reference list. This key information is output in the form of a structured JSON message as input parameters for asset repository hierarchical dependency analysis.

[0160] The system sends the JSON message to the asset repository service module. As the metadata center of the low-code platform, the asset repository records the following hierarchical association information during the creation and each change of a logical flow: the sub-logical flow hierarchy to which the current logical flow belongs, the complete call chain invoked by the upper-level logical flow, the exposed HTTP interface path and access method, and the business function module identifier mapped to this logical flow. Upon receiving the key change information, the asset repository recursively traces the complete impact chain of the changed logical flow by querying the pre-stored hierarchical association data. It analyzes and determines the entire set of interfaces, logical flows, SQL resource identifiers, message queue interfaces, and components affected by this change, and returns the analysis results to the change impact analysis tool in a standardized JSON response message.

[0161] After receiving the JSON response message from the asset repository, the change impact analysis tool invokes the multi-dimensional grouping analysis engine to filter and reorganize the impact data. This engine supports differentiated data extraction and grouped storage based on the business dimensions that different test groups focus on.

[0162] Each test group can customize the analysis dimensions they focus on through the front-end configuration interface. The security test group, focusing on the integrity verification of system security-related functions, has relatively fewer dimensions to consider, primarily including functional dimensions (such as whether key business functions like user login, fund transfers, and logout are affected) and security component dimensions (such as whether security-related components like cross-validation components, encryption / decryption components, and authentication components have changed). The regular test group needs to cover a broader verification scope, configuring all dimensions to focus on, including: interface dimensions (a list of affected API interfaces), functional dimensions (affected business function modules), logic flow dimensions (affected logic flow call chains), SQL resource dimensions (affected SQL query identifiers), message queue dimensions (a list of affected MQ interfaces), and component dimensions (a list of affected general components).

[0163] The analysis engine extracts corresponding field data from the JSON message according to the pre-configured dimensional rules for each group, organizes it by group, and stores it in the memory cache to prepare for the subsequent generation and push of Excel files. At the same time, the system stores the complete analysis data structure after grouping into the ES vector database, providing standardized data input for subsequent integration with AI large-scale models for intelligent change impact analysis.

[0164] The push mechanism for the security testing team is designed to identify development tasks that have been missed in their security testing. In actual production workflows, developers are required to check whether security testing is needed when submitting development task orders, but there are instances where this is missed due to human error. The system generates a change impact analysis file in Excel format based on the dimensions configured by the security testing team, and pushes it to the entire security testing team group via the enterprise communication platform's group robot interface, allowing security testers to review and verify daily for any omissions.

[0165] The push mechanism for regular testing groups is more direct. Since regular testers need to test and verify each development task, the system generates a change impact analysis file in Excel format based on all dimensions configured for the regular testing group. This analysis file is uploaded as an attachment to the attachment list of each development task through the CC system's open API, displayed alongside design and test documents. Each tester can directly download this analysis file when viewing their assigned development task, and use it to formulate targeted testing strategies and verification scope.

[0166] III. Database Change Analysis Branch When the development task order returned by the CC system includes a database change order (i.e., a task order with an attached SQL script), the system automatically routes such tasks to the database change analysis branch. This branch specifically handles database table structure change operations, covering scenarios such as adding data, modifying fields, and changing indexes.

[0167] The system first extracts the SQL script to be executed from the database change order, and then calls the SQL parser to perform a comprehensive analysis of the script. The SQL parser performs lexical and syntactic analysis on the SQL statements, generates an abstract syntax tree, and performs analysis based on the abstract syntax tree in the following five dimensions.

[0168] In terms of semantic interpretation, the parser traverses the nodes of the abstract syntax tree, infers the business semantics of the SQL statement based on the SQL operation type and the operation object, and outputs a semantic description according to a pre-configured text template. For example, for the UPDATE statement, the template output format is "Update records in a certain table that meet a certain condition, and modify the value of a certain field list to a new value".

[0169] In terms of key field extraction, the SQL operation type (operation categories include query, insert, modify, delete, and structure change), the set of affected table names, the set of modified field names (for UPDATE and ALTER statements), and field references in conditional expressions are precisely extracted from the abstract syntax tree.

[0170] In terms of business impact analysis, based on the extracted affected table and field names, the mapping relationship between the SQL resource identifiers defined in the application and the business logic flow is obtained by requesting the asset database query module. By analyzing which logic flows reference the affected SQL identifiers, the scope of the impact of this database change on the upper-layer business function modules can be inferred.

[0171] In terms of table association impact analysis, the system further analyzes the association relationships between the affected table and other tables in the database, including foreign key dependencies, trigger references, stored procedure calls, and view definition references, and identifies all other tables and their associated fields that are directly or indirectly related to the affected table.

[0172] In terms of SQL compliance analysis, the parser performs compliance checks on SQL scripts according to the company's predefined SQL coding standards, detecting any non-compliant usage. Non-compliant SQL statements are marked and recorded, and included in the compliance check section of the analysis report.

[0173] The analysis results from the above five dimensions are organized and stored according to preset data structure rules to form a complete SQL analysis detail record. The system stores the SQL analysis details in an Elasticsearch vector database according to a structured data model. Each SQL analysis record contains the following core fields: change order number, SQL operation type, list of affected table names, list of modified fields, semantic explanation text, list of related logical flows, list of related functional modules, table association analysis results, and standardization check results.

[0174] The system generates an SQL analysis conclusion document from the SQL analysis data temporarily stored in memory according to a pre-configured template. This document, generated in Excel format, is uploaded to the attachment area of ​​the corresponding database change order via the CC system's open API, displayed alongside the database change plan document for testers to reference before performing database change tests.

[0175] IV. Historical Data Statistics and Release Control In addition to the two parallel analysis branches mentioned above, this system also provides a historical data statistics module, which provides the release control group with the ability to analyze the change trends of key interfaces and key logic flows.

[0176] The system periodically pulls historical change record data from the local relational database and Elasticsearch vector database, and performs aggregation and statistics according to a predefined time window (defaulting to the production batch date dimension). The collected data fields include: interface identifier, logical flow identifier, number of changes, most recent change time, and a list of change development order numbers.

[0177] The statistics engine performs the following statistical analyses on each key interface and key logic flow: cumulative change count statistics (total number of changes since the system went live), recent change frequency calculation (number of changes and frequency trends in the last 30 days or the last 90 days), change time distribution analysis (change heat distribution by week or month), and generation of change development order number list (complete list of all associated development task order numbers).

[0178] The statistical results are output in Excel report format, with the report file named ChangeStats_yearmonthdayhourminutesecond.xlsx. The report content includes: interface or logical flow name, cumulative number of changes, most recent change date, number of changes in the last 30 days, number of changes in the last 90 days, list of change development order numbers, and risk assessment flags (automatically marked as high risk when the change frequency exceeds a threshold). The system uses a scheduled task to store the generated Excel report file in a shared directory on a specified file server.

[0179] Release control team members regularly (usually before each production batch review) log into the file server's shared directory to download the latest change statistics report. By analyzing the change frequency trends of key interfaces in the report, they identify interfaces or logic flows that have been frequently changed recently, and trace the root causes of these frequent changes (e.g., whether there are program quality issues in the corresponding module, whether there are design flaws leading to repeated modifications, or whether there are non-standard development processes). Based on the analysis results, the release control team can take targeted measures: increase additional regression testing resources for high-risk interfaces, arrange special code reviews for frequently changed modules, and issue quality warnings to relevant development teams.

[0180] Example 4 (Performance Comparison of Incremental Updates) This embodiment uses actual deployment data from an enterprise-level low-code platform to compare and illustrate the performance of the incremental update mechanism and the full reconstruction scheme of the present invention.

[0181] The low-code platform service asset repository contains 15,000 metadata files, including approximately 3,000 API definition files, 6,000 LogicFlow definition files, 2,000 Database definition files, 2,500 DataSet definition files, and 1,500 ESB definition files. In a typical PullRequest change scenario, developers modified two LogicFlow files, added one DataSet file, and deleted one API file, for a total of four changed files.

[0182] Under the full reconstruction scheme, the system needs to traverse all 15,000 metadata files, sequentially performing file reading, schema parsing, entity extraction, dependency extraction, relational database writing, and vector database writing. Actual testing showed that the average time for a full reconstruction was approximately 280 seconds.

[0183] Under the incremental update scheme of this invention, the system obtains a set of difference files (4 files in total) through the VCS hook, and only re-executes schema semantic parsing and dependency extraction on these 4 files. Relational databases perform insert, update, or delete operations based on the primary key index, while vector databases perform local vector updates. Actual testing shows that the average time for incremental updates is approximately 1.8 seconds.

[0184] The comparison shows that the incremental update mechanism of this invention reduces graph maintenance time from minutes to seconds in typical development scenarios, improving performance by approximately two orders of magnitude. Furthermore, since incremental updates only operate on asset nodes and dependent edges directly related to the changed files, they do not involve read / write operations on the other 15,000 asset nodes in the database, effectively avoiding excessive load on the production environment database.

[0185] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art can make various improvements and modifications without departing from the spirit and principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

[0186] In particular, the method steps described in this invention can be performed in different orders without departing from the core idea of ​​this invention. The system modules of this invention can be merged, split, or reorganized according to actual deployment needs, as long as they achieve the same function, they should be considered to fall within the protection scope of this invention. All equivalent modifications that can be made by those skilled in the art based on the technical solutions disclosed in this invention are within the scope of protection intended by this invention.

Claims

1. A method for analyzing the impact of low-code changes, characterized in that, Includes the following steps: Collect the set of server-side service asset metadata files of the target application; The metadata file is subjected to structured semantic parsing based on a predefined schema template, entity nodes and the dependencies between entity nodes are extracted, and the results are output as standardized triples. The entity nodes and dependency triples are stored in a structured persistent storage unit to construct an accurate dependency graph. At the same time, the multi-source semantic information of the entity nodes is encoded into semantic vectors by a text vectorization encoding unit and stored in a vector index storage unit to construct a semantic vector index. Starting with the changed node, the recursive cascade query of the relational database and the semantic similarity retrieval of the vector database are executed in parallel. The recursive cascade query obtains the directly and indirectly dependent nodes to form a set of precisely affected nodes. The semantic similarity retrieval obtains a set of semantically similar candidate nodes and marks the nodes not covered by the set of precisely affected nodes as semantic risk nodes. Merge the precise set of impact nodes with the semantic risk nodes to generate a change impact report.

2. The method for analyzing the impact of low-code changes according to claim 1, characterized in that, The method also includes an incremental update mechanism: incremental updates are triggered through version control system hooks or CI / CD pipelines to obtain a list of changed files, compare the change history table to determine the set of differing files, re-execute the structured semantic parsing only on the changed files, and perform local update operations on the relational database and vector database; at the same time, a scheduled task is set as a compensation mechanism.

3. The method for analyzing the impact of low-code changes according to claim 1, characterized in that, The method also includes an automatic regression test case generation step: matching the corresponding test case template according to the affected entity nodes in the change impact report, obtaining the pre-bound test case identifier set according to the selected template, and calling the case identifiers in batches through the application programming interface of the test management platform to trigger the execution of regression test cases; the linkage call chain is equipped with a fault tolerance mechanism, including request retry, partial failure isolation, and degradation output when the platform is unavailable.

4. A method for analyzing the impact of low-code changes according to any one of claims 1-3, characterized in that, Structured semantic parsing includes: determining the format of the metadata file to be parsed, loading the corresponding parsing plugin based on the recognition results, parsing the content of different file formats into a unified structure object and passing it to the rule engine to extract reference relationships; handling exceptions encountered during the parsing process according to their types: for field missing exceptions, the parsing continues or is marked as incomplete based on the required field attributes; for data type mismatch exceptions, type conversion or stringification is performed; for multi-level nested reference exceptions, unresolved references are written to a buffer table for later completion.

5. A method for analyzing the impact of low-code changes according to any one of claims 1-3, characterized in that, Multi-source semantic information includes original source code fragments, code comments, interface documentation, and multi-source concatenated text formed by concatenating the above information in priority order; the multi-source concatenated text serves as the input source of the text embedding model and is encoded to generate the main semantic vector, while the original source code, code comments, and interface documentation are stored as supplementary fields for fine-grained reordering and interpretability display of retrieval results.

6. The method for analyzing the impact of low-code changes according to claim 5, characterized in that, After semantic similarity retrieval returns candidate nodes, a multi-stage fine ranking is performed: an additional score is calculated based on the textual relevance of the supplementary fields and the changed nodes, the additional score is weighted and merged with the vector similarity score, and consistency filtering is performed according to the entity type to output the final list of semantic risk nodes.

7. The method for analyzing the impact of low-code changes according to claim 5, characterized in that, In semantic similarity retrieval, after multiple stages of fine ranking of the candidate nodes returned by near nearest neighbor retrieval, nodes not covered by the precisely affected node set are marked as semantic risk nodes, and the semantic original text in the supplementary field of the change impact report serves as the interpretability basis for semantic risk nodes.

8. The method for analyzing the impact of low-code changes according to claim 3, characterized in that, When matching the corresponding test case template: First, retrieve the candidate template list based on the entity type; when multiple candidate templates exist, further compare the entity parameter field set with the matching fields declared in the template, and select the template with the highest coverage.

9. The method for analyzing the impact of low-code changes according to claim 3, characterized in that, The degradation output includes: when the test management platform fails to be called continuously, marking the test platform as temporarily unavailable in the change impact report, and attaching a complete set of case identifiers as a structured list at the end of the report for manual import and execution after the platform is restored.

10. A low-code change impact analysis system, characterized in that, The system includes: The metadata collection module is used to collect a set of server-side service asset metadata files of the target application from the application asset export interface of the version control system or low-code platform. The semantic parsing module is used to perform structured semantic parsing on the metadata file based on a predefined schema template, and to extract entity nodes and the dependencies between entity nodes; A dual-database storage module is used to store the entity nodes and their dependencies in a relational database to construct an accurate dependency graph, and to encode and store the multi-source semantic information of the entity nodes in a vector database to construct a semantic vector index. The impact analysis module is used to perform recursive cascading queries in relational databases and semantic similarity retrieval in vector databases in parallel, starting from the change nodes, to generate a change impact report that includes precise impact nodes and semantic risk nodes. The incremental update module is used to trigger incremental updates through version control system hooks or CI / CD pipelines, obtain a list of changed files, and drive the semantic parsing module to update the dual databases only after re-parseing the changed files. The test integration module is used to match the corresponding test case templates according to the affected entity nodes in the change impact report, call the pre-bound test case ID set in the test management platform, trigger the execution of regression test cases, and output the execution results.

Images