Component dependency checking method, device, equipment and medium

Abstract

Embodiments of the present application disclose a component dependency checking method and device, equipment and a medium, wherein the method realizes comprehensive, flexible and accurate automatic checking of risk decision business component dependency relationship by means of configurable acquisition and graph model construction, combined with a configurable rule engine and result display, improves checking dimension, identifies complex abnormalities, reduces maintenance cost, and provides a clear panoramic view and friendly prompts.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer technology, and in particular to a component-dependent verification method, apparatus, device, and medium. Background Technology

[0002] In modern risk decision-making systems, especially in areas like financial risk control, the implementation of business functions relies on the collaborative operation of numerous decision-making components. These components form complex dependencies through association and reference; for example, the rule set component references data from the system field component, and the scorecard component calls the calculation results from the real-time indicator component. To ensure the stable operation of the risk decision-making system and the accuracy of the decision results, effective verification of the dependencies between business components is crucial.

[0003] Existing technologies typically utilize native database constraints to define and validate dependencies between data. By establishing key-value relationships between relevant data tables of risk decision-making business components, the underlying database automatically enforces dependency validation during data writes or updates, ensuring that the dependent component data must exist and the relationships are valid. However, this approach can only validate basic dependencies such as data existence at the database table structure level and cannot cover complex relationships at the business logic level, such as dependencies related to component online / offline status and version compatibility. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one component-dependent verification method, apparatus, device, and medium.

[0005] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide a method for verifying component dependencies, the method comprising: Configure the data collection attributes, data collection trigger events, and data verification rules for each business component; At key nodes throughout the entire lifecycle of the business component, based on the collection attributes, the collection trigger events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table. The structured data in the component information table and the component relationship table are transformed into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component. The preset set of verification rules is loaded according to the business scenario, and the directed graph model is used to perform multi-dimensional dependency verification on the business component corresponding to the business scenario to obtain the dependency verification result. The dependency verification results are displayed in the form of structured error messages. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

[0006] On the other hand, embodiments of this application provide a component-dependent verification device, the method comprising: The processing module is used to configure the collection attributes, collection trigger events, and data verification rules corresponding to each business component; At key nodes throughout the entire lifecycle of the business component, based on the collection attributes, the collection trigger events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table. The structured data in the component information table and the component relationship table are transformed into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component. The verification module is used to load a preset set of verification rules according to the business scenario, and use the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario, so as to obtain the dependency verification result. The dependency verification results are displayed in the form of structured error messages. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the program to implement some or all of the steps in the verification method on which the above-mentioned components depend.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the verification method upon which the aforementioned components depend.

[0009] In another aspect, embodiments of this application provide a computer program including computer-readable code, wherein when the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps in the verification method for implementing the aforementioned component-dependent method.

[0010] In another aspect, embodiments of this application provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, wherein when the computer program is read and executed by a computer, it implements some or all of the steps in the verification method on which the above-mentioned components depend.

[0011] This application embodiment achieves comprehensive, flexible, and accurate automated verification of the dependencies of risk decision-making business components through configurable data collection and graph model construction, combined with a configurable rule engine and result display. This improves the verification dimensions, identifies complex anomalies, reduces maintenance costs, and provides a clear panoramic view and user-friendly prompts.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 A schematic diagram illustrating the implementation process of a component dependency verification method provided in this application embodiment; Figure 2 This application provides an architectural diagram of a component-dependent verification system. Figure 3 A schematic diagram of the composition structure of a component-dependent verification device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] The terms “first / second / third” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first / second / third” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0019] This application provides a component-dependent verification method, which can be executed by the processor of a computer device. The computer device can refer to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other similar computer equipment. Figure 1 This is a schematic diagram illustrating the implementation process of a component dependency verification method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: Configure the collection attributes, collection trigger events, and data verification rules corresponding to each business component.

[0020] In this embodiment, a business component is a module or unit with independent domain functionality within a risk decision-making business system, such as a system field component, real-time indicator component, rule set component, or scorecard component in the financial risk control field. Collection attributes are specific data fields that need to be extracted from the business component, such as rule set name, version number, and status. Collection trigger events are business events that initiate data collection operations, such as component creation, editing, and status changes. Data validation rules are logical conditions used to verify whether the collected data conforms to a predetermined format or constraints; for example, the version number format must conform to the semantic versioning specification.

[0021] The system first defines the data collection specifications for each type of business component. Through a configuration management module, the system configures a list of attributes to be collected for each business component type, such as rule sets or scorecards. Simultaneously, the system specifies which business events trigger the collection operation for each component type, such as when the component is created, edited, or its state changes. Furthermore, the system configures corresponding data validation rules for each collected attribute to ensure the quality of the collected data. This configuration information is persistently stored in a dedicated configuration table and can be dynamically modified through the management interface without requiring a system restart or code modification.

[0022] Step 102: At key nodes throughout the entire lifecycle of the business component, collect the attribute information of the business component and the association and reference relationship information between the business components according to the collection attributes, the collection triggering events and the data verification rules, and write the attribute information into the component information table and the association and reference relationship information into the component relationship table.

[0023] In this embodiment, the key lifecycle nodes are a series of important state changes or operation points during the creation and destruction of a business component, such as creation, editing, going online, going offline, and deletion. Attribute information is data describing the characteristics of the business component itself, such as component ID, name, type, status, and version number. Association and reference relationship information describes data describing how one business component references another, including the source component, target component, and dependency type. The component information table is a database table used to store the attribute information of all business components. The component relationship table is a database table used to store the association and reference relationship information between all business components.

[0024] The system deploys generic data collection functions at key nodes throughout the lifecycle of business components. When a pre-defined collection trigger event occurs, such as when a rule set component is edited, the system invokes the corresponding collection function. This function dynamically extracts the specified attribute values ​​from the component object instance using reflection, based on the collection attribute list configured for the component type in step 101. During extraction, the system immediately applies the configured data validation rules to verify the data. Simultaneously, the system parses the current component object to identify which other business components it references, thereby generating association and reference relationship information. After collection is complete, the system writes the validated component attribute information to the component information table and the parsed association and reference relationship information to the component relationship table, thus completing the collection and storage of dependency relationship data.

[0025] Step 103: Convert the structured data in the component information table and the component relationship table into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component.

[0026] In this embodiment, structured data is data organized according to a predefined model, typically stored in database tables, and has fixed fields and types. A directed graph model is a mathematical model that uses nodes and directed edges to represent entities and their relationships. Nodes in a graph model represent entities. Directed edges in a graph model represent unidirectional relationships from one entity to another.

[0027] The system reads the data stored in the component information table and component relationship table, and constructs a global dependency graph model based on this data. During the construction process, the system maps each business component record in the component information table to an independent node in the graph model, with each node containing the core attributes of that component. Simultaneously, the system maps each associated reference record in the component relationship table to a directed edge in the graph model. The starting point of this edge is the node corresponding to the source business component (the referrer), and the ending point is the node corresponding to the target business component (the referenced component). Through this mapping, the system transforms the tabular dependency data in the database into an in-memory graph structure that facilitates graph theory operations such as path traversal and cycle detection.

[0028] Step 104: Load the preset verification rule set according to the business scenario, and use the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario to obtain the dependency verification result.

[0029] In this embodiment, the business scenario refers to the specific business operation context in which dependency verification needs to be performed, such as component deployment, component decommissioning, and circular dependency detection. The verification rule set is a collection of predefined verification logics for a specific business scenario. Multi-dimensional dependency verification checks the legality, completeness, and validity of dependencies from multiple perspectives, such as checking whether the dependent component exists, whether its state is compliant, and whether its attributes are compatible.

[0030] When dependency validation is required, such as when a user requests to deploy a rule set component, the system first loads the corresponding preset validation rule set based on the current business scenario. The system uses the directed graph model constructed in step 103 as the data foundation to perform validation. For example, for deployment validation, the system starts from the node corresponding to the component to be deployed and traverses all nodes that it directly or indirectly depends on along the directed edges. For each dependent component node traversed, the system checks its existence, online status, and whether extended attributes such as version meet compatibility requirements, according to the validation rule set. The system integrates the results of all checks to generate a final dependency validation result, indicating whether the validation passed or failed, and records the specific exception information.

[0031] Step 105: Display the dependency verification results in the form of structured error information. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

[0032] In this embodiment, the dependency verification result is conclusive data generated after the verification in step 104, including whether the verification passed and specific exception details. Structured error information is error message data organized according to a predetermined format, containing fields such as explicit error codes, descriptions, and associated component identifiers. The column display items in the list are the data content displayed in each column of the result list. The sorting rule is the order in which the data rows in the result list are arranged. The jump logic is the rule by which the system jumps to a page or performs an operation when a user clicks on an item in the result list. The parameters of the Structured Query Language format are configuration parameters used to dynamically define the data query and display logic.

[0033] After receiving the dependency validation results, the system needs to display the results, especially detailed information when validation fails, to the user. The system encapsulates the validation results into a structured error message object. The display module receives this object and renders the result list based on a set of dynamically defined configuration parameters. These configuration parameters use an SQL-like format, allowing administrators to dynamically define which columns are displayed in the result list, the sorting rules, and which business component's details page a user is redirected to when clicking on a row. The system parses these configuration parameters and generates the final user interface accordingly, thus achieving flexible and configurable display of validation results and improving the user-friendliness and maintainability of the prompts.

[0034] This application embodiment achieves comprehensive, flexible, and accurate automated verification of the dependencies of risk decision-making business components through configurable data collection and graph model construction, combined with a configurable rule engine and result display. This improves the verification dimensions, identifies complex anomalies, reduces maintenance costs, and provides a clear panoramic view and user-friendly prompts.

[0035] Optionally, step 101 includes: Step 1011: Create a data acquisition configuration table, which includes a configuration identifier field, a component type field, a data acquisition attribute list field, a data acquisition trigger event field, a data verification rule field, and an update frequency field.

[0036] In this embodiment, the data collection configuration table is a data table used to store data collection rules, defining how the system collects related reference information from various business components. The configuration identifier field uniquely identifies each data collection configuration record. The component type field specifies the type of business component to which the data collection configuration applies, such as a system field, real-time metric, rule set, or scorecard. The data collection attribute list field defines the specific set of attribute names to be collected from a specified type of business component, such as rule set name, version number, and status. The data collection trigger event field specifies the business event that triggers the data collection operation, such as component creation, editing, deletion, or status change. The data validation rule field defines the rules for validating the format or content of the collected attribute values, such as checking if the version number conforms to a specific specification. The update frequency field specifies the frequency of data collection task execution, such as real-time collection or timed supplementary collection.

[0037] The system first creates a data table named "Collection Configuration Table" in the database. This table contains several predefined fields. These fields include: a configuration identifier field to provide a unique identifier for each configuration rule; a component type field to associate it with a specific business component type; a collection attribute list field to list the attributes to be extracted from that type of component; a collection trigger event field to specify the business event that triggers the collection action; a data validation rule field to set the validation criteria for the collected data; and an update frequency field to control the execution rhythm of the collection task. By establishing this table, the system lays the data foundation for subsequent configurable and dynamic information collection, enabling collection rules to be freed from hard-coded rules and achieve centralized management and flexible adjustment.

[0038] Step 1012: Configure the corresponding collection attribute list, collection trigger event, data verification rule and update frequency for each component type of the business component.

[0039] In this embodiment, a business component refers to a module or unit with independent domain functions in the risk decision-making business system, such as a system field component, a real-time indicator component, a rule set component, or a scorecard component. The component type is a classification identifier for business components, used to distinguish components with different functions.

[0040] Based on the different component types existing in the risk decision-making business system, the system inserts or initializes configuration records one by one in the created data collection configuration table. For each component type, such as a rule set, the system configures a specific list of collection attributes, specifying which attributes of the rule set need to be collected; configures a set of collection trigger events, specifying when collection is triggered when the rule set is created, edited, or its status changes; configures corresponding data verification rules, such as verifying the format of the version number; and configures the update frequency, deciding whether to respond to events in real time or execute on a timed basis. This process completes the initialization of the collection rules, ensuring that each type of component has a matching, standardized information collection and verification scheme.

[0041] Step 1013: Dynamically add or modify the collection attribute list, collection trigger event, and data verification rule in the collection configuration table through a visual management interface or configuration file, and make the modified collection attribute list, collection trigger event, and data verification rule take effect immediately without restarting the system.

[0042] In this embodiment, the visual management interface is a graphical user interface that allows administrators to manage system configurations through clicking, selecting, and inputting. A configuration file is a file that stores system parameters and rules in a specific format, such as a YAML or JSON file, for the system to read during startup or runtime.

[0043] The system provides two methods for administrators to maintain data collection configurations. Administrators can access a dedicated visual management interface to add, edit, or delete records in the data collection configuration table, such as adding configurations for new component types or modifying the collection attributes of existing component types. Alternatively, administrators can update these rules by editing external configuration files. When configuration changes occur, the system can monitor these changes in real time and dynamically load the new configuration information into memory. This ensures that the updated collection attribute list, trigger events, and validation rules can be immediately applied to subsequent data collection processes without interrupting system services or requiring a restart, thus guaranteeing high availability and business continuity.

[0044] This application embodiment creates and maintains a centralized, configurable collection rule table, and predefines and dynamically adjusts the information collection, triggering, and verification rules for each type of business component. This decouples the collection logic from the core business code, achieving the effect of flexibly adapting to business changes and reducing maintenance costs. At the same time, by supporting dynamic activation, it ensures the stability and responsiveness of the system during rapid business iteration.

[0045] Optionally, step 102 includes: Step 1021: Embed a general acquisition function at the creation node, editing node, deletion node and status change node of the business component. The general acquisition function is decoupled from the business logic of the business component and takes the business component object as the input parameter.

[0046] In this embodiment, a business component is a module or unit with independent domain functions in the risk decision-making business system, such as a system field component, a real-time indicator component, a rule set component, and a scorecard component; a general collection function is a standardized program function that is separated from specific business logic and used to collect component information; a creation node is the time point when a business component is initially generated; an edit node is the time point when a business component is modified; a deletion node is the time point when a business component is removed; a status change node is the time point when the running status of a business component changes, such as changing from offline to online; a business component object is a data structure that represents a specific business component instance and contains all the attributes and status information of the component.

[0047] The system pre-sets and invokes a generic data collection function at key lifecycle nodes of business components—namely, creation, editing, deletion, and state changes. This function is designed independently of the specific processing logic of each business component; it doesn't concern itself with how the component internally implements creation or editing, but only receives an object representing that business component as input. In this way, the system decouples data collection functionality from core business functions, ensuring standardization and uniformity in the collection process and laying a structural foundation for subsequent information gathering.

[0048] Step 1022: Read the collection attribute list corresponding to the component type of the business component in the collection configuration table through reflection mechanism, and dynamically extract the specified attribute values ​​from the collection attribute list from the business component object to obtain the attribute information.

[0049] In this embodiment, reflection is the ability of a program to inspect its own structure, such as classes, methods, and properties, and to dynamically invoke object properties and methods at runtime; the collection configuration table is a data table that stores information collection rules corresponding to different component types; the component type is a classification identifier used to distinguish different types of business components, such as system fields, real-time metrics, and rule sets; the collection attribute list is a predefined set of attribute names that need to be collected for a specific component type; and attribute information is a set of attribute values ​​extracted from business component objects that meet the requirements of the collection attribute list.

[0050] When the system executes the general data collection function, it utilizes reflection for dynamic operations. First, the system queries the data collection configuration table based on the component type of the currently processed business component object, finds the configuration record matching that type, and reads the predefined list of data collection attributes from it. Then, using reflection, the system can search for and extract the corresponding attribute values ​​from the passed-in business component object one by one, without hard-coding attribute names in the code, based on this attribute list. This process dynamically completes the capture of target information, and finally organizes these extracted values ​​into structured attribute information.

[0051] Step 1023: Perform format verification and missing data verification on the attribute information according to the data verification rules, and return a standardized error message when the verification fails.

[0052] In this embodiment, the data validation rules are a predefined set of logical conditions used to determine whether data conforms to a specific format and is complete and valid; format validation checks whether the data value conforms to a predetermined structure or pattern, such as whether the version number conforms to the semantic version specification; missing data validation checks whether necessary data items have null values ​​or are not provided; standardized error messages are system-defined error information feedback with a unified structure and content.

[0053] After obtaining the attribute information, the system immediately performs a rigorous check on this information according to the data validation rules related to the component type obtained from the data collection configuration table. The check mainly includes two aspects: first, format validation, verifying whether the format of each attribute value is correct; second, missing attribute validation, confirming that all required attributes have provided valid values. If any validation fails, the system will terminate the current data collection process and generate a standardized error message with a uniform format and clear content, returning it to the caller or user, thereby ensuring the quality of the input data.

[0054] Step 1024: Write the verified attribute information into the component information table, and at the same time parse the association reference relationship between the business components to generate the association record between the source business component and the target business component, and write the association record into the component relationship table.

[0055] In this embodiment, the component information table is a data table that stores the basic metadata of all business components; the association reference relationship is the dependency or usage relationship between business components, such as the rule set component using a certain system field component; the source business component is the initiator in the dependency relationship, that is, the component that references other components; the target business component is the referenced party in the dependency relationship, that is, the component that is depended on by other components; the component relationship table is a data table that specifically records the association reference relationship between business components.

[0056] The system performs write operations on the validated attribute information. This attribute information is persistently stored in the component information table as a new or updated record. The system analyzes the current business component object, resolving all associations and references between this component and other components. For each resolved relationship, the system generates a clear association record, explicitly identifying the source and target business components. These association records are then written to the component relationship table. Through this step, the system not only updates the static information of the components but also simultaneously maintains the dynamic relationship network between components.

[0057] This application embodiment achieves flexibility and maintainability in the data collection process by embedding general data collection functions at key nodes decoupled from business logic and using reflection mechanisms to dynamically read configurations and extract attributes. Combined with automated data verification and structured data entry, the system constructs an accurate and complete foundation of component information and relational data, thereby achieving efficient and reliable collection and persistence of business component metadata and its dependency network, providing a solid data foundation for subsequent dependency model construction and scenario-based verification.

[0058] Optionally, step 103 includes: Step 1031: Map each record in the component information table to a node in the directed graph model, and store the component identifier, component name, component type and component status in the record in the node.

[0059] In this embodiment, the component information table is a data table storing static metadata of risk decision-making business components, including fields such as component identifier, component name, component type, and component status. The directed graph model is a graph theory data structure used to describe the dependencies between risk decision-making business components, consisting of nodes and directed edges. A node is a basic element in the directed graph model, representing a specific risk decision-making business component. The component identifier is a unique code that identifies a risk decision-making business component. The component name is the name of the risk decision-making business component. The component type is the classification of the risk decision-making business component, such as system fields, real-time metrics, rule sets, and scorecards. The component status is the current running status of the risk decision-making business component, such as online, offline, or in preparation.

[0060] The system reads each data record from the component information table, and each record corresponds to a specific risk decision-making business component. The system creates a corresponding node in the graph model for each record. Simultaneously, the system stores the key attributes of the record—component identifier, component name, component type, and component status—as attribute data within the node object. This process ensures that each node in the graph model uniquely represents a business component and carries the basic information required for dependency verification.

[0061] Step 1032: Map each record in the component relationship table to a directed edge in the directed graph model, and annotate the dependency strength and dependency attributes of the record on the directed edge.

[0062] In this embodiment, the component relationship table is a data table that records the association and reference relationships between risk decision-making business components, including fields such as source component identifier, target component identifier, dependency strength, and dependency attributes. A directed edge is a directed line segment in a directed graph model connecting two nodes, used to represent a reference dependency relationship from one component to another. Dependency strength is an attribute describing the strength of the reference relationship, such as strong or weak reference, depending on the state of the source component. Dependency attributes are attributes describing the specific nature of the reference relationship, such as input, output, or input-output.

[0063] The system reads each data record from the component relationship table, where each record defines a reference relationship between two risk decision-making business components. Based on the source and target component identifiers in the record, the system locates the corresponding two nodes in the graph model. Then, the system creates a directed edge between these two nodes, pointing from the source component node to the target component node. After creating the directed edge, the system labels it with the dependency strength and dependency attributes defined in the record. This process transforms the abstract relationships in the data table into visible and computable connections in the graph model.

[0064] Step 1033: The directed graph model is stored in memory. When the component information table or the component relationship table changes, an incremental update operation is performed on the directed graph model. The incremental update operation includes adding nodes, adding directed edges, removing nodes, and removing directed edges.

[0065] In this application embodiment, in-memory graphs are a technical solution that stores graph data structures in computer memory, such as using Neo4j's in-memory mode or Redis's graph structure, to achieve high-speed access and traversal of graph nodes and edges. Incremental update operation is a data synchronization strategy that refers to adding, modifying, or deleting only the changed data, rather than rebuilding the entire dataset.

[0066] The system stores the constructed directed graph model in an in-memory graph, leveraging the high-speed read / write capabilities of memory to ensure the efficiency of subsequent graph computation operations such as dependency queries and path traversal. Simultaneously, the system establishes a listening or polling mechanism to continuously monitor data change events in the component information table and component relationship table. When a new component record is inserted, the system performs a node addition operation, adding the corresponding new node to the graph model. When a new component relationship record is inserted, the system performs a directed edge addition operation, adding the corresponding new edge to the graph model. When a component record is deleted, the system performs a node removal operation, simultaneously removing all directed edges connected to that node. When a component relationship record is deleted, the system performs a directed edge removal operation, deleting the corresponding edge from the graph. Through this incremental update mechanism, the system ensures that the graph model in memory and the data in the persistent data tables remain synchronized in real time.

[0067] This application embodiment constructs and maintains an efficient, dynamic, and computable business component dependency model by mapping component information to graph nodes, mapping component relationships to directed edges, and using in-memory graph storage and incremental updates. This model transforms discrete data table records into a structured network, providing robust data structure support for subsequent complex dependency analysis based on graph theory, such as path search, circular dependency detection, and scenario-based verification. This ultimately improves the accuracy, efficiency, and flexibility of dependency verification.

[0068] Optionally, step 104 includes: Step 1041: When the business component initiates an online application, a preset online verification rule set is loaded according to the component type of the business component. The online verification rule set includes strong dependency component existence verification rules, target component status verification rules, and extended attribute constraint verification rules.

[0069] In this embodiment, a business component is a module or unit with independent domain functions in the risk decision-making business system, such as a system field component, a real-time indicator component, a rule set component, or a scorecard component. The component type is a classification identifier used to distinguish different types of business components, such as system fields, real-time indicators, rule sets, and scorecards. The online verification rule set is a set of verification rules predefined for the online application scenario of a business component. The strong dependency component existence verification rule is a verification rule used to verify whether the dependent component exists. The target component status verification rule is a verification rule used to verify whether the dependent component is in a specific state. The extended attribute constraint verification rule is a verification rule used to verify additional attribute constraints between components in addition to the basic dependency relationship, such as version compatibility and business domain consistency.

[0070] When a business component in the risk decision-making system initiates a deployment request, the system triggers a deployment verification process. The system first identifies the component type, such as a rule set. Then, based on the component type, the system loads the corresponding deployment verification rule set from a pre-defined rule library. This rule set contains several specific verification rules, including strong dependency component existence verification rules to check if the dependent components exist; target component status verification rules to check if the dependent components are online; and extended attribute constraint verification rules to check if additional constraints between components, such as version and business domain, are met. The rule set loading process is configurable, allowing the system to dynamically adapt different verification strategies based on different component types.

[0071] Step 1042: Traverse all strongly dependent directed edges of the business component through the directed graph model to obtain the target component set of the target business component.

[0072] In this embodiment, the directed graph model is a graph theory model used to describe the dependency relationships between risk decision-making business components. Nodes represent business components, and directed edges represent the association and reference relationships between components. Strong dependency directed edges are directed edges in the graph that represent strong reference relationships, i.e., the reference relationship between the source component and the target component when the source component is in an online or approval state. The target business component is the business component referenced by other components in the dependency relationship. The target component set is a set composed of all business components that are strongly dependent on by the currently online application component.

[0073] After loading the deployment validation rule set, the system uses the constructed directed graph model to traverse dependencies. Starting with the business component that initiated the deployment request, the system searches the graph model for all directed edges originating from that node and marked as "strong dependency". The system traverses these edges, collecting the target nodes pointed to by each edge, i.e., the dependent target business components. If multi-level dependencies exist, i.e., target components strongly depend on other components, the system recursively traverses until all indirect strong dependencies are exhausted. Finally, the system aggregates all traversed target business components into a target component set, providing a clear object list for subsequent detailed validation.

[0074] Step 1043: Perform existence verification, status verification, and extended attribute verification on each target business component in the target component set. The existence verification is used to confirm that the target business component has a valid record in the component information table. The status verification is used to confirm that the component status of the target business component is online. The extended attribute verification is used to confirm the version compatibility and business domain consistency between the business component and the target business component.

[0075] In this embodiment, existence verification is a verification operation used to confirm that a specified business component exists in the system's component information table and that the record is valid. The component information table is a data table that stores static metadata of risk decision business components, including fields such as component ID, component number, component name, component type, component status, and component extended attributes. Status verification is a verification operation used to confirm whether the current running status of a business component meets specific requirements. Online status is a running status of a business component, indicating that the component is enabled and can be referenced normally by other components. Extended attribute verification is a verification operation used to check whether the extended attributes of business components, in addition to basic dependencies, meet specific constraints. Version compatibility is one of the extended attribute constraints, requiring that the versions of the source component and the target component can semantically match and work together. Business domain consistency is one of the extended attribute constraints, requiring that interdependent components belong to the same business domain or category.

[0076] The system verifies each target component obtained in step 1042. First, an existence check is performed. Based on the target business component's identifier information, such as the component ID, the system queries the component information table to confirm that the component has a valid record in the table, and that the record is not marked as deleted or invalid. Next, a status check is performed. The system retrieves the component status field of the target business component from the component information table and checks whether its status is "online," ensuring that the dependent component is in a state where it can provide services normally. Then, extended attribute checks are performed. The system retrieves the extended attributes of both the source and target business components, such as version number and business domain. Based on preset verification logic, the system determines whether the version of the source component is compatible with the version of the target component, for example, requiring the target component version to be no lower than a specific version; simultaneously, it determines whether the business domains of the two components are consistent, ensuring that the dependency relationship occurs within reasonable business boundaries. Each check has clear pass / fail criteria.

[0077] This application embodiment achieves automated, comprehensive, and accurate verification of the dependencies of business components before they go online by configuring and loading the online verification rule set, efficiently traversing strong dependencies using a directed graph model, and performing multi-dimensional detailed verification of dependent components. This ensures the stability of risk decision-making business processes and prevents decision-making errors caused by missing dependencies or abnormal states.

[0078] Optionally, step 1043 includes: Step 10431: When the extended attribute verification is a version compatibility verification, obtain the first version number of the business component and the second version number of the target business component.

[0079] In this embodiment, a business component is a module or unit with independent domain functionality within a risk decision-making business system, such as a system field component, a real-time indicator component, a rule set component, or a scorecard component. A target business component is a business component that other business components depend on. The first version number is the version identifier of the business component initiating the dependency verification. The second version number is the version identifier of the target business component that is depended upon. Predefined version dependency rules are a predefined set of conditions used to determine version compatibility. The first version threshold is a specific version number standard value specified in the predefined version dependency rules.

[0080] During the component deployment verification process, this step is triggered when extended attribute verification is required and the specific verification type is version compatibility verification. The system first extracts the version information from the metadata of the business component to be deployed; this information is defined as the first version number. Simultaneously, the system locates and obtains the version information of the target business components that the current business component depends on by querying the component information table or from the constructed dependency graph model; this information is defined as the second version number. This process ensures that the system can obtain accurate version identifiers for both dependent components, providing a data foundation for subsequent compatibility assessments.

[0081] Step 10432: Determine whether the second version number satisfies the preset version dependency rule of the business component on the target business component. The preset version dependency rule includes that the second version number is greater than or equal to the first version threshold specified by the preset standard.

[0082] In this embodiment, the determination is a process of logical comparison and condition evaluation performed by the system. "Satisfying" means that the second version number meets all the conditions of the preset version dependency rules.

[0083] After obtaining the first and second version numbers, the system will invoke the rules engine to load and apply preset version dependency rules configured for the current business scenario. These rules explicitly stipulate that the version of the target business component must meet or exceed a certain minimum requirement, namely the first version threshold. The system will then logically compare the second version number with the first version threshold to evaluate whether the second version number is greater than or equal to the first version threshold. This judgment process is the core of the verification logic, used to determine whether the version of the dependent component is new enough to meet the requirements for normal operation or specific functionality of the dependent component.

[0084] Step 10433: When the second version number does not meet the preset version dependency rule, a version incompatibility error message is generated. The version incompatibility error message includes the first version number, the second version number, and the preset version dependency rule.

[0085] In this embodiment, "generation" refers to the process by which the system creates and formats output information. Version incompatibility error messages are structured prompts generated by the system when version verification fails.

[0086] If the system's judgment in step 10432 fails, meaning the second version number is lower than the first version threshold, the verification fails. In this case, the system triggers an error message generation mechanism. The system encapsulates the first version number, the second version number, and the specific details of the failed preset version dependency rule into a uniformly formatted version incompatibility error message. This message aims to clearly present the specific details of the dependency conflict to users or administrators, including the dependent version, the version of the depended-on, and the expected version requirements, thus providing clear guidance for quickly locating and resolving the problem.

[0087] This application's embodiments achieve automated and accurate verification of version compatibility between components by dynamically acquiring and comparing the version numbers of dependent components with preset version dependency rules during the online verification of business components. When version incompatibility is detected, the system automatically generates an error message containing detailed version information and rule content. This approach effectively intercepts potential risk decision-making errors or functional abnormalities caused by version dependency discrepancies before component deployment, improving system stability and decision accuracy. Furthermore, the structured error information enhances the efficiency of problem localization and resolution.

[0088] Optionally, step 104 further includes: Step 1044: When the component relationship table changes, a circular dependency detection is triggered in real time, and a topological sorting algorithm is executed on the directed graph model to determine whether there is an abnormal set of nodes that cannot be sorted.

[0089] In this embodiment, the component relationship table is a data table that stores the association and reference relationships between risk decision-making business components. It includes fields such as source component ID, target component ID, and dependency attributes, used to record the direction and type of dependency. The directed graph model is a data structure built based on graph theory, where nodes represent business components, and directed edges represent dependencies between components, with the direction pointing from the dependent to the dependent. The topological sorting algorithm is an algorithm that linearly sorts all vertices of a directed acyclic graph, ensuring that for each directed edge in the graph, the starting point always appears before the ending point in the sorting.

[0090] The system continuously monitors data change events in the component relationship table, such as adding, modifying, or deleting a dependency record. Once a change event is detected, the system immediately triggers a circular dependency detection process. The system first accesses the currently built and maintained directed graph model, which reflects all components and their dependencies in real time. The system executes a topological sorting algorithm on this directed graph model, attempting to generate a linear sequence of nodes. If the algorithm successfully sorts all nodes in the graph, it indicates that there are no circular dependencies. If, after execution, the algorithm finds one or more groups of nodes that cannot be included in the sorted sequence, the system determines that these nodes constitute an abnormal set of nodes, indicating the presence of a circular structure in the graph, i.e., a circular dependency.

[0091] Step 1045: When the set of abnormal nodes exists, perform a depth-first search algorithm on each abnormal node in the set of abnormal nodes to trace the circular dependency path of each abnormal node.

[0092] In this embodiment, the abnormal node set refers to the group of nodes that cannot be sorted normally after the topological sorting algorithm is executed. These nodes are parts of the directed graph that may constitute circular dependencies. Depth-first search is an algorithm used to traverse or search a tree or graph. Its strategy is to explore the branches of the graph as deeply as possible, backtracking when a dead end is encountered.

[0093] After confirming the existence of an abnormal node set in step 1044, the system initiates a depth-first search algorithm for each abnormal node in the set. The algorithm uses the current abnormal node as the starting point and performs a depth-first traversal along the dependency direction specified by the directed edges. During the traversal, the system records the visited node paths. When the algorithm, during the traversal, revisits a node already recorded in the path from a certain node, a closed cycle is discovered. By backtracking the visited path, the system can accurately extract all the nodes constituting the cycle and their order, thus determining a complete circular dependency path, such as a path where A depends on B, B depends on C, and C depends on A. The system performs this operation on each node in the abnormal node set to find all possible independent circular dependency cycles.

[0094] Step 1046: Present the circular dependency path to the user by throwing an exception, or write the circular dependency path into a circular dependency detection report and push it to the terminal of the person in charge as specified by the preset standard.

[0095] In this embodiment, a circular dependency path is a closed loop consisting of a series of business component nodes and their inter-node dependencies, describing a complete chain of dependencies forming a circular structure. The circular dependency detection report is a system-generated document used to summarize and record detailed information about all detected circular dependency paths. The responsible party terminal is a pre-configured computing device or system interface belonging to a specific responsible person, used to receive reports or alarm information.

[0096] The system formats all circular dependency paths traced in step 1045. Based on preset configuration rules, the system selects one of two methods for outputting the results. The first method is real-time interactive alerting. Upon detecting a circular dependency, the system immediately constructs a structured exception object containing details of the circular path and displays it directly to the user through error pop-ups and prompts. The second method is asynchronous report generation. The system organizes and writes the detailed information of the circular dependency path, including the component IDs, names, types, and dependency chains involved, into a structured circular dependency detection report file. According to preset standards, the system obtains the terminal address of the person responsible for handling such dependency anomalies and pushes the generated report to the corresponding responsible terminal via message queues, email, or system notifications.

[0097] This application embodiment achieves automated and accurate identification and display of complex circular dependency anomalies by real-time monitoring of dependency changes and triggering detection, combined with topology sorting to quickly locate abnormal node sets, then using depth-first search to accurately trace circular dependency paths, and finally providing feedback through a configurable real-time anomaly throwing or report push mechanism. This effectively avoids the risk decision-making process from being blocked or logical errors caused by hidden circular dependencies, and improves the stability and maintainability of the system.

[0098] Based on the foregoing embodiments, this application provides a component-dependent verification device, which includes each unit and each module included in each unit. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0099] Optionally, refer to Figure 2Output a schematic diagram of the architecture of a component-dependent verification system provided in this application embodiment, wherein: The parameter configuration module manages all configurable rules and display strategies, including: component attribute collection rules; dependency validation rules; and parameters for displaying validation results in the pop-up window. The parameter configuration module provides a visual configuration interface or API interface, supports dynamic hot updates, and takes effect without restarting the service, significantly improving system flexibility and maintainability.

[0100] The data acquisition module, based on reflection and an event-driven model, automatically captures related reference information throughout the entire lifecycle of business components. Specifically, this includes: embedding data points at key nodes such as component creation, editing, and state changes; calling general acquisition functions; dynamically extracting specified attributes of component objects via reflection according to acquisition rules in the parameter configuration module; and synchronously writing the acquired data to the "Component Information Table" and "Component Relationship Table" after format validation and preprocessing. The data acquisition module completely decouples acquisition logic from business code, avoiding hard coding and supporting rapid integration of any newly added component type.

[0101] The model building module transforms structured component metadata and referential relationships into a graph theory model. Specifically, it maps each record in the "Component Information Table" to a graph node, storing attributes such as component ID, type, and state; maps each record in the "Component Relationship Table" to directed edges, labeling dependency direction, strength, and dependency attributes; and uses an in-memory graph database for efficient storage, supporting incremental updates to ensure real-time consistency between the graph model and the underlying data. This module provides an efficient algorithmic foundation for complex dependency analysis.

[0102] The dependency verification module serves as the core execution engine of the system, integrating an extensible rule engine to dynamically perform multi-dimensional dependency verification according to business scenarios. Specifically, it includes: traversing all dependent components of a component to verify the existence, online status, and extended attribute constraints of the target component; performing a reverse query on all upstream components that reference the current component, blocking operations and indicating the scope of impact if strong references exist; and identifying and locating circular dependency paths in real time or at regular intervals based on topology sorting and depth-first search. All validation rules that depend on the validation module are loaded from the parameter configuration module, supporting priority scheduling and batch execution, and the validation results are returned as structured error information.

[0103] The panoramic view visualization module is used to build interactive dependency panoramas based on a web front-end visualization library. Specifically, it displays component nodes and their referencing edges in a tree or force-directed graph format; supports multi-dimensional filtering by component type, status, business domain, etc.; provides interactive functions such as clicking on nodes to view details, highlighting and tracing links, zooming, and dragging; and uses color to distinguish component status and dependency strength. This module serves advanced operational scenarios such as architecture governance, change impact analysis, and dependency network optimization.

[0104] The verification information display module is specifically designed to handle user feedback when verification fails, providing a user-friendly and structured presentation of error information. Specifically, it includes: dynamically rendering a list of related components based on the JSON configuration in the parameter configuration module; supporting custom column display, sorting rules, and click-to-jump logic; and configurable pop-up titles, prompts, and operation suggestions to improve user experience and problem identification efficiency.

[0105] The data storage module serves as the underlying support for the system and contains two core data tables: one storing static metadata of the components and the other recording the reference relationships between components. The data storage module is decoupled from traditional database foreign keys, serving solely as the data source for the graph model. Its structure is simple, easy to maintain, and supports high-concurrency read and write operations. Figure 3 This is a schematic diagram of the composition structure of a component-dependent verification device provided in an embodiment of this application, as shown below. Figure 3 As shown, the verification device 20 on which the component depends includes: Processing module 201 is used to configure the collection attributes, collection trigger events and data verification rules corresponding to each business component; At key nodes throughout the entire lifecycle of the business component, based on the collection attributes, the collection trigger events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table. The structured data in the component information table and the component relationship table are transformed into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component. The verification module 202 is used to load a preset set of verification rules according to the business scenario, and use the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario, so as to obtain the dependency verification result. The dependency verification results are displayed in the form of structured error messages. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

[0106] Optionally, the processing module 201 is configured to: Create a data acquisition configuration table, which includes a configuration identifier field, a component type field, a data acquisition attribute list field, a data acquisition trigger event field, a data verification rule field, and an update frequency field. Configure the corresponding collection attribute list, collection trigger event, data verification rules, and update frequency for each component type of the business component; Through a visual management interface or configuration file, the collection attribute list, collection trigger events, and data verification rules in the collection configuration table can be dynamically added or modified, and the modified collection attribute list, collection trigger events, and data verification rules can take effect immediately without restarting the system.

[0107] Optionally, the processing module 201 is further configured to: A general data collection function is embedded at the creation node, editing node, deletion node, and status change node of the business component. The general data collection function is decoupled from the business logic of the business component and takes the business component object as the input parameter. The collection attribute list corresponding to the component type of the business component is read from the collection configuration table through reflection mechanism, and the specified attribute values ​​in the collection attribute list are dynamically extracted from the business component object to obtain the attribute information; The attribute information is formatted and missing according to the data validation rules, and a standardized error message is returned when the validation fails. The verified attribute information is written into the component information table. At the same time, the association and reference relationship between the business components is parsed to generate the association record between the source business component and the target business component. The association record is then written into the component relationship table.

[0108] Optionally, the processing module 201 is further configured to: Each record in the component information table is mapped to a node in the directed graph model, and the component identifier, component name, component type and component status in the record are stored in the node; Each record in the component relationship table is mapped to a directed edge in the directed graph model, and the dependency strength and dependency attributes in the record are marked on the directed edge; The directed graph model is stored in memory. When the component information table or the component relationship table changes, an incremental update operation is performed on the directed graph model. The incremental update operation includes adding nodes, adding directed edges, removing nodes, and removing directed edges.

[0109] Optionally, the verification module 202 is further configured to: When the business component initiates an online application, a preset online verification rule set is loaded according to the component type of the business component. The online verification rule set includes strong dependency component existence verification rules, target component status verification rules, and extended attribute constraint verification rules. By traversing all strongly dependent directed edges of the business component through the directed graph model, the target component set of the target business component is obtained. For each target business component in the target component set, an existence check, a status check, and an extended attribute check are performed. The existence check is used to confirm that the target business component has a valid record in the component information table. The status check is used to confirm that the component status of the target business component is online. The extended attribute check is used to confirm the version compatibility and business domain consistency between the business component and the target business component.

[0110] Optionally, the verification module 202 is further configured to: When the extended attribute verification is a version compatibility check, obtain the first version number of the business component and the second version number of the target business component; Determine whether the second version number satisfies the preset version dependency rule of the business component on the target business component, wherein the preset version dependency rule includes the second version number being greater than or equal to the first version threshold specified by the preset standard; When the second version number does not meet the preset version dependency rule, a version incompatibility error message is generated. The version incompatibility error message includes the first version number, the second version number, and the preset version dependency rule.

[0111] Optionally, the verification module 202 is further configured to: When the component relationship table changes, a circular dependency detection is triggered in real time, and a topological sorting algorithm is executed on the directed graph model to determine whether there is an abnormal set of nodes that cannot be sorted. When the set of abnormal nodes exists, a depth-first search algorithm is performed on each abnormal node in the set of abnormal nodes to trace the circular dependency path in which each abnormal node is located; The circular dependency path can be displayed to the user by throwing an exception, or the circular dependency path can be written into a circular dependency detection report and pushed to the terminal of the person in charge as specified by the preset standard.

[0112] This application embodiment achieves comprehensive, flexible, and accurate automated verification of the dependencies of risk decision-making business components through configurable data collection and graph model construction, combined with a configurable rule engine and result display. This improves the verification dimensions, identifies complex anomalies, reduces maintenance costs, and provides a clear panoramic view and user-friendly prompts.

[0113] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0114] It should be noted that, in the embodiments of this application, if the above-mentioned component-dependent verification method is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0115] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0116] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0117] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0118] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0119] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0120] It should be noted that, Figure 4 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 4 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0121] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0122] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 700 includes one or more cores.

[0123] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0124] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0125] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0126] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0127] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0128] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0129] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0130] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0131] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0132] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0133] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0134] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for verifying component dependencies, characterized in that, The method includes: Configure the data collection attributes, data collection trigger events, and data verification rules for each business component; At key nodes throughout the entire lifecycle of the business component, based on the collection attributes, the collection trigger events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table. The structured data in the component information table and the component relationship table are transformed into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component. The preset set of verification rules is loaded according to the business scenario, and the directed graph model is used to perform multi-dimensional dependency verification on the business component corresponding to the business scenario to obtain the dependency verification result. The dependency verification results are displayed in the form of structured error messages. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

2. The method according to claim 1, characterized in that, The configuration of the collection attributes, collection trigger events, and data verification rules corresponding to each business component includes: Create a data acquisition configuration table, which includes a configuration identifier field, a component type field, a data acquisition attribute list field, a data acquisition trigger event field, a data verification rule field, and an update frequency field. Configure the corresponding collection attribute list, collection trigger event, data verification rules, and update frequency for each component type of the business component; Through a visual management interface or configuration file, the collection attribute list, collection trigger events, and data verification rules in the collection configuration table can be dynamically added or modified, and the modified collection attribute list, collection trigger events, and data verification rules can take effect immediately without restarting the system.

3. The method according to claim 2, characterized in that, At key nodes throughout the entire lifecycle of the business component, based on the collected attributes, the collected triggering events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table, including: A general data collection function is embedded at the creation node, editing node, deletion node, and status change node of the business component. The general data collection function is decoupled from the business logic of the business component and takes the business component object as the input parameter. The collection attribute list corresponding to the component type of the business component is read from the collection configuration table through reflection mechanism, and the specified attribute values ​​in the collection attribute list are dynamically extracted from the business component object to obtain the attribute information; The attribute information is formatted and missing according to the data validation rules, and a standardized error message is returned when the validation fails. The verified attribute information is written into the component information table. At the same time, the association and reference relationship between the business components is parsed to generate the association record between the source business component and the target business component. The association record is then written into the component relationship table.

4. The method according to claim 1, characterized in that, The step of converting the structured data in the component information table and the component relationship table into a directed graph model includes: Each record in the component information table is mapped to a node in the directed graph model, and the component identifier, component name, component type, and component status in the record are stored in the node. Each record in the component relationship table is mapped to a directed edge in the directed graph model, and the dependency strength and dependency attributes in the record are marked on the directed edge; The directed graph model is stored in memory. When the component information table or the component relationship table changes, an incremental update operation is performed on the directed graph model. The incremental update operation includes adding nodes, adding directed edges, removing nodes, and removing directed edges.

5. The method according to claim 1, characterized in that, The step of loading a preset set of verification rules according to the business scenario and using the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario to obtain the dependency verification result includes: When the business component initiates an online application, a preset online verification rule set is loaded according to the component type of the business component. The online verification rule set includes strong dependency component existence verification rules, target component status verification rules, and extended attribute constraint verification rules. By traversing all strongly dependent directed edges of the business component through the directed graph model, the target component set of the target business component is obtained. For each target business component in the target component set, an existence check, a status check, and an extended attribute check are performed. The existence check is used to confirm that the target business component has a valid record in the component information table. The status check is used to confirm that the component status of the target business component is online. The extended attribute check is used to confirm the version compatibility and business domain consistency between the business component and the target business component.

6. The method according to claim 5, characterized in that, The step of performing existence verification, status verification, and extended attribute verification on each of the target business components in the target component set includes: When the extended attribute verification is a version compatibility check, obtain the first version number of the business component and the second version number of the target business component; Determine whether the second version number satisfies the preset version dependency rule of the business component on the target business component, wherein the preset version dependency rule includes the second version number being greater than or equal to the first version threshold specified by the preset standard; When the second version number does not meet the preset version dependency rule, a version incompatibility error message is generated. The version incompatibility error message includes the first version number, the second version number, and the preset version dependency rule.

7. The method according to claim 5, characterized in that, The step of loading a preset set of verification rules according to the business scenario and using the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario to obtain the dependency verification result further includes: When the component relationship table changes, a circular dependency detection is triggered in real time, and a topological sorting algorithm is executed on the directed graph model to determine whether there is an abnormal set of nodes that cannot be sorted. When the set of abnormal nodes exists, a depth-first search algorithm is performed on each abnormal node in the set of abnormal nodes to trace the circular dependency path of each abnormal node. The circular dependency path can be displayed to the user by throwing an exception, or the circular dependency path can be written into a circular dependency detection report and pushed to the terminal of the person in charge as specified by the preset standard.

8. A component-dependent verification device, characterized in that, The device includes: The processing module is used to configure the collection attributes, collection trigger events, and data verification rules corresponding to each business component; At key nodes throughout the entire lifecycle of the business component, based on the collection attributes, the collection trigger events, and the data verification rules, the attribute information of the business component and the association and reference relationship information between the business components are collected, and the attribute information is written into the component information table, and the association and reference relationship information is written into the component relationship table. The structured data in the component information table and the component relationship table are transformed into a directed graph model. The directed graph model includes multiple nodes and multiple directed edges. Each node corresponds to a business component, and each directed edge corresponds to an association reference relationship. The direction of the directed edge is from the source business component to the target business component. The verification module is used to load a preset set of verification rules according to the business scenario, and use the directed graph model to perform multi-dimensional dependency verification on the business component corresponding to the business scenario, so as to obtain the dependency verification result. The dependency verification results are displayed in the form of structured error messages. The column display items, sorting rules, and jump logic of the list displaying the dependency verification results are dynamically defined through parameter configuration in the structured query language format.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the verification method upon which the component of any one of claims 1 to 7 depends.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps in the verification method upon which the component of any one of claims 1 to 7 depends.

Images