System call relation graph construction method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a system call relation graph construction method and device, equipment and a storage medium. The method comprises the following steps: determining a service system and service data, and obtaining management information of an API management platform; according to the service system, the service data and the management information, determining a plurality of service subsystems in the service system and a calling relationship among the plurality of service subsystems; determining at least one piece of system identification data corresponding to each service subsystem according to the calling relationship among the plurality of service subsystems; filling a preset template with the system identification data corresponding to the plurality of service subsystems, and generating atlas data among the plurality of service subsystems; and according to the atlas data, constructing a system call relation atlas of the business system. According to the method, by constructing the system calling relation graph, the direct calling relation of the system can be clearly determined, and the problem that the program upgrading effect is affected due to the fact that operation and maintenance personnel cannot find dependency and coupling between the systems in time in the development process is solved.

Description

Technical Field

[0001] The present application relates to the field of information technology services, and in particular to a method, device, equipment and storage medium for constructing a system call relationship graph. Background Art

[0002] With the rapid development of information technology, Application Programming Interface (API) has become an indispensable part of modern software systems. They promote the interaction and integration between different software components, services and systems. However, with the rapid growth of the number of APIs, their management has become increasingly complex, especially in large enterprises and complex information technology environments. Through the API interface management platform, the efficient, secure and reliable operation of APIs can be ensured.

[0003] In the prior art, the API interface management platform can achieve full life cycle management of the API interface from entry, review, change, testing to release by integrating the entry module and the automated testing module.

[0004] Although the above management platform records some interface information, the recorded information is scattered in multiple relationship tables, case sets, and test logs, resulting in the interface call relationship not being systematically and comprehensively sorted out, and thus unable to intuitively display the call relationship between each interface and each system. Therefore, the operation and maintenance personnel cannot timely discover the dependencies and couplings between systems, resulting in the inability to achieve effective collaboration during the program release process, thus affecting the effect of program upgrades. Summary of the invention

[0005] The embodiments of the present application provide a method, device, equipment and storage medium for constructing a system call relationship map, which are used to solve the problem that the API interface management platform cannot intuitively display the call relationships between various interfaces and various systems, resulting in the operation and maintenance personnel being unable to promptly discover the dependencies and couplings between systems, affecting the effect of program upgrades.

[0006] In a first aspect, an embodiment of the present application provides a method for constructing a system call relationship graph, the method comprising:

[0007] Identify business systems and business data, and obtain management information from the API management platform;

[0008] Determine, according to the business system, the business data and the management information, a plurality of business subsystems in the business system and a calling relationship between the plurality of business subsystems, wherein sub-business information corresponding to the business subsystem is associated with business information corresponding to the business system;

[0009] Determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems;

[0010] Filling the system identification data corresponding to the plurality of business subsystems into a preset template to generate graph data between the plurality of business subsystems;

[0011] Based on the graph data, a system call relationship graph of the business system is constructed.

[0012] In a possible implementation, determining multiple business subsystems in the business system and calling relationships between the multiple business subsystems according to the business system, the business data, and the management information includes:

[0013] Determine the business information corresponding to the business system, and analyze and process the business information to obtain a plurality of sub-business information, wherein there is an association relationship between the sub-business information and the business information;

[0014] Determine a corresponding business subsystem according to the plurality of sub-business information;

[0015] According to the plurality of business subsystems, determining business logic data corresponding to each business subsystem from the business data, wherein the business logic data is used to indicate the core business logic involved in the business process of the business subsystem;

[0016] Analyze and process the management information of the API management platform to obtain interface information of multiple API interfaces;

[0017] The calling big model determines the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces.

[0018] In a possible implementation, the calling big model determines the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces, including:

[0019] Inputting the business logic data and the interface information of the plurality of API interfaces into a large model;

[0020] The big model analyzes and processes the business logic data and the interface information of the multiple API interfaces according to preset rules, determines the data association information and data reference information between the multiple business logic data, and outputs the calling relationship between the multiple business subsystems based on the data association information and the data reference information, wherein the data association information is used to indicate the data flow relationship between the multiple business subsystems, and the data reference information is used to indicate the data dependency relationship between the multiple business subsystems.

[0021] In a possible implementation, determining at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems includes:

[0022] Regular expressions are used to analyze and process the calling relationships between the multiple business subsystems to determine at least one system identification data corresponding to each business subsystem, wherein the system identification data includes but is not limited to: system name, system attributes and version information.

[0023] In a possible implementation, filling the system identification data corresponding to the plurality of business subsystems into a preset template to generate graph data between the plurality of business subsystems includes:

[0024] Determine the variables to be filled and the filling rules corresponding to the preset template;

[0025] Taking the system identification data corresponding to the plurality of business subsystems as variables to be filled, and filling them into the preset template according to the filling rule, to obtain a plurality of groups of triplet data;

[0026] The multiple groups of triplet data are used as graph data between the multiple business subsystems.

[0027] In a possible implementation, constructing a system call relationship graph of the business system according to the graph data includes:

[0028] Constructing a corresponding RDF graph according to the multiple sets of triple data;

[0029] The RDF graph is used as the system call relationship graph of the business system.

[0030] In a possible implementation, the method further includes:

[0031] Importing the RDF graph into a graph database for execution processing to obtain an execution result;

[0032] When no error occurs in the execution result, it is determined that the system call relationship graph is constructed successfully.

[0033] In a second aspect, an embodiment of the present application provides a system call relationship graph construction device, including:

[0034] The determination module is used to determine the business system and business data and obtain the management information of the API management platform;

[0035] The determination module is further used to determine multiple business subsystems in the business system and the calling relationship between the multiple business subsystems according to the business system, the business data and the management information, wherein the sub-business information corresponding to the business subsystem is associated with the business information corresponding to the business system;

[0036] The determination module is further used to determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems;

[0037] A generation module, used to fill the system identification data corresponding to the plurality of business subsystems into a preset template, and generate graph data between the plurality of business subsystems;

[0038] A construction module is used to construct a system call relationship graph of the business system based on the graph data.

[0039] In a possible implementation, the device further includes: an analysis module;

[0040] The determination module is further used to determine the business information corresponding to the business system, and analyze and process the business information to obtain a plurality of sub-business information, wherein there is an association relationship between the sub-business information and the business information;

[0041] The determination module is further used to determine the corresponding business subsystem according to the plurality of sub-business information;

[0042] The determination module is further used to determine the business logic data corresponding to each business subsystem from the business data according to the multiple business subsystems, wherein the business logic data is used to indicate the core business logic involved in the business process of the business subsystem;

[0043] The analysis module is used to analyze and process the management information of the API management platform to obtain interface information of multiple API interfaces;

[0044] The determination module is also used to call the large model to determine the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces.

[0045] In a possible implementation, the device further includes: an input module;

[0046] The input module is used to input the business logic data and the interface information of the multiple API interfaces into the large model;

[0047] The big model analyzes and processes the business logic data and the interface information of the multiple API interfaces according to preset rules, determines the data association information and data reference information between the multiple business logic data, and outputs the calling relationship between the multiple business subsystems based on the data association information and the data reference information, wherein the data association information is used to indicate the data flow relationship between the multiple business subsystems, and the data reference information is used to indicate the data dependency relationship between the multiple business subsystems.

[0048] In a possible implementation, the analysis module is further used to use regular expressions to analyze and process the calling relationships between the multiple business subsystems to determine at least one system identification data corresponding to each business subsystem, wherein the system identification data includes but is not limited to: system name, system attributes and version information.

[0049] In a possible implementation, the device further includes: a filling module;

[0050] The determination module is further used to determine the variables to be filled and the filling rules corresponding to the preset template;

[0051] The filling module is used to use the system identification data corresponding to the multiple business subsystems as variables to be filled, and fill them into the preset template according to the filling rule to obtain multiple groups of triplet data;

[0052] The determination module is also used to use the multiple groups of triplet data as graph data between the multiple business subsystems.

[0053] In a possible implementation, the construction module is further used to construct a corresponding RDF graph according to the multiple sets of triple data;

[0054] The determination module is further configured to use the RDF graph as a system call relationship graph of the business system.

[0055] In a possible implementation manner, the device further includes: an execution device;

[0056] The execution device is used to import the RDF graph into a graph database for execution processing to obtain an execution result;

[0057] The determination module is further used to determine that the system call relationship graph is successfully constructed when no error occurs in the execution result.

[0058] In a third aspect, an embodiment of the present application provides a system call relationship graph construction device, including: a memory, a processor;

[0059] The memory stores computer-executable instructions;

[0060] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0061] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0062] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0063] The system call relationship graph construction method, device, equipment and storage medium provided in the embodiment of the present application determine the business system and business data, and obtain the management information of the API management platform; determine the multiple business subsystems in the business system and the call relationship between the multiple business subsystems based on the business system, business data and management information; determine at least one system identification data corresponding to each business subsystem based on the call relationship between the multiple business subsystems; fill the system identification data corresponding to the multiple business subsystems into the preset template to generate the graph data between the multiple business subsystems; and construct the system call relationship graph of the business system based on the graph data. This method can clearly determine the direct call relationship of the system by constructing the system call relationship graph, avoiding the problem that the operation and maintenance personnel cannot timely discover the dependencies and couplings between the systems during the development process, which affects the program upgrade effect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0065] Figure 1 Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 1 ;

[0066] Figure 2 Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 2 ;

[0067] Figure 3Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 3 ;

[0068] Figure 4 A schematic diagram of the structure of the system call relationship graph construction device provided in this application;

[0069] Figure 5 A schematic diagram of the structure of the device for building the system call relationship graph provided in this application.

[0070] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0071] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0072] The terms "first", "second", "third", "fourth", etc. (if any) in the description and claims of the present invention and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in sequences other than those illustrated or described herein, for example.

[0073] In the embodiments of the present application, the words "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0074] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0075] First, the terms involved in this application are explained:

[0076] API (Application Programming Interface): is a communication protocol that defines a set of methods, rules and standards, enabling different applications to exchange data and share functions. It defines the specifications and methods for communication and interaction between different software components, allowing different software systems, services or applications to share data and functions so that they can collaborate and integrate with each other.

[0077] API management platform: API management platform is a software tool designed to simplify the management process of APIs, improve development efficiency, ensure the security and reliability of APIs, facilitate system integration, and optimize user experience. It allows enterprises to centrally manage and control all their APIs, including registration, version control, access control, performance monitoring, analysis reports, and developer portals.

[0078] Resource Description Framework (RDF): Triples are a standard data model for describing network resources. They provide a common framework for expressing metadata about resources. Resources and the relationships between them are mainly described through triples (Subject-Predicate-Object). RDF defines a data model that links all RDF-based languages ​​and specifications. Its core concepts include RDF graphs and RDF datasets.

[0079] Triple: The RDF format for describing resources consists of three parts: an RDF graph with two nodes (subject and object) and a predicate connecting them. Each triple represents a fact about a resource, such as " <bob><is a> <person>" means "Bob is a person".

[0080] RDF graph: RDF graph is a collection of subject-verb-object triples, and the elements can be international resource identifiers (IRIs), blank nodes, or data type texts. They are used to express the description of resources.

[0081] RDF dataset: An RDF dataset consists of a default graph and zero or more named RDF graphs. The graphs in a dataset can share blank nodes, which means that they can be logically related together.

[0082] Big model: AI big model refers to a "large parameter" model trained using large-scale data and powerful computing power. These models are usually highly versatile and generalizable, and can be applied to natural language processing, image recognition, speech recognition and other fields.

[0083] The API management platform can ensure efficient, secure and reliable operation of the API. The API management platform can achieve full life cycle management of the API interface from entry, review, change, testing to release by integrating the entry module and the automated testing module. However, the API management platform only records part of the interface information, and this information is scattered in multiple relationship tables, case sets, and test logs.

[0084] Therefore, the API interface management platform is unable to systematically and comprehensively sort out the calling relationships of the interfaces, resulting in the inability to intuitively display the calling relationships between various interfaces and systems. As a result, during the program development process, operation and maintenance personnel are unable to promptly discover the dependencies and couplings between systems, resulting in the inability to achieve effective collaboration during the program release process, which in turn affects the effect of program upgrades.

[0085] The system call relationship graph construction method provided in the present application obtains multiple interface information by collecting the interface management information of the API management platform, and determines the business system and business-related data; determines multiple business subsystems through the business system and business data, analyzes the call relationship between the business subsystems according to the interface management information and business data of the API management platform, and finally, determines the graph data according to the call relationship, automatically extracts and constructs the API blood relationship, reduces the workload of complex manual processing, combines the large model, knowledge base, and regular matching capabilities, can effectively define the call relationship between our systems, and through the extraction of entities and relationships, can construct accurate and complete RDF data of API calls, obtain the call relationship graph between systems, and solve the problem that the operation and maintenance personnel cannot timely discover the dependencies and couplings between systems during the development process, which affects the program upgrade effect.

[0086] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0087] Figure 1 Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0088] S101. Determine the business system and business data, and obtain management information of the API management platform.

[0089] Among them, a business system can refer to a set of information systems used to support business operations in an enterprise or organization, or it can refer to an information system that operates in data processing or business processes in a certain technical field. Such business systems can include the call of multi-level system data, such as hardware systems and software systems. In the hierarchical system, it can also involve multi-level circulation of multi-system data. Business data can be used to indicate data information generated by various information systems, business application systems and other systems within the enterprise.

[0090] It is understandable that the architecture of a business system may include a front-end, a back-end, and a database. The front-end is the interface for users to interact with the system, the back-end is responsible for processing user requests and business logic, and the database is used to store required data. The above architectures may involve different sub-business systems.

[0091] Business data can be obtained by analyzing the dictionary data or log data stored in the business system, or by analyzing the database table structure, viewing the table name, field name, and the relationship between them, etc., to infer the purpose and business relevance of the data. For example, by analyzing the database table of the securities management system, we can understand the risk assessment data, securities market data and other related data.

[0092] The API management system involved in this application can record system data and test data. Specifically, it can export system dimension data in the API management platform. The fields of the table may include, for example: project description, project name, system name, service name, and version name, etc. Such data types can be two-dimensional tables; and then the case set of API automated testing and the log records of test execution can be exported. This part of the data records the calling relationship between interfaces and interfaces. Such data may include two-dimensional tables and data in jason format.

[0093] S102: Determine multiple business subsystems in the business system and the calling relationship between the multiple business subsystems according to the business system, business data and management information.

[0094] Among them, the business subsystems can be divided according to the functional modules provided by the business system. For example, in the securities industry trading system, the trading system needs to call the employee platform system, the market system, and the risk control system to obtain the employee's user information, consulting information, and risk assessment information through the above systems.

[0095] Understandably, business data can be filtered. For example, the table structures corresponding to all internal systems of the enterprise can be exported regularly to form an enterprise-level overall table structure metadata. In the export process, some irrelevant tables such as log tables can be filtered, tables involving core business logic can be stored, and a table list of core business information can be maintained. Data filtering can make data analysis more accurate.

[0096] Specifically, when the data of a subsystem needs to be used by other subsystems, a call relationship will be generated. According to the business system, business data and management information, the corresponding interface call information can be obtained, the business subsystem can be determined according to the business system, and the core business information can be determined through the business data. The data flow and system data dependency are analyzed, and the call relationship between multiple business subsystems is determined through the above information.

[0097] Taking the financial trading system as an example, the risk assessment subsystem can obtain market data provided by the market data subsystem in real time in order to assess the risks of financial products. The market data subsystem will provide corresponding data based on the request of the risk assessment subsystem. This data interaction call relationship is bidirectional. The risk assessment subsystem relies on the data provided by the market data subsystem, and the market data subsystem needs to respond to the request of the risk assessment subsystem.

[0098] It should be noted that the occurrence of certain events can trigger calls between other subsystems. For example, in the customer service system of the business process, when the customer complaint subsystem receives a new complaint event, it will trigger the problem allocation subsystem to assign the complaint problem to the corresponding customer service personnel, and call the knowledge base subsystem to provide the customer service personnel with reference information for solving the problem. This event-triggered call relationship can ensure that when the system faces a specific event, the various subsystems work together to handle the problem. Another example is that in a security monitoring system, when the intrusion detection subsystem detects an abnormal intrusion event, it will trigger the alarm subsystem to sound an alarm, and call the event recording subsystem to record the detailed information of the intrusion event. This call relationship is event-driven. The intrusion detection subsystem acts as an event source to trigger the operation of the alarm subsystem and the event recording subsystem.

[0099] Therefore, during the analysis, the record documents of the interface system can be read according to the management files of the API interface management platform to identify the hidden call relationships as accurately as possible.

[0100] S103: Determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the multiple business subsystems.

[0101] Among them, the system identification data is used to uniquely identify and distinguish the key information of different business subsystems. For example, it may include: subsystem name, number, version number, data source identifier, etc. In a complex business system, the system identification data can be used to accurately locate a specific subsystem, and effective calls and data sharing between subsystems can be achieved. Therefore, the system call graph can be constructed based on the system identification data instead of the subsystem, making the graph information more concise.

[0102] It is understandable that for each business subsystem, its main business functions can be analyzed and key data representing the functions can be extracted as identification data. For example, in the user management subsystem, its core function is to manage user information and user permissions, etc., then "user account" is a typical system identification data, because it can uniquely identify each user in the system, and it is used in many operations related to the subsystem, such as user login verification and permission allocation.

[0103] Specifically, the system identification data is further analyzed according to the calling relationship between the business subsystems. For example, the input parameters received by the business subsystem when called by other subsystems and the data output to the outside are analyzed to select key identification elements.

[0104] S104. Fill the system identification data corresponding to the multiple business subsystems into the preset template to generate graph data between the multiple business subsystems.

[0105] The preset template can be used to store the calling relationships between business subsystems and each other. For example, it can include: subsystem A (i.e., the initiator of the calling relationship); subsystem B (i.e., the called target subsystem); calling type (an optional field used to describe the nature of the calling relationship, such as synchronous calling, asynchronous calling, event triggering, etc.); calling frequency, etc. The format can be, for example, "[Business subsystem A] [identification data A] calls [business subsystem B]".

[0106] It can be understood that the system identification data (such as subsystem name, number, etc.) of each business subsystem is filled into the appropriate position of the template, that is, each subsystem is represented as an independent entity (or node) in the template. Then, the calling relationship between the business subsystems can be added, for example, by specifying the connection between subsystem A and subsystem B in the template.

[0107] Taking the financial leasing system as an example, its subsystems may include, for example, the customer management subsystem, the pre-lease investigation subsystem, the lease contract management subsystem, the rent payment management subsystem, the asset management subsystem, etc. Through the above processing, for example, the following graph data can be obtained: the "customer identification information" in the customer management subsystem provides the basic information of the survey object for the pre-lease investigation subsystem, and can also be the basis for the lease contract management subsystem to associate specific customers, and can also be the key reference for the rent payment management subsystem to clarify the rent payment subject.

[0108] S105. Construct a system call relationship graph of the business system based on the graph data.

[0109] Among them, the graph data can clearly define the goal of the call relationship graph to be constructed, such as identifying key systems, analyzing dependencies between systems, predicting potential problems, etc., and based on the graph data, it can include: log files, API call records, system configuration files, database records, etc., to identify the call relationships between systems.

[0110] It can be understood that the business subsystem can be determined as a graph node, and the call relationship can be determined as the edge of the graph, where each node has a unique identifier, each edge has a direction (from the caller to the callee), and can contain weights (indicating call frequency, importance, etc.). Based on the above processing, corresponding nodes and edges are created in the graph model, and a system call relationship graph can be generated using visualization tools.

[0111] The system call relationship graph construction method, device, equipment and storage medium provided in the embodiments of the present application determine the business system and business data, and obtain the management information of the API management platform; determine the multiple business subsystems in the business system and the call relationship between the multiple business subsystems based on the business system, business data and management information; determine at least one system identification data corresponding to each business subsystem based on the call relationship between the multiple business subsystems; fill the system identification data corresponding to the multiple business subsystems into the preset template to generate the graph data between the multiple business subsystems; and construct the system call relationship graph of the business system based on the graph data. By identifying the critical paths in the system call relationship, the main interaction processes between the systems are understood, and the dependencies between the systems are analyzed to identify potential risk points and bottlenecks. According to the results of the graph analysis, the system is optimized and reconstructed to improve the stability and efficiency of the system. At the same time, when a failure occurs, the graph can be used to quickly locate the problem and take corresponding repair measures.

[0112] Figure 2 Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 2 ,like Figure 2 As shown, in this embodiment Figure 1 Based on the embodiment, a method for constructing a system call relationship graph is described in detail, and the method includes:

[0113] S201. Determine the business system and business data, and obtain management information of the API management platform.

[0114] Among them, step S201 is similar to the above-mentioned step S101, and this application will not repeat them here.

[0115] S202: Determine the business information corresponding to the business system, and analyze and process the business information to obtain a plurality of sub-business information.

[0116] Among them, the scope of business information can be determined according to the business objectives corresponding to the business system. Here, taking the financial leasing business system as an example, its corresponding business information is also financial leasing information. In order to obtain complete financial leasing information, customer-related information, leasing project-related information, contract-related information, asset-related information, and financial-related information are required. The above information is sub-business information.

[0117] S203: Determine a corresponding business subsystem according to the multiple sub-business information.

[0118] It can be understood that the data source of the sub-business information is the business subsystem, and the business needs of the business system can be met by calling the data of the business subsystem.

[0119] It should be noted that the sub-business information may also include lower-level information. For example, customer-related information may include customer credit information, customer evaluation information, etc. For the systems under the subsystem, the above method can be repeated for further analysis according to construction needs, and this solution will not be repeated here.

[0120] S204: According to the multiple business subsystems, determine the business logic data corresponding to each business subsystem from the business data.

[0121] The business data may be extracted from a database of an enterprise or a business provider, and the basic business data may be filtered to obtain core or key data, thereby simplifying the business data.

[0122] It is understandable that business data can be mapped to the corresponding business subsystem according to the functional requirements and business processes of the subsystem to ensure that each subsystem can determine the business logic data it needs. For each subsystem, the specific meaning, format and source of its corresponding business logic data can be clarified so that the business logic data can accurately reflect the business requirements and business processes of the subsystem.

[0123] S205: Analyze and process the management information of the API management platform to obtain interface information of multiple API interfaces.

[0124] Among them, the case set of API automated testing and the log records of test execution. This part of data records the calling relationship between interfaces. Such data can include two-dimensional tables and data in jason format. You can also obtain a basic list of all registered API interfaces from the interface of the API management platform or related management documents, and analyze the API interface information from it.

[0125] It can be understood that the API interface information may include: interface name, interface version number, business system or module to which it belongs, and external system or module, etc.

[0126] S206. The calling large model determines the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces.

[0127] Among them, the business logic data of each business subsystem can be obtained, including data fields, data types, data flows, etc., and all related API interface information, including interface name, function description, input parameters, output parameters, calling methods (such as HTTP request methods, URL paths), authentication methods, etc.

[0128] The above data is input into the big model to limit the scope of the result data of the big model. The big model can determine the calling relationship between subsystems based on the relevance of business logic data and the function of API interface, and identify the direction of calling relationship (such as which subsystem calls which subsystem), calling frequency, data transmission method, etc.

[0129] S207: Use regular expressions to analyze and process the calling relationships between multiple business subsystems to determine at least one system identification data corresponding to each business subsystem.

[0130] The format of the system identifier can be defined. For example, if the system identifier has a certain format, such as subsys_A, where A can be the identifier of the subsystem. The format of the call relationship can also be defined. Assuming that the call relationship is recorded in text form, for example, subsys_A points to subsys_B, which means that subsystem A calls subsystem B. Then, a regular expression is used to extract each subsystem and its identifier.

[0131] It can be understood that regular expressions can be used to extract all unique subsystem identifiers from the call relationship.

[0132] S208: Determine the variables to be filled and the filling rules corresponding to the preset template.

[0133] The filling module may be, for example, "[Business subsystem A]'s [identification data A] calls [business subsystem B]", wherein the set filling rule may be that only the system identification data of the corresponding attribute can be filled in the corresponding variable to ensure the accuracy of the filling.

[0134] S209: Use system identification data corresponding to multiple business subsystems as variables to be filled, and fill them into a preset template according to filling rules to obtain multiple groups of triplet data.

[0135] Among them, triple data can represent a fact about a resource, with two nodes (subject and object) and a predicate connecting them.

[0136] It can be understood that taking the output result of "System A has a table called orders, containing order information" as an example, the corresponding triple data obtained can be <"system A", "orders table", "order information">, where this is the triple data describing the specific data. The system points to the corresponding triple data, which is similar to the above construction process, and this application will not go into details here.

[0137] S210. Construct a corresponding RDF graph based on multiple sets of triple data, and use the RDF graph as a system call relationship graph of the business system.

[0138] Among them, for triple data, the main node can correspond to the subject part in the triple data, and the attribute node can correspond to the predicate part in the triple data. Taking the financial leasing business system as an example, the main node can include the customer number, project number, contract number and other identifiers representing different business objects, as well as the names of various business subsystems, which are the core entity elements in the diagram; the attribute node can include "customer type", "company name", "credit score", "lease term", etc. These nodes are used to describe the specific system attribute characteristics of the main node.

[0139] Edges represent the relationship between a subject node and an attribute node or between different subject nodes. They correspond to the predicates in the triple data. Arrows are used to indicate the direction, reflecting the association and call relationship between data. For example, an edge from a customer number node to a customer type node indicates that the customer has a specific type attribute; an edge from a customer management subsystem node to a pre-rental investigation subsystem node indicates that there is a call relationship or data transfer relationship from customer management to pre-rental investigation.

[0140] It can be understood that in the drawing area, each subject node can be drawn according to the business subsystem and important identification data, and then attribute nodes can be added and connected. For example, the triples between the business subsystems, such as the relevant triples that reflect the association between the customer management subsystem and the pre-rental investigation subsystem (such as the case of citing the customer number in the pre-rental investigation), lead an edge from the "customer management subsystem" node to the "pre-rental investigation subsystem" node, and annotate the specific content of the data transfer on the edge (such as "transferring customer information through the customer number"), so as to reflect the calling relationship between the business subsystems.

[0141] According to the above method, all nodes and edges corresponding to triple data are added to the graph, and the positions of nodes and the directions of edges are continuously adjusted to make the entire RDF graph structure clear and easy to understand.

[0142] In a possible implementation, the RDF graph is imported into a graph database for execution processing to obtain an execution result; when no error is reported in the execution result, it is determined that the system call relationship graph is successfully constructed.

[0143] Among them, you can choose a graph database that is easy to implement, and the specific database selection is not limited here.

[0144] It is understandable that after successfully importing RDF graph data into the graph database, some query operations are performed using the query language supported by the graph database (such as Neo4j's Cypher language) to verify whether the data is correctly imported and whether the graph structure is complete and reasonable.

[0145] When executing the above query statements or other related verification operations, carefully check the result information returned by the graph database. If the query results returned are in line with the expectations, and there are no error messages such as "Syntax error", "Node not found", "Relationship type mismatch", etc., it means that the RDF graph has been successfully imported into the graph database, and the system call relationship graph construction is successful, and its structure and data can be correctly represented and queried in the graph database.

[0146] On the contrary, if an error message appears, you need to troubleshoot the problem according to the error prompt. It may be that the imported data format does not meet the requirements, resulting in some data parsing errors, Cypher query statements are written incorrectly, or there are problems such as inaccurate node relationship definitions when the RDF graph is initially constructed. You need to make corresponding adjustments and corrections based on the specific error cause, re-import the data and verify until the execution result is error-free and meets the expected business system call relationship.

[0147] The system call relationship graph construction method provided in the embodiment of the present application can clearly and intuitively serve as the system call relationship graph of the business system by constructing a system call relationship graph, presenting the complex relationships and call processes between various business subsystems and between different business objects and attributes in the business system, making it convenient for business personnel, technical personnel, etc. to understand the operating logic of the entire business system, and also helping with subsequent system optimization, expansion, and maintenance.

[0148] Figure 3 Schematic diagram of the process of constructing the system call relationship graph provided in this application Figure 3 ,like Figure 3 As shown, in this embodiment Figure 2 Based on the embodiment, a process of calling a large model to analyze and determine the calling relationship between multiple business subsystems is described in detail. The method includes:

[0149] S301. Input business logic data and interface information of multiple API interfaces into the large model.

[0150] Among them, the business logic data corresponding to each business subsystem can be clearly sorted and formatted. For example, for the customer management subsystem in the financial leasing business system, the relevant data including basic customer information (such as customer number, name, contact information, etc.), customer credit information (credit score, credit rating, etc.) and customer classification identification are sorted out; for the lease contract management subsystem, the business logic data such as contract number, contract terms (rent payment, lease term, etc.), contract execution status (signed, in execution, terminated, etc.) are sorted out, and these data classified by subsystem are sorted into structured documents or data sets for input into the big model.

[0151] The interface information of multiple API interfaces is also organized, including interface names (such as "Get Customer Information API", "Create Lease Contract API", etc.), interface function descriptions (detailed descriptions of the business operations that can be implemented by the interface, such as "Get the customer's complete credit and basic information through the customer number"), request parameters (for example, the request parameters of the "Get Customer Information API" may include "customer number", etc.), return values ​​(the returned data structure and specific meaning, such as returning detailed customer information in JSON format), and the business module to which the interface belongs (corresponding to a specific business subsystem, such as the "Get Customer Information API" and the related interface of the customer management subsystem). This information is also organized into a standardized format and entered into the big model to facilitate the big model's reading and analysis.

[0152] It is understandable that the sorted business logic data and API interface information can be accurately input according to the input method required by the big model. For example, the big model can pass in data content in JSON format through API calls. At this time, the above two types of data can be converted into JSON format that meets the requirements and submitted in corresponding fields respectively; if input through a text box, it should be input into the interactive interface of the big model according to a clear text structure (such as describing the business logic data first, then describing the API interface information, with separation and annotation in between). The specific input method is not limited in this solution.

[0153] S302: The large model analyzes and processes the business logic data and the interface information of multiple API interfaces according to preset rules to determine the data association information and data reference information between the multiple business logic data.

[0154] S303: The large model outputs the calling relationship between multiple business subsystems based on the data association information and the data reference information.

[0155] Understandably, the goal of determining the calling relationship between business subsystems can be clearly communicated to the big model. For example, it can be expressed in natural language, such as "Please analyze and determine the calling relationship between each business subsystem based on the business logic data and API interface information of each subsystem of the financial leasing business provided, and output a clear calling relationship diagram and corresponding text description" to make the big model understand the specific task requirements; or choose prompt words to convey the requirements. Through the form of prompt words, let the big model extract possible dependencies from the text, and then let it output all possible dependencies through fixed output.

[0156] Specifically, the big model can use its pre-trained knowledge and powerful logical reasoning ability to comprehensively analyze the data association of different subsystems in the business logic data and the interaction between API interfaces in each subsystem based on the input data. For example, the big model can identify that the customer information data in the customer management subsystem will be used as an important input for the pre-lease investigation subsystem to carry out risk assessment (by calling the relevant data through the "Get Customer Information API"), thereby inferring that the customer management subsystem has a calling relationship with the pre-lease investigation subsystem; for another example, during the execution of the contract, the lease contract management subsystem needs to use the "Get Asset Status API" (this API belongs to the asset management subsystem related interface) to understand the real-time status of the leased assets, and then determine that there is a calling relationship between the lease contract management subsystem and the asset management subsystem.

[0157] The big model will give the results related to the calling relationship between business subsystems according to the set output requirements. For example, it will use clear text paragraphs to explain in detail the calling relationship between each business subsystem, such as "The customer management subsystem will call the pre-rental investigation subsystem, specifically by providing the customer's basic information and credit information, and using the 'Get Customer Details API' to assist the pre-rental investigation subsystem in conducting a comprehensive assessment of the customer. After completing the assessment, the pre-rental investigation subsystem will return the risk assessment result data to the customer management subsystem through the 'Update Customer Risk Information API' to update the customer's risk level record."

[0158] The overall process is illustrated as follows:

[0159] First, the task description is "analyze a set of table structures and API interface information from different systems, and infer the possible calling relationships between systems based on this information; the goal is to build a system call relationship graph, where each node represents a system and each edge represents a potential calling relationship." Secondly, the input information is "table structure information (the name of the database table of each system, the name of the field in the table and its data type, and the relationship between tables)" and "API interface information (the name of the API interface of each system, the input parameters and return type of the interface, and the document description of the interface)".

[0160] Based on the above information, the specific analysis steps can be:

[0161] First, analyze the table structure, including identifying the core tables and key fields of each system; analyze the relationships between tables, especially foreign key constraints, to understand how data flows between systems.

[0162] Secondly, analyze the API interfaces, including reading the document description of each API interface and looking for references to other systems or data sources; analyzing the input parameters of the interface to see if they match the table structure or API output of other systems; and checking the return types of the interface to see if they provide data that other systems may need.

[0163] Next, the calling relationship is constructed, including: inferring the calling relationship between systems based on the association relationship of the table structure and the dependency relationship of the API interface; if the API interface of one system uses the data of another system (whether directly through database query or through API call), a calling relationship is established between the two systems.

[0164] The last step is verification and adjustment, which includes using domain knowledge and system documentation to verify whether the inferred calling relationship is reasonable; adjusting the calling relationship graph as needed to ensure its accuracy and completeness.

[0165] The output obtained through the above process includes a system call relationship graph, in which each node represents a system and each edge represents a potential call relationship; and for each call relationship, a brief description is provided to explain why it is believed that there is a call relationship between the two systems.

[0166] Taking two subsystems: system A and system B as examples, the input can be obtained as follows: system A has a table named orders, which contains order information; system B has a table named order_details, which contains detailed order information, and the order_details table has a foreign key pointing to the orders table of system A; system B also provides an API interface getOrderDetails, which accepts an order ID as input and returns detailed information of the order.

[0167] The system call relationship graph construction method provided in the embodiment of the present application can efficiently and accurately sort out the call relationship between business subsystems based on business logic data and API interface information by calling a large model for analysis, thereby providing strong support for subsequent system optimization, integration, and improvement of business processes.

[0168] Figure 4 A schematic diagram of the structure of the system call relationship graph construction device provided in this application, such as Figure 4 As shown, the system call relationship graph construction device 400 provided in this embodiment includes:

[0169] Determination module 401, used to determine the business system and business data, and obtain management information of the API management platform;

[0170] The determination module 401 is further used to determine multiple business subsystems in the business system and the calling relationship between the multiple business subsystems according to the business system, the business data and the management information, wherein the sub-business information corresponding to the business subsystem is associated with the business information corresponding to the business system;

[0171] The determination module 401 is further configured to determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems;

[0172] A generating module 402, used to fill the system identification data corresponding to the plurality of business subsystems into a preset template, and generate graph data between the plurality of business subsystems;

[0173] The construction module 403 is used to construct a system call relationship graph of the business system according to the graph data.

[0174] In a possible implementation, the device further includes: an analysis module 404;

[0175] The determination module 401 is further used to determine the business information corresponding to the business system, and analyze and process the business information to obtain a plurality of sub-business information, wherein there is an association relationship between the sub-business information and the business information;

[0176] The determination module 401 is further configured to determine a corresponding business subsystem according to the plurality of sub-business information;

[0177] The determination module 401 is further used to determine the business logic data corresponding to each business subsystem from the business data according to the multiple business subsystems, wherein the business logic data is used to indicate the core business logic involved in the business process of the business subsystem;

[0178] The analysis module 404 is used to analyze and process the management information of the API management platform to obtain interface information of multiple API interfaces;

[0179] The determination module 401 is further used to call the large model to determine the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces.

[0180] In a possible implementation, the device further includes: an input module 405;

[0181] The input module 405 is used to input the business logic data and the interface information of the multiple API interfaces into the large model;

[0182] The big model analyzes and processes the business logic data and the interface information of the multiple API interfaces according to preset rules, determines the data association information and data reference information between the multiple business logic data, and outputs the calling relationship between the multiple business subsystems based on the data association information and the data reference information, wherein the data association information is used to indicate the data flow relationship between the multiple business subsystems, and the data reference information is used to indicate the data dependency relationship between the multiple business subsystems.

[0183] In a possible implementation, the analysis module 404 is further used to use regular expressions to analyze and process the calling relationships between the multiple business subsystems to determine at least one system identification data corresponding to each business subsystem, wherein the system identification data includes but is not limited to: system name, system properties and version information.

[0184] In a possible implementation, the device further includes: a filling module 406;

[0185] The determination module 401 is further used to determine the variables to be filled and the filling rules corresponding to the preset template;

[0186] The filling module 406 is used to use the system identification data corresponding to the multiple business subsystems as variables to be filled, and fill them into the preset template according to the filling rule to obtain multiple groups of triplet data;

[0187] The determination module 401 is further used to use the multiple groups of triplet data as graph data between the multiple business subsystems.

[0188] In a possible implementation, the construction module 403 is further used to construct a corresponding RDF graph according to the multiple sets of triple data;

[0189] The determination module 401 is further configured to use the RDF graph as a system call relationship graph of the business system.

[0190] In a possible implementation manner, the device further includes: an execution device 407;

[0191] The execution device 407 is used to import the RDF graph into a graph database for execution processing to obtain an execution result;

[0192] The determination module 401 is further configured to determine that the system call relationship graph is constructed successfully when no error occurs in the execution result.

[0193] The system call relationship graph construction device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.

[0194] Figure 5 A schematic diagram of the structure of the device for building the system call relationship graph provided in this application. Figure 5 As shown, the system call relationship graph construction device 500 provided in this embodiment includes: at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected via a bus 504.

[0195] In a specific implementation process, at least one processor 501 executes the computer-executable instructions stored in the memory 502, so that at least one processor 501 executes the above method.

[0196] The specific implementation process of the processor 501 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0197] In the above embodiments, it should be understood that the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the invention can be directly implemented as a hardware processor, or can be implemented by a combination of hardware and software modules in the processor.

[0198] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[0199] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0200] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0201] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0202] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0203] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0204] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0205] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0206] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0207] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0208] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0209] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.< / person> < / bob>

Claims

1. A method for constructing a system call relationship graph, characterized in that: include: Identify business systems and business data, and obtain management information from the API management platform; Determine, according to the business system, the business data and the management information, a plurality of business subsystems in the business system and a calling relationship between the plurality of business subsystems, wherein sub-business information corresponding to the business subsystem is associated with business information corresponding to the business system; Determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems; Filling the system identification data corresponding to the plurality of business subsystems into a preset template to generate graph data between the plurality of business subsystems; Based on the graph data, a system call relationship graph of the business system is constructed.

2. The method according to claim 1, characterized in that Determining a plurality of business subsystems in the business system and a calling relationship between the plurality of business subsystems according to the business system, the business data and the management information includes: Determine the business information corresponding to the business system, and analyze and process the business information to obtain a plurality of sub-business information, wherein there is an association relationship between the sub-business information and the business information; Determine a corresponding business subsystem according to the plurality of sub-business information; According to the plurality of business subsystems, determining business logic data corresponding to each business subsystem from the business data, wherein the business logic data is used to indicate the core business logic involved in the business process of the business subsystem; Analyze and process the management information of the API management platform to obtain interface information of multiple API interfaces; The calling big model determines the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces.

3. The method according to claim 2, characterized in that The calling big model determines the calling relationship between the multiple business subsystems based on the business logic data corresponding to the multiple business subsystems and the interface information of the multiple API interfaces, including: Inputting the business logic data and the interface information of the plurality of API interfaces into a large model; The big model analyzes and processes the business logic data and the interface information of the multiple API interfaces according to preset rules, determines the data association information and data reference information between the multiple business logic data, and outputs the calling relationship between the multiple business subsystems based on the data association information and the data reference information, wherein the data association information is used to indicate the data flow relationship between the multiple business subsystems, and the data reference information is used to indicate the data dependency relationship between the multiple business subsystems.

4. The method according to claim 3, characterized in that The step of determining at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems includes: Regular expressions are used to analyze and process the calling relationships between the multiple business subsystems to determine at least one system identification data corresponding to each business subsystem, wherein the system identification data includes but is not limited to: system name, system attributes and version information.

5. The method according to claim 4, characterized in that The step of filling the system identification data corresponding to the plurality of business subsystems into a preset template to generate graph data between the plurality of business subsystems includes: Determine the variables to be filled and the filling rules corresponding to the preset template; Taking the system identification data corresponding to the plurality of business subsystems as variables to be filled, and filling them into the preset template according to the filling rule, to obtain a plurality of groups of triplet data; The multiple groups of triplet data are used as graph data between the multiple business subsystems.

6. The method according to claim 5, characterized in that The step of constructing a system call relationship graph of the business system according to the graph data includes: Constructing a corresponding RDF graph according to the multiple sets of triple data; The RDF graph is used as the system call relationship graph of the business system.

7. The method according to claim 6, characterized in that The method further comprises: Importing the RDF graph into a graph database for execution processing to obtain an execution result; When no error occurs in the execution result, it is determined that the system call relationship graph is constructed successfully.

8. A system call relationship graph construction device, characterized in that: include: The determination module is used to determine the business system and business data and obtain the management information of the API management platform; The determination module is further used to determine multiple business subsystems in the business system and the calling relationship between the multiple business subsystems according to the business system, the business data and the management information, wherein the sub-business information corresponding to the business subsystem is associated with the business information corresponding to the business system; The determination module is further used to determine at least one system identification data corresponding to each business subsystem according to the calling relationship between the plurality of business subsystems; A generation module, used to fill the system identification data corresponding to the plurality of business subsystems into a preset template, and generate graph data between the plurality of business subsystems; A construction module is used to construct a system call relationship graph of the business system based on the graph data.

9. A system call relationship graph construction device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images