Resource processing method and system, electronic equipment and storage medium

Abstract

The invention discloses a resource processing method and system, electronic equipment and a storage medium. The method can comprise the steps that the scene type of a scene where a to-be-processed resource is located is determined, and the scene type is used for representing the type of operation executed on the to-be-processed resource in the scene; an expansion strategy matched with the scene type and metadata matched with the scene type are determined, the expansion strategy is used for representing a rule for expanding the to-be-processed resource according to an expansion level matched with the scene type, and the metadata is used for describing a format and / or content defined by the to-be-processed resource in a scene of the scene type; according to an expansion strategy, the to-be-processed resources are expanded on the expansion level by means of the metadata, and target resources are obtained; and executing an operation corresponding to the scene type on the target resource to obtain an operation result. The technical problem of low flexibility of resource processing is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular, to a resource processing method, system, electronic device and storage medium. Background Art

[0002] At present, with the gradual deepening of informatization, resource management has become an increasingly prominent challenge. In related technologies, resource processing platforms are often limited to basic archiving and directory services when processing these assets. This processing method has significant limitations in resource description, definition, type support and scalability.

[0003] Specifically, the description of assets in the resource processing platform in the relevant technology is often superficial, lacking in-depth systematic explanation and clear definition, which leads to deviations in the application and understanding of assets in different scenarios. It is also limited by preset asset types, such as documents, code libraries, etc., and cannot flexibly adapt to the asset types in various emerging and specific scenarios encountered by enterprises in their development, which limits the scope of application of the platform and the optimal allocation of enterprise resources. Due to the limitations of the design of the asset processing platform, there is a lack of effective mechanisms to accept and integrate the extension of external systems or custom asset types, which hinders the iteration and upgrade of platform functions, as well as deep integration with other internal systems and external services of the enterprise. The asset archiving method of the resource processing platform is often fixed and rigid, which makes it difficult to meet the flexible processing and customization needs of enterprises for resources, such as resource combination, splitting, conversion and other operations.

[0004] In summary, the asset management platform in the relevant technology is not able to cope with the complex and changeable resources accumulated over the years within the enterprise, and its processing methods and capabilities are insufficient. Therefore, there is still a technical problem of low flexibility in resource processing.

[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present application provide a resource processing method, system, electronic device and storage medium to at least solve the technical problem of low flexibility in resource processing.

[0007] According to one aspect of an embodiment of the present application, a method for processing resources is provided. The method may include: determining a scenario type of a scenario in which a resource to be processed is located, wherein the scenario type is used to indicate the type of operation performed on the resource to be processed in the scenario; determining an extension strategy matching the scenario type, and metadata matching the scenario type, wherein the extension strategy is used to indicate a rule for extending the resource to be processed according to an extension level matching the scenario type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scenario of the scenario type; according to the extension strategy, using the metadata to extend the resource to be processed at the extension level to obtain a target resource; performing an operation corresponding to the scenario type on the target resource to obtain an operation result.

[0008] According to another aspect of the embodiment of the present application, a method for processing enterprise assets is provided. The method is applied to an asset processing platform and may include: determining the scenario type of the scenario in which the enterprise asset to be processed is located, wherein the scenario type is used to indicate the type of operation performed on the enterprise asset to be processed in the scenario; determining an extension point matching the scenario type, and asset metadata matching the scenario type, wherein the extension point is used to indicate the rule for extending the enterprise asset to be processed according to the extension level matching the scenario type, and the asset metadata is used to describe the format and / or content defined by the enterprise asset to be processed in the scenario of the scenario type; according to the extension point, using the asset metadata to extend the enterprise asset to be processed at the extension level to obtain the target enterprise asset; performing the operation corresponding to the scenario type on the target enterprise asset to obtain the asset mirror file of the target enterprise asset in the scenario.

[0009] According to another aspect of the embodiment of the present application, a method for processing resources is provided. The method may include: responding to an operation instruction acting on an operation interface, determining the scene type of the scene in which the resource to be processed is located, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene; displaying an extension policy matching the scene type and metadata matching the scene type on the operation interface, wherein the extension policy is used to indicate the rule for extending the resource to be processed according to the extension level matching the scene type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scene of the scene type; displaying the target resource corresponding to the resource to be processed on the operation interface, wherein the target resource is obtained by extending the resource to be processed at the extension level using the metadata according to the extension policy; and displaying the operation result obtained by performing the operation corresponding to the scene type on the target resource on the operation interface.

[0010] According to another aspect of the embodiment of the present application, a method for processing resources is provided. The method may include: determining the scene type of the scene in which the resource to be processed is located by calling the first interface, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene by calling the first interface; determining an extension strategy matching the scene type, and metadata matching the scene type, wherein the extension strategy is used to indicate the rule for extending the resource to be processed according to the extension level matching the scene type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scene of the scene type; according to the extension strategy, using the metadata to extend the resource to be processed at the extension level to obtain the target resource; performing the operation corresponding to the scene type on the target resource to obtain the operation result; outputting the operation result by calling the second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter is the operation result.

[0011] According to another aspect of the embodiment of the present application, a resource processing system is provided. The system may include: a client, for uploading a resource processing request, wherein the resource processing request is used to request processing of a resource to be processed; at least one resource processing platform, for responding to the resource processing request, determining the scene type of the scene in which the resource to be processed is located, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene; determining an extension policy matching the scene type, and metadata matching the scene type, wherein the extension policy is used to indicate the rule for extending the resource to be processed according to the extension level matching the scene type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scene of the scene type; according to the extension policy, using the metadata to extend the resource to be processed at the extension level to obtain the target resource; performing the operation corresponding to the scene type on the target resource to obtain the operation result; and sending the operation result to the client.

[0012] According to another aspect of the embodiment of the present application, an electronic device is provided. The electronic device may include a memory and a processor: the memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the method of the embodiment of the present application is implemented.

[0013] According to another aspect of an embodiment of the present application, a processor is further provided. The processor is used to run a program, wherein the above method of the embodiment of the present application is executed when the program is running.

[0014] According to another aspect of the embodiment of the present application, a computer-readable storage medium is further provided. The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the storage medium is located is controlled to execute the above method of the embodiment of the present application.

[0015] According to another aspect of the embodiment of the present application, a computer program product is also provided. The computer program product includes a computer program, and when the computer program is executed by a processor, the method of the embodiment of the present application is implemented.

[0016] In the embodiment of the present application, by determining the scenario type of the scene in which the resource to be processed is located, it is possible to identify and adapt to different operational requirements, such as the production, synchronization, and installation of resources, etc., to ensure that the processing process is accurately matched with the current business scenario, avoid the "one-size-fits-all" management method, and improve the pertinence and applicability of resource processing. After determining the expansion strategy that matches the scenario type, the expansion rules and levels can be dynamically adjusted according to the characteristics of the resource and the scenario requirements, which means that resource processing is no longer limited to the preset framework, but can be flexibly expanded according to actual conditions, greatly enhancing the flexibility and adaptability of resource processing. Through the use of metadata, the definition of resources under any scenario type becomes clear and structured. Metadata can not only describe the basic information of resources, but also describe the manifestation and operational requirements of resources in specific scenarios, providing a unified and detailed information basis for resource processing. By setting an expansion level that matches the scenario type, users can customize the expansion of asset materials, the expansion of the entire asset, and the expansion of asset processes. Through the above-mentioned multi-level expansion capabilities, it is ensured that the resource processing method can meet the diversified and deeply customized needs of enterprises for asset management. Based on the extension strategy and metadata, the resources to be processed can be quickly extended and transformed to obtain the target resources, and the operations corresponding to the scenario type can be performed on the target resources.

[0017] In this embodiment, through scene type identification, extension policy customization, metadata drive and multi-level extension, the low flexibility in traditional resource management in related technologies is avoided, thereby achieving the technical effect of improving the flexibility of resource processing and solving the technical problem of low flexibility of resource processing.

[0018] It is easy to notice that the above general description and the following detailed description are only for the purpose of exemplifying and explaining the present application, and do not constitute a limitation of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] Figure 1 is a schematic diagram of an application scenario of a resource processing method according to an embodiment of the present application;

[0021] Figure 2is a flow chart of a method for processing resources according to an embodiment of the present application;

[0022] Figure 3 is a flow chart of a method for processing enterprise assets according to an embodiment of the present application;

[0023] Figure 4 is a flowchart of another resource processing method according to an embodiment of the present application;

[0024] Figure 5 is a flowchart of another resource processing method according to an embodiment of the present application;

[0025] Figure 6 is a schematic diagram of a resource processing system according to an embodiment of the present application;

[0026] Figure 7 is a schematic diagram of an asset extension point according to an embodiment of the present application;

[0027] Figure 8 is a flow chart of an asset production process according to an embodiment of the present application;

[0028] Fig. 9 is a flow chart of an asset synchronization process according to an embodiment of the present application;

[0029] Fig.10 is a flow chart of an asset installation process according to an embodiment of the present application;

[0030] Fig.11 is a schematic diagram of a distributed asset management and operation platform architecture according to an embodiment of the present application;

[0031] Fig.12 is a schematic diagram of a resource processing device according to an embodiment of the present application;

[0032] Fig.13 is a schematic diagram of another resource processing device according to an embodiment of the present application;

[0033] Fig.14 is a schematic diagram of another resource processing device according to an embodiment of the present application;

[0034] Fig.15 is a schematic diagram of another resource processing device according to an embodiment of the present application;

[0035] Fig.16 is a structural block diagram of a computer terminal according to an embodiment of the present application;

[0036] Fig.17 is a block diagram of an electronic device for a resource processing method according to an embodiment of the present application;

[0037] Fig.18 It is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a resource processing method according to an embodiment of the present application;

[0038] Fig.19 It is a structural block diagram of a computing environment of a resource processing method according to an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0040] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned 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 data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to the above-mentioned process, method, product or device.

[0041] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following explanations:

[0042] Enterprise Information Technology (IT) heterogeneous assets, referred to as assets, in enterprise IT, assets usually refer to a relatively independent functional component within the enterprise, which may be composed of multiple heterogeneous atomic products. These atomic products include but are not limited to multiple images, source codes, document descriptions, etc., which together constitute a complete functional component, i.e., an asset;

[0043] Asset image is an asset file in a special format that can be recognized by the asset center (HUB). It is a collection of heterogeneous assets composed of multiple atomic products. As an important part of the asset HUB, asset image is a heterogeneous asset file in a special format composed of multiple atomic products. It has rich functions and features, which can help enterprises better manage and utilize assets and improve IT operation efficiency and management level;

[0044] Asset materials are a general term for atomic products contained in asset images. The asset materials can be abstracted into a relatively independent atomic product. Asset materials can be various types of assets, such as source code, rich text, files, etc., and can also include user-defined materials. In general, asset materials are a general term for various atomic products in asset images, including multiple types of assets. These asset materials together constitute a complete asset image, helping enterprises to define, manage, and operate assets.

[0045] According to an embodiment of the present application, a method for processing resources is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0046] The resource processing method provided in the embodiment of the present application can be applied to Figure 1 The application scenarios shown are not limited to these. Figure 1 In the application scenario shown, the server 10 can be a cloud, in which a resource processing platform can be deployed. The server 10 can be connected to one or more client devices 20 via a local area network connection, a wide area network connection, an Internet connection, or other types of data networks. The client devices 20 here may include but are not limited to: smart phones, tablet computers, laptops, PDAs, personal computers, smart home devices, vehicle-mounted devices, etc. The client devices together constitute the client relative to the server. An operating interface for user operation can be deployed on the graphical user interface on the client device. The client device 20 can interact with the user through the graphical user interface to implement the resource processing method provided in the embodiment of the present application.

[0047] In the embodiment of the present application, the system composed of the client device 20 and the server 10 can perform the following steps: if a certain resource to be processed needs to be processed, the user can perform corresponding operations on the client device 20 according to his own needs to select or input the resource to be processed. The resource to be processed can be transmitted to the server 10 through the network 30. Specifically, the following steps can be performed in the server 10: step S102, determining the scene type of the scene where the resource to be processed is located; step S104, determining the extension strategy matching the scene type, and the metadata matching the scene type; step S106, according to the extension strategy, using the metadata to expand the resource to be processed at the extension level to obtain the target resource; step S108, performing the operation corresponding to the scene type on the target resource to obtain the operation result.

[0048] In the above process, the operation result obtained by processing the resources to be processed in the server 10 can be sent to the client device 20 through the network 30. The operation result can be displayed on the client device 20 for the user to view.

[0049] In the embodiments of the present application, through scene type identification, extension strategy customization, metadata-driven and multi-level extension, the low flexibility, weak customization capability, low operational efficiency and other problems in traditional resource management in related technologies are avoided, thereby achieving the technical effect of improving the flexibility of resource processing and solving the technical problem of low flexibility of resource processing.

[0050] The present application embodiment proposes the following method. In the above application scenario, the present application provides the following Figure 2 The processing method of the resource shown. Figure 2 is a flow chart of a method for processing resources according to an embodiment of the present application, such as Figure 2 As shown, the method may include the following steps:

[0051] Step S202, determining the scene type of the scene where the resource to be processed is located.

[0052] In the technical solution provided in the above step S202 of the present application, the resource to be processed may be an asset, for example, a computer electronic asset. If the application scenario for the resource to be processed is an enterprise, the resource to be processed may be an enterprise IT resource, for example, an enterprise IT heterogeneous asset. The scenario may be a usage scenario for the resource to be processed. The scenario type may be used to indicate the type of operation performed on the resource to be processed in the scenario, for example, the scenario type may be a resource production, resource synchronization, or resource installation type, which is only for example and not specifically limited.

[0053] In this embodiment, if the resource to be processed needs to be processed, the scene type of the scene in which the resource to be processed is located can be determined.

[0054] Optionally, the resource processing method in the embodiment of the present application can be executed using a corresponding platform for resource management and operation, for example, a resource management system. If the resource to be processed is an asset, the resource management system can be an asset management system, for example, an asset HUB. In enterprise IT resource management, resources may be in different life cycle stages, including but not limited to resource creation, distribution, synchronization, deployment, installation, etc. The scenario type can be determined based on the purpose and objectives of the resource at a specific point in time.

[0055] Optionally, the choice of scenario type provides guidance for subsequent specific operations, ensuring the flexibility and applicability of resource processing. Different scenario types correspond to different operational requirements and processes. For example, resource production may require the creation of new combinations from elements such as source code and images; resource synchronization may involve the transmission, conversion, or update of data; and resource installation may require configuration and deployment in a specific IT environment. By clarifying the scenario type, the corresponding processing flow can be dynamically called and configured, avoiding the limitation of single operation on resource management.

[0056] Optionally, each scenario type has its own unique customized processing requirements. For example, in the resource production scenario, metadata can be collected and organized; in the resource synchronization scenario, network transmission and permission verification can be processed; in the resource installation scenario, environment adaptation and dependency management are performed. By accurately determining the scenario type, it can be ensured that the resource processing method can meet these customized requirements in a targeted manner, improving the efficiency and quality of resource processing.

[0057] Step S204: determining an extension strategy that matches the scene type and metadata that matches the scene type.

[0058] In the technical solution provided in the above step S204 of the present application, the extension strategy can be used to represent the rule for extending the resource to be processed according to the extension level matching the scenario type, which can also be called an extension point. Metadata can be used to describe the format and / or content defined by the resource to be processed in the scenario of the scenario type, for example, it can be data describing the format and content of the asset image.

[0059] In this embodiment, after determining the scene type of the scene in which the resource to be processed is located, an expansion strategy matching the scene type may be determined, and metadata matching the scene type may also be determined.

[0060] Optionally, determining the extension strategy that matches the scenario type and the metadata that matches the scenario type is the core dynamic configuration link in the resource processing method. The extension strategy can be a mechanism for guiding the resource processing method on how to extend and customize the resource processing flow according to a specific scenario type. In the architecture of the asset HUB, the extension strategy can be implemented based on the Service Provider Interface (SPI) mechanism and the custom asset domain-specific language (DSL). For different scenario types (for example, resource production, resource synchronization, resource installation, etc.), the asset HUB can pre-define a series of extension strategies, which describe the external services or logic that may be required when processing resources, such as obtaining resource metadata, archiving resources, synchronizing resources, and installing resources.

[0061] Optionally, when the asset HUB receives a request or task involving a specific scenario type, it can find and call the corresponding extension strategy based on the scenario type. This means that the asset HUB can flexibly call different SPI service implementations according to different scenarios, or use the default controller (Operator) to process resources to meet the specific needs of the scenario.

[0062] Optionally, metadata can be key information used to describe and control resources at various stages of resource processing. Depending on the type of scenario, the type of metadata that needs to be collected and determined will also be different. For example, in a resource production scenario, metadata may include basic information about resources (e.g., name, version), material composition of resources (e.g., specific Docker images, source code, etc.), and entity metadata and operational metadata of materials. In resource synchronization or installation scenarios, metadata may focus more on operational metadata, such as the source warehouse address of the resource, username and password, configuration information of the target installation environment, etc. It should be noted that the content included in the above-mentioned metadata is for illustrative purposes only, and no specific restrictions are made here. As long as it can be used to describe and control resources, it is within the protection scope of the embodiments of the present application.

[0063] Optionally, by determining the metadata that matches the scenario type, the key to automating and intelligentizing resource processing can be achieved. Metadata is not only used to describe the attributes and status of resources, but also to guide the specific logic of resource processing, such as the archiving location of resources, synchronization targets, installation steps, etc. Through metadata, the asset HUB can understand and execute the specific requirements of the scenario type, ensuring the accuracy and efficiency of resource processing.

[0064] Optionally, through the above-mentioned dynamic configuration mechanism, that is, determining the extension strategy and metadata by scenario type, the high flexibility and customizability of the resource processing method is guaranteed. The above-mentioned flexibility is mainly reflected in the fact that the asset HUB can flexibly adjust and optimize the logic and process of resource processing according to different scenario types and requirements. For example, for resource synchronization scenarios, the asset HUB may call specific SPI services to handle network transmission and storage compatibility issues; for resource installation, it may call specific Operators to implement environment configuration and dependency management. The dynamic configuration mechanism also enables the asset HUB to be seamlessly integrated with other systems within the enterprise or external third-party services, thereby expanding its functions and service scope. Through the above-mentioned mechanism, enterprises can use the asset HUB as an open and extensible platform to introduce and register new SPI service implementations according to their own needs, or customize new metadata fields to support a wider range of resource types and scenarios.

[0065] Step S206: according to the expansion strategy, the metadata is used to expand the resource to be processed at the expansion level to obtain the target resource.

[0066] In the technical solution provided in the above step S206 of the present application, the target resource can be obtained by expanding the resource to be processed according to the extension level, and can be a resource image with specific metadata and customized processing logic for the corresponding operation to be performed. For example, if the scenario is asset production, the target resource can be a resource image to be packaged and arranged.

[0067] In this embodiment, after determining the expansion strategy matching the scenario type and the metadata matching the scenario type, the resource to be processed can be expanded at the expansion level using the metadata according to the expansion strategy to obtain the target resource.

[0068] Optionally, based on the determined extension strategy and metadata, the resource to be processed is extended and transformed to generate a target resource. The above process can be regarded as an operation of converting abstract resource definitions and scenario requirements into specific resource instances.

[0069] Optionally, to ensure that resource processing can efficiently and securely adapt to the changing network environment and target environment characteristics, the asset HUB adopts a dynamic expansion mechanism, which can expand the resources to be processed at the corresponding expansion level according to the needs of the scenario in which the resources to be processed are located. Among them, the asset HUB can include three expansion levels, such as the expandability of asset materials, the expandability of assets, and the expandability of asset processes. The above three expansion levels correspond to corresponding expansion strategies respectively. The above three expansion levels provide customized solutions for different scenario requirements.

[0070] Optionally, for the extensibility of asset materials, when the scenario involves specific types of resources or components that are not among the preset material types of the asset HUB, or when the processing logic of the above resources needs to be specially customized, the extensibility of asset materials can be used. For example, in scenarios such as resource production, resource synchronization, and resource installation, asset materials can be extensible. For the extensibility of assets, when the scenario requires customization of the definition, structure, and metadata of the entire asset, asset extensibility can be used. The above situation usually occurs when assets need to contain a specific type of material combination, or additional attributes and operation logic need to be defined to meet specific business needs. For example, in scenarios such as asset production and asset display, assets can be extensible. For the extensibility of asset processes, when the scenario involves the need to customize the operation process of the entire life cycle of the asset, asset processes can be extensible. For example, in scenarios such as resource listing, resource synchronization, and resource installation, asset processes can be extensible.

[0071] In summary, to determine which extension level to extend resources from, we can analyze the core requirements of the corresponding scenario. If the requirements are focused on processing specific resource materials, then we should start with the scalability of asset materials; if the requirements are to customize the structure and metadata of the entire asset, then we should start with the scalability of assets; if the requirements involve customization or automation of the entire process, then we should adopt the scalability of asset processes. In actual applications, these three extension levels may need to be used in combination to meet more complex and specific scenario requirements.

[0072] Optionally, metadata can be used dynamically to guide the resource expansion process during the execution of the expansion strategy. This means that the specific steps and details of resource processing can be adjusted in real time based on metadata and expansion strategies to adapt to different scenario requirements and resource types. In other words, metadata is crucial in the expansion process of the asset HUB executing three levels of expansion. It not only contains the inherent information of the resource, but also contains the rules and logic of resource processing, and also contains information such as network environment characteristics (for example, the current network bandwidth, latency, network protocol compatibility), so that the asset HUB can be adjusted intelligently and dynamically based on metadata.

[0073] Optionally, in the process of asset material extensibility, metadata contains specific material information, such as material type, format, source, operation requirements, etc. The asset HUB will parse the metadata and call the corresponding SPI service or Operator for processing according to the material type and operation requirements. In the process of asset extensibility, metadata not only describes the materials that constitute the asset, but also contains key information such as the structure, operation requirements, and dependencies of the entire asset. The asset HUB will use metadata to determine the processing flow and operation details of the asset. In the process of asset process extensibility, metadata is used to guide the process customization of the entire asset life cycle, including the stages of asset listing, synchronization, and installation. Metadata may contain process control information, such as synchronization strategy, installation steps, approval process, etc. Based on metadata, the asset HUB will dynamically adjust the processing flow of resources, such as selecting synchronization strategy, triggering specific installation steps, or calling SPI services for approval processes.

[0074] For example, in the scenario of resource synchronization, suppose you need to synchronize a large resource package to a target environment with limited bandwidth. At this time, the network environment characteristic fields in the metadata (such as the current network bandwidth, latency, storage capacity of the target environment, network protocol compatibility, etc.) are particularly critical. Before synchronizing resources, the asset HUB can parse the network environment characteristics in the metadata and dynamically select the most appropriate transmission method and data format conversion logic.

[0075] Step S208: perform an operation corresponding to the scenario type on the target resource to obtain an operation result.

[0076] In the technical solution provided in the above step S208 of the present application, the operation result corresponds to the scenario type. The operation result can be used to indicate whether the operation corresponding to the scenario type is completed, or it can be used to indicate the final resource obtained by performing the operation on the target resource. For example, operations such as resource production, synchronization, and installation obtain the corresponding resources. This is only an example and no specific limitation is made. The operation result can be a set of resource files that have been synchronized, or a functional component that has been installed and configured. This is only an example and no specific limitation is made. It can be determined based on the scenario in which the resource to be processed is located and the operation to be performed.

[0077] In this embodiment, after the resource to be processed is expanded at the expansion level by using metadata according to the expansion strategy, an operation corresponding to the scenario type may be performed on the target resource obtained after the expansion to obtain an operation result.

[0078] Optionally, the above method is the final execution stage of the entire resource processing process, and its core is to perform operations corresponding to the scenario type on the target resources processed by the extended hierarchy and generate operation results. The above process converts the abstract processing logic into specific execution actions, ensuring that the entire resource processing process is closed-loop, and at the same time provides a basis for subsequent resource status tracking, feedback and operational decisions.

[0079] For example, if the scenario type is "resource production type", then you can perform operations such as packaging and orchestration on the resource image to form a packaged and orchestrated resource image; if the scenario type is "resource synchronization", the asset HUB can perform operations such as copying and transferring the target resource, and send the target resource to another asset HUB to form a resource file that has been synchronized; if the scenario type is "resource installation", you can perform operations such as downloading, parsing, and initializing configuration on the target resource to form a functional component that has been installed.

[0080] Through the above steps S202 to S208 of the present application, the scene type of the scene in which the resource to be processed is located is determined, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene; an extension strategy matching the scene type and metadata matching the scene type are determined; according to the extension strategy, the resource to be processed is extended at an extension level using metadata to obtain a target resource; the operation corresponding to the scene type is performed on the target resource to obtain an operation result, thereby achieving the technical effect of improving the flexibility of resource processing and solving the technical problem of low flexibility of resource processing.

[0081] The above method of this embodiment is further introduced below.

[0082] As an optional implementation, the method also includes: determining an interface that matches an extension strategy, wherein the extension strategy includes attribute information of the interface; step S206, according to the extension strategy, using metadata to expand the resource to be processed at an extension level to obtain a target resource, including: calling the interface, according to the extension strategy, using metadata to expand the resource to be processed at an extension level to obtain a target resource.

[0083] In this embodiment, an interface that matches the extension strategy can be determined. Thus, in the process of extending the resource to be processed at the extension level using metadata according to the extension strategy, the corresponding interface can be called, and according to the extension strategy corresponding to the interface, the resource to be processed can be extended at the extension level using the original data to obtain the target resource. Among them, the interface can be an SPI interface that matches the extension point. The extension strategy can include attribute information of the interface. The attribute information can include attributes such as the address corresponding to the interface, the authentication method, the service implementation method, and whether to use the default Operator. It should be noted that the attribute information of the above-mentioned interface is only for example and is not specifically limited here.

[0084] Optionally, an interface mechanism that matches the expansion strategy can be introduced in this embodiment, particularly the use of SPI. By introducing the above mechanism, not only the flexibility of the resource expansion process is increased, but also the operation is allowed to be performed in a more modular manner, while ensuring the customizability and security of the operation.

[0085] Optionally, in the preparation stage of resource processing, you can determine the interface that matches the extension policy to be executed. The interface here usually refers to the SPI service interface, which allows third-party services or plug-ins to interact with the asset HUB system to perform specific resource operations. The extension policy contains the attribute information of the interface, which defines the purpose of the interface, the calling method, the authentication mechanism, and whether to use the system default Operator. By matching the correct interface, you can ensure that the resource operation executed meets the current scenario requirements, and also provide specific technical guidance for subsequent calls and executions.

[0086] Optionally, after determining the interface that matches the extension strategy, the above interface can be called, and metadata can be used to perform resource extension and conversion based on the attribute information of the interface. For example, if the extension strategy involves archiving of resource materials, the corresponding SPI interface can be called to handle operations such as packaging and uploading of materials through the specific implementation provided by the interface service, while using material operation metadata to guide this process. In the resource synchronization scenario, an SPI interface for network transmission and data conversion can be called to ensure that resources can be smoothly transmitted from the source HUB to the target HUB. Through the above method, the specific logic of resource extension and conversion can be provided by external implementation, which increases the flexibility and scalability of the asset HUB.

[0087] Optionally, the attribute information of the interface, such as address, authentication method, service implementation method, and whether to use the default operator, is crucial for the expansion and processing of resources. The address information defines the location of the SPI service, the authentication method ensures the security and legality of resource operations, the service implementation method indicates the specific functions and operation procedures of the interface, and whether to use the default operator determines whether it is necessary to call the preset service implementation or whether it is necessary to provide services through an external system. The use of these attribute information enables the asset HUB system to dynamically call the correct service at different stages of resource processing, perform customized resource operations, and ensure the security and consistency of operations.

[0088] Optionally, by determining and calling the interface that matches the extension strategy, the corresponding resource operation can be dynamically performed according to the current scenario requirements and resource types. This dynamism not only allows the asset HUB system to adapt to complex resource processing environments, but also makes the resource conversion process more intelligent and efficient. For example, when synchronizing resources, the system can dynamically select the most appropriate transmission protocol based on the characteristics of the target environment, and call the corresponding service implementation through the SPI interface to complete the synchronization operation.

[0089] In the embodiment of the present application, by introducing the SPI interface and defining its attribute information in detail, a modular and pluggable design of resource expansion and conversion is achieved. It not only reduces the degree of coupling within the asset HUB system, but also allows external services or plug-ins to participate in the resource processing process in a standardized manner, thereby improving the scalability of the asset HUB system. In addition, the above settings also enhance the security and controllability of resource operations, because the authentication method of the interface and whether to use the default Operator and other properties can ensure that only authorized services can operate on resources, thereby reducing security risks in the resource processing process.

[0090] In summary, by determining the interface that matches the extension strategy and calling the interface during resource processing, the asset HUB system can perform resource extension and conversion operations in a more flexible, secure and efficient manner.

[0091] As an optional implementation, step S204, determining an extension strategy that matches the scenario type, includes: in an extension strategy set, determining an extension strategy that matches the scenario type, wherein the extension strategy set includes at least one of the following: a material extension strategy, a resource extension strategy, and a process extension strategy, the material extension strategy is used to represent the rules for expanding the atomic artifacts contained in the resources to be processed, the resource extension strategy is used to represent the rules for expanding the resources to be processed as a whole, and the process extension strategy is used to represent the rules for expanding the operation process of the resources to be processed.

[0092] In this embodiment, in the process of determining the extension strategy that matches the scenario type, the extension strategy that matches the scenario type can be determined from the extension strategy set, wherein the extension strategy set can include: material extension strategy, resource extension strategy and smooth extension strategy. The material extension strategy can be used to represent the rule for extending the atomic artifacts contained in the resource to be processed, and can also be called the asset material extension point, which can be used for the extensibility of the asset material. The resource extension strategy can be used to represent the rule for extending the resource to be processed as a whole.

[0093] Optionally, the above method can ensure the flexibility and customization of resource processing, so that the asset HUB can adapt to various business scenarios and needs.

[0094] Optionally, in the process of determining the expansion strategy that matches the scenario type, the identification and understanding of the current scenario requirements can be used. Scenario types may include resource production, resource synchronization, resource installation, etc., and each scenario has its own specific goals and requirements. For example, resource production may require packaging and combining multiple atomic artifacts, resource synchronization may involve network transmission and data consistency, and resource installation may require environment configuration and execution of initialization scripts.

[0095] Optionally, the extended strategy set includes material extension strategy, resource extension strategy and process extension strategy. These three strategies respectively extend and customize the atomic artifacts of resources, the resources as a whole and the resource operation process to meet the needs of specific scenarios.

[0096] Optionally, the material extension strategy focuses on the atomic artifacts in the resources, such as Docker images, source code files, Helm Charts, etc. It defines how to process and extend these materials, including rules for obtaining material metadata, packaging materials, synchronizing materials to different environments, etc. Through the above strategy, specific SPI services can be called on demand to perform extension operations on specific materials to ensure the integrity and consistency of the materials.

[0097] Optionally, the resource extension strategy focuses on extending the resource to be processed as a whole. It may include the definition and extension of overall attributes such as resource description, classification, labeling, and permission settings. The resource extension strategy ensures the universality and identifiability of resources in different scenarios, while also supporting personalized description and management of resources.

[0098] Optionally, the process extension strategy focuses on the process and steps of resource processing, such as the process of resource production, pre-processing before synchronization, dependency checking during installation, etc. It allows users or system administrators to customize the process of resource operations, including adding approval flows, customizing operation sequences, integrating third-party services, etc. The process extension strategy enhances the flexibility of resource processing and enables the asset HUB to be seamlessly integrated with the enterprise's business processes and workflows.

[0099] Optionally, in the process of determining the strategy that matches the scenario type, the scenario requirements of the user or the current operation can be identified to determine whether it is a specific scenario such as resource production, synchronization or installation. According to the identified scenario type, a matching extension strategy is selected from the extension strategy set. For example, in the resource production scenario, material extension strategy and resource extension strategy can be selected to ensure that the resources and their materials are correctly packaged and described. Once the extension strategy is determined, the system will perform corresponding operations according to these strategies. For example, call the SPI service to obtain material metadata, use a specific Operator to package materials, update the description information of the resource, etc.

[0100] In the embodiment of the present application, through the above method, the asset HUB system can dynamically adapt to different business scenarios and provide highly customized resource processing services. It not only enhances the flexibility and efficiency of resource processing, but also ensures the consistency and security of resources. In addition, due to the modular design of the expansion strategy, new material types, resource attributes and operation processes can be easily integrated, thereby promoting innovation and reuse of resources throughout the enterprise.

[0101] For example, assuming the scenario type is resource synchronization, you can select "resource synchronization strategy" from the extended strategy set. The above strategy includes rules such as pre-check before synchronization, selection of network transmission protocol, and data consistency check after synchronization. According to the above strategy, the corresponding SPI services, such as network transmission service and data verification service, can be called to handle the whole process of synchronizing resources from one HUB to another. Through the above process, the efficiency and accuracy of resource synchronization are ensured, while also adapting to the network restrictions and security requirements that enterprises may face.

[0102] In summary, by determining the strategy that matches the scenario type from the extended strategy set, the asset HUB system can process and manage resources in a more intelligent and adaptive way, support the diversification and customization of resources within the enterprise, and thus bring higher IT asset management and operational efficiency to the enterprise.

[0103] As an optional implementation, in the extension policy set, an extension policy that matches the scenario type is determined, including: when the operation corresponding to the scenario type is a resource production operation, in the extension policy set, at least a material extension policy corresponding to the resource production operation and a resource extension policy corresponding to the resource production operation are determined; when the operation corresponding to the scenario type is a resource synchronization operation, in the extension policy set, at least a material extension policy corresponding to the asset synchronization operation is determined; when the operation corresponding to the scenario type is a resource installation operation, in the expansion policy set, at least a material extension policy corresponding to the resource installation operation is determined; in the extension policy set, a process extension policy that matches the extension requirement information under the scenario type is determined, wherein the extension requirement information is used to indicate the need to expand the operation process of the resource to be processed.

[0104] In this embodiment, in the process of determining the extension policy that matches the scenario type from the extension policy set, if the operation corresponding to the scenario type is a resource production operation, then at least the material extension policy and the resource extension policy corresponding to the resource production operation can be determined from the extension policy set. If the operation corresponding to the scenario type is a resource synchronization operation, then the material extension policy corresponding to the resource synchronization operation can be determined from the extension policy set. If the operation corresponding to the scenario type is a resource installation operation, then the material extension policy corresponding to the resource installation operation can be determined from the extension policy set. It is also possible to determine in the extension policy set a process extension policy that matches the extension requirement information under the scenario type. Among them, the extension requirement information can be used to indicate the need to expand the operation process of the resource to be processed, for example, it can be the actual needs of the user.

[0105] Optionally, it is important to select specific extension strategies based on the scenario type (resource production, resource synchronization, resource installation). In the resource production scenario, in order to ensure that the resource and its component materials are correctly packaged, described, and archived, at least the material extension strategy and the resource extension strategy will be selected.

[0106] Optionally, for resource synchronization or resource installation operations, at least a material extension strategy can be determined. In the synchronization scenario, the material extension strategy guides how to transfer resources from one environment to another, which may include the selection of network transmission protocols, data format conversion, and adaptability processing of the target environment. In the installation scenario, the material extension strategy involves how to deploy materials in the resource image to the target environment, such as executing initialization scripts, configuring environment variables, etc.

[0107] Through the above analysis, the selection of different extension strategies ensures the portability and operability of resources in different environments, and supports the cross-environment use and rapid deployment of resources. The process extension strategy is used to meet the needs of extending the resource operation process. It allows users to define and customize the resource processing process, including but not limited to the approval process, backup strategy, exception handling, etc. Through the process extension strategy, it can adapt to the specific business processes of the enterprise and provide customized resource operation services. For example, users can define a complex approval process to ensure that high-value resources are reviewed and approved before production or installation.

[0108] In an embodiment of the present application, by selecting an extension strategy that matches the scenario type, the process and details of resource processing can be customized according to specific business needs, thereby improving the flexibility and efficiency of resource management. In resource synchronization and installation operations, the material extension strategy ensures the compatibility and operability of resources in different environments, and supports cross-environment reuse and rapid deployment of resources. The process extension strategy allows dynamic adjustment and expansion of the process of resource operations, supporting rapid changes and adaptation of enterprise business processes. The policies in the extension strategy set define the security criteria and consistency requirements for resource processing, such as authentication methods, use of specific Operators, etc., which enhance the security of resource processing and the consistency of data.

[0109] For example, suppose a user needs to create a resource image that contains multiple Docker images and source code files. You can determine the material extension strategy, call the SPI service to obtain the metadata of all images and source code, and use the Operator to package these materials into the resource image. You can set the description, tags, and permissions of the resource according to the resource extension strategy to generate a complete and secure resource image.

[0110] For another example, in a resource synchronization scenario, when resources need to be synchronized from one HUB to another, the most appropriate network transmission protocol can be selected according to the material extension strategy, the transmission SPI service can be called, and the data verification mechanism can be used during the synchronization process to ensure data integrity.

[0111] As an optional example, in a resource installation scenario, when resources are installed in a specific environment, you can call the Operator or SPI service to execute the initialization script according to the material extension policy and configure the environment variables to ensure that the resources are correctly deployed and run in the target environment.

[0112] As another optional example, if the user defines a complex approval process that requires multiple levels of approval before resource production, the process extension strategy will be executed before the resource production operation begins, and the corresponding approval service will be called to ensure that the resource obtains all necessary approvals before production.

[0113] In summary, it can be concluded that based on scenario type selection and application expansion strategy, Asset HUB can provide more flexible, secure and efficient resource processing services to adapt to the diverse needs of enterprises and the rapidly changing business environment.

[0114] As an optional implementation method, according to the extension strategy, metadata is used to expand the resources to be processed at the extension level to obtain the target resources, including: when the extension strategy is a material extension strategy, metadata is used to expand the atomic products of different prefabricated types that constitute the resources to be processed to obtain the target resources; when the extension strategy is a resource extension strategy, metadata is used to expand the resource information of the resources to be processed as a whole to obtain the target resources; when the extension strategy is a process extension strategy, metadata is used to configure the process information of the operation process of the resources to be processed to obtain the target resources.

[0115] In this embodiment, in the process of extending the resources to be processed at the extension level using metadata according to the extension strategy, if the extension strategy is a material extension strategy, the metadata can be used to extend the atomic products of different prefabricated types that constitute the resources to be processed to obtain the target resources. If the extension strategy is a resource extension strategy, the metadata can be used to extend the resource information of the resources to be processed as a sort to obtain the target resources. If the extension strategy is a process extension strategy, the metadata can be used to configure the process information of the operation process of the resources to be processed to obtain the target resources. Among them, the prefabricated type can be an asset material type. The process information can be used to indicate whether the resources to be processed are available for listing, whether the listing automatically produces assets, whether the subscription requires approval, whether it is subscribed or whether which materials need to support the installation of assets. It should be noted that the above process information is only for example and is not specifically limited here.

[0116] Optionally, the above method not only involves the processing of atomic products, but also includes the expansion of overall resource information and the configuration of resource operation processes to ensure that resources can be correctly expanded and used in different scenarios.

[0117] Optionally, when the extension strategy is a material extension strategy, it will focus on the extension of different types of prefabricated atomic products in the resources to be processed. The above process involves using metadata to operate each atomic product to meet the needs of a specific scenario. For example, in the resource production process, the material extension strategy may include: obtaining metadata, packaging and archiving, and material operations.

[0118] Optionally, when the extension policy is a resource extension policy, the focus is on the metadata extension of the resource as a whole. This involves updating and configuring the resource description, classification, label, dependency, permission setting and other attributes. For example: updating resource description, setting permissions and dependencies, and resource operation configuration.

[0119] Optionally, the process extension strategy focuses on the configuration and extension of resource operation processes, by leveraging metadata to define and control the lifecycle management of resources. For example: process configuration, custom operations.

[0120] In an embodiment of the present application, by utilizing metadata for resource expansion, the asset HUB system can flexibly process resources according to different scenarios and requirements, and support the diversification and customization of resources. The expansion of prefabricated atomic products and resource information ensures the operability and consistency of resources in different scenarios, and supports the rapid production and deployment of resources. The configuration of process information allows users and administrators to customize the process of resource operations, enhancing the configurability and adaptability of the asset HUB system. Under the resource extension strategy, the asset HUB system can set permissions and perform dependency checks based on metadata to ensure the security and compliance of resource processing. Through the automated and standardized resource extension process, the efficiency of resource processing can be significantly improved, human errors can be reduced, and the reuse rate of resources can be increased.

[0121] For example, for resource production, suppose the user needs to produce a resource that includes a Docker image and source code files. Using the material extension strategy, obtain the image and source code information through metadata, and then package and archive these materials into the resource image. According to the resource extension strategy, update the description information of the resource, set the resource dependencies and permissions, and generate the final resource image. For resource synchronization, when synchronizing resources to another HUB, use the material extension strategy and process extension strategy to configure the network transmission protocol according to the metadata, perform synchronization operations, and handle abnormal situations in the synchronization process, such as retry mechanism, data verification, etc. For resource installation, when resources need to be installed in a specific environment, the asset HUB system configures the environment and performs installation operations based on the metadata based on the material extension strategy, such as pulling and running Docker images, compiling and deploying source code, etc.

[0122] In summary, by using metadata to extend resources under the extension strategy, the asset HUB can provide a more intelligent, secure and efficient resource management and operation platform to support the diverse needs of resources and the specific business processes of the enterprise. The above method ensures the comprehensiveness and flexibility of resource processing through the expansion of three levels: materials, resources and processes, and is a key step in realizing the automation and intelligence of resource management.

[0123] Optionally, the asset HUB prefabricates a variety of common asset material types (prefabricated types), including Docker images, source code, files, attachments, rich text (Markdown), Java Archive (Java Archive, referred to as JAR), Helm chart (Chart), Application Programming Interface (Application Programming Interface, referred to as API), etc. This is only for example and not for specific limitation. The above prefabricated types cover common asset forms and contents, making it convenient for users to quickly create and manage various types of assets.

[0124] Optionally, in addition to pre-made asset material types, users can also use the asset DSL language to describe custom extended material types. This flexible customization method enables users to define new asset material types according to specific needs to meet specific business scenarios and requirements.

[0125] Optionally, in the asset HUB, the entire asset is supported to be extended, i.e., the asset type is customized, and this is mainly achieved through the extensibility of the asset metadata and the asset DSL.

[0126] Optionally, the extensibility of asset metadata mainly refers to the expansion of asset basic metadata, that is, the expansion in the overall description definition of the asset. In addition to native information, users can customize the display attributes, operation attributes, dependency attributes, sales attributes, etc. of assets. The above extended attributes can help users describe and define assets more comprehensively. At the same time, using the metadata-driven approach, user-defined asset management details pages can be dynamically rendered. By expanding asset metadata, users can improve the description and attributes of assets according to specific needs and business scenarios, making asset management more flexible and personalized.

[0127] Optionally, through the asset DSL, users can complete the definition of assets through concise grammatical descriptions, including asset attributes, structure, operation logic, etc. The asset HUB will manage the entire life cycle of assets based on the asset DSL, allowing users to easily manage and operate assets.

[0128] Through the scalability of asset metadata and asset DSL functions, Asset HUB provides users with flexible and powerful asset management capabilities. Users can customize and extend the metadata and definitions of assets according to actual needs to achieve personalized customization and expansion of assets. At the same time, through the use of asset DSL, users can describe and manage all aspects of assets in a simple way, improving work efficiency and system flexibility. The above scalability and customization capabilities enable Asset HUB to meet various complex asset management needs and improve the flexibility and adaptability of the system.

[0129] As an optional implementation, when the extension strategy is a material extension strategy, metadata is used to expand atomic products of different prefabricated types that constitute the resources to be processed to obtain target resources, including: when the extension strategy is a material extension strategy, metadata is used to call a controller corresponding to the prefabricated type, and the atomic products of the prefabricated type are expanded to obtain the target resources, wherein different prefabricated types correspond to different controllers.

[0130] In this embodiment, if the extension strategy is a physical extension strategy, the controller corresponding to the prefabricated type can be called by metadata to extend the atomic product of the prefabricated type to obtain the target resource, wherein different prefabricated types correspond to different controllers (Operators).

[0131] Optionally, for each prefabricated asset material type, the asset HUB prefabricates a complete set of default operator implementations. The above operator implementations include various operations and functions, such as asset creation, update, deletion, synchronization, etc. Users can directly use these default implementations to quickly manage and operate asset materials.

[0132] By supporting a variety of prefabricated asset material types and custom extended material types, as well as providing a complete default implementation of Operators, Asset HUB provides users with flexible and powerful asset management capabilities. Users can select appropriate asset material types according to actual needs and perform customized extensions to meet asset management requirements for different business scenarios and needs. The above scalability and customization capabilities enable Asset HUB to adapt to various complex asset management scenarios and improve work efficiency and flexibility.

[0133] Optionally, when the extension strategy is a material extension strategy, how to use metadata and a specific controller (Operator) to extend atomic products of different prefabricated types to generate target resources. This process is the core mechanism of material extension in the asset HUB system, which ensures the correct processing of atomic products and the generation of resource images.

[0134] Optionally, an Operator is a component in the asset HUB system that is responsible for processing a specific type of asset material. It performs operations related to that material type based on the rules and metadata defined in the material extension policy. Different prefab types correspond to different Operators, because each material may require different processing logic and operation processes. For example, an Operator for Docker images may be responsible for operations such as pulling images, relabeling, and archiving to resource images; while an Operator for source code may be responsible for downloading code from the code repository, compiling, testing, packaging, and other operations.

[0135] For example, when the extension strategy is specified as a material extension strategy, the system will use metadata to call the Operator corresponding to the material prefabrication type. The above process usually involves the following steps: Read metadata, read metadata related to a specific atomic artifact from the asset HUB, which may include information such as the name, version, source, and operation parameters of the material; call the Operator, call the corresponding Operator based on the information in the metadata, and perform the material extension operation. For example, for a Docker image, the Docker Operator may be called to pull the image using the version information in the metadata, and relabel and archive it as needed; perform the extension operation. The Operator performs material extension operations, such as compiling and packaging source code, based on the instructions and parameters in the metadata. The above operations may include predefined or customized processing logic to adapt to different prefabrication types and scenario requirements; update metadata. After the material extension is completed, the Operator will update the material metadata, such as version information, operation status, error information, etc., for subsequent operations.

[0136] In an embodiment of the present application, metadata and Operator are used to expand materials, and the asset HUB system is able to handle various types of atomic products and support the diversification and customization of resources. The setting of Operator allows the asset HUB system to easily add new material types and processing logic, improving the scalability and flexibility of the system. Operator ensures that all materials of the same type are processed consistently, reducing human errors and inconsistencies. Through metadata, users can customize the parameters and processes of material processing, allowing the asset HUB to adapt to specific business needs and environments. The use of Operator automates and standardizes the processing of materials, improving the efficiency of resource production and packaging.

[0137] As an optional implementation, when the extension strategy is a resource extension strategy, metadata is used to expand the resource information of the resource to be processed as a whole to obtain a target resource, including: when the extension strategy is a resource extension strategy, metadata is extended, wherein the extended metadata is used to describe the resource attribute information of the resource to be processed after expansion; using the extended metadata, the resource attribute information of the resource to be processed as a whole is extended to obtain the target resource; and / or, when the extension strategy is a resource extension strategy, metadata is used to expand the definition description language of the resource to be processed as a whole to obtain the target resource, wherein the definition description language is used to describe the resource composition information of the resource to be processed.

[0138] In this embodiment, if the extension strategy is a resource extension strategy, the metadata can be extended. Using the extended metadata, the resource attribute information of the resource to be processed as a whole can be extended to obtain the target resource. The metadata can also be used as a definition description language of the resource to be processed as a whole to obtain the target resource. Among them, the resource attribute information can be display attributes, operation attributes, dependency attributes, and sales attributes, etc., which are only used as examples and are not specifically limited. The definition description language can be used to describe the resource composition information of the resource to be processed, which can be DSL. The resource composition information can be various components of the asset.

[0139] Optionally, the extensibility of asset metadata is a crucial feature in the asset HUB system, which is directly related to the description, management, operation and use efficiency of assets. Asset metadata refers to the data used to describe the characteristics and attributes of assets, which is divided into asset basic metadata and asset extended metadata. Asset basic metadata usually includes the name, identifier (ID), version, type and other native information of the asset, which is the basic identification of the asset. Asset extended metadata is user-defined information used to enhance the description of assets and make them richer and more specific in specific business scenarios.

[0140] Optionally, the introduction of asset extension metadata makes the description of assets no longer limited to preset attributes, but can be expanded and customized according to the actual needs of users. This includes but is not limited to the following types: display attributes, which are used to define the display method of assets in the interface, such as asset icons, descriptions, classifications, tags, etc. This information helps users quickly identify and understand assets; operational attributes, which are used for asset operation and management, such as asset ratings, usage statistics, recommendation levels, popularity, etc. This information helps operators evaluate and optimize assets; dependency attributes, which describe the dependency relationship between assets and other resources, such as dependent libraries, images, interfaces, etc. This information is crucial for the installation and use of assets and can avoid conflicts and errors during deployment; sales attributes, if it is a commercial asset, may include the price of the asset, purchase method, license agreement, etc. This information is very important for commercial operation scenarios.

[0141] Optionally, the asset HUB system uses asset metadata to dynamically render a user-defined asset management details page. This means that the system will automatically create and update the asset display interface based on the metadata of each asset, including asset details, usage guides, ratings and comments, dependencies, etc. The benefits of this mechanism are: improving the flexibility of asset processing, users can customize metadata as needed, and the system will dynamically adjust the display interface to meet the needs of different business scenarios; assets are generated based on the corresponding metadata, ensuring the consistency and accuracy of assets; improving user experience, the dynamically rendered interface can provide more detailed information based on the richness of metadata, and improve the efficiency of users in finding and using assets.

[0142] For example, an enterprise may need to display specific business indicators of assets on the asset details page. For example, assets in the financial industry may need to display compliance assessment, risk level and other information. Through the extension mechanism of asset metadata, the enterprise can customize these display attributes and add them to the asset metadata. After reading these extended metadata, the asset HUB system will dynamically render the asset details page containing this customized information, so that the asset management page can reflect the key indicators of the asset in a specific business scenario, improving the business relevance and use value of the asset.

[0143] For another example, when the extension strategy is specified as a resource (material) extension strategy, the following steps can be used to extend the resources to be processed: Read metadata. The asset HUB system can parse the asset DSL and read all metadata related to the Docker image, including the image name, multiple version numbers, source warehouse address, target warehouse address, custom tags and other information. Call Operator. Based on the metadata, the asset HUB calls the Docker Operator. Execute the extension operation. The DockerOperator executes the extension operation based on the obtained metadata information. Update metadata. After the extension operation is completed, the DockerOperator will update the metadata related to the image, such as recording the download status of each image, the re-label status, the status of pushing to the target warehouse, and possible error information. The above updated metadata will be stored in the asset image for subsequent operations (such as asset synchronization and asset installation).

[0144] In summary, the scalability of asset metadata enables the asset HUB system to support more complex and detailed asset descriptions to meet the specific needs of different companies or teams. By dynamically rendering user-defined display attributes, the system can not only provide rich asset information, but also improve the user experience and asset operation efficiency. This mechanism is the key to the flexibility of the asset HUB system and enterprise adaptability.

[0145] Optionally, the scalability of asset metadata and asset DSL are two key features in the asset HUB system, which together ensure that the definition, description and management of assets can be highly customized to adapt to various complex business scenarios. The scalability of asset metadata means that users can customize and add additional asset attributes according to their own needs. Asset basic metadata usually includes basic information such as the name, version, and type of the asset, and through the expansion capability, users can freely add display attributes, operation attributes, dependency attributes, and sales attributes. Through a metadata-driven mechanism, the asset HUB dynamically generates an asset management detail page based on user-defined metadata, providing users with a personalized and rich display of asset information. The above mechanism not only improves the efficiency of asset management, but also improves the user experience, making it more convenient to find and use assets.

[0146] Optionally, Asset DSL is a customized language based on a specific syntax (e.g., YAML syntax) provided by the Asset HUB to describe the structure and operation process of assets. Users can use Asset DSL to define the complete composition of an asset, including basic information, extended information, asset material composition, and supported asset operations. Among them, basic information can be basic information such as the name, version, type, and description of the asset. Extended information can be display attributes, operation attributes, dependency attributes, and sales attributes defined through the extensibility of asset metadata. Asset material composition can be various elements contained in the asset, such as Docker images, source code, documents, library files, etc. Supported asset operations can be asset production, listing, delisting, subscription, synchronization, installation, and other operations.

[0147] Asset HUB automatically performs the full life cycle management of assets according to the definition in the asset DSL, from resource creation, storage, distribution to use and update, realizing the automation and standardization of resource management. The use of DSL reduces the complexity of resource management, improves the flexibility and efficiency of resource management, and also enables the asset HUB to adapt to various resource types and business needs.

[0148] As an optional implementation, when the extension strategy is a process extension strategy, metadata is used to configure the process information of the operation process of the resource to be processed to obtain the target resource, including: when the extension strategy is a process extension strategy, at least one target operation process is determined in the operation process set; and metadata is used to configure the process information of the target operation process to obtain the target resource.

[0149] In this embodiment, if the extension policy is a process extension policy, the target operation process can be determined from the operation process set. The process information of the target operation process can be configured using metadata to obtain the target resource. The process operation set can also be called an asset process, and the process operation set can include process operations such as resource listing, delisting, subscription, synchronization, and installation. This is only an example and is not specifically limited.

[0150] Optionally, in the asset HUB, the scalability of the asset process is also very important. Users may need to customize and expand the asset process according to actual needs and business scenarios. At the macro level, an asset process includes operations such as asset listing, delisting, subscription, synchronization, and installation. The above operations are optional, and users can configure the asset process as needed.

[0151] Optionally, for the listing operation, users can configure whether an asset is available for listing, that is, whether it supports distribution and reuse. At the same time, users can also choose whether to automatically create assets, making the listing process more automated and efficient.

[0152] Optionally, for subscription operations, users can configure whether subscriptions require approval and how to configure the subscription approval process. This ensures the compliance and security of subscription operations.

[0153] Optionally, users can also choose to subscribe and sync, which can simplify the process and improve operational efficiency for smaller assets.

[0154] Optionally, for installation operations, users can configure which materials the asset needs to support installation, and can choose to install specific materials based on actual needs to meet different installation requirements.

[0155] By arranging a series of extension points for asset operations, users can customize the entire life cycle of an asset and meet their business needs more flexibly. Users can choose whether to enable and configure each operation step according to the specific situation, making the asset management process more in line with actual needs and business scenarios, and improving the flexibility and customization capabilities of the system.

[0156] Optionally, the application of resource extension strategies in the asset HUB system is to achieve flexible customization and execution of resource operation processes through metadata drive and extension point mechanism. The core of the above strategy is to allow users to define and configure the full life cycle management process of resources according to specific resource types or business scenarios, including key operations such as asset listing, delisting, subscription, synchronization and installation.

[0157] Optionally, users need to determine the resource expansion strategy based on their own business needs. This may involve the type of resource, source, usage scenario, dependency, and expected management process. For example, for internally developed software components, you may need to customize a set of processes including approval, publishing, subscription, and installation; while for externally purchased commercial software, you may focus more on the management of sales attributes and operational attributes. Users select and configure target operation processes from the operation process set based on the resource expansion strategy. The operation process set is a series of standard operations provided by the asset HUB system, including asset listing, delisting, subscription, synchronization, and installation. Users can select a combination of these operations based on the specific needs of the resources and customize the management process suitable for specific resource types. For example, for resources that need to be reused in multiple environments, you can configure synchronization and installation processes; for sensitive resources, you may need to add an approval process.

[0158] For example, when the extension policy is specified as a process extension policy, the resources to be processed can be extended through the following steps: Define extension points. In the asset HUB, corresponding extension points can be defined to introduce approval links in the subscription process. Implement the SPI service corresponding to the corresponding extension point, which may be an internal service or an external system. The implementation of the SPI service may include an approval flow service to provide approval logic for asset subscriptions, such as sending approval requests, waiting for approval, and recording approval results. Register and configure extension points. Register the implemented SPI service in the asset HUB and configure it to a specific asset type or subscription process to specify which asset subscriptions need to go through the approval process. Subscription operation triggers. When a user tries to subscribe an asset from one HUB to another HUB, the asset HUB will detect whether the above defined extension point needs to be called according to the configuration. Call the SPI service. If the subscription configuration requires approval, the asset HUB will call the registered SPI service. The SPI service starts the approval process according to the pre-set logic, which may include sending notifications to approvers, waiting for approval, and recording approval status. Approval process execution: the approver performs the approval operation through the interface provided by the SPI service. Once the approval is passed, the asset subscription process will continue, otherwise the subscription operation will be blocked until it is approved. Subscription result feedback: after the approval process is completed, the SPI service will report the result to the asset HUB. The system will decide whether to continue the subscription operation based on the approval result, such as downloading the asset image, synchronizing metadata, etc. Update metadata and status: after the asset subscription is successful, the asset HUB will update the asset metadata and status information, such as subscription status, synchronization status, target HUB information, etc., for subsequent asset management and operation.

[0159] As an optional implementation, the method also includes: utilizing resources from a third-party system to generate a resource extension policy in an extension policy set; and / or utilizing resource materials from a third-party system to generate a material extension policy in an extension policy set, wherein the resource materials are used to represent the atomic artifacts included in the resource image file of the third-party system.

[0160] In this embodiment, the resource extension strategy in the extension strategy set can be generated by using the resources from the third-party system. The material extension strategy in the extension strategy set can also be generated by using the resource objects from the third-party system. The third-party system can be an upstream business system. The resources of the third-party system can be third-party extension assets. The resource objects of the third-party system can be third-party extension materials.

[0161] Optionally, using resources from third-party systems to generate an extended policy set is an important mechanism for the asset HUB system to support ecological expansion and improve resource management flexibility. The above mechanism allows the asset HUB to not only manage internally generated resources, but also seamlessly integrate and manage resources from suppliers, thereby building an open and ecological resource management platform.

[0162] Optionally, the asset HUB can obtain the resources available in these systems by connecting with third-party systems. These resources may include specific functional modules, services, data sets or software packages. In a metadata-driven manner, the asset HUB can identify and parse the properties and functions of these resources. The asset HUB will automatically generate or allow users to define resource extension policies based on the resource information obtained. This policy includes configuration information for the entire life cycle management of resource production, listing, subscription, synchronization and installation, such as the release process, approval mechanism, distribution channels and usage restrictions of specific resources. The asset HUB will manage resources according to the resource extension policy, including automatically creating resource images, executing resource listing processes, processing resource subscription requests, synchronizing resources to other HUBs or environments, and installing and configuring resources.

[0163] Optionally, the Asset HUB can identify and parse resource materials from third-party systems, that is, the atomic artifacts contained in these resources, such as Docker images, source code, documents, etc. For the identified materials, the Asset HUB provides material extension points, allowing users or systems to customize the material processing logic, including the material packaging method, storage format, dependencies, and operation procedures. For example, for a Docker image, the user can define the warehouse address, authentication information, and network policy for its production and synchronization. When the Asset HUB processes the resource image of a third-party system, it will automatically perform operations such as packaging, storage, synchronization, and installation of the material according to the defined material extension policy. This ensures that the materials contained in the resource image can be correctly processed and used according to the requirements of the user or system.

[0164] In the embodiment of the present application, through the above mechanism, the asset HUB system can effectively integrate and manage resources and materials from three-party systems, which not only improves the reusability and distribution efficiency of resources, but also enhances the flexibility and customization of resource management. For upstream business systems, this means that they can seamlessly connect the resources they generate to the asset HUB and take advantage of the powerful management capabilities of the asset HUB without having to worry about the underlying resource packaging, distribution, and installation details. This further promotes the sharing of internal resources and the introduction of external resources within the enterprise, builds a more open and ecological resource management system, and accelerates innovation and business development.

[0165] As an optional implementation, using resource materials from a third-party system to generate a material extension strategy in an extension strategy set includes: using resource materials from a third-party system and a resource extension strategy in an extension strategy set to generate a material extension strategy in an extension strategy set.

[0166] In this embodiment, using resource materials from the third-party system to generate material extension policies in the extension policy set is a key step for the asset HUB system to achieve efficient management of third-party resources. The above process involves the identification of resource materials, the use of resource extension policies in the extension policy set, and the generation of material extension policies, aiming to ensure that the asset HUB system can seamlessly integrate and efficiently process heterogeneous resources from different external systems.

[0167] Optionally, the asset HUB connects with a third-party system to obtain external resources, which may include a variety of materials, such as Docker images, source code, documents, files in a specific format, etc. Through metadata parsing technology, the asset HUB can identify key attributes such as the type, format, and dependencies of these resource materials, laying the foundation for the subsequent generation of material management strategies. While acquiring resource materials, the asset HUB will also acquire or define resource extension policies related to these resources. The resource extension policy includes configuration information for the entire life cycle management of resources, such as production, listing, subscription, synchronization, and installation. The above policies may be preset by the asset HUB system, or they may be provided by a third-party system or customized by the user. They usually include details on how to handle specific resource types, such as the production process of Docker images, packaging rules for source code, and storage formats for documents.

[0168] Optionally, based on the identified resource materials and resource extension policies, the asset HUB will generate a specific material extension policy. The material extension policy defines the specific processing logic and operation process for each specific material type. For example, for a Docker image material, the material extension policy may include the image production rules (such as source warehouse, version control), image packaging method (such as compression format, metadata attachment), image storage strategy (such as storage location, permission setting), image synchronization rules (such as target HUB, network policy) and image installation and configuration process. The generated material extension policy will be applied by the asset HUB when processing the asset image. In the asset production, listing, subscription, synchronization and installation links, the asset HUB will automatically process and manage resource materials according to the processing logic and operation process defined in the material extension policy. This ensures that each material in the asset image can be correctly packaged, stored, distributed and installed according to the predefined strategy, and also provides a unified management framework for the reuse, update and operation of materials.

[0169] As an optional implementation method, determining metadata that matches the scenario type includes: determining resource basic metadata that matches the scenario type, resource extension strategy, and definition description language of the resource to be processed, wherein the resource basic metadata is used to describe the basic information of the asset image file of the resource to be processed in the scenario, and the definition description language is used to describe the resource composition information of the resource to be processed; determining resource material metadata that matches the scenario type, material extension strategy, and definition description language, wherein the resource material metadata is used to describe the atomic artifacts in the asset image file of the resource to be processed in the scenario.

[0170] In this embodiment, in the process of determining the metadata that matches the scenario type, the resource basic metadata that matches the scenario type, the resource extension policy, and the definition description language of the resource to be processed can be determined. The resource material metadata that matches the scenario type, the material extension policy, and the definition description language can be determined. Among them, the resource basic metadata can be used to describe the basic information of the asset image file of the resource to be processed in the scenario, and can be the asset basic metadata. The definition description language can be used to describe the resource composition information of the resource to be processed. The resource material metadata can be used to describe the atomic artifacts in the asset image file of the resource to be processed in the scenario, and can be the asset material metadata. The resource basic metadata is data that describes the overall properties of the asset image file, which contains basic information and extended information of the resource, such as the name, version, description, author, license, tag, dependency, etc. of the resource. This information is crucial for identifying, classifying, searching, and understanding the role of resources in the scenario.

[0171] Optionally, in the asset HUB system, determining the metadata that matches the scenario type is a key step in achieving automated and intelligent resource management. This process involves the generation of resource basic metadata and resource material metadata, as well as the use of a defined description language, to ensure that the asset image file can accurately reflect the information and requirements of the resource in a specific scenario.

[0172] Optionally, the asset HUB system determines the structure and content of the asset base metadata based on the scenario type (i.e., usage scenario, such as asset production, synchronization, installation, synchronization, listing, subscription, etc.) and the asset process corresponding to the scenario type (e.g., how to produce, synchronize, install, etc.). The scenario type affects the usage and management requirements of the asset, while the asset process specifically specifies the management process of the asset in the asset HUB system. Define a description language, usually using languages ​​such as YAML, to describe the composition information, properties, and dependencies of the asset. It is the basis for the asset HUB system to generate asset base metadata. The asset HUB system will parse this language and extract the basic information of the asset, such as the asset's name, version, type, usage scenario, dependencies, etc. This information will be encoded into the asset base metadata for the generation of asset image files and subsequent asset management.

[0173] Optionally, for each atomic artifact in the asset image file, the asset HUB system will determine its asset material metadata based on the scenario type and material extension strategy. The material extension strategy defines how to process and operate a specific type of asset material, such as Docker images, source code, documents, etc. The asset HUB system will also parse the definition description language to extract detailed information related to the asset material, such as the specific type, format, source, version control, dependencies, operational metadata, etc. of the material. This information will be encoded into the asset material metadata to guide the packaging, storage, distribution and installation process of resource materials (asset materials). The asset material metadata is a specific description of each material in the asset image file, including the material's entity metadata (such as name, type, version) and operational metadata (such as the source warehouse address, username and password during production, and the target location during synchronization). The above information ensures that when processing asset materials, the asset HUB system can operate according to predefined rules and processes, ensuring the consistency and correctness of the materials.

[0174] As an optional implementation, the resource basic metadata includes resource native information and / or resource extended detailed information, wherein the resource native information is used to describe the native information defined by the resource to be processed in the scenario, and the resource extended detailed information is used to describe the extended detailed information defined by the resource to be processed in the scenario; the resource material metadata includes material entity metadata and / or material operation metadata, wherein the material entity metadata is used to describe the entity attributes of the atomic artifact defined by the resource to be processed in the scenario, and the material operation metadata is used to describe the data required during the operation of the atomic artifact defined by the resource to be processed in the scenario.

[0175] In this embodiment, the resource base metadata may include resource native information and / or resource extended detailed information. Resource material metadata may include material entity metadata and / or material operation metadata. Among them, resource native information can be used to describe the native information defined by the resource to be processed in the scenario, which can be asset native information. Resource extended detailed information can be used to describe the extended detailed information defined by the resource to be processed in the scenario, which can be asset extended detailed information. Material entity metadata can be used to describe the entity attributes of the atomic artifact defined by the resource to be processed in the scenario, for example, it can be asset material entity metadata, referred to as entity metadata for short. Material operation metadata can be used to describe the data required by the atomic artifact defined by the resource to be processed in the scenario during the operation, which can be asset material operation metadata, referred to as operation metadata for short.

[0176] Optionally, the subdivision of resource base metadata and resource material metadata is the cornerstone of the metadata-driven mechanism in the asset HUB system, which provides the key information required in the asset image file generation and asset management process.

[0177] Optionally, resource native information describes the basic properties of the resource, which is the core information that the resource must carry in any scenario. For example, the name, version, description, author, license, category, etc. of the resource. Asset native information ensures the unique identification and basic description of the asset image, and is the basis for resource identification and classification. Resource extended detailed information allows assets to be given more attributes and functions, and is additional information added based on specific scenarios or requirements. For example, the use cases, practices, dependencies, operating environment requirements, security assessments, etc. of the resource. Asset extended detailed information enriches the description of the resource, provides more usage guidance and metadata, and helps with the efficient use and management of resources.

[0178] Optionally, the material entity metadata describes the specific attributes of each atomic artifact in the asset image file, such as the name and tag of the Docker image, the name and size of the file, the version and language of the code, etc. Entity metadata is a fixed description of the resource material in the asset image and will not change with resource operations. It ensures the identifiability and traceability of the resource material.

[0179] Optionally, material operation metadata defines how to handle and operate specific resource materials during production, synchronization, installation, etc. For example, the source warehouse address, username and password when packaging Docker images, network policies when synchronizing files, etc. Operation metadata is dynamic and changes with different resource operations. It guides the specific process and details of the production, storage, distribution and installation of resource materials.

[0180] In the embodiment of the present application, through the segmentation and definition of the above-mentioned metadata, the asset HUB system can intelligently process and manage various resources in a metadata-driven manner. During the life cycle of the resource, the resource basic metadata ensures the global uniqueness of the resource and the accuracy of the basic information, while the resource extension details provide a rich description and usage guidance of the resource in a specific scenario. At the same time, the entity metadata and operation metadata in the resource material metadata respectively ensure the accurate recording of the inherent properties and operation details of the resource material, and provide specific and flexible guidance for the packaging, storage, distribution and installation of the resource material. Through the above-mentioned mechanism, the asset HUB system can support highly customized asset management processes, not only can it handle various types of resources, but also can dynamically adjust the description and operation process of the resource according to the specific needs of the user, thereby providing a more flexible, efficient and secure resource management experience. The above-mentioned metadata-driven management mode is one of the core technologies for the asset HUB system to realize its definable, scalable, programmable, reusable and operational capabilities.

[0181] As an optional implementation, step S202, performing an operation corresponding to the scene type on the target resource to obtain an operation result, includes: performing an operation corresponding to the scene type on the target resource to obtain an asset image file of the target resource in the scene.

[0182] In this embodiment, in the process of performing the operation corresponding to the scene type on the target resource, the operation corresponding to the scene type can be performed on the target resource to obtain the asset image file of the target resource in the scene.

[0183] Optionally, performing operations corresponding to the scenario type on the target resource to obtain the asset image file of the target resource in a specific scenario is one of the core steps in the resource production and asset management process in the asset HUB system. The above process reflects the asset HUB system's highly customized processing capabilities for resources and metadata-driven management mechanism.

[0184] Optionally, the asset HUB system can determine the type of operation scenario to be performed by the target resource. Operation scenarios may include but are not limited to stages such as asset production, listing, synchronization, and installation. The goals and processing logic of each stage may be different. For example, the goal of the asset production stage is to package the resources and generate an asset image file, while the asset installation stage focuses on deploying the resources in the asset image file into a specific environment.

[0185] Optionally, the asset HUB system will parse the resource base metadata and resource material metadata of the target resource to understand the basic information, material composition and operation details of the resource. The resource base metadata provides a global description of the resource, while the resource material metadata defines the properties and operation processes of each atomic product in detail.

[0186] Optionally, based on the parsed metadata and the determined operation scenario, the asset HUB system will execute the corresponding operation logic. This may involve using predefined operators or calling registered SPI services to perform operations such as packaging, orchestration, and installation on resource materials. For example, in the asset production scenario, the system will read the operation metadata of the resource material, such as the source warehouse, version information, packaging rules, etc., and then use the corresponding operator or SPI service to generate the asset image file.

[0187] As an optional implementation, an operation corresponding to the scenario type is performed on the target resource to obtain an operation result, including at least one of the following: performing a resource production operation corresponding to the resource production scenario type on the target resource to obtain multiple atomic products of the target resource in the scenario; combining multiple atomic products to obtain a first asset image file of the target resource in the scenario; performing a resource synchronization operation corresponding to the resource synchronization scenario type on the target resource to synchronize the second asset image file corresponding to the resource information of the target resource in the scenario to the resource management and operation platform; performing a resource installation operation corresponding to the resource installation scenario type on the target resource to install the third asset image file of the target resource in the scenario into the target project system or cluster.

[0188] In this embodiment, in the process of performing an operation corresponding to a scenario type on a target resource, a resource production operation corresponding to a resource production scenario type can be performed on the target resource to obtain multiple atomic products of the target resource in the scenario. Multiple atomic products can be combined to obtain a first asset image file of the target resource in the scenario. A resource synchronization operation corresponding to a resource synchronization scenario type can be performed on the target resource to obtain resource information of the target resource in the scenario. The asset image file corresponding to the resource information can be saved. The second asset image file corresponding to the resource information of the target resource in the scenario can be synchronized to the resource management and operation platform. A resource installation operation corresponding to a resource installation scenario type is performed on the target resource to obtain a corresponding third asset image file. Among them, resource information can also be referred to as asset information. Resource information is information that describes the attributes and status of resources in an asset image file. Resource information may include basic metadata, material metadata, operation status, usage, etc. of resources, which is an important basis for the asset HUB system to manage and operate resources.

[0189] Optionally, in the asset HUB system, operations corresponding to the scenario type are performed on the target resource, specifically involving three core scenarios: resource production, resource synchronization, and resource installation. This process not only reflects the automation and intelligence of resource management in the asset HUB system, but also makes full use of metadata and extension point mechanisms to achieve efficient reuse and customized management of resources.

[0190] Optionally, in the resource production scenario, the asset HUB system will perform production operations on the resources based on the definition description language of the target resource and the resource material metadata. This process may include operations such as pulling code from the source repository, packaging Docker images, generating Helm Charts, and ultimately generating a series of atomic artifacts. Production operations may call SPI services or use the system's built-in Operator to ensure the flexibility and scalability of operations. After completing the production of atomic artifacts, the asset HUB system will combine these atomic artifacts into an asset image file in a specific format based on the resource basic metadata and material entity metadata. The asset image file contains a complete description of the resource and the data of all atomic artifacts, and is the main form of storage and distribution of resources in the asset HUB system.

[0191] Optionally, in the resource synchronization scenario, the asset HUB system will perform resource synchronization operations based on the resource information of the target resource. This process may involve synchronizing asset image files from one HUB to another, or uploading specific atomic artifacts (such as Docker images, files, etc.) in the asset image file to the target storage service. The resource synchronization operation will also use the SPI service or the system's built-in Operator to ensure the intelligence and customization of the synchronization process. After the resource synchronization operation is completed, the asset HUB system will save the asset image file corresponding to the resource information to the storage of the target HUB for subsequent resource distribution and reuse.

[0192] Optionally, in the resource installation scenario, the asset HUB system will perform resource installation operations based on the resource information of the target resource. This process may involve deploying resources in the asset image file to a specific project or Kubernetes cluster for use in a specific environment. The resource installation operation may include specific steps such as starting containers, configuring services, and deploying applications. Similarly, this process may be completed by calling SPI services or using the system's built-in Operator.

[0193] As an optional implementation, the method also includes at least one of the following: in response to an orchestration operation instruction for the target resource, orchestrating the display result of the target resource and / or the operation process of the target resource; in response to an reuse operation instruction for the target resource, controlling the reuse of the target resource in a distributed system, wherein the distributed system is constructed based on a distributed deployment architecture; in response to an operation operation instruction for the target resource, obtaining operation information generated by the target resource during the operation process.

[0194] In this embodiment, when an orchestration operation instruction for a target resource is received, the display result of the target resource and / or the operation process of the target resource can be orchestrated. When a reuse operation instruction for a target resource is received, the reuse of the target resource in a distributed system can be controlled. When an operation operation instruction for a target resource is received, the operation information generated by the target resource during the operation process can be obtained.

[0195] Optionally, in the asset HUB system, the orchestration operation, reuse operation and operation operation of the target resources are three important links in the asset management process, which respectively affect the display, use and operation optimization of the resources.

[0196] Optionally, for the orchestration operation, the display result orchestration, when receiving the display result orchestration operation instruction for the target resource, the asset HUB system will personalize the resource display page according to the user's customized rules. This may include adjusting the page layout, adding or deleting display attributes, customizing the control style, etc., to ensure that the resource display results meet the internal management needs and user habits of the enterprise. Operation process orchestration: When receiving the operation process orchestration instruction for the target resource, the asset HUB system will adjust the order, conditions and execution methods of the resource operation according to the user-defined process rules. This may involve process customization for operations such as resource production, listing, subscription, synchronization and installation, allowing users to introduce approval flows, role authority control, automated testing and other links according to actual needs, thereby improving the flexibility and security of resource operations.

[0197] Optionally, for reuse operations, the asset HUB system supports a distributed deployment architecture to control the reuse of target resources in a distributed system, allowing resources to flow freely between multiple HUBs, and realizing cross-system and cross-team reuse of resources. When receiving a reuse operation instruction for a target resource, the system will automatically download the resource image file from the provider HUB to the consumer HUB, or directly install the resource in the target environment (such as a Kubernetes cluster) based on the resource subscription relationship and synchronization strategy. Through this mechanism, the asset HUB system ensures efficient reuse of resources, reduces repeated development and resource waste within the enterprise, and accelerates business iteration and innovation.

[0198] Optionally, for operational operations, the operational information of the target resource during the operation process is obtained. The asset HUB system has the ability to operate resources. When receiving operational operation instructions for target resources, the system will collect and analyze the usage of resources, including the number of resource views, downloads, subscriptions, installations, user feedback, resource scores and other operational information. This information not only provides resource managers with real-time feedback on resource usage, but can also be used for resource optimization, promotion and elimination decisions, enhancing the operational intelligence of the asset HUB system. The collection and analysis of operational information is the key to the asset HUB system's ability to realize resource operability. Based on resource metadata and operation results, it provides rich data support for resource lifecycle management, helping enterprises better understand and optimize resource use, and promote continuous improvement and innovative use of resources.

[0199] The embodiment of the present application also provides a method for processing enterprise assets from the application scenario of enterprise asset management. Figure 3 is a flow chart of a method for processing enterprise assets according to an embodiment of the present application, such as Figure 3 As shown, the method may include the following steps:

[0200] Step S302, determining the scenario type of the scenario in which the enterprise asset to be processed is located, wherein the scenario type is used to indicate the type of operation performed on the enterprise asset to be processed in the scenario.

[0201] In the technical solution provided in the above step S302 of the present application, if a certain enterprise asset to be processed needs to be processed, the scene type of the scene in which the enterprise asset to be processed is located can be determined.

[0202] Step S304, determine the extension points that match the scenario type, and the asset metadata that matches the scenario type, wherein the extension points are used to represent the rules for extending the enterprise assets to be processed according to the extension levels that match the scenario type, and the asset metadata is used to describe the format and / or content defined by the enterprise assets to be processed in the scenario of the scenario type.

[0203] In the technical solution provided in the above step S304 of the present application, after determining the scenario type of the scenario in which the enterprise asset to be processed is located, an extension strategy matching the scenario type can be determined. Metadata matching the scenario type can also be determined. Among them, the extension point can be used to represent the rule for extending the enterprise asset to be processed according to the extension level matching the scenario type. The asset metadata can be used to describe the result defined by the enterprise asset to be processed in the scenario of the scenario type.

[0204] Optionally, when the asset HUB receives a request or task involving a specific scenario type, it will look up and call the corresponding extension policy based on the scenario type. This means that the asset HUB can flexibly call different SPI service implementations according to different scenarios, or use the default controller (Operator) to process the enterprise assets to be processed, thereby meeting the specific needs of the scenario.

[0205] Step S306: according to the extension point, the enterprise asset to be processed is extended at the extension level using the asset metadata to obtain the target enterprise asset.

[0206] In the technical solution provided in the above step S306 of the present application, after determining the extension strategy that matches the scenario type and the metadata that matches the scenario type, the metadata can be used to expand the enterprise assets to be processed at the extension level according to the extension strategy to obtain the target enterprise assets.

[0207] Optionally, based on the determined extension policy and metadata, the enterprise asset to be processed is extended and transformed to generate a target enterprise asset.

[0208] Step S308: perform an operation corresponding to the scenario type on the target enterprise asset to obtain an asset image file of the target enterprise asset in the scenario.

[0209] In the technical solution provided in the above step S308 of the present application, after the enterprise assets to be processed are expanded at the extension level using metadata according to the extension strategy, operations corresponding to the scenario type can be performed on the target enterprise assets obtained after the expansion to obtain operation results.

[0210] Optionally, the target enterprise assets processed through the extended hierarchy are subjected to operations corresponding to the scenario type, and operation results are generated. The above process converts the abstract processing logic into specific execution actions, ensuring that the entire asset processing process is closed-loop, while providing a basis for subsequent asset status tracking, feedback, and operational decisions.

[0211] Through the above steps S302 to S308 of this application, the scenario type of the scenario in which the enterprise asset to be processed is located is determined; the extension point matching the scenario type and the asset metadata matching the scenario type are determined, and the asset metadata is used to describe the result defined by the enterprise asset to be processed in the scenario type scenario; according to the extension point, the enterprise asset to be processed is extended at the extension level using the asset metadata to obtain the target enterprise asset; the operation corresponding to the scenario type is performed on the target enterprise asset to obtain the asset mirror file of the target enterprise asset in the scenario. Thus, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

[0212] The embodiment of the present application also provides a method for processing resources from the human-computer interaction side. Figure 4 is a flow chart of a method for processing resources according to an embodiment of the present application, such as Figure 4 As shown, the method may include the following steps:

[0213] Step S402, in response to an operation instruction on the operation interface, determining a scene type of a scene in which the resource to be processed is located, wherein the scene type is used to indicate a type of operation performed on the resource to be processed in the scene.

[0214] In the technical solution provided in the above step S402 of the present application, when an operation instruction on the operation interface is detected, the scene type of the scene in which the resource to be processed is located can be determined.

[0215] Optionally, the operation interface of the asset HUB system is the front end for the user to interact with the system. Through this interface, the user can initiate various management operations on resources, such as resource production, resource listing, resource subscription, resource synchronization and resource installation. When the user performs a specific operation on the operation interface (such as clicking the "Make Resources" button), the system will detect this operation instruction. After receiving the operation instruction, the asset HUB system will determine the type of operation scenario in which the resource to be processed is located based on the content of the instruction and the user's selection. The scenario type is a specific resource management process pointed to by the operation instruction. It defines how the system will perform operations on the resources to be processed, as well as the goals and requirements of the operation. For example, if the user initiates the "Make Resources" operation instruction, the system will determine the scenario type as a resource production scenario to facilitate the resource packaging and production process.

[0216] Step S404, displaying the extension strategy matching the scene type and the metadata matching the scene type on the operation interface, wherein the extension strategy is used to indicate the rules for extending the resources to be processed according to the extension level matching the scene type, and the metadata is used to describe the format and / or content defined by the resources to be processed in the scenario of the scene type.

[0217] In the technical solution provided in the above step S404 of the present application, after determining the scene type of the scene in which the resource to be processed is located, an extension strategy matching the scene type can be determined. Metadata matching the scene type can also be determined. The extension strategy and metadata can be displayed on the operation interface.

[0218] Optionally, the HUB system will dynamically display the extension policies and metadata that match the scenario type on the operation interface to provide users with intuitive operation guidance. For example, in the asset production scenario, the asset HUB system will display on the operation interface how to define the material combination in the asset image, how to add custom metadata information, and how to use the SPI service to expand the resource operation options. This function optimizes the user's operation interface experience, allowing users to quickly understand and adjust the operation process and extension rules of resource management according to specific scenario requirements.

[0219] Optionally, by displaying the expansion strategy and metadata on the operation interface, the asset HUB system provides decision support for users, helping them make more informed choices in the resource management process. Users can evaluate the scalability, operability, and customizability of resources based on the displayed expansion strategy and metadata, thereby optimizing resource usage and management strategies.

[0220] Step S406 , displaying the target resource corresponding to the resource to be processed on the operation interface, wherein the target resource is obtained by expanding the resource to be processed at an expansion level using metadata according to the expansion strategy.

[0221] In the technical solution provided in the above step S406 of the present application, after determining the extension strategy that matches the scene type and the metadata that matches the scene type, the resources to be processed can be expanded at the extension level using the metadata according to the extension strategy to obtain the target resources, and the target resources can be displayed on the operation interface.

[0222] Step S408: Displaying the operation result obtained by performing the operation corresponding to the scenario type on the target resource on the operation interface.

[0223] In the technical solution provided in the above step S408 of the present application, after the processed resources are expanded at the extension level using metadata according to the extension strategy, the operation corresponding to the scenario type can be performed on the target resources obtained after the expansion to obtain the operation result, and the operation result can be displayed on the operation interface.

[0224] Through the above steps S402 to S408 of the present application, in response to the operation instruction acting on the operation interface, the scene type of the scene where the resource to be processed is located is determined; the expansion strategy matching the scene type and the metadata matching the scene type are displayed on the operation interface; the target resource corresponding to the resource to be processed is displayed on the operation interface; the operation result obtained by performing the operation corresponding to the scene type on the target resource is displayed on the operation interface. Thus, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

[0225] The embodiment of the present application also provides a method for processing resources from the perspective of Software as a Service (SAAS). Figure 5 is a flow chart of a method for processing resources according to an embodiment of the present application, such as Figure 5 As shown, the method may include the following steps:

[0226] Step S502, determining the scene type of the scene in which the resource to be processed is located by calling the first interface, wherein calling the first interface is the scene type, and the scene type is used to indicate the type of operation performed on the resource to be processed in the scene.

[0227] Step S504, determine the extension strategy that matches the scene type and the metadata that matches the scene type, wherein the extension strategy is used to represent the rules for extending the resources to be processed according to the extension level that matches the scene type, and the metadata is used to describe the format and / or content defined by the resources to be processed in the scenario of the scene type.

[0228] Step S506: according to the expansion strategy, the metadata is used to expand the resource to be processed at the expansion level to obtain the target resource.

[0229] Step S508: perform an operation corresponding to the scenario type on the target resource to obtain an operation result.

[0230] Step S510: outputting the operation result by calling the second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter is the operation result.

[0231] Through the above steps S502 to S510 of the present application, the scene type of the scene where the resource to be processed is located is determined by calling the first interface; the extension strategy matching the scene type and the metadata matching the scene type are determined; according to the extension strategy, the metadata is used to extend the resource to be processed at the extension level to obtain the target resource; the operation corresponding to the scene type is performed on the target resource to obtain the operation result; and the operation result is output by calling the second interface. Thus, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

[0232] According to an embodiment of the present application, an embodiment of a resource processing system is also provided. Figure 6 is a schematic diagram of a resource processing system according to an embodiment of the present application, such as Figure 6 As shown, the resource processing system 600 may include: a client 601 and at least one resource processing platform 602 .

[0233] The client 601 is used to upload a resource processing request, wherein the resource processing request is used to request processing of resources to be processed.

[0234] In this embodiment, the client 601 plays the role of the front-end interaction layer in the asset HUB system. It is a bridge for users to communicate with the asset HUB system and is used to upload resource processing requests. Resource processing requests are instructions for users to perform specific operations on resources. This mechanism is the core of the asset HUB system to achieve resource management flexibility and responsiveness.

[0235] Optionally, client 601 is responsible for receiving the user's operation instructions on the operation interface, encapsulating them into resource processing requests, and uploading them to the back-end processing layer of the asset HUB system. This upload process may be implemented through technologies such as RESTful API, WebSocket or message queues, ensuring the efficient transmission of requests and the decoupling between asset HUB systems. The upload function of client 601 is a key link in the interaction between users and the asset HUB system. Through this mechanism, users can flexibly initiate resource processing operations without having to deeply understand the specific implementation details within the system. The system intelligently performs resource operations based on the requests uploaded by users, providing users with efficient and customized resource management services.

[0236] At least one resource processing platform 602 is used to respond to a resource processing request, determine the scene type of the scene in which the resource to be processed is located, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene; determine an extension policy that matches the scene type, and metadata that matches the scene type, wherein the extension policy is used to indicate the rule for extending the resource to be processed according to the extension level that matches the scene type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scene of the scene type; according to the extension policy, use the metadata to extend the resource to be processed at the extension level to obtain a target resource; perform an operation corresponding to the scene type on the target resource to obtain an operation result; and send the operation result to the client.

[0237] In this embodiment, the resource processing platform 602 plays the role of the core resource management and execution engine in the asset HUB system. It is a key component of the system to respond to client requests and execute resource operations. The operation mechanism of the resource processing platform 602 ensures the flexibility, intelligence and efficiency of resource management. The resource processing platform can be an asset HUB.

[0238] Optionally, the resource processing platform 602 receives resource processing requests from the client, which contain specific operation instructions and parameters of the user for the resources to be processed. As a backend service, the resource processing platform 602 parses and understands these requests and prepares to perform corresponding resource management operations. The resource processing platform 602 determines the scenario type of the resource according to the operation type in the resource processing request and the current state of the resource to be processed. The scenario type defines the specific type of resource operation and provides context clues for subsequent resource processing. After determining the scenario type, the resource processing platform 602 will match the corresponding extension strategy and metadata according to the scenario type. The extension strategy guides how to customize the extension of resources at the extension level, while the metadata is the data that describes the results defined by the resource in a specific scenario, including the attributes of the resource, the operation rules and the result status, etc. The above matching process ensures that the asset HUB system can intelligently adjust the resource management process and strategy according to specific business needs. The resource processing platform 602 extends the resources to be processed according to the matched extension strategy and metadata to generate the target resource. This process may involve using SPI services, operators, or built-in logic to process resource metadata, package, customize, and orchestrate resources to obtain resources that meet user needs and scenario requirements.

[0239] Optionally, after the target resource is generated, the resource processing platform 602 can perform operations corresponding to the scenario type, such as resource production, resource synchronization, resource installation, etc. The operation execution is based on the metadata and scenario type of the resource, calling the corresponding services and components to ensure the efficiency and accuracy of resource management. After the operation is completed, the resource processing platform 602 generates the operation result and feeds it back to the client 601.

[0240] In an embodiment of the present application, a resource processing system is provided. A resource processing request is uploaded through a client 601; at least one resource processing platform 602 responds to the resource processing request and determines the scene type of the scene in which the resource to be processed is located; determines an extension strategy matching the scene type and metadata matching the scene type; according to the extension strategy, the metadata is used to extend the resource to be processed at the extension level to obtain the target resource; the operation corresponding to the scene type is performed on the target resource to obtain the operation result; the operation result is sent to the client. Thus, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

[0241] Currently, in the enterprise IT environment, the management of heterogeneous assets has always been a complex and challenging task. With the continuous expansion of the scale of enterprise resource systems, the demand for asset management is also growing. From simple archiving and storage to comprehensive definability, scalability, orchestration, reusability and operational support, the asset management platform of related technologies can no longer meet the flexible and changeable IT asset management needs of modern enterprises.

[0242] The embodiment of the present application provides an extensible enterprise IT heterogeneous asset management and operation platform based on metadata drive, that is, asset HUB. Asset HUB provides a customizable, extensible and optimizable solution for enterprises by defining, extending, arranging, managing and operating various IT assets. Asset HUB defines and describes various assets, including hardware, software, network equipment, etc., through metadata. In this way, unified management and operation of assets can be achieved, and various assets can also be easily extended and customized. Asset HUB is an extensible platform that can be customized and extended according to the needs and scale of the enterprise. Through extension points and SPI mechanisms, enterprises can easily add new functions and services. Asset HUB can help enterprises to arrange and manage assets, including resource allocation, scheduling, monitoring, etc. It can improve the resource utilization and efficiency of enterprises. Asset HUB provides a variety of reusable components and services that can help enterprises better manage and operate assets. This can reduce the operating costs and risks of enterprises. Through metadata-driven methods, asset HUB can achieve a high degree of customization and flexibility to meet the ever-changing needs of enterprises. Thereby achieving the technical effect of improving the flexibility of resource processing and solving the technical problem of low flexibility of resource processing.

[0243] The above method of this embodiment is further introduced below.

[0244] The asset HUB in the embodiment of the present application is a metadata-driven, scalable enterprise IT heterogeneous asset management and operation platform. The HUB is designed to solve the urgent need for definable, scalable, programmable, reusable, and operational capabilities for assets accumulated by the system over the years within the enterprise. The HUB is based on extension points and SPI mechanisms to define, program, manage, and operate various types of IT heterogeneous assets in a metadata-driven manner.

[0245] In this embodiment, the definability of assets refers to the abstraction and definition of various assets in the asset HUB in order to better manage and operate these assets. In the asset HUB, a metadata-driven approach is used to implement the definition of assets, which are abstracted into asset metadata and subdivided into asset basic metadata and asset material metadata. Asset basic metadata is the basic information description of the asset, including asset native information and asset extended detailed information. Asset native information: refers to the basic attribute information of the asset, such as asset type, name, identifier, etc. This information is the basic characteristics of the asset and is used to distinguish and identify different types of assets. Asset extended details: refers to a more detailed description and definition of the asset, including the asset's configuration, association relationship, status, etc. This information can help users better understand and manage assets.

[0246] Optionally, asset material metadata includes asset material entity metadata and asset material operation metadata. Asset material entity metadata: describes the entity attributes and structure of the asset, including the components of the asset, related resources, associated objects, etc. This information can help users understand the internal structure and association relationships of the asset. Asset material operation metadata: describes the methods and rules for operating and managing assets, including asset lifecycle management, authority control, operation procedures, etc. This information can help users better manage and operate assets.

[0247] By defining and describing the metadata of assets in the above way, Asset HUB can achieve unified management and operation of various assets, and can also provide users with more customization and scalability. Through the metadata-driven approach, Asset HUB can achieve high flexibility and configurability to meet the asset management needs of enterprises of different sizes and needs.

[0248] In this embodiment, the core of HUB is flexible scalability for asset scalability. Due to the complexity and diversity of assets, the definition of actual assets, the composition of asset materials, and the operation of assets all require customized extensions. The scalability of this solution is based on the extension point + SPI mechanism, combined with a custom asset DSL, to uniformly describe the definition of an asset and its asset production, synchronization, installation and other operation logic.

[0249] Optionally, users need to use asset DSL to describe the composition of an asset. According to different usage scenarios (asset production, synchronization, installation), complete different SPI interface implementations, register the SPI service implementation with the asset HUB (the service implementation can be exported as a Jar package and hosted in the asset HUB or independently deployed as a third-party service) for use by the asset HUB. There are currently two main calling methods for calling SPI implementation: one is to package the SPI implementation into a Jar and host it in the asset HUB system; the other is to independently deploy it as a third-party service, and the asset HUB directly calls the third-party system. The asset HUB has a complete feedback mechanism. The results of all asset operations will be notified to the upper-level business system through kafka messages, and the feedback results can also be received by registering the SPI implementation.

[0250] Optionally, in this embodiment, the asset HUB supports three levels of expansion, which are, from small to large, asset material expansion, asset expansion, and asset process expansion.

[0251] In this embodiment, the scalability of asset materials is a very important part of the asset management system. Various types of asset materials can be customized and extended according to different business needs and scenarios. In the asset HUB, asset materials are the core elements of assets, including prefabricated types such as Docker images, source code, files, attachments, rich text, JAR, Helm Chart, API, etc., and also support users to use asset DSL language to describe custom extended material types. The asset HUB prefabricated a complete set of Operator default implementations for each prefabricated asset material type, which is convenient for users to use and customize.

[0252] Optionally, the Asset HUB prefabricates a variety of common asset material types. These prefabricated types cover common asset forms and contents, making it easy for users to quickly create and manage various types of assets. In addition to prefabricated asset material types, users can also use the Asset DSL language to describe custom extended material types. This flexible customization method enables users to define new asset material types based on specific needs to meet specific business scenarios and requirements.

[0253] Optionally, for each prefabricated asset material type, the asset HUB prefabricates a complete set of default operator implementations. These operator implementations include various operations and functions, such as asset creation, update, deletion, synchronization, etc. Users can directly use these default implementations to quickly manage and operate asset materials.

[0254] Asset HUB provides users with flexible and powerful asset management capabilities by supporting a variety of prefabricated asset material types and custom extended material types, as well as providing a complete default implementation of Operators. Users can select appropriate asset material types according to actual needs and perform customized extensions to meet asset management requirements for different business scenarios and needs. This scalability and customization capabilities enable Asset HUB to adapt to various complex asset management scenarios and improve work efficiency and flexibility.

[0255] Optionally, during the asset synchronization process, the main SPI interfaces include obtaining material operation metadata and synchronizing asset materials. These interfaces play a key role in the asset synchronization process, helping the asset HUB process the material information in the asset and complete the synchronization operation of the asset. The following is a detailed analysis of these two SPI interfaces:

[0256] Optionally, obtain asset material metadata. This interface is used to obtain metadata information of each material in the asset during the asset production process, including material basic metadata and material operation metadata. These metadata describe the basic properties, operation rules and processes of the material. When processing materials in the asset, the asset HUB will call this interface to obtain metadata information for each material, including material entity metadata, which is used to store in a specific location in the asset image, and material operation metadata for subsequent material operations.

[0257] Optionally, archive asset materials. This interface is used to actually archive the operation logic of a certain asset material in the asset production operation. Depending on the configuration of the asset material extension point, archiving asset materials can use the system pre-made Operator or the archiving service provided by the external system. The asset HUB will obtain the binary stream data of the material according to the interface implementation and store it in a specific location of the asset image. This ensures the smooth archiving and storage of materials in the asset production process.

[0258] Through the implementation of the above SPI interface, the asset HUB can effectively process the material information in the asset production process, obtain and store material metadata, and implement the archiving operation of the material. This can ensure the smooth progress of the asset production process and improve the reliability and stability of the system. At the same time, through the archiving service provided by the external system, it can also meet more flexible and customized needs, making the asset production process more customizable and scalable.

[0259] Optionally, during the asset installation process, the main SPI interfaces include obtaining material operation metadata and installing asset materials. These interfaces play a key role in the asset installation process, helping the asset HUB process the material information in the asset and complete the asset installation operation. The following is a detailed analysis of these two SPI interfaces:

[0260] Optionally, obtain material operation metadata. This interface is used to obtain the operation metadata required for the installation of each material in the asset during the asset installation process. During an asset installation process, the asset HUB will call this SPI interface to obtain the operation metadata required for material installation in order to perform subsequent installation operations. Asset material installation is an optional operation. If you need to operate an asset material during the asset installation process, you need to register the corresponding extension point. In this way, you can customize the material installation operation method and rules as needed.

[0261] Optionally, install asset materials. This interface is used to actually operate the logic of a certain asset material during the asset installation process. During an asset installation process, when the asset HUB needs to install a specific material, the binary stream of the specific material is output to the specified system through this extension point, and the system performs subsequent installation operations. According to the configuration of the asset material extension point, the installation of asset materials can use the system pre-made Operator or the service provided by the external system. In this way, you can choose the appropriate installation method according to specific needs to ensure a smooth installation process of the asset.

[0262] Through the implementation of these two SPI interfaces, the asset HUB can effectively process the material information during the asset installation process, obtain and install the operational metadata required for the material, and ensure the smooth progress of the asset installation process. At the same time, through customized installation operation methods, it can adapt to asset installation scenarios of different types and requirements, and improve the flexibility and adaptability of the system. This customized installation method can meet specific business needs and ensure the accuracy and completeness of asset installation.

[0263] In this embodiment, in the asset HUB, the extension of the entire asset, that is, custom asset types, is supported, and is mainly achieved through the extensibility of asset metadata and asset DSL.

[0264] Optionally, the extensibility of asset metadata mainly refers to the expansion of asset basic metadata, that is, the expansion in the overall description definition of the asset. In addition to native information, users can customize the display attributes, operation attributes, dependency attributes, sales attributes, etc. of assets. These extended attributes can help users describe and define assets more comprehensively. At the same time, using the metadata-driven approach, user-defined asset management details pages can be dynamically rendered. By expanding asset metadata, users can improve the description and attributes of assets according to specific needs and business scenarios, making asset management more flexible and personalized.

[0265] Optionally, Asset DSL is an asset definition description language provided by Asset HUB, which uses YAML syntax to describe the various components of an asset, including basic information, extended information, asset material composition, and supported asset operations. Through Asset DSL, users can complete the definition of assets through concise grammatical descriptions, including asset attributes, structure, and operation logic. Asset HUB will manage the entire life cycle of assets based on Asset DSL, allowing users to easily manage and operate assets.

[0266] Through the scalability of asset metadata and asset DSL functions, Asset HUB provides users with flexible and powerful asset management capabilities. Users can customize and extend asset metadata and definitions according to actual needs to achieve personalized customization and expansion of assets. At the same time, through the use of asset DSL, users can describe and manage all aspects of assets in a simple way, improving work efficiency and system flexibility. This scalability and customization capabilities enable Asset HUB to meet various complex asset management needs and improve the flexibility and adaptability of the system.

[0267] In this embodiment, Figure 7 is a schematic diagram of an asset extension point according to an embodiment of the present application, such as Figure 7 As shown, Figure 7 As shown in the figure, in the asset management system, the scalability of the asset process is also very important. Users may need to customize and expand the asset process according to actual needs and business scenarios. At the macro level, an asset process includes operations such as asset listing, delisting, subscription, synchronization, and installation. These operations are optional, and users can configure the asset process as needed.

[0268] Optionally, for the listing operation, users can configure whether an asset is available for listing, that is, whether it supports distribution and reuse. At the same time, users can also choose whether to automatically create assets, making the listing process more automated and efficient.

[0269] Optionally, for subscription operations, users can configure whether subscriptions require approval and how to configure the subscription approval process. This ensures the compliance and security of subscription operations.

[0270] Optionally, users can also choose to subscribe and sync, which can simplify the process and improve operational efficiency for smaller assets.

[0271] Optionally, for installation operations, users can configure which materials the asset needs to support installation, and can choose to install specific materials based on actual needs to meet different installation requirements.

[0272] By orchestrating a series of extension points for asset operations, users can customize the entire life cycle of an asset and meet their own business needs more flexibly. Users can choose whether to enable and configure each operation step according to the specific situation, so that the asset management process is more in line with actual needs and business scenarios, and improve the flexibility and customization capabilities of the system. In summary, the scalability of the asset process allows users to customize and configure operations such as asset listing, subscription, synchronization, and installation according to actual needs, and achieve flexible control and customization of the asset management process, thereby improving the adaptability and efficiency of the system. This flexibility and customization capabilities enable the asset management system to better meet user needs, improve work efficiency and the overall performance of the system.

[0273] Figure 8 is a flow chart of an asset production process according to an embodiment of the present application, such as Figure 8 As shown, the process may include the following steps:

[0274] Step S802: Match asset extension points and construct asset metadata.

[0275] In this embodiment, the asset HUB will first identify and match the asset extension point. The asset extension point is the key mechanism in the asset HUB to define the asset composition, metadata format, and operation process. It allows users to customize different aspects of assets, such as material type, metadata field, operation logic, etc. When an asset production request enters the system, the HUB will pull all metadata related to the asset, including basic metadata and material metadata, according to the predefined extension point rules.

[0276] Optionally, basic metadata contains basic information about the asset, such as the asset's name, version, description, author, license agreement, etc. Material metadata describes in detail the specific information of each asset material (such as Docker images, source code, documents, etc.), such as the material's type, version, source, dependencies, etc. These metadata information is obtained from the upstream system through the SPI service interface. The SPI service is usually provided by users or partners of the asset HUB to achieve more flexible and personalized asset definitions. Building asset metadata is the basis of the asset production process, ensuring the integrity and consistency of asset information. In this step, the HUB system will organize the acquired metadata into the structure of asset metadata through the metadata-driven mechanism to provide data support for subsequent material production and image assembly.

[0277] Step S804: Material metadata drives the production of asset materials.

[0278] In this embodiment, the asset HUB will start the material production process according to the material metadata constructed in step S802. Material production involves packaging, archiving and preparing asset materials so that they can be combined into asset images. This is achieved by calling the SPI service of the material extension point. The SPI service contains the specific logic of making materials, such as pulling Docker images from remote warehouses, obtaining source code files from version control systems, converting document formats, etc.

[0279] Optionally, for each material, the SPI service performs the corresponding production operations based on the information in the material metadata. For example, if the material metadata defines a Docker image, the SPI service is responsible for pulling or building this image and preparing it for asset image creation. If the material metadata defines a source code package, the SPI service is responsible for cloning or downloading the source code from the version control system and organizing it into a form that can be included in the asset image.

[0280] Optionally, the material production process is highly dependent on metadata, which not only defines the properties of the material, but also guides the production method and content of the material. Through the call of SPI services, the asset HUB can support the production of many different types of materials, improving the flexibility and scalability of asset production.

[0281] Step S806, assembling the asset image file.

[0282] In this embodiment, when all asset materials are completed and passed the inspection, the asset HUB will enter the final stage of assembling the asset image file. The asset image is a file in a special format that contains asset metadata and all completed material data. The assembly of the image file is performed according to predefined rules and formats to ensure that the structure and content of the image file conform to the storage and distribution standards of the asset HUB.

[0283] Optionally, during the assembly process, the HUB will organize different material entity metadata and binary streams into the image file according to a certain structure based on the material metadata. Material operation metadata, such as the source warehouse address, username and password, will not be directly stored in the image file, but will be used to guide operations during the image production process, such as authentication information for pulling Docker images.

[0284] Optionally, after assembly is complete, the asset image file will be stored in the asset HUB and marked as available for sale, waiting for subsequent distribution and installation operations. The storage and management of asset image files is based on the distributed architecture and metadata-driven mechanism of the asset HUB, ensuring the security, integrity and reusability of the asset image.

[0285] In summary, the asset production process is a key link in the asset HUB. It builds asset metadata by matching asset extension points, drives the production of asset materials using material metadata, and finally assembles a structured asset image file, providing a solid foundation for asset distribution and reuse. This process fully reflects the metadata-driven, scalable, and distributed architecture characteristics of the asset HUB, and is an advanced practice in modern enterprise IT asset management.

[0286] Asset synchronization is an important part of asset lifecycle management. It allows assets and their image files to be transferred from one HUB to another, thereby enabling the sharing and reuse of assets in different environments or teams. Fig. 9 is a flowchart of an asset synchronization process according to an embodiment of the present application, such as Fig. 9 As shown, the process may include the following steps:

[0287] Step S902, downloading the asset image file.

[0288] In this embodiment, at the beginning of asset synchronization, the target HUB (receiving HUB) will download the specified asset image file from the source HUB (sending HUB). This process may include obtaining the image file through network transmission, which usually requires access rights and network connection of the source HUB. The download operation can be a file download based on the Hypertext Transfer Protocol (HTTP) or a more professional transmission protocol, depending on the implementation details of the asset HUB.

[0289] Optionally, downloading the asset image file is the basis for asset synchronization, ensuring that the target HUB can obtain complete asset information and material data, and prepare the data source for subsequent parsing and saving operations. It should be noted that since the asset image may contain multiple materials and metadata, the file size may be quite large, so an efficient and stable download mechanism is the key to ensure a smooth synchronization process.

[0290] Step S904: parse the asset image file and match the asset extension point.

[0291] In this embodiment, after downloading is completed, the target HUB will parse the contents of the asset image file and extract the asset metadata and material data therein. The parsing process involves reading and understanding the structure and data format in the image file, which usually requires a special parser or module to complete. The parsed asset metadata and material data are the basis for further processing and operation.

[0292] Optionally, the target HUB will match the corresponding asset extension point based on the parsed asset metadata. The asset extension point defines the composition, material type, operation logic, etc. of the asset in the asset HUB, which allows the target HUB to identify and understand the specific structure and characteristics of the asset. Matching asset extension points is the core of intelligent and customized processing in asset synchronization. Through this mechanism, the target HUB can determine how to process and use the synchronized asset image file.

[0293] For example, if the asset image contains a Docker image, the target HUB will match the asset extension point of the Docker image and call the corresponding SPI service to process the image data, which may include uploading the image to the local Docker repository, processing dependencies in the image, converting the image format, etc.

[0294] Step S906, saving the asset image file.

[0295] In this embodiment, after parsing and processing, the target HUB saves the asset image file to its local storage system. The save operation involves the allocation of physical storage space, writing of the image file, and updating the asset status information in the asset HUB database to reflect that the asset image file has been successfully synchronized and saved.

[0296] Optionally, saving the asset image file is a key step to ensure asset availability and persistence. When saving the image file, the target HUB may also need to execute some additional logic, such as checking the integrity and consistency of the file, updating the metadata information of the asset, generating an index or metadata summary of the asset, etc., for subsequent query and use.

[0297] At the same time, the saving step may also include further processing of the parsed material data, such as pushing the Docker image to the local Docker repository, or processing other types of asset materials to ensure that they can be correctly identified and used by the local environment. In addition, the target HUB will also use the feedback mechanism to notify the source HUB or other related systems of the synchronization results (including success or failure information) to ensure the consistency of asset status and feedback of synchronization operations.

[0298] Optionally, once the asset image file is successfully saved, the target HUB can put it on the shelf for local users or teams to subscribe and use. Through the above method, the asset synchronization process not only realizes the physical transmission of the asset image file, but also ensures the accuracy and availability of the asset information.

[0299] The asset installation process is an important part of the asset lifecycle, which is the process in which assets in the asset HUB are downloaded and deployed to a specific environment (such as a local server, etc.). Fig.10 is a flowchart of an asset installation process according to an embodiment of the present application, such as Fig.10 As shown, the process may include the following steps:

[0300] Step S1002: download asset metadata.

[0301] In this embodiment, the first step of the asset installation process is to download asset metadata. Asset metadata contains key data such as properties, material information, and operation rules that describe the asset image. This process is usually pulled from the asset HUB by the asset installation service or agent of the target environment after the installation request is initiated. The downloaded metadata is the basis for subsequent parsing and installation operations, ensuring that the target environment can obtain complete and up-to-date asset information to correctly install and configure the asset.

[0302] Step S1004: parse asset metadata and match asset extension points.

[0303] In this embodiment, after downloading the asset metadata, the next step is to parse and understand the specific structure and dependencies of the asset. Parsing the asset metadata involves reading the metadata file, parsing its format and content, and extracting the basic information of the asset, the material list, the operational metadata, and any custom attributes.

[0304] Optionally, after parsing, the target environment matches the corresponding asset extension points based on the information in the asset metadata. The asset extension points define the composition of the asset, the material type, and the rules for how to install and configure the asset in different environments. By matching the asset extension points, the target environment can identify the specific type and material of the asset, and how to perform the installation operation.

[0305] For example, if a Docker image is defined in the downloaded asset metadata, the target environment will match the corresponding Docker image asset extension point to know how to download the image from the HUB, how to install and run the image in the local environment, and any metadata specific to the installation process (such as environment variables, port mappings, etc.).

[0306] Step S1006: The asset metadata driver installs the asset image file.

[0307] In this embodiment, after parsing and matching are completed, the target environment will start the installation process of the asset image file according to the rules and information of the asset metadata. This usually involves downloading the complete asset image file from the asset HUB, and then performing the installation operation according to the asset material metadata and operation metadata.

[0308] Optionally, the installation process of the asset image file is highly dependent on metadata, which not only contains the composition information of the asset, but also provides guidance for the installation logic. For example, asset metadata may include installation scripts for specific materials, paths to configuration files, required system resources, etc., and the above information can be used to guide specific installation operations. During the installation process, the target environment calls the SPI service defined in the asset extension point to perform the material installation operation. The SPI service contains specific types of material installation logic, such as how to deploy a Docker image into a container environment, how to configure and start a Helm Chart, etc. These operations may require interaction with external systems or services, such as Docker repositories, Kubernetes API Servers, etc., to complete the installation and configuration of assets.

[0309] Optionally, after the installation is complete, the target environment will update the asset status information to indicate that the asset has been successfully installed, and may also execute some additional logic, such as generating a report on asset usage, updating asset version information, etc. In addition, the target environment will also use the feedback mechanism to notify the asset HUB and related business systems of the installation results to ensure consistency of asset status and feedback of installation operations.

[0310] In summary, through the above steps, the asset installation process realizes the deployment and configuration of the asset image file in the target environment, ensuring the normal operation and function realization of the asset. This process makes full use of the metadata-driven mechanism and the extensibility of the asset HUB, so that different types of assets can be flexibly installed and used in various target environments.

[0311] In this embodiment, the programmability of the asset HUB is mainly reflected in the programmability of asset display and asset flow.

[0312] Optionally, for the programmability of asset display, by utilizing the above-mentioned asset metadata definition and extension point definition, users can program the asset display page. By describing the asset display attributes, they can define the asset's homepage, logo, details page, various attribute controls and layout, etc., to truly realize an asset display page that meets the company's own needs.

[0313] Optionally, for the orchestration of asset processes, as described in the above extension points, through the asset DSL, users can customize the entire life cycle of an asset, and can also define the entire life cycle of a material in the asset. Approval flows can be defined for certain specific operations.

[0314] In this embodiment, in view of the reusability of assets, the asset HUB naturally serves the sedimentation and reuse of assets. At the same time, the asset HUB has a distributed deployment architecture, and assets can flow freely among multiple HUBs to meet different usage scenarios.

[0315] Fig.11 is a schematic diagram of a distributed asset management and operation platform architecture according to an embodiment of the present application, such as Fig.11As shown, the subscription relationship between HUBs will eventually form a mesh relationship. Public HUB: The asset HUB provides an authoritative central HUB in the public cloud, which is subscribed to by other HUBs, but will not subscribe to any other HUBs. This HUB can only be officially maintained by the asset HUB. Enterprise HUB: The HUB deployed within the enterprise is an enterprise-level HUB. The enterprise has complete control over the HUB. This HUB can subscribe to Public HUB or other Private HUBs. Developer Local HUB: This HUB is special and is directly deployed on the developer's local machine. An important reason for needing this HUB is that when the developer does not have Internet access, he can also create and upload assets locally, and then wait until there is a network, and then the local HUB will deliver with the enterprise HUB and automatically synchronize the asset image. Of course, in theory, Local HUB can also interact directly with Public HUB. The CLI command line interface can be used to obtain user input commands and display asset images. Through the CLI command line, you can send a request to the Local HUB to push resource images to the Private HUB, or you can display the pulled asset images on the above interface.

[0316] In this embodiment, the HUB not only has the ability to manage assets, but also has the ability to operate assets. It can manage and view operational information such as asset homepage recommendations, asset scoring, asset operation statistics screen, asset usage details, etc. Among them, the asset operation screen includes asset usage statistics in multiple dimensions such as asset sorting, asset type distribution, asset tag distribution, asset browsing, asset listing, asset subscription, and asset installation. It provides asset managers with rich asset operation functions.

[0317] In the embodiment of the present application, the asset HUB solves the business pain points encountered by the asset center, such as the deep binding of products to the upper-level business system, the inability to flexibly expand assets and their material composition, the solidification of asset operation processes, the inability to precipitate and quickly reuse assets, and the inability to specifically evaluate an asset, through the five dimensions of asset definability, scalability, programmability, reusability, and operability. It provides a solid technical foundation for enterprises to customize a concrete asset for use in their own internal systems. Combined with the extension point and SPI mechanism, the common business pain points of the asset center in use can be solved from five dimensions. For example, the definability of assets, the extensibility of assets, the programmability of assets, the reusability of assets, and the operability of assets.

[0318] According to an embodiment of the present application, there is also provided a method for implementing the above Figure 2 The resource processing method shown is a resource processing device.

[0319] Fig.12 is a schematic diagram of a resource processing device according to an embodiment of the present application, such as Figure 8 As shown, the resource processing device 1200 may include: a first determining unit 1202 , a second determining unit 1204 , a first extending unit 1206 and a first executing unit 1208 .

[0320] The first determination unit 1202 is used to determine the scene type of the scene where the resource to be processed is located. The second determination unit 1204 is used to determine the extension strategy matching the scene type and the metadata matching the scene type. The first extension unit 1206 is used to extend the resource to be processed at the extension level using the metadata according to the extension strategy to obtain the target resource. The first execution unit 1208 is used to perform the operation corresponding to the scene type on the target resource to obtain the operation result.

[0321] Here, the first determination unit 1202, the second determination unit 1204, the first expansion unit 1206 and the first execution unit 1208 correspond to steps S202 to S208 in the above embodiment, and the four units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above units can be hardware components or software components stored in a memory (e.g., memory 1604) and processed by one or more processors (e.g., processors 1602a, 1602b..., 1602n), and the above units can also be run as part of the device in the computer terminal A provided in the following embodiment.

[0322] According to an embodiment of the present application, there is also provided a method for implementing the above Figure 3 The enterprise asset processing method shown is an enterprise asset processing device.

[0323] Fig.13 is a schematic diagram of a device for processing enterprise assets according to an embodiment of the present application, such as Fig.13 As shown, the resource processing device 1300 may include: a third determining unit 1302 , a fourth determining unit 1304 , a second extending unit 1306 and a second executing unit 1308 .

[0324] The third determination unit 1302 is used to determine the scene type of the scene where the enterprise asset to be processed is located. The fourth determination unit 1304 is used to determine the extension point matching the scene type and the asset metadata matching the scene type. The second extension unit 1306 is used to extend the enterprise asset to be processed at the extension level using the asset metadata according to the extension point to obtain the target enterprise asset. The second execution unit 1308 is used to perform the operation corresponding to the scene type on the target enterprise asset to obtain the asset mirror file of the target enterprise asset in the scene.

[0325] It should be noted that the third determining unit 1302, the fourth determining unit 1304, the second expansion unit 1306 and the second execution unit 1308 correspond to steps S302 to S308 in the above embodiment, and the four units and the corresponding steps implement the same examples and application scenarios, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above units can be hardware components or software components stored in a memory (e.g., memory 1604) and processed by one or more processors (e.g., processors 1602a, 1602b..., 1602n), and the above units can also be run as part of the device in the computer terminal A provided in the following embodiment.

[0326] According to an embodiment of the present application, there is also provided a method for implementing the above Figure 4 The resource processing method shown is a resource processing device.

[0327] Fig.14 is a schematic diagram of a resource processing device according to an embodiment of the present application, such as Fig.14 As shown, the resource processing device 1400 may include: a fifth determination unit 1402 , a first display unit 1404 , a second display unit 1406 , and a third display unit 1408 .

[0328] The fifth determination unit 1402 is used to respond to the operation instruction acting on the operation interface and determine the scene type of the scene in which the resource to be processed is located. The first display unit 1404 is used to display the extension policy matching the scene type and the metadata matching the scene type on the operation interface. The second display unit 1406 is used to display the target resource corresponding to the resource to be processed on the operation interface. The second display unit 1408 is used to display the operation result obtained by performing the operation corresponding to the scene type on the target resource on the operation interface.

[0329] It should be noted that the fifth determination unit 1402, the first display unit 1404, the second display unit 1406 and the second display unit 1408 correspond to steps S402 to S408 in the above embodiment, and the four units and the corresponding steps implement the same examples and application scenarios, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above units can be hardware components or software components stored in a memory (e.g., memory 1604) and processed by one or more processors (e.g., processors 1602a, 1602b..., 1602n), and the above units can also be run as part of the device in the computer terminal A provided in the following embodiment.

[0330] Fig.15 is a schematic diagram of a resource processing device according to an embodiment of the present application, such as Fig.15 As shown, the resource processing device 1500 may include: a first calling unit 1502 , a sixth determining unit 1504 , a third extending unit 1506 , a third executing unit 1508 and a second calling unit 1510 .

[0331] The first calling unit 1502 is used to determine the scene type of the scene where the resource to be processed is located by calling the first interface. The sixth determining unit 1504 is used to determine the extension strategy matching the scene type and the metadata matching the scene type. The third extension unit 1506 is used to extend the resource to be processed at the extension level using the metadata according to the extension strategy to obtain the target resource. The third execution unit 1508 is used to perform the operation corresponding to the scene type on the target resource to obtain the operation result. The second calling unit 1510 is used to output the operation result by calling the second interface.

[0332] It should be noted that the first calling unit 1502, the sixth determining unit 1504, the third expanding unit 1506, the third executing unit 1508 and the second calling unit 1510 correspond to steps S502 to S510 in the above embodiment, and the five units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above units can be hardware components or software components stored in a memory (e.g., memory 1604) and processed by one or more processors (e.g., processors 1602a, 1602b..., 1602n), and the above units can also be run as part of the device in the computer terminal A provided in the following embodiment.

[0333] The embodiment of the present application may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced by a terminal device such as a mobile terminal.

[0334] Optionally, in this embodiment, the computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

[0335] In this embodiment, the computer terminal can execute the program code of the above steps in the resource processing method.

[0336] Optionally, Fig.16 is a structural block diagram of a computer terminal according to an embodiment of the present application. Fig.16 As shown, the computer terminal A may include: one or more (only one is shown in the figure) processors 1602 , a memory 1604 and a transmission device 1606 .

[0337] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the resource processing method and device in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned resource processing method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and the above-mentioned remote memory may be connected to the computer terminal A via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0338] It can be understood by those skilled in the art that Fig.16 The structure shown is for illustration only, and the computer terminal A may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID for short), a PAD, or other terminal devices. Fig.16 It does not limit the structure of the above-mentioned computer terminal A. For example, the computer terminal A may also include Fig.16 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Fig.16 Different configurations are shown.

[0339] A person skilled in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing the hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0340] The embodiment of the present application further provides a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store the program code executed by the resource processing method provided in the first embodiment.

[0341] Optionally, in this embodiment, the computer-readable storage medium may be located in any one of the computer terminals in a computer terminal group in a computer network, or in any one of the mobile terminals in a mobile terminal group.

[0342] Optionally, in this embodiment, a computer-readable storage medium is configured to store program codes for executing the above steps.

[0343] An embodiment of the present application may provide an electronic device, which may include a memory and a processor.

[0344] Fig.17 It is a block diagram of an electronic device according to a method for processing resources in an embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0345] like Fig.17 As shown, the device 1700 includes a computing unit 1701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1702 or a computer program loaded from a storage unit 1708 into a random access memory (RAM) 1703. In the RAM 1703, various programs and data required for the operation of the device 1700 can also be stored. The computing unit 1701, the ROM 1702, and the RAM 1703 are connected to each other via a bus 1704. An input / output (I / O) interface 1705 is also connected to the bus 1704.

[0346] A number of components in the device 1700 are connected to the I / O interface 1705, including: an input unit 1706, such as a keyboard, a mouse, etc.; an output unit 1704, such as various types of displays, speakers, etc.; a storage unit 1708, such as a disk, an optical disk, etc.; and a communication unit 1709, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 1709 allows the device 1700 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0347] The computing unit 1701 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 1701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (Graphics Processing Unit, referred to as GPU), various dedicated artificial intelligence (Artificial Intelligence, referred to as AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (Digital Signal Processor, referred to as DSP), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 1701 performs the various methods and processes described above, such as the processing method of resources. For example, in some embodiments, the processing method of resources may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 1708. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 1700 via the ROM 1702 and / or the communication unit 1709. When the computer program is loaded into the RAM 1703 and executed by the computing unit 1701, one or more steps of the processing method of resources described above may be performed. Alternatively, in other embodiments, the computing unit 1701 may be configured to execute the resource processing method in any other appropriate manner (eg, by means of firmware).

[0348] The embodiment of the present application further provides a computer program product. Optionally, in the present embodiment, the computer program product may include a computer program, and when the computer program is executed by a processor, the resource processing method of the embodiment of the present application is implemented.

[0349] According to an embodiment of the present application, a method for processing resources is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0350] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Fig.18 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a resource processing method according to an embodiment of the present application, such as Fig.18 As shown, the computer terminal 180 (or mobile device) may include one or more (shown in the figure as 1802a, 1802b, ..., 1802n) processors 1802 (the processor 1802 may include but is not limited to a processing device such as a microprocessor (MicroControllerUnit, abbreviated as MCU) or a programmable logic device (Field Programmable Gate Array, abbreviated as FPGA)), a memory 1804 for storing data, and a transmission device 1806 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art will understand that Fig.18 The structure shown is only for illustration and does not limit the structure of the above electronic device. Fig.18 More or fewer components as shown, or with Fig.18 Different configurations are shown.

[0351] Fig.18 The hardware structure block diagram shown can be used not only as an exemplary block diagram of the above-mentioned computer terminal 180 (or mobile device), but also as an exemplary block diagram of the above-mentioned server. In an optional embodiment, Fig.18 The block diagram shows the use of the above Fig.18 The computer terminal 180 (or mobile device) is shown as an embodiment of a computing node in the computing environment 1901 .

[0352] Fig.19 is a structural block diagram of a computing environment of a resource processing method according to an embodiment of the present application, such as Fig.19 As shown, computing environment 1901 includes multiple computing nodes (such as servers) running on a distributed network (illustrated by 1910-1, 1910-2, ..., in the figure). The computing nodes all contain local processing and memory resources, and end users 1902 can remotely run applications or store data in computing environment 1901. Applications can be provided as multiple services 1920-1, 1920-2, 1920-3 and 1920-4 in computing environment 1901, representing services "F", "G", "I" and "H" respectively.

[0353] The end user 1902 can provide and access services through a web browser or other software application on the client, and in some embodiments, the end user 1902's provision and / or request can be provided to the entry gateway 1930. The entry gateway 1930 may include a corresponding agent to handle the provision and / or request for the service (one or more services provided in the computing environment 1901).

[0354] Services are provided or deployed based on various virtualization technologies supported by computing environment 1901. In some embodiments, services can be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. Virtual machine-based virtualization can be to simulate a real computer by initializing a virtual machine, and execute programs and applications without directly contacting any actual hardware resources. While the virtual machine virtualizes the machine, according to container-based virtualization, a container can be started to virtualize the entire operating system so that multiple workloads can run on a single operating system instance.

[0355] In an embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). Fig.19 As shown, service 1920-2 can be equipped with one or more Pods 1940-1, 1940-2, ..., 1940-N (collectively referred to as Pods). Pods can include a proxy 1945 and one or more containers 1942-1, 1942-2, ..., 1942-M (collectively referred to as containers). One or more containers in a Pod process requests related to one or more corresponding functions of the service, and the proxy 1945 generally controls network functions related to the service, such as routing, load balancing, etc. Other services can also be equipped with Pods similar to Pods.

[0356] During operation, executing a user request from the end user 1902 may require calling one or more services in the computing environment 1901, and executing one or more functions of a service may require calling one or more functions of another service. Fig.19 As shown, service "F" 1920-1 receives a user request from terminal user 1902 from ingress gateway 1930, service "F" 1920-1 may call service "G" 1920-2, and service "G" 1920-2 may request service "I" 1920-3 to perform one or more functions.

[0357] The computing environment described above can be a cloud computing environment, where the allocation of resources is managed by the cloud service provider, allowing the development of functions without analyzing, implementing, adjusting, or expanding servers. The computing environment allows developers to execute code that responds to events without building or maintaining complex infrastructure. Services can be segmented to complete a set of functions that can be automatically and independently scaled, rather than expanding a single hardware device to handle potential loads.

[0358] Various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard parts (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. The various embodiments described above may include: being implemented in one or more computer programs, which may be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general programmable processor, which may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0359] The program code for implementing the method of the present application can be written in any combination of one or more programming languages. The above program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0360] In the context of the present application, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory for short), an optical fiber, a portable compact disk read-only memory (CD-ROM for short), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0361] To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having: a display device (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD), a monitor for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a path ball), through which the user may provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0362] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a Local Area Network (LAN), a Wide Area Network (WAN), and the Internet.

[0363] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0364] The above are only preferred implementations of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. The above improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for processing resources, characterized in that: include: Determine a scenario type of a scenario in which the resource to be processed is located, wherein the scenario type is used to indicate a type of operation performed on the resource to be processed in the scenario; Determine an extension strategy that matches the scenario type, and metadata that matches the scenario type, wherein the extension strategy is used to represent a rule for extending the resource to be processed according to an extension level that matches the scenario type, and the metadata is used to describe a format and / or content defined by the resource to be processed in a scenario of the scenario type; According to the expansion strategy, the resource to be processed is expanded at the expansion level using the metadata to obtain a target resource; An operation corresponding to the scenario type is performed on the target resource to obtain an operation result.

2. The method according to claim 1, characterized in that The method further comprises: Determining an interface that matches the extension policy, wherein the extension policy includes attribute information of the interface; According to the extension strategy, the resource to be processed is extended at the extension level using the metadata to obtain the target resource, including: calling the interface, according to the extension strategy, the resource to be processed is extended at the extension level using the metadata to obtain the target resource.

3. The method according to claim 1, characterized in that Determine the scaling strategy that matches the scenario type, including: In the extension strategy set, determine the extension strategy that matches the scenario type, wherein the extension strategy set includes at least one of the following: a material extension strategy, a resource extension strategy, and a process extension strategy, wherein the material extension strategy is used to represent the rules for extending the atomic artifacts contained in the resource to be processed, the resource extension strategy is used to represent the rules for extending the resource to be processed as a whole, and the process extension strategy is used to represent the rules for extending the operation process of the resource to be processed.

4. The method according to claim 3, characterized in that In the extension strategy set, determining the extension strategy that matches the scenario type includes: In the case where the operation corresponding to the scenario type is a resource production operation, in the extension strategy set, at least the material extension strategy corresponding to the resource production operation and the resource extension strategy corresponding to the resource production operation are determined; In the case where the operation corresponding to the scenario type is a resource synchronization operation, in the extension strategy set, at least the material extension strategy corresponding to the resource synchronization operation is determined; In the case where the operation corresponding to the scenario type is a resource installation operation, in the extension strategy set, at least the material extension strategy corresponding to the resource installation operation is determined; In the extension strategy set, the process extension strategy that matches the extension requirement information under the scenario type is determined, wherein the extension requirement information is used to indicate a requirement for extending the operation process of the resource to be processed.

5. The method according to claim 3, characterized in that: According to the extension strategy, the resource to be processed is extended at the extension level using the metadata to obtain a target resource, including: In the case where the extension strategy is the material extension strategy, the atomic products of different prefabricated types constituting the resource to be processed are extended by using the metadata to obtain the target resource; In the case where the extension strategy is the resource extension strategy, the resource information of the resource to be processed as a whole is extended by using the metadata to obtain the target resource; In the case where the extension strategy is the process extension strategy, the process information of the operation process of the resource to be processed is configured using the metadata to obtain the target resource.

6. The method according to claim 5, characterized in that In the case where the extension strategy is the material extension strategy, the atomic products of different prefabricated types constituting the resource to be processed are extended by using the metadata to obtain the target resource, including: In the case where the extension strategy is the material extension strategy, the metadata is used to call the controller corresponding to the prefabricated type, and the atomic product of the prefabricated type is expanded to obtain the target resource, wherein different prefabricated types correspond to different controllers.

7. The method according to claim 5, characterized in that In the case where the extension strategy is the resource extension strategy, the resource information of the resource to be processed as a whole is extended by using the metadata to obtain the target resource, including: In the case where the extension strategy is the resource extension strategy, the metadata is extended, wherein the extended metadata is used to describe the resource attribute information of the resource to be processed after extension; using the extended metadata, the resource attribute information of the resource to be processed as a whole is extended to obtain the target resource; and / or, In the case where the extension strategy is the resource extension strategy, the metadata is used to extend the definition description language of the resource to be processed as a whole to obtain the target resource, wherein the definition description language is used to describe resource composition information of the resource to be processed.

8. The method according to claim 5, characterized in that In the case where the extension strategy is the process extension strategy, configuring the process information of the operation process of the resource to be processed by using the metadata to obtain the target resource includes: In a case where the extension strategy is the process extension strategy, determining at least one target operation process in the operation process set; The process information of the target operation process is configured using the metadata to obtain the target resource.

9. The method according to claim 3, characterized in that: The method further comprises: Using resources from a third-party system to generate the resource extension strategy in the extension strategy set; and / or, The material extension policy in the extension policy set is generated by using resource materials from the third-party system, wherein the resource materials are used to represent atomic artifacts included in the resource image file of the third-party system.

10. The method according to claim 9, characterized in that Using the resource materials from the third-party system, generating the material extension strategy in the extension strategy set includes: The material extension policy in the extension policy set is generated by using the resource material from the third-party system and the resource extension policy in the extension policy set.

11. The method according to claim 3, characterized in that Determine metadata that matches the scene type, including: Determine resource basic metadata that matches the scenario type, the resource extension strategy, and the definition description language of the resource to be processed, wherein the resource basic metadata is used to describe basic information of the asset image file of the resource to be processed in the scenario, and the definition description language is used to describe resource composition information of the resource to be processed; Determine resource material metadata that matches the scenario type, the material extension strategy, and the definition description language, wherein the resource material metadata is used to describe the atomic artifact of the resource to be processed in the asset image file in the scenario.

12. The method according to claim 11, characterized in that The resource basic metadata includes resource native information and / or resource extended detailed information, wherein the resource native information is used to describe the native information defined by the resource to be processed in the scenario, and the resource extended detailed information is used to describe the extended detailed information defined by the resource to be processed in the scenario; the resource material metadata includes material entity metadata and / or material operation metadata, wherein the material entity metadata is used to describe the entity attributes of the atomic product defined by the resource to be processed in the scenario, and the material operation metadata is used to describe the data required during the operation of the atomic product defined by the resource to be processed in the scenario.

13. The method according to claim 1, characterized in that Performing an operation corresponding to the scenario type on the target resource to obtain an operation result, including at least one of the following: Performing a resource production operation corresponding to a resource production scenario type on the target resource to obtain a plurality of atomic products of the target resource in the scenario; combining the plurality of atomic products to obtain a first asset image file of the target resource in the scenario; Performing a resource synchronization operation corresponding to the resource synchronization scenario type on the target resource, and synchronizing the second asset image file corresponding to the resource information of the target resource in the scenario to the resource management and operation platform; A resource installation operation corresponding to a resource installation scenario type is performed on the target resource, and a third asset image file of the target resource in the scenario is installed into a target project system or cluster.

14. A method for processing enterprise assets, characterized in that: Applied to enterprise asset processing platforms, including: Determine a scenario type of a scenario in which the enterprise asset to be processed is located, wherein the scenario type is used to indicate a type of operation performed on the enterprise asset to be processed in the scenario; Determine an extension point that matches the scenario type, and asset metadata that matches the scenario type, wherein the extension point is used to represent a rule for extending the enterprise asset to be processed according to an extension level that matches the scenario type, and the asset metadata is used to describe the format and / or content defined by the enterprise asset to be processed in the scenario of the scenario type; According to the extension point, the enterprise asset to be processed is extended at the extension level using the asset metadata to obtain a target enterprise asset; An operation corresponding to the scenario type is performed on the target enterprise asset to obtain an asset image file of the target enterprise asset in the scenario.

15. A method for processing resources, characterized in that: include: In response to an operation instruction acting on the operation interface, determine a scene type of a scene in which the resource to be processed is located, wherein the scene type is used to indicate a type of operation performed on the resource to be processed in the scene; Displaying an extension policy matching the scenario type and metadata matching the scenario type on the operation interface, wherein the extension policy is used to indicate a rule for extending the resource to be processed according to an extension level matching the scenario type, and the metadata is used to describe a format and / or content defined by the resource to be processed in the scenario of the scenario type; Displaying a target resource corresponding to the resource to be processed on the operation interface, wherein the target resource is obtained by extending the resource to be processed at the extension level using the metadata according to the extension strategy; The operation result obtained by performing the operation corresponding to the scenario type on the target resource is displayed on the operation interface.

16. A method for processing resources, characterized in that: include: Determine the scenario type of the scenario in which the resource to be processed is located by calling the first interface, wherein the scenario type is determined by calling the first interface, and the scenario type is used to indicate the type of operation performed on the resource to be processed in the scenario; Determine an extension strategy that matches the scenario type, and metadata that matches the scenario type, wherein the extension strategy is used to represent a rule for extending the resource to be processed according to an extension level that matches the scenario type, and the metadata is used to describe a format and / or content defined by the resource to be processed in a scenario of the scenario type; According to the expansion strategy, the resource to be processed is expanded at the expansion level using the metadata to obtain a target resource; Performing an operation corresponding to the scenario type on the target resource to obtain an operation result; The operation result is output by calling a second interface, wherein the second interface includes a second parameter, and a parameter value of the second parameter is the operation result.

17. A resource processing system, characterized in that: include: A client, used to upload a resource processing request, wherein the resource processing request is used to request processing of a resource to be processed; At least one resource processing platform is used to determine the scene type of the scene in which the resource to be processed is located in response to the resource processing request, wherein the scene type is used to indicate the type of operation performed on the resource to be processed in the scene; determine an extension policy matching the scene type, and metadata matching the scene type, wherein the extension policy is used to indicate the rule for extending the resource to be processed according to the extension level matching the scene type, and the metadata is used to describe the format and / or content defined by the resource to be processed in the scene of the scene type; according to the extension policy, use the metadata to extend the resource to be processed at the extension level to obtain a target resource; perform the operation corresponding to the scene type on the target resource to obtain an operation result; and send the operation result to the client.

18. The system according to claim 17, characterized in that The multiple resource processing platforms are constructed based on a distributed deployment architecture, and the multiple resource processing platforms are interconnected, and the target resources are allowed to be reused in the multiple resource processing platforms.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is executed, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 16.

20. A computer program product, characterized in that It comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 16.

Images