Component dependency relationship processing method and device, equipment and storage medium

Abstract

The invention provides a component dependency relationship processing method and device, equipment and a storage medium. Relates to the technical field of big data. The method comprises the steps that the category of enterprise-level components is determined based on the research and development process of the enterprise-level components, and the enterprise-level components are classified into open source components, public components in an enterprise and private components; based on the category, determining a dependency relationship between the enterprise-level component and other components, the dependency relationship including at least one of direct dependency, transfer dependency and total dependency; constructing an enterprise-level application dependency panoramic view based on component dimensions on the basis of at least one of direct dependency, transfer dependency and total dependency in the dependency relationship; and performing global monitoring on the enterprise-level component based on the enterprise-level application dependent panoramic view. According to the method provided by the invention, the problem that effective monitoring and governance optimization of the global governance process of the enterprise component cannot be carried out in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of big data technology, and in particular to a component dependency processing method, device, equipment and storage medium. Background Art

[0002] The architecture governance of enterprise-level applications has always been a relatively advanced and complex topic in the IT field. Different enterprises have different understandings and perceptions of enterprise-level architecture. A scientific and complete description of the scope and level division of enterprise-level architecture can effectively guide business and IT teams to transform enterprise strategic goals and enterprise business knowledge into enterprise IT capabilities and business operation capabilities, and to integrate business operations and IT systems.

[0003] At present, in some financial enterprises, enterprise-level architecture is generally considered to be a description of the enterprise's business operations and IT support framework, including business architecture and IT architecture. IT architecture includes application architecture, data architecture, technical architecture and security architecture.

[0004] In actual applications, although the enterprise has divided the architecture into layers, it is unable to effectively perform maintenance and control. Summary of the invention

[0005] The present application provides a component dependency processing method, device, equipment and storage medium to solve the problem in the prior art that internal components of an enterprise cannot be effectively and globally managed.

[0006] In a first aspect, the present application provides a method for processing component dependencies, including:

[0007] Based on the R&D process of the enterprise-level components, determining the categories of the enterprise-level components, wherein the enterprise-level components are classified into open source components, public components within the enterprise, and private components;

[0008] Based on the category, determining the dependency relationship between the enterprise-level component and other components, wherein the dependency relationship includes at least one of direct dependency, transitive dependency and full dependency;

[0009] Based on at least one of direct dependency, transitive dependency and full dependency in the dependency relationship, a component-based panoramic view of enterprise-level application dependencies is constructed;

[0010] Based on the enterprise-level application dependency panoramic view, the enterprise-level components are globally monitored. In a possible design, the enterprise-level component-based R&D process determines the category of the enterprise-level components, including:

[0011] Obtaining a publishing medium for the enterprise-level component;

[0012] If the enterprise-level component is published in an open source repository, determining that the enterprise-level component is an open source component;

[0013] If the enterprise-level component is published in a shared resource library within the enterprise, then the enterprise-level component is determined to be a public component within the enterprise;

[0014] If the enterprise-level component is published in a private repository of a specific organization in a public repository within an enterprise, it is determined that the enterprise-level component is a private component.

[0015] In a possible design, determining the dependency relationship between the enterprise-level component and other components based on the category includes:

[0016] If the enterprise-level component is an open source component, obtaining a definition description file of the enterprise-level component from an open source repository;

[0017] The definition description file is parsed to determine the dependency relationship of the enterprise-level components.

[0018] In a possible design, determining the dependency relationship between the enterprise-level component and other components based on the category includes:

[0019] If the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an intermediate dependent component, where the intermediate dependent component is a component that cannot be deployed independently and is used by other components or other applications for dependency;

[0020] If the enterprise-level component is the intermediate dependent component, obtaining a direct dependency from a definition description file of the enterprise-level component, wherein the direct dependency is a component dependency relationship defined in the definition description file of the enterprise-level component;

[0021] Based on the component dependency view and the direct dependency, the transitive dependency and full dependency of the enterprise-level component are obtained, wherein the transitive dependency is the dependency relationship defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

[0022] In one possible design, the method further includes:

[0023] Acquire version information from a definition description file of the enterprise-level component, wherein the version information includes a version number of a component that has a dependency relationship with the enterprise-level component;

[0024] Based on the version information, determining whether the enterprise-level component has a dependency relationship with multiple versions of the same component;

[0025] If the enterprise-level component has dependencies with multiple versions of the same component, version deduplication is performed.

[0026] In a possible design, determining the dependency relationship between the enterprise-level component and other components based on the category includes:

[0027] If the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an independently deployable application, wherein the independently deployable application is an application that can be independently deployed in a physical device, a virtual device, or a container and includes a clear startup entry and an independent main process;

[0028] If the enterprise-level component is an independently deployed application, then continue to determine whether the enterprise-level component is a reusable independently deployed application or a single deployed application, wherein the reusable independently deployed application includes a public application for a specific field of an enterprise or a multi-project group, and the single deployed application includes a business application of the enterprise for a specific business, and the business application includes a standard business application and a non-standard business application;

[0029] If the enterprise-level component is a reusable independently deployable application or a standard business application in the single deployable application, the direct dependency is obtained from the definition description file of the enterprise-level component, and the dependency relationship of the enterprise-level component is determined based on the direct dependency.

[0030] In a possible design, determining the dependency relationship between the enterprise-level component and other components based on the category includes:

[0031] If the enterprise-level component is a non-standard business application in the single deployment application, obtaining the direct dependency of the enterprise-level component from the component content view of the enterprise-level component;

[0032] Acquire other dependent components that are directly dependent on the enterprise-level component;

[0033] Determine whether there is a target component matching the other dependent components in the enterprise component library;

[0034] If the target component exists, then establishing a dependency relationship of the enterprise-level component based on the target component;

[0035] If the target component does not exist, a non-standard component publishing task is established, and the non-standard component publishing task is used to supplement the component information of the enterprise-level component.

[0036] In one possible design, the method further includes:

[0037] If the enterprise-level component is a business application or a public application, a version change record history of other components that have a dependency relationship with the enterprise-level component is established.

[0038] In one possible design, the method further includes:

[0039] If the enterprise-level component is an open source component, the properties of the open source component are verified, and the open source component is monitored based on the enterprise's external security risk information and the enterprise's internal security and vulnerability scan results. The properties of the open source component include security, effectiveness, and compliance;

[0040] If the enterprise-level component is a public component or a private component within the enterprise, a scanning operation is performed on the public component or the private component within the enterprise to obtain a problem rectification report of the public component or the private component within the enterprise, and the scanning operation includes at least one of a security scan and a virus scan.

[0041] In a second aspect, the present application provides a component dependency processing device, including:

[0042] A category determination module, used to determine the category of the enterprise-level component based on the R&D process of the enterprise-level component, wherein the enterprise-level component is classified into open source components, public components within the enterprise, and private components;

[0043] A relationship determination module, configured to determine, based on the category, a dependency relationship between the enterprise-level component and other components, wherein the dependency relationship includes at least one of direct dependency, transitive dependency and full dependency;

[0044] A view building module, used to build a component-based enterprise-level application dependency panoramic view based on at least one of direct dependency, transitive dependency and full dependency in the dependency relationship;

[0045] A global monitoring module is used to perform global monitoring on the enterprise-level components based on the enterprise-level application dependency panoramic view.

[0046] In a third aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method described in the first aspect and various possible designs of the first aspect.

[0047] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the method described in the first aspect and various possible designs of the first aspect are implemented.

[0048] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the method described in the first aspect and various possible designs of the first aspect.

[0049] The component dependency processing method, device, equipment and storage medium provided in this application are based on the R&D process of enterprise-level components, and establish corresponding component dependencies for enterprise-level components of various technical levels, namely, open source components, enterprise-level components, and private components. The above component dependencies are used to establish a panoramic view of enterprise-level application dependencies based on component dimensions, so as to achieve global control and risk analysis of enterprise-level component dependencies. It can achieve effective monitoring and governance of the global component governance process. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] 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.

[0051] Figure 1 Schematic diagram of enterprise-level IT architecture infrastructure provided for embodiments of the present application;

[0052] Figure 2 A flowchart of a method for processing component dependencies applicable to an embodiment of the present application;

[0053] Figure 3 Schematic diagram of the asset release management process provided in the embodiment of this application;

[0054] Figure 4 A flowchart of a dependency relationship acquisition method provided in an embodiment of the present application;

[0055] Figure 5 A schematic diagram of the structure of a fuzzy testing device provided in an embodiment of the present application;

[0056] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0057] 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

[0058] 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.

[0059] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data involved shall comply with the provisions of relevant laws and regulations and shall not violate public order and good morals.

[0060] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0061] The architecture governance of enterprise-level applications has always been a relatively advanced and complex topic in the IT field. Because architecture itself is a high-level abstraction, organizations of different sizes and different analytical perspectives have different views. For example, from the perspective of most application developers or small enterprises, technical components or component frameworks such as Spring Cloud, Dubbo, and Spring Framework are enterprise-level architectures. Distributed service strategies and end-to-end monitoring are usually the responsibilities of architects. However, in some large financial enterprises, based on the industry-leading architectural perspectives and concepts, financial enterprises will scientifically divide the enterprise-level architecture in an orderly manner based on the strategic goals of the enterprise. For example, a large bank has made the following definition of enterprise-level architecture: Enterprise-level architecture is a description of the enterprise business operation and IT support framework, including business architecture and IT architecture. Among them, IT architecture includes application architecture, data architecture, technical architecture, and security architecture. The above description scientifically and completely describes the scope and hierarchical division of enterprise-level architecture, and can effectively guide business and IT teams to transform enterprise strategic goals and enterprise business knowledge into enterprise IT capabilities and business operation capabilities, and to integrate business operations and IT systems.

[0062] However, in traditional large banks, since their main business is banking, the personnel roles of the enterprise have a good understanding of banking business and clear governance ideas. Therefore, they often have good division capabilities and management ideas in the management of business architecture and application architecture in IT architecture. However, in other areas of IT architecture (such as technical architecture), due to professional reasons, there is no clear hierarchical division and effective governance structure. In practice, although the enterprise has divided the architecture level and governance field, there is no effective management method and tool implementation. The existing component dependency management only includes the dependency source warehouse management and oral and written notification forms, lacking effective monitoring means and governance optimization measures for the overall governance process. And there is a lack of effective monitoring measures for key information such as the version used.

[0063] In response to the above problems, this application provides a technical component dependency governance solution for enterprises. This solution combines the enterprise-level R&D process and the actual infrastructure to conduct multi-dimensional analysis and governance of the technical component dependencies of the Java application system, and provides effective management and control means and measures for the governance of technical components in the enterprise-level IT architecture.

[0064] 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.

[0065] For example, Figure 1 The schematic diagram of the enterprise-level IT architecture infrastructure provided by the embodiment of this application provides an IT component and dependency management method and tool based on the enterprise-level IT management platform and enterprise-level IT architecture infrastructure. Figure 1 As shown in Figure 1, in the enterprise-level IT architecture and system, there are the following infrastructures: ① Enterprise-level IT management platform, which is used for online and structured management of enterprise-level R&D processes and assets. ② Enterprise-level dependency warehouse (reference Figure 1 ③ Document system, used to implement the release and notification of enterprise-level specifications and standards. ④ Artifact building and release process and pipeline, used to implement the construction, release and verification of enterprise-level application products. ⑤ Artifact scanning and verification tools, used to parse artifacts and perform specific verification operations, such as security vulnerability scanning, virus scanning, etc.

[0066] The following will be combined Figure 1 The method for handling component dependencies in this application is described in detail. Figure 2FIG. 1 is a flow chart of a method for processing component dependencies applicable to an embodiment of the present application. Figure 2 As shown, it specifically includes the following steps:

[0067] Step S210: Based on the R&D process of the enterprise-level components, the categories of the enterprise-level components are determined, wherein the enterprise-level components are classified into open source components, public components within the enterprise, and private components.

[0068] In this embodiment, the R&D process includes component release, component asset management, component dependency management, component security risk management, etc., where component release is divided into open source component release, enterprise public component release and private component release.

[0069] Open source component release means that the assets of open source components come from open source repositories, such as the Maven central repository, or enterprise-level open source component repositories released by various open source components, such as the public component repositories provided by the Apache organization and the Spring organization. For open source components, a trusted enterprise component gateway or proxy repository can be provided, which is open to various project teams and systems within the enterprise to achieve controlled access to open source components within the enterprise.

[0070] Among them, the release of public components within an enterprise means: public components within an enterprise are developed by a responsible unit or project team within the enterprise, and are global general components used by all projects and applications within the enterprise, or are domain business components widely used in a certain business field. Enterprise-level public components include enterprise-level security components and access client components for key systems (such as single sign-on client components, etc.). Public components within an enterprise are released in the internal shared resource library of the enterprise, and are released, updated, and repaired by specific responsible units for maintenance work, and are open to the enterprise for use.

[0071] Among them, private component release means: private components are components used by a system or project team within an enterprise in a single application or multiple applications. Based on the project-level or application-level layered architecture principle, they are components shared by a single project or application. Such components are published in the private warehouse of a specific organization in the enterprise's public warehouse for independent use by the project team or application. Their release, update, problem fixing and other maintenance work are completed independently by the specific organization.

[0072] Among them, in the component release, based on the release carrier that the enterprise-level component is facing, it can be determined what category of component the enterprise-level component belongs to. For example, if the enterprise-level component is released in an open source warehouse, the enterprise-level component is determined to be an open source component; if the enterprise-level component is released in an internal shared resource library of the enterprise, the enterprise-level component is determined to be a public component within the enterprise; if the enterprise-level component is released in a private warehouse of a specific organization in the public warehouse within the enterprise, the enterprise-level component is determined to be a private component.

[0073] In this embodiment, technical components are divided into open source components, public components within the enterprise, and private components based on their categories. Components of different categories are published in different warehouses to facilitate permission management. For example, when internal personnel of an enterprise need to obtain open source components, they are given permission to access the open source warehouse. For some private components with higher privacy, since they are published in the private warehouse of a specific organization, even if internal personnel of the enterprise have access rights to the open source warehouse, they cannot obtain the private components, which facilitates the management and control of components.

[0074] Furthermore, since different categories of components are published in different warehouses, the technical components in the enterprise have multiple sources, multiple warehouses, multiple levels of authority, multiple management organizations, and other issues. The traditional component management system based on a unified silo or fixed process becomes complicated and impractical. Therefore, in some embodiments, for multiple categories of components published in different warehouses, a facet management process based on the key process nodes of the enterprise development process is proposed for asset release management, so that components in each warehouse can be under management. Figure 3 The asset release management process diagram provided in the embodiment of the present application specifically includes the following steps:

[0075] Step S310: Open source component introduction: The IT department can set up a public open source component gateway to act as an agent for mainstream central warehouses and open warehouses of open source organizations at home and abroad for the outside of the enterprise. For the inside of the enterprise, it provides access to controlled open source components.

[0076] Step S320: Management and control of public components within the enterprise: The IT department can set up a central warehouse for enterprise-level public technical components to uniformly provide global access to public components within the enterprise. The responsible department for the component shall perform maintenance work such as release, update and withdrawal of the component, and supervise and guide the work.

[0077] Step S330: Private component management: The IT department can set up a unified project-level private warehouse, or open management and control permissions to the project team at a specific level of the enterprise-level project warehouse. The project team is the primary responsible department for component release, update, withdrawal and other maintenance work.

[0078] Different management and control strategies are applied to the categories of enterprise-level components. Specifically, if the enterprise-level component is an open source component, the properties of the open source component are verified, and the open source component is monitored based on the external security risk information and the internal security and vulnerability scan results of the enterprise; if the enterprise-level component is a public or private component within the enterprise, the public or private component within the enterprise is scanned to obtain a problem rectification report for the public or private component within the enterprise.

[0079] Among them, the attributes of the open source component include security, effectiveness, and compliance, and the scanning operation includes at least one of security scanning and virus scanning.

[0080] In addition, during the asset release control process, you can also configure specific functional departments of the enterprise to implement the control of open source components, public components within the enterprise, and private components. Figure 3 , which specifically also includes the following steps:

[0081] Step S340: Perform global regulatory control work such as security scanning, virus scanning, and various regulatory scanning on public components and private components within the enterprise. Global control is initiated by a specific organization, and a problem rectification report is generated and sent to the product project team for problem rectification.

[0082] Step S350: For open source components, specific functional departments of the enterprise are responsible for the security, effectiveness, and compliance of open source components. Based on external security risk information and internal security and vulnerability scanning results, timely release risk and vulnerability warnings and replacement and deprecation notifications for open source components that enter the enterprise's control scope. By configuring corresponding control strategies for open source components, public components within the enterprise, and private components, the security of components can be guaranteed.

[0083] Step S220: Based on the category, determine the dependency relationship between the enterprise-level component and other components, wherein the dependency relationship includes at least one of direct dependency, transitive dependency and full dependency;

[0084] In this embodiment, the IT department establishes a component dependency management and control platform on the enterprise-level IT management platform to record the dependency relationships of various components. Component dependencies are divided into direct dependencies, transitive dependencies, and full dependencies. Among them, direct dependencies are component dependencies defined in the definition description file of the component. Transitive dependencies are dependencies defined in the definition description file of the component that the component directly depends on and the resulting multi-level transitive dependencies. Full dependencies are the union of direct dependencies and transitive dependencies.

[0085] In particular, in some implementations, when an enterprise-level component is released, the developer submits a definition description file, which may include version information (e.g., version number) of the enterprise-level component and may also include version numbers of other components that have dependencies on the enterprise-level component. When a component has dependencies on multiple versions of the same component, version deduplication may be performed.

[0086] Version deduplication refers to the selection of specific component version uniqueness based on enterprise-level version uniqueness rules. The version deduplication rules for component dependencies can refer to industry standards in the field of Java component management and control, or they can be adjusted or independently formulated.

[0087] By performing unique selection of a specific component version, the embodiment of the present application can reduce the complexity of the dependency relationship of the component, and the constructed enterprise-level application dependency panoramic view is clearer, which is convenient for global monitoring of enterprise-level components. At the same time, it is also convenient to strengthen the control of component versions.

[0088] Step S230: Based on at least one of direct dependency, transitive dependency and full dependency in the dependency relationship, a component-dimensional enterprise-level application dependency panoramic view is constructed.

[0089] Step S240: Based on the enterprise-level application dependency panoramic view, the enterprise-level components are globally monitored.

[0090] In this embodiment, the enterprise-level IT platform should use the above-mentioned component dependencies to establish a panoramic view of enterprise-level application dependencies based on component dimensions, so as to achieve global management and risk analysis of enterprise-level component dependencies, and issue rectification instructions and guidance suggestions for specific applications when specific component vulnerability risks occur.

[0091] The embodiment of the present application defines the management and control methods of a unified component library, multiple technical component levels such as open source components, enterprise-level components, and private components, and the technical component management and control processes and methods based on product scanning and IT architecture management platforms, thereby ultimately achieving a comprehensive management and control method from the technical component dimension of the enterprise-level IT architecture, and providing corresponding management and control tools, which can optimize the enterprise component management and control process and improve the management and control effect of enterprise components.

[0092] The above has described in detail how to implement a comprehensive management and control approach for the technical components of an enterprise-level IT architecture. The following will use some examples to illustrate how to determine component dependencies based on component dependency management and processes.

[0093] As mentioned above, enterprise-level components can be classified into open source components, public components within the enterprise, and private components. Different categories of components have different ways of obtaining dependencies. Based on this, in some embodiments, if the enterprise-level component is an open source component, the definition description file of the enterprise-level component is obtained from the open source warehouse; and the definition description file is parsed to determine the dependency of the enterprise-level component.

[0094] In this embodiment, the component management and control module of the enterprise-level IT management platform is responsible for the storage and management of component definitions and component dependency relationship data. For open source component dependency and management, Java's open source component dependency technology can be used. The dependency hierarchy of Java open source technology components is already included in the standard central warehouse and the open warehouse of the open source organization. The IT department uses xml and json parsing tools to perform dependency description document parsing and scanning on the open source components that enter the enterprise's control scope to form a standard open source component dependency tree.

[0095] As for the dependency management of public and private components within an enterprise, the IT achievements developed by an enterprise generally include two categories: intermediate dependency components and independently deployed applications. Therefore, in other embodiments, if the enterprise-level component is an intermediate dependency component, the direct dependency is obtained from the definition description file of the enterprise-level component; based on the component dependency view and the direct dependency, the transitive dependency and full dependency of the enterprise-level component are obtained.

[0096] Among them, direct dependency is the component dependency defined in the definition description file of the enterprise-level component. Transitive dependency is the dependency defined in the definition description file of other components that have direct dependencies on the enterprise-level component. Full dependency is the union of direct dependency and transitive dependency.

[0097] In this embodiment, the intermediate dependency component is a component that cannot be deployed independently but is used by other components or applications. Such components are usually integrated into the deployable application and released uniformly when the application is deployed. Independently deployable applications refer to software that can be independently deployed in physical devices, virtual devices or containers, and has a clear startup entry and an independent main process.

[0098] For intermediate dependent components, when submitting components, the responsible department must upload the component definition description file synchronously in accordance with the component definition description file specifications specified by the enterprise. The definition description file contains the component's direct dependency description and component coordinates (unique identifier). After receiving the component upload event, the component dependency library reads and parses the definition description file and uploads the component direct dependency to the component management and control module. The component dependency management and control module receives the upload event, searches the internal component dependency view, searches for all component transitive dependencies, and forms component transitive dependency data and component full dependency data.

[0099] In particular, according to the component definition description file specification, the component definition description also includes a summary value of a specific version of the component calculated based on one or more summary algorithms. The summary value is generally calculated in the component warehouse or product library and uploaded to the corresponding control module of the enterprise-level IT management platform for control.

[0100] In other embodiments, if the enterprise-level component is an independently deployed application, it is necessary to further classify the independently deployed application and then adopt different strategies to obtain the corresponding dependencies. Figure 4 A flowchart of a dependency relationship acquisition method provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, it includes the following steps:

[0101] Step S410: Determine whether the enterprise-level component is an independently deployable application.

[0102] Step S420: If the enterprise-level component is an independently deployable application, continue to determine whether the enterprise-level component is a reusable independently deployable application or a single deployable application.

[0103] Step S430: If the enterprise-level component is a reusable independently deployable application or a standard business application in a single deployable application, obtain direct dependencies from the definition description file of the enterprise-level component, and determine the dependency relationship of the enterprise-level component based on the direct dependencies.

[0104] Step S440: If the enterprise-level component is a non-standard business application, the direct dependency of the enterprise-level component is obtained from the component content view of the enterprise-level component.

[0105] Step S450: Acquire other dependent components that are directly dependent on the enterprise-level component.

[0106] Step S460: Determine whether there is a target component in the enterprise component library that matches other dependent components.

[0107] Step S470: If the target component exists, then a dependency relationship of the enterprise-level component is established based on the target component.

[0108] Step S480: If the target component does not exist, a non-standard component publishing task is created. The non-standard component publishing task is used to supplement the component information of the enterprise-level component.

[0109] In this embodiment, reusable deployable applications can be divided into public applications for specific fields or multiple project groups, such as enterprise-level service gateway applications, project construction applications, etc. Independently deployable components can be applications for specific businesses, such as personal financial service applications, etc. Public applications are published in the public application product library. Business applications are built into standard products according to enterprise-level business application specifications and published. For public applications, a component definition description file will be submitted when uploading the application. When receiving the public application, the product library will also receive the component definition description file and upload the component definition description file according to the existing specifications. The component management module uses the aforementioned method to parse the file, read the direct dependencies, and calculate the transitive dependencies and full dependencies.

[0110] In addition, business applications can be divided into two types: standard business applications built according to component definition description file specifications and non-standard business applications. For standard business applications, when the artifact library receives the standard business application, it also receives the artifact description file and uploads the artifact description file according to the existing specifications. The component management module uses the aforementioned method to parse the artifact description file and read the direct dependencies, calculate the transitive dependencies and the full dependencies. In addition, the dependency relationship of the standard business application needs to establish a dependency relationship with the corresponding application data on the enterprise-level IT management platform.

[0111] For non-standard business applications, after receiving the artifact, the artifact library sends an artifact scanning and verification event. The artifact scanning and verification tool scans and deconstructs the artifact according to the enterprise-level business application specifications. Independently deployed applications are discovered from enterprise-level artifacts, and the artifact deconstruction tool is used to analyze the artifact content to obtain an artifact content view, which includes the direct dependencies of the artifact.

[0112] For example, taking the business application product of a financial enterprise as an example, its standard product structure includes the following contents in order of hierarchy: ① application name; ② published application compressed package; ③ published application document. Among them, the published application compressed package includes a file with the suffix war format and a file with the suffix sh format.

[0113] Among them, the war format file with the suffix is ​​the application function component, and the sh format file is the deployment startup instruction file. The product scanning and verification tool deconstructs the product according to the above standard structure, and reads the actual dependent component content of the project from the internal specific directory of the war format file (generally / WEB-INF / lib). For all files in the above directory (generally ***.jar type files), read the file name and the file-specific digest algorithm calculation value. The product scanning and verification tool uploads the above scanning results to the component management module. After receiving the uploaded data, the component management module matches each dependent component in the component library according to the file digest algorithm calculation value. The steps are as follows:

[0114] First, enterprise standard components are matched (including open source components, public components within the enterprise, and private components). If the match is successful, a dependency relationship with the standard components is established and relevant information is supplemented.

[0115] Secondly, the enterprise non-standard components are matched. If the match is successful, the dependency relationship with the non-standard components is established and the relevant information is supplemented.

[0116] Finally, if no defined component is matched, a non-standard component release task is established, key information such as component name, summary value, and related deployment applications are recorded, and the task is released to the responsible department of the non-standard business application, which fills in and submits relevant information of the non-standard business application. Based on the nature of the non-standard business application and whether it is an open source component, the relevant department will conduct review, security scanning, vulnerability scanning, and other operations. Finally, a non-standard business application is formed. In addition, an alternative solution can be used to exclude and replace the non-standard business application.

[0117] The embodiment of the present application further classifies public components and private components within the enterprise, and configures different dependency acquisition strategies for components of different subclasses. This can relatively reduce the complexity of dependency acquisition and quickly generate a panoramic view of enterprise-level application dependencies based on component dimensions.

[0118] In addition, in some other embodiments, each official version released to the component repository is immutable. To this end, for business applications and public applications, the component dependency repository can establish a version change record history of its dependent components. Based on the version change history, the changes of specific components can be queried to discover the potential risks caused by component dependency version changes to the application.

[0119] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0120] Figure 5 A schematic diagram of the structure of the fuzzy testing device provided in the embodiment of the present application is shown in FIG. Figure 5 As shown, the component dependency processing device 500 includes a category determination module 510 , a relationship determination module 520 , a view construction module 530 , and a global monitoring module 540 .

[0121] Among them, the category determination module 510 is used to determine the category of enterprise-level components based on the R&D process of enterprise-level components. Enterprise-level components are classified into open source components, public components within the enterprise, and private components. The relationship determination module 520 is used to determine the dependency relationship between enterprise-level components and other components based on the category. The dependency relationship includes at least one of direct dependency, transitive dependency, and full dependency. The view construction module 530 is used to construct an enterprise-level application dependency panoramic view based on the component dimension based on at least one of direct dependency, transitive dependency, and full dependency in the dependency relationship. The global monitoring module 540 is used to perform global monitoring of enterprise-level components based on the enterprise-level application dependency panoramic view.

[0122] Optionally, the category determination module can be specifically used to: obtain the publishing carrier of the enterprise-level component; if the enterprise-level component is published in an open source repository, determine that the enterprise-level component is an open source component; if the enterprise-level component is published in an internal shared resource library of the enterprise, determine that the enterprise-level component is a public component within the enterprise; if the enterprise-level component is published in a private repository of a specific organization in the public repository within the enterprise, determine that the enterprise-level component is a private component.

[0123] Optionally, the relationship determination module can be specifically used to: if the enterprise-level component is an open source component, obtain a definition description file of the enterprise-level component from an open source repository; parse the definition description file to determine the dependency relationship of the enterprise-level component.

[0124] Optionally, the relationship determination module can be specifically used for: if the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an intermediate dependency component, and the intermediate dependency component is a component that cannot be deployed independently and is used for dependency by other components or other applications; if the enterprise-level component is an intermediate dependency component, then obtain the direct dependency from the definition description file of the enterprise-level component, and the direct dependency is the component dependency relationship defined in the definition description file of the enterprise-level component; based on the component dependency view and direct dependency, obtain the transitive dependency and full dependency of the enterprise-level component, and the transitive dependency is the dependency relationship defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

[0125] Optionally, it also includes a version deduplication module, which is used to obtain version information from the definition description file of the enterprise-level component, the version information including the version number of the component that has a dependency relationship with the enterprise-level component; based on the version information, determine whether the enterprise-level component has a dependency relationship with multiple versions of the same component; if the enterprise-level component has a dependency relationship with multiple versions of the same component, perform version deduplication.

[0126] The relationship determination module can be specifically used for: if the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an independently deployable application. An independently deployable application is an application that can be independently deployed in a physical device, a virtual device, or a container, and contains a clear startup entry and an independent main process; if the enterprise-level component is an independently deployable application, then continue to determine whether the enterprise-level component is a reusable independently deployable application or a single deployable application. Reusable independently deployable applications include public applications for specific areas of the enterprise or multiple project teams. Single deployable applications include business applications for specific businesses of the enterprise. Business applications include standard business applications and non-standard business applications; if the enterprise-level component is a reusable independently deployable application If the enterprise-level component is a standard business application in an application or a single deployment application, the direct dependency is obtained from the definition description file of the enterprise-level component, and the dependency relationship of the enterprise-level component is determined based on the direct dependency; if the enterprise-level component is a non-standard business application, the direct dependency of the enterprise-level component is obtained from the component content view of the enterprise-level component; other dependent components that have direct dependencies on the enterprise-level component are obtained; it is determined whether there is a target component in the enterprise component library that matches the other dependent components; if there is a target component, the dependency relationship of the enterprise-level component is established based on the target component; if there is no target component, a non-standard component release task is established, and the non-standard component release task is used to supplement the component information of the enterprise-level component.

[0127] Optionally, a recording module is also included, which is used to establish a version change record history of other components that have a dependency relationship with the enterprise-level component if the enterprise-level component is a business application or a public application.

[0128] Optionally, it also includes a detection module, which is used to verify the properties of the open source component if the enterprise-level component is an open source component, and monitor the open source component based on the external security risk information of the enterprise and the internal security and vulnerability scanning results of the enterprise. The properties of the open source component include security, effectiveness, and compliance; if the enterprise-level component is a public or private component within the enterprise, a scanning operation is performed on the public or private component within the enterprise to obtain a problem rectification report for the public or private component within the enterprise, and the scanning operation includes at least one of a security scan and a virus scan.

[0129] The device provided in the embodiments of the present application can be used to execute the method in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0130] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software called by processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware. For example, the message acquisition module can be a separately established processing element, or it can be integrated in a chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a processing element of the above device. The function of the above message acquisition module. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0131] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 6 As shown, the electronic device 600 includes: at least one processor 601, a memory 602, a bus 603 and a communication interface 604. Among them: the processor, the communication interface and the memory communicate with each other through the bus. The communication interface is used to communicate with other devices. The communication interface includes a communication interface for data transmission and a display interface or an operation interface for human-computer interaction.

[0132] The processor is used to execute the computer-executable instructions stored in the memory, and specifically can execute the relevant steps in the method described in the above embodiment.

[0133] The processor may be a central processing unit, or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement an embodiment of the present invention. The one or more processors included in the review device may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The memory is used to store computer execution instructions. The memory may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk memory.

[0134] This embodiment also provides a computer-readable storage medium, in which computer instructions are stored. When at least one processor of an electronic device executes the computer instructions, the electronic device executes the methods provided in the above-mentioned various implementation modes.

[0135] This embodiment also provides a computer program product, which includes computer instructions stored in a readable storage medium. At least one processor of the electronic device can read the computer instructions from the readable storage medium, and at least one processor executes the computer instructions so that the electronic device implements the methods provided in the above various embodiments.

[0136] In the present application, "at least one" means one or more, and "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship; in the formula, the character " / " indicates that the previous and next associated objects are in a "division" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0137] 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.

[0138] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing component dependencies, characterized in that: include: Based on the R&D process of the enterprise-level components, determining the categories of the enterprise-level components, wherein the enterprise-level components are classified into open source components, public components within the enterprise, and private components; Based on the category, determining the dependency relationship between the enterprise-level component and other components, wherein the dependency relationship includes at least one of direct dependency, transitive dependency and full dependency; Based on at least one of direct dependency, transitive dependency and full dependency in the dependency relationship, a component-based panoramic view of enterprise-level application dependencies is constructed; Based on the enterprise-level application dependency panoramic view, the enterprise-level components are globally monitored.

2. The method according to claim 1, characterized in that The R&D process based on the enterprise-level components determines the category of the enterprise-level components, including: Obtaining a publishing medium for the enterprise-level component; If the enterprise-level component is published in an open source repository, determining that the enterprise-level component is an open source component; If the enterprise-level component is published in a shared resource library within the enterprise, then the enterprise-level component is determined to be a public component within the enterprise; If the enterprise-level component is published in a private repository of a specific organization in a public repository within an enterprise, it is determined that the enterprise-level component is a private component.

3. The method according to claim 1 or 2, characterized in that: Determining the dependency relationship between the enterprise-level component and other components based on the category includes: If the enterprise-level component is an open source component, obtaining a definition description file of the enterprise-level component from an open source repository; The definition description file is parsed to determine the dependency relationship of the enterprise-level components.

4. The method according to claim 1 or 2, characterized in that: Determining the dependency relationship between the enterprise-level component and other components based on the category includes: If the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an intermediate dependent component, where the intermediate dependent component is a component that cannot be deployed independently and is used by other components or other applications for dependency; If the enterprise-level component is the intermediate dependent component, obtaining a direct dependency from a definition description file of the enterprise-level component, wherein the direct dependency is a component dependency relationship defined in the definition description file of the enterprise-level component; Based on the component dependency view and the direct dependency, the transitive dependency and full dependency of the enterprise-level component are obtained, wherein the transitive dependency is the dependency relationship defined in the definition description file of other components that have direct dependencies on the enterprise-level component, and the full dependency is the union of the direct dependency and the transitive dependency.

5. The method according to claim 4, characterized in that The method further comprises: Acquire version information from a definition description file of the enterprise-level component, wherein the version information includes version numbers of components that have a dependency relationship with the enterprise-level component; Based on the version information, determining whether the enterprise-level component has a dependency relationship with multiple versions of the same component; If the enterprise-level component has dependencies with multiple versions of the same component, version deduplication is performed.

6. The method according to claim 1 or 2, characterized in that: Determining the dependency relationship between the enterprise-level component and other components based on the category includes: If the enterprise-level component is a public component or a private component within the enterprise, then continue to determine whether the enterprise-level component is an independently deployable application, wherein the independently deployable application is an application that can be independently deployed in a physical device, a virtual device, or a container and includes a clear startup entry and an independent main process; If the enterprise-level component is an independently deployed application, then continue to determine whether the enterprise-level component is a reusable independently deployed application or a single deployed application, wherein the reusable independently deployed application includes a public application for a specific field of an enterprise or a multi-project group, and the single deployed application includes a business application of the enterprise for a specific business, and the business application includes a standard business application and a non-standard business application; If the enterprise-level component is a reusable independently deployable application or a standard business application in the single deployable application, the direct dependency is obtained from the definition description file of the enterprise-level component, and the dependency relationship of the enterprise-level component is determined based on the direct dependency.

7. The method according to claim 6, characterized in that Determining the dependency relationship between the enterprise-level component and other components based on the category includes: If the enterprise-level component is a non-standard business application in the single deployment application, obtaining the direct dependency of the enterprise-level component from the component content view of the enterprise-level component; Acquire other dependent components that are directly dependent on the enterprise-level component; Determine whether there is a target component matching the other dependent components in the enterprise component library; If the target component exists, then establishing a dependency relationship of the enterprise-level component based on the target component; If the target component does not exist, a non-standard component publishing task is established, and the non-standard component publishing task is used to supplement the component information of the enterprise-level component.

8. The method according to claim 6, characterized in that The method further comprises: If the enterprise-level component is a business application or a public application, a version change record history of other components that have a dependency relationship with the enterprise-level component is established.

9. The method according to claim 1, characterized in that: The method further comprises: If the enterprise-level component is an open source component, the properties of the open source component are verified, and the open source component is monitored based on the enterprise's external security risk information and the enterprise's internal security and vulnerability scan results. The properties of the open source component include security, effectiveness, and compliance; If the enterprise-level component is a public component or a private component within the enterprise, a scanning operation is performed on the public component or the private component within the enterprise to obtain a problem rectification report of the public component or the private component within the enterprise, and the scanning operation includes at least one of a security scan and a virus scan.

10. A component dependency processing device, characterized in that: include: A category determination module, used to determine the category of the enterprise-level component based on the R&D process of the enterprise-level component, wherein the enterprise-level component is classified into open source components, public components within the enterprise, and private components; A relationship determination module, configured to determine, based on the category, a dependency relationship between the enterprise-level component and other components, wherein the dependency relationship includes at least one of direct dependency, transitive dependency and full dependency; A view building module, used to build a component-based enterprise-level application dependency panoramic view based on at least one of direct dependency, transitive dependency and full dependency in the dependency relationship; A global monitoring module is used to perform global monitoring on the enterprise-level components based on the enterprise-level application dependency panoramic view.

11. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 9.

12. 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 9 when executed by a processor.

13. A computer program product, characterized in that The invention comprises a computer program for implementing the method according to any one of claims 1 to 9 when the computer program is executed by a processor.

Images