CN119168432A

CN119168432A - Resource processing method, system, electronic device and storage medium

Info

Publication number: CN119168432A
Application number: CN202411678320.2A
Authority: CN
Inventors: 于浩洋; 石兵; 郭平; 谢纯良
Original assignee: Alibaba Cloud Feitian Hangzhou Cloud Computing Technology Co ltd
Current assignee: Alibaba Cloud Feitian Hangzhou Cloud Computing Technology Co ltd
Priority date: 2024-11-21
Filing date: 2024-11-21
Publication date: 2024-12-20

Abstract

The application discloses a resource processing method, a resource processing system, electronic equipment and a storage medium. The method comprises the steps of determining a scene type of a scene where a resource to be processed is located, wherein the scene type is used for representing the type of operation executed by the resource to be processed under the scene, determining an expansion strategy matched with the scene type and metadata matched with the scene type, wherein the expansion strategy is used for representing a rule that the resource to be processed expands according to an expansion hierarchy matched with the scene type, the metadata is used for describing the format and/or content defined by the resource to be processed under the scene of the scene type, expanding the resource to be processed on the expansion hierarchy by utilizing the metadata according to the expansion strategy to obtain a target resource, and executing the operation corresponding to the scene type on the target resource to obtain an operation result. The application solves the technical problem of low flexibility of resource processing.

Description

Resource processing method, system, electronic equipment and storage medium

Technical Field

The present application relates to the field of computers, and in particular, to a method, a system, an electronic device, and a storage medium for processing resources.

Background

Currently, in the process of gradual deepening of informatization, management of resources becomes an increasingly prominent challenge. In the related art, a resource processing platform is often limited to basic archiving and directory services when processing the assets, and the processing mode has significant limitations in description, definition, type support and expansibility of the resources.

In particular, descriptions of assets by resource processing platforms in the related art tend to flow to surfaces, lacking systematic elucidation and explicit definition of depth, which leads to bias in the application and understanding of assets in different scenarios. And the method is also limited by preset asset types, such as documents, code libraries and the like, and cannot flexibly adapt to the asset types of various emerging and specific scenes encountered by enterprises in development, so that the application range of a platform and the optimal configuration of enterprise resources are limited. Because of limitations in asset processing platform design, there is a lack of efficient mechanisms to accommodate and integrate extensions to external systems or custom asset types, which prevents the iteration and upgrading of platform functionality, as well as deep integration with other systems and external services within the enterprise. The asset archiving mode of the resource processing platform is often fixed and stiff, and is difficult to meet the flexible processing and customization requirements of enterprises on resources, such as the operations of combining, splitting, converting and the like of the resources.

In summary, the asset management platform in the related art has a processing manner and capability that is a part of the forefront in the face of complex and varied resources accumulated in the enterprise for many years. Therefore, there is still a technical problem that flexibility of resource processing is low.

In view of the above problems, no effective solution has been proposed at present.

Disclosure of Invention

The embodiment of the application provides a resource processing method, a system, electronic equipment and a storage medium, which are used for at least solving the technical problem of low flexibility of resource processing.

According to one aspect of the embodiment of the application, a method for processing resources is provided. The method comprises the steps of determining a scene type of a scene where a resource to be processed is located, wherein the scene type is used for representing the type of operation executed by the resource to be processed under the scene, determining an expansion strategy matched with the scene type and metadata matched with the scene type, wherein the expansion strategy is used for representing a rule that the resource to be processed expands according to an expansion hierarchy matched with the scene type, the metadata is used for describing the format and/or content defined by the resource to be processed under the scene of the scene type, expanding the resource to be processed on the expansion hierarchy by utilizing the metadata according to the expansion strategy to obtain a target resource, and executing the operation corresponding to the scene type on the target resource to obtain an operation result.

According to another aspect of an embodiment of the present application, a method for processing an enterprise asset is provided. The method is applied to an asset processing platform and comprises the steps of determining a scene type of a scene where an enterprise asset to be processed is located, wherein the scene type is used for representing the type of operation executed by the enterprise asset to be processed under the scene, determining an expansion point matched with the scene type and asset metadata matched with the scene type, wherein the expansion point is used for representing a rule that the enterprise asset to be processed expands according to an expansion level matched with the scene type, the asset metadata is used for describing a format and/or content defined by the enterprise asset to be processed under the scene of the scene type, expanding the enterprise asset to be processed on the expansion level according to the expansion point by utilizing the asset metadata to obtain a target enterprise asset, and executing operation corresponding to the scene type on the target enterprise asset to obtain an asset image file of the target enterprise asset under the scene.

According to another aspect of the embodiment of the application, a method for processing resources is provided. The method comprises the steps of responding to an operation instruction acted on an operation interface, determining a scene type of a scene where a resource to be processed is located, wherein the scene type is used for representing the type of operation executed by the resource to be processed under the scene, displaying an expansion strategy matched with the scene type and metadata matched with the scene type on the operation interface, wherein the expansion strategy is used for representing a rule that the resource to be processed expands according to an expansion level matched with the scene type, the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type, displaying a 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 on the expansion level by utilizing the metadata according to the expansion strategy, and displaying an operation result obtained by executing the operation corresponding to the scene type on the target resource on the operation interface.

According to another aspect of the embodiment of the application, a method for processing resources is provided. The method comprises the steps of determining a scene type of a scene where a resource to be processed is located by calling a first interface, wherein the scene type is used for representing the type of an operation executed by the resource to be processed under the scene by calling the first interface as the scene type, determining an expansion strategy matched with the scene type and metadata matched with the scene type, wherein the expansion strategy is used for representing a rule for expanding the resource to be processed according to an expansion level matched with the scene type, the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type, expanding the resource to be processed on the expansion level by utilizing the metadata according to the expansion strategy to obtain a target resource, executing the operation corresponding to the scene type on the target resource to obtain an operation result, and outputting the operation result by calling a second interface, wherein the second interface comprises a second parameter, and the parameter value of the second parameter is the operation result.

According to another aspect of an embodiment of the present application, a processing system for a resource is provided. The system comprises a client, at least one resource processing platform, at least one expansion strategy and metadata, wherein the client is used for uploading a resource processing request, the resource processing request is used for requesting to process a resource to be processed, the at least one resource processing platform is used for responding to the resource processing request, determining a scene type of a scene where the resource to be processed is located, the scene type is used for representing a type of operation executed by the resource to be processed under the scene, determining the expansion strategy matched with the scene type and the metadata matched with the scene type, the expansion strategy is used for representing a rule that the resource to be processed is expanded according to an expansion level matched with the scene type, the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type, expanding the resource to be processed on the expansion level according to the expansion strategy, obtaining a target resource, executing operation corresponding to the scene type on the target resource, obtaining an operation result, and issuing the operation result to the client.

According to another aspect of the embodiment of the application, an electronic device is also provided. The electronic device may include a memory for storing computer-executable instructions and a processor for executing the computer-executable instructions that, when executed by the processor, perform the above-described methods of embodiments of the present application.

According to another aspect of an embodiment of the present application, there is also provided a processor. The processor is configured to execute a program, where the method according to the embodiment of the present application is executed when the program is executed.

According to another aspect of an embodiment of the present application, there is also provided a computer-readable storage medium. The computer readable storage medium includes a stored program, where the program when executed controls a device in which the storage medium resides to perform the above-described method according to the above-described embodiment of the present application.

According to another aspect of an embodiment of the present application, a computer program product is also provided. The computer program product comprises a computer program which, when executed by a processor, implements the above-described method of the above-described embodiments of the application.

In the embodiment of the application, different operation requirements, such as manufacturing, synchronization, installation and the like of the resource, can be identified and adapted by determining the scene type of the scene where the resource to be processed is located, so that the accurate matching between the processing process and the current service scene is ensured, a one-cut management mode is avoided, and the pertinence and the applicability of the resource processing are improved. After the expansion strategy matched with the scene type is determined, the expansion rule and the expansion hierarchy can be dynamically adjusted according to the characteristics of the resource and the scene requirement, which means that the resource processing is not limited to a preset framework, but can be flexibly expanded according to the actual situation, and the flexibility and the adaptability of the resource processing are greatly enhanced. Through the use of metadata, the definition of resources under any scene type becomes clear and structured. The metadata can describe not only basic information of the resource, but also the expression form and operation requirement of the resource in a specific scene, and provides a uniform and detailed information basis for processing the resource. By setting the expansion hierarchy matched with the scene type, a user can customize the expansion of asset materials, the expansion of the whole asset and the expansion of the asset flow, and the multi-level expansion capability ensures that the resource processing method can meet the diversified and deep customization requirements of enterprises on asset management. Based on the expansion strategy and the metadata, the resources to be processed can be rapidly expanded and converted, so that target resources are obtained, and operations corresponding to scene types are executed on the target resources.

In the embodiment, the situation of low flexibility in the traditional resource management in the related technology is avoided through scene type identification, expansion strategy customization, metadata driving and multi-level expansion, so that the technical effect of improving the flexibility of resource processing is realized, and the technical problem of low flexibility of resource processing is solved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application, as claimed.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

Fig. 1 is a schematic diagram of an application scenario of a resource processing method according to an embodiment of the present application;

FIG. 2 is a flow chart of a method of processing resources according to an embodiment of the application;

FIG. 3 is a flow chart of a method of processing an enterprise asset according to an embodiment of the application;

FIG. 4 is a flow chart of another method of processing resources according to an embodiment of the application;

FIG. 5 is a flow chart of another method of processing resources according to an embodiment of the application;

FIG. 6 is a schematic diagram of a processing system for a resource according to an embodiment of the application;

FIG. 7 is a schematic diagram of an asset extension point according to an embodiment of the application;

FIG. 8 is a flow chart of an asset fabrication process according to an embodiment of the application;

FIG. 9 is a flow chart of an asset synchronization process according to an embodiment of the application;

FIG. 10 is a flow chart of an asset installation process according to an embodiment of the application;

FIG. 11 is a schematic diagram of a distributed asset management and operation platform architecture according to an embodiment of the application;

FIG. 12 is a schematic diagram of a processing arrangement for a resource according to an embodiment of the application;

FIG. 13 is a schematic diagram of another resource processing device according to an embodiment of the application;

FIG. 14 is a schematic diagram of a processing arrangement of another resource according to an embodiment of the application;

FIG. 15 is a schematic diagram of a processing arrangement of another resource according to an embodiment of the application;

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

FIG. 17 is a block diagram of an electronic device of a method of processing resources according to an embodiment of the application;

Fig. 18 is a hardware configuration block diagram of a computer terminal (or mobile device) for implementing a processing method of resources according to an embodiment of the present application;

FIG. 19 is a block diagram of a computing environment for a method of processing resources according to an embodiment of the application.

Detailed Description

In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.

First, partial terms or terminology appearing in the course of describing embodiments of the application are applicable to the following explanation:

Enterprise information technology (Information Technology, abbreviated as IT) heterogeneous assets, abbreviated as assets, in enterprise IT, assets generally refer to a relatively independent functional component within an enterprise that may be composed of multiple heterogeneous atomic products. Such atomic articles include, but are not limited to, images, source code, document descriptions, etc., which together form a complete functional component, i.e., an asset;

asset mirroring is a special format asset file recognizable by the asset center (HUB), which is a collection of heterogeneous assets made up of multiple atomic artifacts. The asset mirror image is taken as an important component in the asset HUB, is a special format heterogeneous asset file composed of a plurality of atomic products, has rich functions and characteristics, can help enterprises to better manage and utilize the assets, and improves IT operation efficiency and management level;

Asset materials, which are a collective term for atomic artifacts contained in asset images, can be abstracted into a relatively independent atomic artifact. Asset materials may be various types of assets, such as source code, rich text, files, etc., and may also include user-defined materials. Taken together, asset materials are a collective term for the various atomic artifacts in asset images, including multiple types of assets. The asset materials together form a complete asset image, which helps enterprises to define, manage and operate assets.

According to an embodiment of the present application, there is provided a method of processing resources, it being noted that the steps illustrated in the flowchart of the drawings may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is illustrated in the flowchart, in some cases the steps illustrated or described may be performed in an order other than that illustrated herein.

The method for processing the resources provided by the embodiment of the application can be applied to the application scene shown in fig. 1, but is not limited to the application scene. In the application scenario shown in fig. 1, the server 10 may be a cloud, in which a resource processing platform may be deployed. The server 10 may be connected to one or more client devices 20 via a local area network connection, a wide area network connection, the internet connection, or other type of data network, where the client devices 20 may include, but are not limited to, smart phones, tablets, notebooks, palmtops, personal computers, smart home devices, vehicle devices, etc., which together constitute a client to the server. An operator interface may be deployed on a graphical user interface on a client device for user operation. The client device 20 may interact with a user through a graphical user interface to implement the method for processing resources provided by the embodiment of the present application.

In the embodiment of the present application, the system formed by the client device 20 and the server 10 may perform the following steps, if a certain resource to be processed needs to be processed, the user may perform corresponding operations on the client device 20 according to the own needs to select or input the resource to be processed that needs to be processed. The resources to be processed may be transmitted to the server 10 via the network 30. Specifically, the server 10 may execute the steps of determining a scene type of a scene where the resource to be processed is located in step S102, determining an expansion policy matched with the scene type and metadata matched with the scene type in step S104, expanding the resource to be processed on an expansion level by using metadata according to the expansion policy in step S106 to obtain a target resource, and executing an operation corresponding to the scene type on the target resource in step S108 to obtain an operation result.

In the above-described procedure, the operation result obtained by processing the resources to be processed in the server 10 may be transmitted to the client device 20 through the network 30. The results of the operation may be displayed on the client device 20 for viewing by the user.

In the embodiment of the application, the situations of low flexibility, weak customizing capability, low operation efficiency and the like in the traditional resource management in the related technology are avoided through scene type identification, expanding strategy customization, metadata driving and multi-level expansion, so that the technical effect of improving the flexibility of resource processing is realized, and the technical problem of low flexibility of resource processing is solved.

The embodiment of the application provides a method, and under the application scene, the application provides a resource processing method shown in figure 2. Fig. 2 is a flowchart of a method for processing resources according to an embodiment of the present application, as shown in fig. 2, the method may include the following steps:

step S202, determining the scene type of the scene where the resource to be processed is located.

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, an electronic asset. If the application scenario targeted by the resource to be processed is enterprise, the resource to be processed may be enterprise IT resource, for example, may be enterprise IT heterogeneous asset. The scenario may be a usage scenario of the resource to be processed. The scene type may be used to represent a type of operation performed on the resource to be processed in the scene, for example, the scene type may be a type of resource production, resource synchronization, or resource installation, which are only illustrated herein, and not particularly limited.

In this embodiment, if the resource to be processed needs to be processed, the scene type of the scene where the resource to be processed is located may be determined.

Alternatively, the method for processing resources in the embodiment of the present application may be performed by using a corresponding platform for resource management and operation, for example, may be a resource management system. If the resource to be processed is an asset, the resource management system may be an asset management system, for example, an asset HUB. In enterprise IT resource management, resources may be in different lifecycle stages including, but not limited to, creation, distribution, synchronization, deployment, installation, etc. of resources. The scene type may be determined based on the purpose and goal of the resource at a particular point in time.

Optionally, the selection of scene type provides guidance for subsequent specific operations, and flexibility and applicability of resource processing can be ensured. Because different scene types correspond to different operational requirements and flows, for example, resource fabrication may require creating new combinations from elements such as source code, images, etc., resource synchronization may involve the transmission, conversion, or updating of data, and resource installation may require configuration and deployment in a particular IT environment. By defining the scene type, the corresponding processing flow can be dynamically invoked and configured, and the limitation of single operation on resource management is avoided.

Alternatively, each scene type has its own unique custom processing requirements. For example, metadata may be collected and organized in a resource production scenario, network transmissions and rights verification may be handled in a resource synchronization scenario, and environment adaptation and dependency management in a resource installation scenario. By accurately judging the scene type, the resource processing method can be ensured to meet the customization demands in a targeted manner, and the efficiency and quality of resource processing are improved.

Step S204, an expansion strategy matched with the scene type and metadata matched with the scene type are determined.

In the technical solution provided in the above step S204 of the present application, the expansion policy may be used to represent a rule for expanding the resource to be processed according to an expansion hierarchy matched with the scene type, which may also be referred to as an expansion point. The metadata may be used to describe the format and/or content defined by the resource to be processed in the context of the context type, e.g., may be data describing the asset image format and content.

In this embodiment, after determining the scene type of the scene in which the resource to be processed is located, an extension policy matching the scene type may be determined. Metadata matching the scene type may also be determined.

Optionally, determining an expansion policy matching the scene type and metadata matching the scene type are dynamic configuration links of the core in the resource processing method. An expansion policy may be a mechanism for directing a resource processing method how to expand and customize the processing flow of a resource according to a particular scenario type. In the architecture of an asset HUB, the extended policy may be implemented based on a service provider interface (Service Provider Interface, abbreviated SPI) mechanism and a custom asset Domain specific language (Domain-Specific Language, abbreviated DSL). For different scenario types (e.g., resource fabrication, resource synchronization, resource installation, etc.), the asset HUB may predefine a series of expansion policies describing external services or logic that may be needed in processing the resource, e.g., acquiring resource metadata, archiving the resource, synchronizing the resource, installing the resource, etc.

Alternatively, when the asset HUB receives a request or task relating to a particular scene type, the corresponding expansion policy may be looked up and invoked in accordance with that scene type. This means that the asset HUB can flexibly call different SPI service implementations according to different scenarios, or use a default controller (Operator) to handle resources to meet specific needs of the scenario.

Alternatively, the metadata may be key information used to describe and control the resource during various stages of the resource processing. The type of metadata that needs to be collected and determined will also vary from scene type to scene type. For example, in a resource production scenario, metadata may include basic information of the resource (e.g., name, version), material composition of the resource (e.g., specific Docker image, source code, etc.), and entity metadata and operation metadata of the material. In a resource synchronization or installation scenario, metadata may be more focused on operating metadata, such as source repository address of the resource, username password, configuration information of the installation target environment, etc. It should be noted that the content included in the metadata is only illustrative, and is not limited in particular herein, and any content that can be used to describe and control the resource is within the scope of the embodiments of the present application.

Alternatively, by determining metadata matching scene types, the key to automation and intelligence of resource processing can be achieved. Metadata is used not only to describe the properties and status of a resource, but also to direct specific logic of the resource's processing, such as the archive location of the resource, synchronization targets, installation steps, etc. Through the metadata, the asset HUB can understand and execute specific requirements of scene types, and accuracy and high efficiency of resource processing are ensured.

Optionally, by the dynamic configuration mechanism described above, i.e. by determining the extension policy and metadata by scene type, a high flexibility and customizable nature of the resource handling method is ensured. The flexibility described above is mainly manifested in the ability of the asset HUB to flexibly adjust and optimize the logic and flow of resource processing according to different scene types and requirements. For example, for a resource synchronization scenario, an asset HUB may call a specific SPI service to handle network transport and storage compatibility issues, and for a resource installation it may call a specific Operator 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 with external third party services, thereby expanding its functionality and service scope. Through the mechanism, an enterprise can use the HUB as an open and extensible platform, introduce and register new SPI service realization according to own requirements, or customize new metadata fields to support wider resource types and scenes.

And S206, expanding the resources to be processed on an expansion level by utilizing metadata according to an expansion strategy to obtain target resources.

In the technical solution provided in the above step S206 of the present application, the target resource may be a resource image of specific metadata and customized processing logic to be executed, which is obtained by expanding the resource to be processed according to an expansion hierarchy, for example, if the scene is asset production, the target resource may be a resource image to be packaged and arranged.

In this embodiment, after determining the expansion policy matching the scene type and the metadata matching the scene type, the resource to be processed may be expanded on the expansion level by using the metadata according to the expansion policy, to obtain the target resource.

Optionally, the resource to be processed is expanded and converted based on the determined expansion policy and metadata to generate the target resource. The above-described process may be viewed as an operation that translates abstract resource definitions and scenario requirements into concrete resource instances.

Optionally, to ensure that the resource processing can efficiently and safely adapt to the changing network environment and the target environment characteristics, the asset HUB adopts a dynamic expansion mechanism, and the mechanism can expand the resource to be processed in a corresponding expansion level according to the requirements of the scene where the resource to be processed is located. The asset HUB may include three expansion levels, such as, for example, an expansion of asset materials, an expansion of assets, and an expansion of asset flows. The three expansion levels correspond to corresponding expansion strategies respectively. The three expansion levels provide customized solutions for different scene requirements.

Alternatively, for asset material scalability, asset material scalability may be employed when the scene relates to a particular type of resource or component that is not within the preset material type of the asset HUB, or where special customization of the processing logic of the resource is required. For example, in the scenes of resource production, resource synchronization, resource installation and the like, the expansion of asset materials can be performed. For the extensibility of assets, the extensibility of assets may be employed when a scene requires customization of the definition, structure, and metadata of the entire asset. This typically occurs where the asset needs to contain a particular type of portfolio of materials, or additional attributes and operating logic need to be defined to meet a particular business requirement. For example, in the scenarios of asset production and asset presentation, etc., the scalability of assets can be performed. For the scalability of asset flows, the scalability of asset flows may be employed when the operational flows for which the scene relates to the entire lifecycle of the asset need to be customized. For example, asset flow scalability can be performed in the scenarios of resource up-shelves, resource synchronization, resource installation, etc.

In summary, determining from which expansion hierarchy to expand a resource may analyze the core requirements of the corresponding scenario. If the demand is focused on handling a particular resource material, then the extensibility of the asset material should be initiated, if the demand is to customize the structure and metadata of the entire asset, then the extensibility of the asset flow should be employed, if the demand is related to the customization or automation of the entire flow. In practical applications, these three expansion levels may need to be used in combination to meet more complex and specialized scene requirements.

Alternatively, metadata may be dynamically used to guide the extension process of the resource in executing the extension policy. This means that the specific steps and details of the resource processing can be adjusted in real time according to the metadata and the expansion policy to adapt to different scene requirements and resource types. That is, in the process of performing three expansion levels of the asset HUB, metadata is of vital importance, and includes not only the inherent information of the resource, but also rules and logic of resource processing, and further includes information such as network environment characteristics (e.g., bandwidth, delay, network protocol compatibility of the current network) and the like, so that the asset HUB can perform intelligent and dynamic adjustment based on the metadata.

Optionally, in the extensible process of the asset material, specific material information, such as type, format, source, operation requirement, etc., of the material is included in the metadata. The asset HUB may parse the metadata and invoke the corresponding SPI service or Operator for processing according to the type of material and operational requirements. In the extensible process of the asset, metadata not only describes materials constituting the asset, but also contains key information such as the structure, operation requirements, dependency relationship and the like of the whole asset. The asset HUB will use the metadata to determine the process flow and operational details of the asset. In the extensible process of the asset flow, metadata is used to guide the flow customization of the whole asset lifecycle, including the stages of stocking, synchronizing, installing, etc. of the asset. The metadata may include flow control information such as synchronization policies, installation steps, approval flows, etc. The asset HUB may dynamically adjust the processing flow of the resource based on the metadata, such as selecting a synchronization policy, triggering a specific installation step, or invoking an SPI service of the approval flow.

For example, in the context of resource synchronization, it is assumed that a large resource packet needs to be synchronized to a target environment with limited bandwidth, where network environment characteristic fields in metadata (such as bandwidth, delay of the current network, storage capacity of the target environment, network protocol compatibility, etc.) are particularly critical. Before resource synchronization, the asset HUB can analyze the network environment characteristics in the metadata and dynamically select the most appropriate transmission mode and data format conversion logic.

Step S208, executing the operation corresponding to the scene type on the target resource to obtain an operation result.

In the technical solution provided in step S208 of the present application, the operation result corresponds to the scene type, and the operation result may be used to indicate whether to complete the operation corresponding to the scene type, or may be used to indicate the final resource obtained by performing the operation on the target resource, for example, the operation such as resource making, synchronization, and installation, and the like, to obtain the corresponding resource, which is only illustrated herein without being limited specifically. The result of the operation may be a set of resource files that have been completed synchronously, or a functional component that completes installation and configuration, etc. The method is merely illustrative, and the operation result is not particularly limited, and may be determined according to the scenario in which the resource to be processed is located and the operation to be performed.

In this embodiment, after the resource to be processed is expanded on the expansion hierarchy by using metadata according to the expansion policy, an operation corresponding to the scene type may be performed on the target resource obtained after expansion, so as to obtain an operation result.

Optionally, the method is the final execution stage of the whole resource processing flow, and the core of the method is to execute the operation corresponding to the scene type on the target resource processed through the expansion hierarchy and generate the operation result. The process converts abstract processing logic into specific execution actions, ensures that the whole resource processing flow is closed-loop, and provides basis for follow-up resource state tracking, feedback and operation decision.

For example, if the scene type is "resource production type", operations such as packaging and arranging can be performed on the resource image to form a packaged and arranged resource image, if the scene type is "resource synchronization", the asset HUB can perform operations such as copying and transmitting on the target resource and send the target resource to another asset HUB to form a resource file which is already finished synchronously, and if the scene type is "resource installation", operations such as downloading, analyzing and initializing configuration can be performed on the target resource to form a functional component which is already finished to be installed.

The method comprises the steps S202 to S208 of determining the scene type of the scene where the resource to be processed is located, wherein the scene type is used for representing the type of operation executed by the resource to be processed under the scene, determining an expansion strategy matched with the scene type and metadata matched with the scene type, expanding the resource to be processed on an expansion level by utilizing the metadata according to the expansion strategy to obtain a target resource, and executing the operation corresponding to the scene type on the target resource to obtain an operation result, thereby realizing the technical effect of improving the flexibility of resource processing and solving the technical problem of low flexibility of resource processing.

The above-described method of this embodiment is further described below.

The method further comprises the steps of determining an interface matched with an expansion strategy, wherein the expansion strategy comprises attribute information of the interface, and expanding the resources to be processed on an expansion level by using metadata according to the expansion strategy to obtain target resources, wherein the step S206 comprises the steps of calling the interface and expanding the resources to be processed on the expansion level by using metadata according to the expansion strategy to obtain the target resources.

In this embodiment, an interface that matches the expansion policy may be determined. Therefore, in the process of expanding the resources to be processed on the expansion level by utilizing the metadata according to the expansion strategy, a corresponding interface can be called, and the resources to be processed are expanded on the expansion level by utilizing the original data according to the expansion strategy corresponding to the interface, so that the target resources are obtained. The interface can be an SPI interface matched with the expansion point. The extended policy may include attribute information of the interface. The attribute information may include an address, an authentication manner, a service implementation manner, whether a default Operator is used, and the like, corresponding to the interface. It should be noted that, the attribute information of the interface is merely illustrative, and is not limited herein.

Optionally, an interface mechanism matching the expansion policy, in particular the use of SPI, may be introduced in this embodiment. By introducing the above mechanism, not only is the flexibility of the resource expansion process increased, but also the operation is allowed to be performed in a more modularized manner, and meanwhile, the customization and the safety of the operation are ensured.

Optionally, at the preparation stage of the resource processing, an interface may be determined that matches the expansion policy to be executed. The interfaces referred to herein, generally referred to as SPI service interfaces, allow third party services or plug-ins to interact with the asset HUB system to perform specific resource operations. The expansion policy contains attribute information of the interface, and the attribute information defines details of the use, calling mode, authentication mechanism, whether to use the default Operator of the system, and the like of the interface. By matching the correct interfaces, the executed resource operation can be ensured to meet the current scene requirement, and meanwhile, specific technical guidance is provided for subsequent calling and execution.

Alternatively, after determining the interface matching the expansion policy, the interface may be called, and expansion and conversion of the resource may be performed using metadata according to attribute information of the interface. For example, if the extended policy involves archiving of resource materials, then the corresponding SPI interface may be invoked to handle packaging, uploading, etc. of the materials through the specific implementation provided by the interface service, while utilizing the materials operations metadata to guide this process. In the resource synchronization scenario, an SPI interface for network transport and data conversion may be invoked to ensure that resources can be successfully transported from the source HUB to the target HUB. By the method, the specific logic of resource expansion and conversion can be provided by external implementation, so that the flexibility and the expandability of the HUB are improved.

Optionally, attribute information of the interface, such as address, authentication mode, service implementation mode, and whether to use default operators, etc., is critical to the expansion and processing of resources. The address information defines the position of SPI service, the authentication mode ensures the safety and legitimacy of resource operation, the service implementation mode indicates the specific function and operation flow of the interface, and whether the default Operator is used or not determines whether the preset service implementation is required to be invoked or whether the service is required to be provided through an external system. The use of these attribute information enables the asset HUB system to dynamically invoke the correct services at different resource processing stages, performing customized resource operations while guaranteeing the security and consistency of the operations.

Optionally, by determining an interface matching the expansion policy and invoking the interface, a corresponding resource operation can be dynamically performed according to the current scenario requirements and resource types. This dynamics not only allows the asset HUB system to adapt to complex resource handling environments, but also makes the process of resource conversion more intelligent and efficient. For example, when synchronizing resources, the system may dynamically select the most appropriate transmission protocol according to the characteristics of the target environment, and call the corresponding service implementation through the SPI interface to complete the synchronization operation.

In the embodiment of the application, the modularization and pluggable design of resource expansion and conversion are realized by introducing the SPI interface and defining the attribute information thereof in detail. The method not only reduces the coupling degree in the asset HUB system, but also allows external services or plug-ins to participate in the resource processing flow in a standardized manner, thereby improving the expandability of the asset HUB system. In addition, the security and controllability of the resource operation are enhanced by the arrangement, and the security risk in the resource processing process is reduced because the authentication mode of the interface and whether the default Operator and other attributes are used can ensure that only authorized services can operate the resource.

In summary, by determining interfaces that match the expansion policy and invoking the interfaces during the processing of the resource, the asset HUB system is able to perform expansion and conversion operations of the resource in a more flexible, secure and efficient manner.

As an optional implementation manner, step S204 is to determine an expansion policy matched with the scene type, which includes determining an expansion policy matched with the scene type in an expansion policy set, where the expansion policy set includes at least one of a material expansion policy, a resource expansion policy and a flow expansion policy, the material expansion policy is used for representing a rule for expanding an atomic product contained in a resource to be processed, the resource expansion policy is used for representing a rule for expanding the resource to be processed as a whole, and the flow expansion policy is used for representing a rule for expanding an operation flow of the resource to be processed.

In this embodiment, in determining an expansion policy that matches a scene type, an expansion policy that matches a scene type may be determined from an expansion policy set, where the expansion policy set may include a material expansion policy, a resource expansion policy, and a fluent expansion policy. The material expansion policy may be used to represent a rule for expanding atomic artifacts contained in a resource to be processed, and may also be referred to as an asset material expansion point, which may be used for expanding asset materials. The resource expansion policy may be used to represent a rule that expands the resource to be processed as a whole.

Optionally, the flexibility and customization of resource processing can be ensured by the method, so that the asset HUB can adapt to various different business scenes and requirements.

Alternatively, the current scene need may be identified and understood in determining an extension policy that matches the scene type. The scene types may include resource production, resource synchronization, resource installation, etc., each scene having its specific goals and requirements. For example, resource fabrication may require packaging and combining multiple atom artifacts, resource synchronization may involve network transport and data consistency, and resource installation may require environmental configuration and initiation of script execution.

Optionally, the expansion policy set includes a material expansion policy, a resource expansion policy and a flow expansion policy, which are respectively expanded and customized for an atomic product of the resource, an integral resource and a resource operation flow, so as to meet the requirements of a specific scene.

Optionally, a material expansion policy focuses on atomic artifacts in the resource, such as Docker images, source code files, sea diagrams (HELM CHART), and so on. It defines rules how these materials are handled and expanded, including obtaining material metadata, packaging materials, synchronizing materials to different environments, etc. Through the strategy, the specific SPI service can be called as required, the expansion operation of the specific materials is executed, and the integrity and consistency of the materials are ensured.

Optionally, a resource expansion policy focuses on expanding the resources to be processed as a whole. It may include the definition and extension of the overall attributes of the resource description, classification, tags, rights settings, etc. The resource expansion strategy ensures the universality and the identifiability of the resource under different scenes, and simultaneously supports the personalized description and management of the resource.

Optionally, a flow expansion policy focuses on the flow and steps of resource processing, such as the flow of resource fabrication, pre-processing before synchronization, dependency checking at installation, and so on. It allows a user or system administrator to customize the flow of resource operations, including adding approval flows, customizing the order of operations, integrating third party services, etc. The flow expansion policy enhances the flexibility of resource handling so that asset HUB can be seamlessly integrated with business flows and workflows of an enterprise.

Optionally, in determining a policy matching the scene type, the user or the current operating scene requirement may be identified, and a specific scene such as resource production, synchronization or installation may be determined. And selecting an expansion strategy matched with the scene type from the expansion strategy set according to the identified scene type. For example, in a resource production scenario, a material expansion policy and a resource expansion policy may be selected to ensure that the resource and its materials are properly packaged and described. Once the expansion policies are determined, the system will perform the corresponding operations according to these policies. For example, call SPI services to obtain material metadata, package materials with specific operators, update description information of resources, and so forth.

In the embodiment of the application, the asset HUB system can dynamically adapt to different business scenes by the method and provide highly customized resource processing service. The method not only enhances the flexibility and efficiency of resource processing, but also ensures the consistency and safety of resources. In addition, due to the modular design of the expansion strategy, new material types, resource attributes and operation flows can be easily integrated, thereby promoting the innovation and multiplexing of resources inside the whole enterprise.

For example, assuming that the scene type is resource synchronization, a "resource synchronization policy" may be selected from the set of extended policies. The policy includes rules such as pre-check before synchronization, selection of network transmission protocol, and data consistency check after synchronization. Corresponding SPI services, such as network transport services, data verification services, etc., may be invoked according to the policies described above to handle the overall process of synchronizing resources from one HUB to another. Through the process, the high efficiency and accuracy of resource synchronization are ensured, and meanwhile, the network limitation and the security requirement possibly faced by enterprises are also met.

In summary, by determining the policies matching the scene types from the extended policy set, the asset HUB system can process and manage resources in a more intelligent and adaptive manner, and support the resource diversification and customization requirements inside the enterprise, thereby bringing higher IT asset management and operation efficiency for the enterprise.

As an alternative implementation manner, in the expansion policy set, the expansion policy matched with the scene type is determined, wherein in the expansion policy set, at least the material expansion policy corresponding to the resource making operation and the resource expansion policy corresponding to the resource making operation are determined, in the expansion policy set, in the case that the operation corresponding to the field Jing Leixing is the resource synchronous operation, at least the material expansion policy corresponding to the asset synchronous operation is determined, in the expansion policy set, in the case that the operation corresponding to the field Jing Leixing is the resource installation operation, at least the material expansion policy corresponding to the resource installation operation is determined, in the expansion policy set, and in the expansion policy set, the flow expansion policy matched with the expansion requirement information under the scene type is determined, wherein the expansion requirement information is used for representing the requirement of expanding the operation flow of the resource to be processed.

In this embodiment, in determining an expansion policy matching a scene type from the expansion policy set, if an operation corresponding to the scene type is a resource creation operation, at least a material expansion policy and a resource expansion policy corresponding to the resource creation operation may be determined from the expansion policy set. If the operation corresponding to the scene type is the resource synchronous operation, determining a material expansion strategy corresponding to the resource synchronous operation from the expansion strategy set. If the operation corresponding to the scene type is a resource installation operation, determining a material expansion strategy corresponding to the resource installation operation from the expansion strategy set. And the flow expansion strategy matched with the expansion requirement information under the scene type can be determined in the expansion strategy set. The extended requirement information may be used to indicate a requirement for extending an operation flow of the resource to be processed, for example, may be an actual requirement of a user.

Alternatively, it is important to choose a specific expansion strategy according to different scenario types (resource production, resource synchronization, resource installation). In the resource production scenario, at least a material expansion policy and a resource expansion policy will be selected in order to ensure that the resource and its constituent materials are properly packaged, described and archived.

Optionally, at least a material expansion policy may be determined for a resource synchronization or resource installation operation. In a synchronous scenario, the material expansion policy directs how resources are transferred from one environment to another, possibly including selection of network transport protocols, conversion of data formats, adaptive processing of the target environment, and so on. In the installation scenario, the material expansion policy then relates to how to deploy the material in the resource image into the target environment, such as executing an initialization script, configuring environment variables, and so on.

Through the analysis, the portability and operability of the resources in different environments are ensured by the selection of different expansion strategies, and the cross-environment use and rapid deployment of the resources are supported. Flow expansion policies are used to meet the need for expanding resource operational flows, which allow users to define and customize the flow of resource processing, including but not limited to approval flows, backup policies, exception handling, and the like. The method can adapt to the specific business process of enterprises and provide customized resource operation service through the process expansion strategy. For example, a user may define a complex approval process that ensures that high value resources are approved and approved as necessary prior to fabrication or installation.

In the embodiment of the application, the flow and the details of the resource processing can be customized according to specific service requirements by selecting the expansion strategy matched with the scene type, so that the flexibility and the efficiency of resource management are improved. In the resource synchronization and installation operation, the material expansion strategy ensures the compatibility and operability of the resources under different environments, and supports the cross-environment multiplexing and rapid deployment of the resources. The flow expansion strategy allows dynamic adjustment and expansion of the flow of resource operation, and supports rapid change and adaptation of enterprise business flow. The policies in the extended policy set define security criteria and consistency requirements of the resource processing, such as authentication mode, use of specific operators, etc., and enhance security of the resource processing and consistency of data.

For example, suppose a user needs to make a resource image that contains multiple Docker images and source code files. The material expansion policy may be determined, the SPI service is invoked to obtain metadata for all images and source code, and the operators are used to package the materials into the resource images. The description, label and authority of the resource can be set according to the resource expansion strategy, and a complete and safe resource mirror image can be generated.

For another example, in the resource synchronization scenario, when a resource needs to be synchronized from one HUB to another HUB, the most appropriate network transmission protocol may be selected according to the material expansion policy, the transmission SPI service may be invoked, and the integrity of the data may be ensured by using a data checking mechanism during the synchronization process.

As an optional example, in the resource installation scenario, when the resource is installed in a specific environment, an Operator or SPI service may be called according to a material expansion policy to execute an initialization script, and an environment variable is configured, so as to ensure correct deployment and operation of the resource in a target environment.

As another alternative, if the user defines a complex approval process, multiple levels of approval are required before the resource is made. The process expansion strategy is executed before the resource making operation starts, and all necessary approval of the resource before making is ensured by calling the corresponding approval service.

In summary, the asset HUB can provide more flexible, safe and efficient resource processing services based on scene type selection and application of the expansion strategy, and adapt to diversified demands of enterprises and rapidly-changing business environments.

As an optional implementation manner, according to an expansion policy, the resource to be processed is expanded on an expansion level by utilizing metadata to obtain a target resource, wherein the method comprises the steps of expanding atomic products of different prefabrication types forming the resource to be processed by utilizing the metadata under the condition that the expansion policy is a material expansion policy to obtain the target resource, expanding resource information of the resource to be processed as a whole under the condition that the expansion policy is a resource expansion policy to obtain the target resource, and configuring flow information of an operation flow of the resource to be processed by utilizing the metadata under the condition that the expansion policy is a flow expansion policy to obtain the target resource.

In this embodiment, in the process of expanding the resource to be processed on the expansion hierarchy by using metadata according to the expansion policy, if the expansion policy is a material expansion policy, the metadata may be used to expand the atomic products of different prefabricated types that constitute the resource to be processed, so as to obtain the target resource. If the expansion policy is a resource expansion policy, metadata can be utilized to expand the resource information of the resources to be processed as the arrangement, so as to obtain the target resource. If the expansion policy is a flow expansion policy, the metadata may be used to configure flow information of an operation flow of the resource to be processed, so as to obtain the target resource. Wherein the prefabricated type may be an asset material type. The flow information may be used to indicate whether the resource to be processed provides information on shelves, whether shelves automatically make assets, whether subscriptions require approval, whether subscriptions, or which materials to support installing assets, etc. It should be noted that the above flow information is merely illustrative, and is not limited herein.

Optionally, the method not only relates to the processing of the atomic product, but also comprises the expansion of the whole information of the resource and the configuration of the operation flow of the resource, so that the resource can be correctly expanded and used under different scenes.

Alternatively, when the expansion strategy is a material expansion strategy, attention is paid to the expansion of atomic species of different prefabricated types in the resource to be treated. The above process involves manipulating individual atom products with metadata to meet the needs of a particular scenario. For example, in a resource creation process, a material expansion policy may include obtaining metadata, packaging archive, and material manipulation, etc.

Alternatively, when the expansion policy is a resource expansion policy, metadata expansion of the whole resource is focused. This involves the updating and configuration of attributes for resource descriptions, classifications, labels, dependencies, rights settings, etc. Such as updating resource descriptions, setting permissions and dependencies, resource operation configurations, etc.

Optionally, a flow expansion policy focuses on the configuration and expansion of resource operational flows, defining and controlling lifecycle management of resources by utilizing metadata. Such as flow configuration, custom operations.

In the embodiment of the application, the asset HUB system can flexibly process the resources according to different scenes and requirements by utilizing the metadata to expand the resources, and support the diversification and customization of the resources. The extension of the prefabricated type atomic product and the resource information ensures the operability and consistency of the resource under different scenes and supports the rapid manufacture and deployment of the resource. The configuration of the flow information allows users and administrators to customize the flow of resource operations, enhancing the configurability and adaptability of the asset HUB system. Under the resource expansion strategy, the asset HUB system can perform authority setting and dependency checking based on metadata, and ensures the safety and compliance of resource processing. Through an automatic and standardized resource expansion process, the efficiency of resource processing can be obviously improved, human errors are reduced, and the multiplexing rate of resources is improved.

For example, for resource creation, assume that a user needs to create a resource that contains a Docker image and a source code file. And acquiring mirror images and source code information through metadata by utilizing a material expansion strategy, and then packaging and archiving the materials into the resource mirror images. And updating the description information of the resource according to the resource expansion strategy, setting the dependency and authority of the resource, and generating a final resource mirror image. For resource synchronization, when synchronizing resources to another HUB, a network transmission protocol is configured according to metadata by utilizing a material expansion strategy and a flow expansion strategy, and synchronization operation is executed, and abnormal conditions in the synchronization process, such as a retry mechanism, data verification and the like, are processed. For resource installation, when resources need to be installed in a specific environment, the asset HUB system configures the environment and performs installation operations, such as pulling and running of a Docker mirror image, compiling and deploying source codes and the like, according to metadata based on a material expansion strategy.

In summary, by using metadata to perform resource expansion under an expansion policy, the asset HUB can provide a more intelligent, safe and efficient resource management and operation platform, and support diversified demands of resources and specific business processes of enterprises. The method ensures the comprehensiveness and the flexibility of resource processing through the expansion of three layers of materials, resources and processes, and is a key step for realizing the automation and the intellectualization of resource management.

Optionally, the asset HUB is prefabricated with a variety of common asset material types (prefabricated types), including, by way of example only, docker mirror, source code, files, attachments, rich text (Markdown), java Archive (JAR for short), helm Chart (Chart), application programming interface (Application Programming Interface for short, API), and the like. The prefabricated types cover common asset forms and contents, and a user can conveniently and quickly create and manage various types of assets.

Alternatively, in addition to the pre-formed asset material types, the user may also describe custom extended material types using the asset DSL language. The flexible customization mode enables a user to define new asset material types according to specific requirements, and meets specific business scenes and requirements.

Optionally, in asset HUB, the extension of the entire asset, i.e. custom asset type, is supported and is mainly implemented by asset metadata extensibility and asset DSL.

Optionally, the extensibility of asset metadata primarily refers to the extension of asset base metadata, i.e., in the overall description definition of the asset. In addition to the native information, the user may customize the presentation properties, operational properties, dependency properties, vending properties, etc. of the asset. The extended attributes can help the user to describe and define the assets more fully, and meanwhile, the asset management detail page customized by the user can be dynamically rendered by using a metadata-driven mode. Through expansion of asset metadata, a user can perfect description and attribute of assets according to specific requirements and business scenes, so that asset management is more flexible and personalized.

Alternatively, through the DSL of the asset, the user may complete the definition of the asset by means of a concise grammatical description, including the attributes, structure, operating logic, etc. of the asset. Asset HUB will manage the full lifecycle of the asset according to asset DSL so that the user can conveniently manage and operate the asset.

Asset HUB provides users with flexible and powerful asset management capabilities through asset metadata extensibility and asset DSL functionality. The user can customize the metadata and definition of the extended assets according to the actual requirements, and personalized customization and extension of the assets are realized. At the same time, through the use of asset DSL, a user can describe and manage various aspects of the asset in a simple manner, improving operational efficiency and system flexibility. The expandability and the customization capability enable the asset HUB to meet various complex asset management requirements, and improve the flexibility and adaptability of the system.

As an optional implementation manner, when the expansion strategy is a material expansion strategy, the metadata is utilized to expand the atomic products of different prefabrication types forming the resource to be processed to obtain the target resource, and when the expansion strategy is a material expansion strategy, the metadata is utilized to call the controller corresponding to the prefabrication type to expand the atomic product of the prefabrication type to obtain the target resource, wherein the different prefabrication types correspond to the different controllers.

In this embodiment, if the expansion policy is a physical expansion policy, the controllers corresponding to the prefabricated types may be called by using metadata, and the atom products of the prefabricated types may be expanded to obtain the target resource, where different prefabricated types correspond to different controllers (operators).

Alternatively, for each pre-manufactured asset material type, the asset HUB is pre-manufactured with a complete set of Operator default implementations. The above-described Operator implementation includes various operations and functions, such as creation, updating, deletion, synchronization, etc. of assets, and a user can directly use these default implementations to quickly implement management and operation of asset materials.

By supporting multiple pre-manufactured asset material types and custom extended material types, and providing a complete Operator default implementation, the asset HUB provides a flexible and powerful asset management capability for the user. The user can select proper asset material types according to actual demands and perform customized expansion so as to meet asset management requirements of different business scenes and demands. The expandability and the customization capability enable the asset HUB to adapt to various complex asset management scenes, and improve the working efficiency and the flexibility.

Optionally, where the expansion policy is a material expansion policy, how to utilize metadata and a specific controller (Operator) to expand atomic artifacts of different prefabrication types to generate the target resource. This process is the core mechanism for material expansion in an asset HUB system, which ensures proper handling of atomic artifacts and generation of resource images.

Alternatively, an Operator is a component of the asset HUB system that is responsible for handling a particular type of asset material. It performs operations related to the material type based on rules and metadata defined in the material extension policy. Different prefabricated types correspond to different operators because each material may require different processing logic and operational flows. For example, an Operator of a Docker image may be responsible for pulling images, re-labeling, archiving to resource images, etc., while an Operator of source code may be responsible for downloading code from a code repository, compiling, testing, packaging, etc.

For example, when an expansion policy is designated as a material expansion policy, the system may call an Operator corresponding to a material prefabrication type using metadata. The above process typically involves the steps of reading metadata, reading metadata from the asset HUB that is related to a particular atom product, which may include information on the name, version, source, operating parameters, etc. of the material, invoking operators, invoking corresponding operators based on the information in the metadata, and performing an expansion operation of the material. For example, for a Docker image, a Docker Operator may be called, the image is pulled using version information in the metadata, and re-labeled and archived as needed, performing the extension operation. The Operator executes the expansion operation of the material, such as compiling and packing of the source code, according to the instructions and parameters in the metadata. The operations may include predefined or custom processing logic to adapt to different prefabrication types and scene requirements, updating metadata, and after the material expansion is completed, the Operator updates metadata of the material, such as version information, operation status, error information, etc., for use in subsequent operations.

In the embodiment of the application, the metadata and the operators are utilized for material expansion, and the asset HUB system can process various types of atomic products and support the diversified and customized demands of resources. The arrangement of the operators enables the HUB system to easily add new material types and processing logic, and improves the expandability and flexibility of the system. Operators ensure that all the same type of material is handled consistently, reducing human error and inconsistencies. Through metadata, a user can customize parameters and flows of material processing, so that the asset HUB can adapt to specific business requirements and environments. The use of the operators enables the processing of materials to be automated and standardized, and improves the efficiency of resource manufacturing and packaging.

As an optional implementation manner, when the expansion policy is a resource expansion policy, the metadata is utilized to expand the resource information of the whole to-be-processed resource to obtain the target resource, and the method comprises the steps of expanding the metadata, when the expansion policy is the resource expansion policy, of describing the resource attribute information of the to-be-processed resource after expansion, expanding the resource attribute information of the whole to-be-processed resource to obtain the target resource by utilizing the expanded metadata, and/or expanding the definition description language of the whole to-be-processed resource by utilizing the metadata to obtain the target resource, wherein the definition description language is used for describing the resource composition information of the to-be-processed resource.

In this embodiment, if the expansion policy is a resource expansion policy, metadata may be expanded. And expanding the resource attribute information of the resources to be processed as a whole by utilizing the expanded metadata to obtain the target resources. And the definition description language of the resource to be processed with the metadata as a whole can be used for expansion to obtain the target resource. The resource attribute information may be a presentation attribute, an operation attribute, a dependency attribute, a vending attribute, etc., which are only illustrated herein and not particularly limited. The definition description language may be used to describe resource composition information of the resource to be processed, which may be DSL. The resource composition information may be various compositions of the asset.

Alternatively, the extensibility of asset metadata is a vital feature in an asset HUB system that directly relates to the description, management, operation and usage efficiency of the asset. Asset metadata refers to data used to describe characteristics and attributes of an asset, and is divided into asset base metadata and asset extension metadata. Asset base metadata typically includes the name, identifier (ID), version, type, etc. of the asset, which is the basic identification of the asset. The asset extension metadata is user-defined information for enhancing the description of the asset, so that the asset extension metadata is richer and more specific in a specific business scene.

Alternatively, the asset extension metadata is introduced so that the description of the asset is not limited to preset attributes any more, but can be extended and customized according to the actual needs of the user. This includes, but is not limited to, presentation attributes defining how the asset is presented in the interface, such as icons, descriptions, classifications, labels, etc. of the asset, which information helps the user to quickly identify and understand the asset, operational attributes for the operation and management of the asset, such as scoring of the asset, statistics of use, recommended levels, heat, etc., which information helps the operator to evaluate and optimize the asset, dependency attributes describing the dependency of the asset on other resources, such as dependent libraries, mirrors, interfaces, etc., which information is critical to the installation and use of the asset, which can avoid conflicts and errors when deployed, and sales attributes, which may include price, purchasing style, licensing agreements, etc. of the asset, which information is important to a commercial operational scenario.

Optionally, the asset HUB system dynamically renders a user-defined asset management details page using asset metadata. This means that the system will automatically create and update the presentation interface of the asset, including detailed information of the asset, instructions for use, scores and comments, dependencies, etc., based on the metadata of each asset. The mechanism has the advantages that the processing flexibility of the assets is improved, the user can customize metadata according to the needs, the system can dynamically adjust the display interface accordingly to meet the requirements of different business scenes, the assets are generated based on the corresponding metadata, the consistency and the accuracy of the assets are ensured, the user experience is improved, the dynamically rendered interface can provide more detailed information according to the richness of the metadata, and the efficiency of searching and using the assets by the user is improved.

For example, an enterprise may need to present specific business indicia of an asset on an asset details page, such as assets in the financial industry may need to present compliance assessment, risk level, etc. information. Through an extension mechanism of asset metadata, the enterprise can customize these presentation properties and add them to the asset metadata. After the asset HUB system reads the extended metadata, asset detail pages containing the custom information are dynamically rendered, so that the asset management pages can reflect key indexes of the assets in specific business scenes, and business relevance and use value of the assets are improved.

For another example, when the expansion policy is designated as a resource (material) expansion policy, the resource to be processed may be expanded by reading metadata, the asset HUB system may parse the asset DSL, and read all metadata related to the Docker mirror, including information such as the mirror name, version numbers, source repository address, destination repository address, custom tag, etc. The Operator is called, and the asset HUB calls the Docker Operator according to the metadata. And executing the expansion operation, wherein the Docker Operator executes the expansion operation according to the acquired metadata information. Updating metadata, the Docker Operator updates metadata associated with the images after the extension operation is completed, such as recording the download status of each image, the status of the re-tags, the status of pushing to the target repository, and possibly error information. The updated metadata will be stored in the asset image for use by subsequent operations (e.g., asset synchronization, asset installation).

In summary, the extensibility of asset metadata enables an asset HUB system to support more complex and detailed asset descriptions, meeting specific needs of different enterprises or teams. Through the dynamic rendering of the user-defined display attributes, the system not only can provide rich asset information, but also can promote the user experience and the asset operation efficiency. This mechanism is critical to asset HUB system flexibility and enterprise adaptability.

Alternatively, asset metadata extensibility and asset DSL are two key features in an asset HUB system that together ensure that asset definition, description and management can be highly customized to accommodate a variety of complex business scenarios. The extensibility of asset metadata means that users can customize and add additional asset attributes according to their own needs. Asset base metadata typically includes basic information about the name, version, type, etc. of the asset, while by extension capabilities, users are free to add presentation properties, operational properties, dependent properties, vending properties, etc. Asset HUB dynamically generates asset management detail pages according to user-defined metadata through a metadata-driven mechanism, and personalized and rich asset information display is provided for users. The mechanism not only improves the efficiency of asset management, but also improves the user experience, so that the searching and the use of the assets become more convenient.

Alternatively, asset DSL is a custom language provided by asset HUB based on a specific grammar (e.g., YAML grammar) for describing the structure and operational flow of the asset. The user may use the asset DSL to define the complete composition of an asset, including base information, extension information, asset material composition, and supported asset operations. The basic information may be the name, version, type, description, etc. of the asset. The extension information may be presentation properties, operational properties, dependent properties, vending properties, etc., defined by the extensibility of the asset metadata. The asset material composition may be individual elements contained in the asset, such as a Docker image, source code, documents, library files, and the like. The supported asset operations may be operations such as asset production, shelving, off-shelf, subscription, synchronization, installation, etc.

The asset HUB automatically performs full life cycle management of the asset according to the definition in the asset DSL, from creation, storage, distribution to use and update of the resource, and automation and standardization of resource management are achieved. The use of DSL reduces the complexity of resource management, increases the flexibility and efficiency of resource management, and also enables the asset HUB to accommodate a variety of different resource types and business requirements.

As an optional implementation manner, when the expansion policy is a flow expansion policy, the metadata is utilized to configure the flow information of the operation flows of the resources to be processed to obtain the target resources.

In this embodiment, if the extension policy is a flow extension policy, the target operation flow may be determined from the operation flow set. The metadata may be utilized to configure flow information of the target operational flow to obtain the target resource. The process operation set may also be referred to as an asset process, and the process operation set may include process operations such as resource loading, unloading, subscription, synchronization, and installation, which are only for illustration and not limitation.

Optionally, in the asset HUB, the scalability of the asset flow is also very important, and the user may need to customize and expand the asset flow according to the actual needs and business scenario. On a macroscopic level, an asset flow includes operations of putting an asset on shelf, putting the asset off shelf, subscribing, synchronizing, installing, and the like, the operations are optional, and a user can configure the asset flow according to requirements.

Alternatively, for the put-on-shelf operation, the user may configure whether an asset provides put-on-shelf, i.e., whether distribution and multiplexing is supported. Meanwhile, a user can also select whether to automatically manufacture the asset, so that the racking process is more automatic and efficient.

Optionally, for subscription operations, the user may configure whether the subscription requires approval and how the subscription approval process is configured. This ensures compliance and security of the subscription operation.

Optionally, the user can also select a subscription, i.e. synchronization, mode, and for smaller assets, the process can be simplified, and the operation efficiency can be improved.

Optionally, for installation operation, the user may configure which materials the asset needs to support for installation, and may select to install a specific material according to actual requirements, so as to meet different installation requirements.

By arranging a series of extension points of asset operation, a user can customize the full life cycle of an asset, and the service requirement of the user can be met more flexibly. The user can choose whether to start and configure each operation step according to specific conditions, so that the asset management flow better accords with actual requirements and business scenes, and the flexibility and customization capability of the system are improved.

Optionally, the application of the resource expansion policy in the asset HUB system is to implement flexible customization and execution of the resource operation flow through metadata driven and expansion point mechanisms. The core of the strategy is to allow the user to define and configure the whole life cycle management flow of the resource according to the specific resource type or service scene, including the key operations of putting the asset on shelf, putting the asset off shelf, subscribing, synchronizing and installing the asset.

Optionally, the user needs to determine the expansion policy of the resource according to the own service requirement. This may involve the type of resource, source, usage scenario, dependencies, desired management flow, etc. For example, for internally developed software components, a suite of flows including approval, release, subscription, and installation may need to be customized, while for externally purchased business software, the management of vending and operational attributes may be more focused. And the user selects and configures the target operation flow from the operation flow set according to the resource expansion strategy. The operation flow set is a series of standard operations provided by the asset HUB system, including asset loading, unloading, subscription, synchronization, installation and the like, and a user can select a combination of the operations according to specific requirements of resources, so as to customize a management flow suitable for a specific resource type. For example, for resources that need to be multiplexed in multiple environments, synchronization and installation procedures may be configured, and for sensitive resources, an additional approval procedure may be required.

For example, when an expansion policy is designated as a flow expansion policy, the resource to be processed may be expanded by defining an expansion point, and in the asset HUB, a corresponding expansion point may be defined for introducing an approval link in the subscription flow. The SPI service corresponding to the corresponding extension point is implemented, and the service may be an internal service or an external system. Implementation of the SPI service may include an approval streaming service that provides approval logic for the subscription of the asset, such as sending approval requests, waiting for approval, logging approval results, etc. The registration and configuration extension point registers the realized SPI service into the asset HUB, and configures the realized SPI service into a specific asset type or subscription process, and specifies which asset subscription needs to pass through the approval process. The subscription operation triggers that when a user attempts to subscribe to an asset from one HUB to another, the asset HUB will detect if the above-defined extension point needs to be invoked, depending on the configuration. And calling the SPI service, and if the subscription configuration needs approval, calling the registered SPI service by the asset HUB. The SPI service starts the approval process according to preset logic, which may include sending a notification to the approver, waiting for approval, recording approval status, etc. And the approval process is executed, an approver performs approval operation through an interface provided by the SPI service, and once the approval passes, the asset subscription process is continued, otherwise, the subscription operation is prevented until the approval is obtained. After the subscription result is reported back and the approval process is finished, the SPI service reports the result back to the asset HUB, and the system decides whether to continue to execute subscription operation or not according to the approval result, and downloads asset images, synchronous metadata and the like. Updating metadata and status, after successful subscription of the asset, the asset HUB updates metadata and status information of the asset, such as subscription status, synchronization status, target HUB information, etc., for subsequent asset management and operation.

As an optional implementation mode, the method further comprises the steps of generating a resource expansion strategy in the expansion strategy set by utilizing resources from the three-party system, and/or generating a material expansion strategy in the expansion strategy set by utilizing resource materials from the three-party system, wherein the resource materials are used for representing atomic products included in a resource image file of the three-party system.

In this embodiment, the resource expansion policy in the expansion policy set may be generated using resources from a three-party system. And resource objects from a three-party system can be utilized to generate a material expansion strategy in the expansion strategy set. The three-party system may be an upstream service system. The resources of the three-party system may extend the asset for the three parties. The resource physics of the three-party system can be a three-party extension material.

Optionally, generating an extended policy set with resources from a three-party system is an important mechanism for the asset HUB system to support ecological extension and to increase resource management flexibility. The above mechanism allows asset HUB to manage not only internally generated resources, but also seamlessly integrate and manage resources from suppliers, thereby building an open, ecologized resource management platform.

Alternatively, the asset HUB may acquire the resources available in the three-way systems by interfacing with these systems. These resources may include specific functional modules, services, datasets, or software packages, and by means of metadata driven means, the asset HUB is able to identify and parse the attributes and functions of these resources. Asset HUB will automatically generate or allow a user to define a resource extension policy based on the acquired resource information. This policy contains configuration information for full life cycle management such as resource production, stocking, subscription, synchronization, and installation, for example, release flow, approval mechanism, distribution channel, and usage restriction of a specific resource. Asset HUB manages resources according to resource expansion policies, including automatically making resource images, executing resource shelving flows, handling subscription requests for resources, synchronizing resources to other HUB or environments, and performing installation and configuration of resources.

Alternatively, the asset HUB can identify and parse resource material from a three-party system, i.e., atomic artifacts contained in these resources, such as Docker images, source code, documents, etc. For identified materials, the asset HUB provides a material expansion point that allows a user or system to customize the processing logic of the material, including the packing of the material, storage format, dependencies, operational flow, and the like. For example, for a Docker mirror, the user may define the repository address, authentication information, network policies, etc. at the time of its creation and synchronization. When the HUB processes the resource mirror image of the three-party system, operations such as packing, storing, synchronizing and installing the materials are automatically executed according to the defined material expansion strategy. This ensures that the material contained in the resource image can be properly handled and used as required by the user or system.

In the embodiment of the application, through the mechanism, the asset HUB system can effectively integrate and manage the resources and materials from the three-party system, thereby not only improving the reusability and distribution efficiency of the resources, but also enhancing the flexibility and customization capability of the resource management. For upstream business systems, this means that they can seamlessly access their own generated resources into the asset HUB, taking advantage of the powerful management capabilities of the asset HUB, without concern for the underlying resource packaging, distribution and installation details. The method further promotes the sharing of internal resources and the introduction of external resources of enterprises, constructs a more open and ecological resource management system, and accelerates innovation and business development.

As an alternative implementation, the resource materials from the three-party system are utilized to generate the material expansion strategy in the expansion strategy set, which comprises utilizing the resource materials from the three-party system and the resource expansion strategy in the expansion strategy set to generate the material expansion strategy in the expansion strategy set.

In this embodiment, the generation of a material expansion policy in the expansion policy set using resource materials from the three-party system is a key step in the asset HUB system to achieve efficient management of third-party resources. The above process involves the identification of resource materials, the utilization of resource expansion policies in an expansion policy set, and the generation of material expansion policies, aimed at ensuring that an asset HUB system can seamlessly integrate and efficiently handle heterogeneous resources from different external systems.

Alternatively, the asset HUB interfaces with a three-party system to obtain external resources, which may include diverse materials such as Docker images, source code, documents, files in a specific format, and the like. The asset HUB can identify key attributes such as types, formats, dependency relationships and the like of the resource materials through metadata analysis technology, and lays a foundation for subsequent material management strategy generation. The asset HUB may acquire resource material and at the same time acquire or define resource extension policies associated with the resources. The resource expansion strategy comprises configuration information of full life cycle management such as resource production, loading, subscription, synchronization, installation and the like. The policies may be preset by the asset HUB system, may be provided by a three-way system or may be customized by a user, and generally include details of how to handle a specific resource type, such as a manufacturing process of a Docker image, a packing rule of source code, a storage format of a document, and the like.

Optionally, the asset HUB may generate a specific material expansion policy based on the identified resource material and resource expansion policy. The material expansion strategy is to define specific processing logic and operation flow for each specific material type. For example, for a Docker mirror material, the material expansion policy may include mirror creation rules (e.g., source repository, version control), mirror packaging (e.g., compression format, metadata attachment), mirror storage policies (e.g., storage location, rights setting), mirror synchronization rules (e.g., target HUB, network policy), and mirror installation and configuration procedures. The generated material expansion policy will be applied by the asset HUB when handling asset mirroring. In the links of asset production, stocking, subscription, synchronization, installation, etc., the asset HUB will automatically process and manage resource materials according to the processing logic and operational flows defined in the material expansion policy. This ensures that the individual materials in the asset image can be properly packaged, stored, distributed and installed according to predefined policies, while also providing a unified management framework for the reuse, updating and operation of the materials.

As an alternative implementation mode, determining metadata matched with the scene type comprises determining resource base metadata matched with the scene type, the resource expansion strategy and the definition description language of the resource to be processed, wherein the resource base metadata is used for describing base information of an asset image file of the resource to be processed in the scene, the definition description language is used for describing resource composition information of the resource to be processed, and determining resource material metadata matched with the scene type, the material expansion strategy and the definition description language, wherein the resource material metadata is used for describing an atomic product of the resource to be processed in the asset image file in the scene.

In this embodiment, in determining metadata that matches a scene type, resource base metadata that matches a scene type, a resource extension policy, a definition description language of the resource to be processed may be determined. Resource material metadata can be determined that matches the scene type, material expansion policy, definition description language. The resource base metadata may be used to describe base information of an asset image file of the resource to be processed in the scene, and may be asset base metadata. A definition description language may be used to describe resource composition information of the resources to be processed. The resource material metadata may be used to describe an atomic article in an asset image file of the resource to be processed in the scene, and may be asset material metadata. The resource base metadata is data describing the overall properties of the asset image file, and contains basic information and extension information of the resource, such as the name, version, description, author, license, tag, dependency and the like of the resource. Such information is critical to the identification, classification, searching, and understanding of the role of resources in a scene.

Optionally, in an asset HUB system, determining metadata matching scene types is a key step in achieving automation and intelligence of resource management. This process involves the generation of resource base metadata and resource material metadata, and the use of definition description languages, aimed at ensuring that asset image files can accurately reflect the information and requirements of a resource in a particular scenario.

Alternatively, the asset HUB system may determine the structure and content of asset base metadata based on the scene type (i.e., use the scene, such as asset production, synchronization, installation, synchronization, stocking, subscription, etc.), and the asset flow corresponding to the scene type (e.g., how to produce, synchronize, install, etc.). The scene type affects the usage and management requirements of the asset, and the asset flow specifies the asset management flow in the asset HUB system. A description language is defined, typically using a language such as YAML, for describing the composition information, attributes and dependencies of the asset, which is the basis for the asset HUB system to generate asset base metadata. The asset HUB system will parse this language, extracting the underlying information of the asset, such as the name, version, type, usage scenario, dependencies, etc. of the asset, which will be encoded into the asset base metadata for the generation of asset image files and subsequent asset management.

Optionally, for each atom artifact in the asset image file, the asset HUB system will determine its asset material metadata based on the scene type and material expansion policy. Material extension policies define how specific types of asset materials, such as Docker images, source code, documents, etc., are handled and manipulated. The asset HUB system will also parse the definition description language to extract detailed information about the asset materials, such as the specific type, format, source, version control, dependencies, operational metadata, etc. of the materials. This information will be encoded into asset material metadata for guiding the packaging, storage, distribution and installation process of the asset material (asset material). Asset metadata is a specific description of each asset in an asset image file, including the entity metadata (e.g., name, type, version) and operation metadata (e.g., source repository address at the time of manufacture, username password, destination location at the time of synchronization, etc.) of the asset. The information ensures that the asset HUB system can operate according to predefined rules and procedures when the asset materials are processed, and the consistency and the correctness of the materials are ensured.

As an alternative implementation mode, the resource basic metadata comprises resource native information and/or resource expansion detailed information, wherein the resource native information is used for describing native information of the resources to be processed defined in the scene, the resource expansion detailed information is used for describing the expansion detailed information of the resources to be processed defined in the scene, the resource material metadata comprises material entity metadata and/or material operation metadata, the material entity metadata is used for describing entity attributes of the atomic products defined in the scene of the resources to be processed, and the material operation metadata is used for describing data required by the atomic products defined in the scene of the resources to be processed in the operation process.

In this embodiment, the resource base metadata may include resource native information and/or resource extension detailed information. The resource material metadata may include material entity metadata and/or material operation metadata. The resource native information may be used to describe the native information defined by the resource to be processed in the scene, and may be asset native information. The resource extension details may be used to describe extension details defined by the resource to be processed in the scenario, and may be asset extension details. The material entity metadata may be used to describe entity attributes of an atom product defined by a resource to be processed in a scenario, for example, may be asset material entity metadata, which is abbreviated as entity metadata. The material operation metadata can be used for describing data required by an atomic product defined by a resource to be processed in a scene in the operation process, and can be asset material operation metadata, which is simply referred to as operation metadata.

Alternatively, the subdivision of resource base metadata and resource material metadata is the basis for metadata driven mechanisms in the asset HUB system that provide the key information required in asset image file generation and asset management processes.

Alternatively, the resource native information describes the basic attribute of the resource, which is the core information that the resource must carry in any scenario. Such as the name, version, description, author, permissions, category, etc. of the resource. The asset native information ensures the unique identification and basic description of the asset image, which is the basis for resource identification and classification. The resource extension details allow the asset to be given more properties and functionality, additional information added according to a particular scenario or requirement. Such as use cases, practices, dependencies, operating environment requirements, security assessments, etc. of the resource. Asset extension details enrich the description of the resource, provide more usage guidance and metadata, and facilitate efficient utilization and management of the resource.

Optionally, the material entity metadata describes information of specific attributes of each atomic artifact in the asset image file, such as name and Tag of the dock image, name and size of the file, version and language of the code, and the like. Entity metadata is a fixed description of the asset material in the asset image, which does not change with the operation of the asset, and which ensures the identifiability and traceability of the asset material.

Optionally, the materials operations metadata defines how particular resource materials are handled and manipulated during operations such as production, synchronization, installation, and the like. Such as the source repository address when packaging the Docker image, the username password, the network policy when synchronizing the files, etc. The operation metadata is dynamic and varies from one resource operation to another, and directs the specific flow and details of the production, storage, distribution and installation of resource materials.

In the embodiment of the application, the asset HUB system can intelligently process and manage various resources in a metadata-driven manner through the subdivision and definition of the metadata. The resource base metadata ensures the global uniqueness of the resource and the accuracy of basic information in the life cycle of the resource, and the resource extension detailed information provides rich description and use guidance of the resource in a specific scene. Meanwhile, the entity metadata and the operation metadata in the resource material metadata respectively ensure the accurate record of the inherent attribute and the operation detail of the resource material, and provide specific and flexible guidance for packaging, storing, distributing and installing the resource material. Through the mechanism, the asset HUB system can support highly customized asset management processes, can process various types of resources, and can dynamically adjust the description and operation processes of the resources according to specific requirements of users, so that more flexible, efficient and safe resource management experience is provided. The metadata driven management model described above is one of the core technologies that asset HUB systems implement their definable, extensible, orchestratable, reusable and operational capabilities.

As an optional implementation manner, step S202 is to execute an operation corresponding to a scene type on the target resource to obtain an operation result, and includes to execute an operation corresponding to the scene type on the target resource to obtain an asset image file of the target resource under the scene.

In this embodiment, in the process of executing the operation corresponding to the scene type on the target resource, the operation corresponding to the scene type may be executed on the target resource, so as to obtain the asset image file of the target resource under the scene.

Optionally, performing an operation corresponding to the scene type on the target resource to obtain an asset image file of the target resource under a specific scene is one of core steps of resource making and asset management processes in the asset HUB system. The above process embodies a highly customized processing capability and metadata driven management mechanism for assets HUB systems to resources.

Alternatively, the asset HUB system may determine the type of operational scenario to be performed by the target resource. Operational scenarios may include, but are not limited to, asset fabrication, racking, synchronization, installation, etc., and the goals and processing logic may be different for each stage. For example, the objective of the asset creation phase is to package the assets and generate an asset image file, while the asset installation phase focuses on deploying the assets in the asset image file into a particular environment.

Optionally, the asset HUB system parses the resource base metadata and resource material metadata of the target resource to learn the basic information, material composition, and operational details of the resource. The resource base metadata provides a global description of the resource, while the resource material metadata defines the attributes and operational flows of the individual atomic artifacts in detail.

Optionally, the asset HUB system may execute corresponding operational logic based on the parsed metadata and the determined operational scenario. This may involve performing packaging, orchestration, installation, etc. of resource items using predefined operators or invoking registered SPI services. For example, in an asset production scenario, the system may read the operational metadata of the asset material, such as source repository, version information, packaging rules, etc., and then use the corresponding Operator or SPI service to generate the asset image file.

The method comprises the steps of executing a resource making operation corresponding to a resource making scene type on a target resource to obtain a plurality of atomic products of the target resource under the scene, combining the atomic products to obtain a first asset image file of the target resource under the scene, executing a resource synchronization operation corresponding to a resource synchronization scene type on the target resource, synchronizing a second asset image file corresponding to resource information of the target resource under the scene to a resource management and operation platform, executing a resource installation operation corresponding to a resource installation scene type on the target resource, and installing a third asset image file of the target resource under the scene to a target project system or cluster.

In this embodiment, in the process of executing the operation corresponding to the scene type on the target resource, the resource making operation corresponding to the resource making scene type may be executed on the target resource, so as to obtain a plurality of atomic products of the target resource in the scene. And combining a plurality of atomic products to obtain a first asset image file of the target resource in the scene. The resource synchronization operation corresponding to the resource synchronization scene type can be executed on the target resource, so that the resource information of the target resource under the scene is obtained. Asset image files corresponding to the resource information can be saved. And synchronizing the second asset image file corresponding to the resource information of the target resource in the scene to the resource management and operation platform. And executing resource installation operation corresponding to the resource installation scene type on the target resource to obtain a corresponding third asset image file. Wherein the resource information may also be referred to as asset information. The resource information is information describing attributes and states of resources in the asset image file. The resource information may include basic metadata, material metadata, operating status, usage, etc. of the resource, which is an important basis for the asset HUB system to manage and operate the resource.

Optionally, in the asset HUB system, an operation corresponding to the scene type is executed on the target resource, and the method specifically relates to three core scenes of resource production, resource synchronization and resource installation. The process not only embodies the automation and the intellectualization of the asset HUB system to the resource management, but also fully utilizes metadata and an extension point mechanism, thereby realizing the efficient multiplexing and the customized management of the resources.

Optionally, in a resource production scenario, the asset HUB system may perform production operations on the resource based on the definition description language of the target resource and the resource material metadata. This process may include pulling code from a source repository, packaging a Docker image, generating HELM CHART, etc., ultimately generating a series of atomic artifacts. The authoring operation may call the SPI service or use an Operator built in the system to ensure flexibility and extensibility of the operation. After the atomic product is manufactured, the asset HUB system combines the atomic products into an asset image file in a specific format according to the resource basic metadata and the material entity metadata. The asset image file contains a complete description of the asset and data of all atomic artifacts, which is the primary form of storage and distribution of the asset in the asset HUB system.

Optionally, in the resource synchronization scenario, the asset HUB system may perform a resource synchronization operation according to the resource information of the target resource. This process may involve synchronizing asset image files from one HUB to another HUB or uploading specific atomic artifacts (e.g., docker images, files, etc.) in the asset image files to a target storage service. The resource synchronization operation can also use SPI service or a system built-in Operator to ensure the intellectualization and customization of the synchronization process. After the resource synchronization operation is completed, the asset HUB system stores the asset image file corresponding to the resource information in the storage of the target HUB so as to facilitate subsequent resource distribution and multiplexing.

Optionally, in a resource installation scenario, the asset HUB system may perform a resource installation operation according to the resource information of the target resource. This process may involve deploying resources in an asset image file into a particular project or Kubernetes cluster for use in a particular environment. The resource installation operation may include specific steps of launching a container, configuring a service, deploying an application, and the like, and as such, this process may call the SPI service or be accomplished using an Operator built into the system.

As an optional implementation mode, the method further comprises at least one of scheduling a display result of the target resource and/or an operation flow of the target resource in response to the scheduling operation instruction of the target resource, controlling the target resource to be multiplexed in a distributed system in response to the multiplexing operation instruction of the target resource, wherein the distributed system is constructed based on a distributed deployment architecture, and acquiring operation information generated in an operation process of the target resource in response to the operation instruction of the target resource.

In this embodiment, when the scheduling operation instruction for the target resource is received, the display result of the target resource and/or the operation flow of the target resource may be scheduled. When a multiplexing operation instruction for the target resource is received, the target resource can be controlled to be multiplexed in the distributed system. When an operation instruction for the target resource is received, operation information generated by the target resource in the operation process can be acquired.

Optionally, in the asset HUB system, the scheduling operation, multiplexing operation and operation on the target resource are three important links in the asset management flow, which affect the exhibition, use and operation optimization of the resource respectively.

Optionally, for the arrangement operation, the display result arrangement, when receiving the display result arrangement operation instruction for the target resource, the asset HUB system performs personalized setting on the display page of the resource according to the user-defined rule of the user. This may include adjusting page layout, adding or deleting presentation properties, custom control styles, etc., to ensure that the presentation results of the resources meet the management needs and user habits within the enterprise. And (3) operation flow arrangement, namely when an operation flow arrangement instruction for the target resource is received, the asset HUB system adjusts the sequence, condition and execution mode of resource operation according to a user-defined flow rule. The method can relate to the process customization of operations such as resource production, shelving, subscription, synchronization, installation and the like, allows users to introduce links such as approval flow, role authority control, automatic test and the like according to actual requirements, and improves the flexibility and the safety of resource operation.

Optionally, for multiplexing operation, the control target resource is multiplexed in the distributed system, the asset HUB system supports a distributed deployment architecture, allows free circulation of resources among multiple HUB, and realizes cross-system and cross-team multiplexing of the resources. When receiving a multiplexing operation instruction for the target resource, the system automatically downloads the resource image file from the provider HUB to the consumer HUB according to the subscription relation and the synchronization strategy of the resource, or installs the resource directly in the target environment (such as a Kubernetes cluster). Through the mechanism, the asset HUB system ensures the efficient multiplexing of resources, reduces repeated development and resource waste in enterprises, and accelerates the iteration and innovation of the business.

Optionally, for operation, the operation information of the target resource in the operation process is obtained, the asset HUB system has resource operation capability, and when an operation instruction for the target resource is received, the system can collect and analyze the use condition of the resource, including the operation information of browsing times, downloading amount, subscription amount, installation amount, user feedback, resource score and the like of the resource. The information not only provides real-time feedback of the use condition of the resource for a resource manager, but also can be used for optimizing, popularizing and eliminating the resource, and enhances the operation intelligence of the HUB system. The collection and analysis of the operation information are key to realizing the resource operation capability of the HUB system, and based on the resource metadata and the operation result, the HUB system provides rich data support for the life cycle management of the resource, helps enterprises to better understand and optimize the resource use, and promotes the continuous improvement and innovative utilization of the resource.

The embodiment of the application also provides a method for processing the enterprise asset from the application scene of enterprise asset management, and fig. 3 is a flowchart of a method for processing the enterprise asset according to the embodiment of the application, as shown in fig. 3, the method can include the following steps:

In step S302, a scenario type of a scenario in which the to-be-processed enterprise asset is located is determined, where the scenario type is used to represent a type of operation performed on the to-be-processed enterprise asset under the scenario.

In the technical solution provided in the above step S302 of the present application, if a certain to-be-processed enterprise asset needs to be processed, a scene type of a scene where the to-be-processed enterprise asset is located may be determined.

Step S304, determining an expansion point matched with the scene type and asset metadata matched with the scene type, wherein the expansion point is used for representing a rule for expanding the to-be-processed enterprise asset according to an expansion hierarchy matched with the scene type, and the asset metadata is used for describing a format and/or content defined by the to-be-processed enterprise asset under the scene of the scene type.

In the technical solution provided in the above step S304 of the present application, after determining the scene type of the scene where the to-be-processed enterprise asset is located, an expansion policy matched with the scene type may be determined. Metadata matching the scene type may also be determined. The extension point may be used to represent a rule that extends the enterprise asset to be processed according to an extension hierarchy that matches the scene type. Asset metadata may be used to describe the results defined by the enterprise asset to be processed in the context of the context type.

Alternatively, when the asset HUB receives a request or task relating to a particular scene type, it will look up and invoke the corresponding expansion policy based on that scene type. This means that the asset HUB can flexibly call different SPI service implementations according to different scenarios, or use a default controller (Operator) to handle the enterprise asset to be processed, thus meeting the specific needs of the scenario.

And step S306, expanding the enterprise assets to be processed on an expansion level by utilizing asset metadata according to the expansion points to obtain target enterprise assets.

In the technical scheme provided in the step S306 of the present application, after determining the expansion policy matching the scene type and the metadata matching the scene type, the enterprise asset to be processed may be expanded on the expansion level by using the metadata according to the expansion policy, so as to obtain the target enterprise asset.

Optionally, the enterprise assets to be processed are expanded and transformed based on the determined expansion policy and metadata to generate target enterprise assets.

Step S308, executing the operation corresponding to the scene type on the target enterprise asset to obtain the asset image file of the target enterprise asset in the scene.

In the technical scheme provided in the above step S308 of the present application, after the to-be-processed enterprise asset is expanded on the expansion level by using the metadata according to the expansion policy, the operation corresponding to the scene type may be performed on the target enterprise asset obtained after expansion, so as to obtain the operation result.

Optionally, performing an operation corresponding to the scene type on the target enterprise asset processed through the expansion hierarchy, and generating an operation result. The process converts abstract processing logic into specific execution actions, ensures that the whole asset processing flow is closed-loop, and provides basis for follow-up asset state tracking, feedback and operation decision.

The method comprises the steps of determining a scene type of a scene where an enterprise asset to be processed is located through the steps of S302 to S308, determining an expansion point matched with the scene type and asset metadata matched with the scene type, wherein the asset metadata are used for describing a result defined by the enterprise asset to be processed in the scene of the scene type, expanding the enterprise asset to be processed on an expansion level by utilizing the asset metadata according to the expansion point to obtain a target enterprise asset, and executing an operation corresponding to the scene type on the target enterprise asset to obtain an asset image file of the target enterprise asset in the scene. Therefore, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

The embodiment of the application also provides a method for processing resources from a man-machine interaction side, and fig. 4 is a flowchart of a method for processing resources according to an embodiment of the application, as shown in fig. 4, the method may include the following steps:

In step S402, a scene type of a scene where the resource to be processed is located is determined in response to an operation instruction acting on the operation interface, where the scene type is used to represent a type of an operation performed on the resource to be processed in the scene.

In the technical scheme provided in the step S402, when an operation instruction on an operation interface is detected, a scene type of a scene where a resource to be processed is located may be determined.

Optionally, the operation interface of the asset HUB system is a front end of the interaction between the user and the system, through which the user can initiate various management operations on the resource, such as resource making, resource stocking, resource subscription, resource synchronization, resource installation, and the like. When a user performs a particular operation (e.g., clicks on a "make resources" button) on the operator interface, the system detects this operation instruction. After receiving the operation instruction, the asset HUB system determines the type of the operation scene where the resource to be processed is located according to the content of the instruction and the selection of the user. The scene type is a specific resource management flow to which an operation instruction is directed, which defines how the system will perform an operation on a resource to be processed, as well as the goals and requirements of the operation. For example, if a user initiates a "make resource" operation instruction, the system may determine that the scene type is a resource-making scene for the process of resource packaging and making.

Step S404, displaying an expansion strategy matched with the scene type and metadata matched with the scene type on an operation interface, wherein the expansion strategy is used for representing a rule for expanding the resource to be processed according to an expansion hierarchy matched with the scene type, and the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type.

In the technical solution provided in the above step S404 of the present application, after determining the scene type of the scene where the resource to be processed is located, an expansion policy matched with the scene type may be determined. Metadata matching the scene type may also be determined. And the extended policies and metadata may be displayed on the operator interface.

Optionally, the HUB system dynamically displays the expansion strategy and metadata matched with the scene type on the operation interface, so as to provide visual operation guidance for the user. For example, in an asset production scenario, the asset HUB system may display on the operator interface options of how to define the material combinations in the asset image, how to add custom metadata information, and how to use the SPI service to extend the operation of the resource. The function optimizes the user's operation interface experience, so that the user can quickly understand and adjust the operation flow and the expansion rule of resource management according to specific scene requirements.

Optionally, by exposing the extended policies and metadata on the operator interface, the asset HUB system provides decision support for the user, helping the user make more intelligent choices in the resource management process. The user can evaluate the expandability, operability and customizable property of the resource according to the displayed expansion strategy and metadata, thereby optimizing the use and management strategy of the resource.

Step S406, displaying a 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 on an expansion level by using metadata according to an expansion strategy.

In the technical scheme provided in the step S406, after determining the expansion policy matching the scene type and the metadata matching the scene type, the resource to be processed may be expanded on the expansion level by using the metadata according to the expansion policy to obtain the target resource, and the target resource may be displayed on the operation interface.

Step S408, displaying the operation corresponding to the execution scene type of the target resource on the operation interface, and obtaining an operation result.

In the technical scheme provided in the above step S408 of the present application, after the resources to be processed are expanded on the expansion level by using metadata according to the expansion policy, the operation corresponding to the scene type can be performed on the target resources obtained after expansion, so as to obtain the operation result, and the operation result can be displayed on the operation interface.

The method comprises the steps of responding to an operation instruction acted on an operation interface to determine the scene type of the scene where the resource to be processed is located through the steps S402 to S408, displaying an expansion strategy matched with the scene type and metadata matched with the scene type on the operation interface, displaying a target resource corresponding to the resource to be processed on the operation interface, and displaying an operation corresponding to the scene type on the target resource on the operation interface to obtain an operation result. Therefore, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

The embodiment of the application also provides a resource processing method from a Software As A Service (SAAS) side, and fig. 5 is a flowchart of a resource processing method according to an embodiment of the application, and as shown in fig. 5, the method may include the following steps:

step S502, determining a scene type of a scene where the resource to be processed is located by calling a first interface, wherein the scene type is used for representing a type of an operation executed by the resource to be processed in the scene by calling the first interface as the scene type.

In step S504, an expansion policy matching the scene type and metadata matching the scene type are determined, where the expansion policy is used to represent a rule that the resource to be processed expands according to an expansion hierarchy matching the scene type, and the metadata is used to describe a format and/or content defined by the resource to be processed in the scene of the scene type.

And step S506, expanding the resources to be processed on an expansion level by utilizing metadata according to an expansion strategy to obtain target resources.

Step S508, executing the operation corresponding to the scene type on the target resource to obtain an operation result.

Step S510, outputting the operation result by calling a second interface, where the second interface includes a second parameter, and a parameter value of the second parameter is the operation result.

The method comprises the steps of determining the scene type of the scene where the resource to be processed is located by calling the first interface, determining an expansion strategy matched with the scene type and metadata matched with the scene type, expanding the resource to be processed on an expansion level by utilizing the metadata according to the expansion strategy to obtain a target resource, executing operation corresponding to the scene type on the target resource to obtain an operation result, and outputting the operation result by calling the second interface. Therefore, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

In accordance with an embodiment of the present application, there is further provided an embodiment of a resource processing system, and fig. 6 is a schematic diagram of a resource processing system according to an embodiment of the present application, and as shown in fig. 6, a resource processing system 600 may include a client 601 and at least one resource processing platform 602.

The client 601 is configured to upload a resource processing request, where the resource processing request is used to request processing of a resource to be processed.

In this embodiment, client 601 plays the role of a front-end interaction layer in the asset HUB system, which is the bridge for users to communicate with the asset HUB system for uploading resource processing requests. The resource processing request is an instruction of a user to perform a specific operation on a resource, and this mechanism is a core of the asset HUB system for realizing the flexibility and responsiveness of resource management.

Optionally, the client 601 is responsible for receiving an operation instruction of a user on an operation interface, encapsulating the operation instruction into a resource processing request, and uploading the resource processing request to a back-end processing layer of the asset HUB system. This upload process may be implemented through RESTful API, webSocket, or message queue techniques, ensuring efficient delivery of requests and decoupling between asset HUB systems. The upload function of client 601 is a key element of interaction between the user and the asset HUB system. By this mechanism, a user can flexibly initiate resource processing operations without having to go deep into the specific implementation details within the system. The system intelligently executes the resource operation according to the request uploaded by the user, and provides efficient and customized resource management service for the user.

The resource processing platform 602 is configured to determine a scene type of a scene where the resource to be processed is located in response to the resource processing request, where the scene type is used to represent a type of operation performed on the resource to be processed in the scene, determine an expansion policy matched with the scene type, and metadata matched with the scene type, where the expansion policy is used to represent a rule that the resource to be processed expands according to an expansion hierarchy matched with the scene type, the metadata is used to describe a format and/or content defined by the resource to be processed in the scene of the scene type, expand the resource to be processed on the expansion hierarchy according to the expansion policy by using the metadata 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.

In this embodiment, resource processing platform 602 plays a central role as a resource management and execution engine in an asset HUB system, which is a key component of the system to perform resource operations in response to client requests. The operating mechanism of the resource handling platform 602 ensures flexibility, intelligence, and efficiency of resource management. The resource processing platform may be an asset HUB.

Optionally, the resource processing platform 602 receives resource processing requests from clients that contain specific operating instructions and parameters for the user to process the resource. The resource processing platform 602, as a back-end service, parses and understands the requests in preparation for performing the corresponding resource management operations. The resource processing platform 602 determines the scene 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 scene type defines a specific type of resource operation, providing context cues for subsequent resource processing. After determining the scene type, the resource processing platform 602 matches the corresponding expansion policy and metadata according to the scene type. The expansion policy guides how to perform customized expansion on the resource on the expansion level, and the metadata is data describing the result defined by the resource under a specific scene, including the attribute, the operation rule, the result state and the like of the resource. The above-described matching process ensures that the asset HUB system can intelligently adjust resource management flows and policies according to specific business needs. The resource processing platform 602 expands the resources to be processed according to the matched expansion policy and metadata to generate target resources. This process may involve processing metadata of the resource using SPI services, operators, or built-in logic, packaging, customizing, orchestrating, etc., the resource to obtain a resource that meets user and scenario requirements.

Optionally, after the target resource is generated, the resource processing platform 602 may perform operations corresponding to the scene type, such as resource fabrication, resource synchronization, resource installation, and the like. The operation execution is based on the metadata and scene types of the resources, corresponding services and components are called, and the high efficiency and accuracy of resource management are ensured. After the operation is completed, the resource processing platform 602 generates an operation result and feeds it back to the client 601.

In an embodiment of the application, a processing system for a resource is provided. The method comprises the steps of uploading a resource processing request through a client 601, responding to the resource processing request through at least one resource processing platform 602, determining a scene type of a scene where a resource to be processed is located, determining an expansion strategy matched with the scene type and metadata matched with the scene type, expanding the resource to be processed on an expansion level by utilizing the metadata according to the expansion strategy to obtain a target resource, executing operation corresponding to the scene type on the target resource to obtain an operation result, and transmitting the operation result to the client. Therefore, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

Currently, in enterprise IT environments, management of heterogeneous assets has been a complex and challenging task. With the continuous expansion of enterprise resource system scale, the demand for asset management is increasing, from simple archiving and storage to comprehensive definability, expansibility, orchestration capability, reusability and operation support, and the related art asset management platform has difficulty in meeting the flexible and changeable IT asset management demands of modern enterprises.

The embodiment of the application provides an extensible enterprise IT heterogeneous asset management and operation platform based on metadata driving, namely an asset HUB. Asset HUB provides a customizable, scalable, optimizable solution for enterprises by defining, expanding, orchestrating, managing, and operating a variety of IT assets. The asset HUB defines and describes various assets, including hardware, software, network devices, etc., through metadata. Thus, unified management and operation of the assets can be realized, and various assets can be easily expanded and customized. Asset HUB is an extensible platform that can be customized and extended to the needs and size of the enterprise. Through the extension point and SPI mechanisms, enterprises can easily add new functions and services. Asset HUB may assist enterprises in orchestrating and managing assets, including allocation, scheduling, monitoring, etc. of resources. The resource utilization rate and efficiency of enterprises can be improved. Asset HUB provides various reusable components and services that can help businesses better manage and operate assets. This may reduce the operating costs and risks for the enterprise. Through metadata driven mode, asset HUB can realize high customization and flexibility, satisfies the demand that the enterprise constantly changes. Therefore, the technical effect of improving the flexibility of resource processing is achieved, and the technical problem of low flexibility of resource processing is solved.

The above-described method of this embodiment is further described below.

The asset HUB in the embodiment of the application is an extensible enterprise IT heterogeneous asset management and operation platform based on metadata driving. The HUB is intended to address definable, extensible, orchestratable, reusable, operational capabilities within an enterprise that are urgent to address assets accumulated by the system over years. The HUB defines, organizes, manages and operates various IT heterogeneous assets in a metadata driven manner based on extension points and SPI mechanisms.

In this embodiment, definable of assets refers to abstracting and defining various assets in an asset HUB to better manage and operate the assets. In an asset HUB, definition of assets is implemented in a metadata driven manner, abstracted into asset metadata, and subdivided into asset base metadata and asset material metadata. Asset base metadata is a basic information description of an asset, including asset native information and asset extension detailed information. Asset-native information refers to basic attribute information of an asset, such as asset type, name, identifier, etc. This information is an essential feature of the asset for distinguishing and identifying different types of assets. Asset extension details, which refers to more detailed description and definition of assets, include configuration, association, status, etc. of the assets. Such information may help the user better understand and manage the asset.

Optionally, the asset material metadata includes asset material entity metadata and asset material operation metadata. Asset materials entity metadata-entity attributes and structures describing the asset, including constituent parts of the asset, related resources, associated objects, etc. Such information may help the user to understand the internal structure and associations of the assets. Asset materials operations metadata describing methods and rules for operating and managing assets, including lifecycle management of assets, rights control, operational flows, and the like. Such information may help the user better manage and manipulate the asset.

By defining and describing the metadata of the assets in the manner, the asset HUB can realize unified management and operation of various assets, and can provide more customization and expansibility for users. By means of metadata driving, the asset HUB can achieve high flexibility and configurability, and meets asset management requirements of enterprises on different scales and requirements.

In this embodiment, the core of the HUB is flexible extensibility for the extensibility of assets. Due to the complexity and diversity of assets, there is a custom expansion of the requirements for definition of actual assets, composition of asset materials, and operation of assets. The expandability of the scheme is based on an expansion point+SPI mechanism, and the definition of one asset and the operation logic of asset manufacture, synchronization, installation and the like are uniformly depicted by combining with a custom asset DSL.

Alternatively, the user needs to use the asset DSL to profile the composition of one asset. According to different usage scenarios (asset making, synchronizing, installing), different SPI interface implementations are completed, and the SPI service implementation is registered with the asset HUB (the service implementation can be output as a Jar package to be hosted to the asset HUB or independently deployed as a three-party service) for the asset HUB to use. The SPI realization is mainly supported by two calling modes at present, namely one is to package the SPI realization into Jar and host the Jar to an asset HUB system, and the other is to independently deploy the Jar to a three-party service, and the asset HUB directly calls the three-party system. The HUB has a perfect report back mechanism, and the result of all the asset operations can be notified to an upper-layer service system through a kafka message, and can also be received by a mode realized through a registration SPI.

Optionally, in this embodiment, the asset HUB supports three levels of expansion. The three expansion steps are from small to large, namely the expansion of the asset materials, the expansion of the assets and the expansion of the asset flow.

In this embodiment, the scalability of asset materials is a very important ring in asset management systems, and various types of asset materials can be customized and expanded according to different business needs and scenarios. In an asset HUB, asset materials are core elements of the asset, including preformed types such as Docker images, source code, files, attachments, rich text, JAR, HELM CHART, APIs, etc., while also supporting users to describe custom extended material types using the asset DSL language. The asset HUB is prefabricated with a set of complete Operator default implementation for each prefabricated asset material type, so that the use and customization of users are facilitated.

Alternatively, the asset HUB is prefabricated with a plurality of common asset material types. These prefabricated types cover common asset forms and content, facilitating the user's quick creation and management of various types of assets. In addition to the pre-formed asset material types, the user may also describe custom extended material types using the asset DSL language. The flexible customization mode enables a user to define new asset material types according to specific requirements, and meets specific business scenes and requirements.

Alternatively, for each pre-manufactured asset material type, the asset HUB is pre-manufactured with a complete set of Operator default implementations. These Operator implementations include various operations and functions, such as creation, updating, deletion, synchronization, etc. of assets, which can be used directly by users to quickly implement management and operation of asset materials.

Optionally, during asset synchronization, the primary SPI interface includes acquiring material operation metadata and synchronizing asset material. 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 asset synchronization operation. The following is a detailed analysis of these two SPI interfaces:

Optionally, asset material metadata is acquired, and the interface is used for acquiring metadata information of each material in the asset, including material base metadata and material operation metadata, in the asset manufacturing process. These metadata describe basic properties of the material, operational rules, flows, etc. The asset HUB invokes the interface when processing the materials in the asset, and acquires metadata information of each material, including material entity metadata, for storing in a specific position of the asset image, and material operation metadata for subsequent material operation.

Optionally, the asset material is archived, and the interface is used for operation logic for actually archiving a certain asset material in the asset production operation. According to the configuration of the asset material expansion points, the archiving of the asset materials can be realized by using operators prefabricated by the system or by providing archiving services by an external system. The asset HUB will obtain binary stream data of the material based on the interface implementation and store it in a specific location of the asset image. Thus, smooth archiving and storage of materials in the asset manufacturing process can be ensured.

Through the realization of above-mentioned SPI interface, the material information in the asset preparation process can be effectively handled to the asset HUB, acquires and stores material metadata, realizes the archival operation to the material simultaneously. Thus, the smooth proceeding of the asset manufacturing process can be ensured, and the reliability and stability of the system are improved. Meanwhile, the archiving service provided by the external system is realized, so that the requirements of more flexibility and customization can be met, and the asset manufacturing process has more customization and expandability.

Optionally, during asset installation, the primary SPI interface includes acquiring material handling metadata and installing asset material. These interfaces play a key role in the asset installation process, helping the asset HUB process material information in the asset and complete the asset installation operation. The following is a detailed analysis of these two SPI interfaces:

Optionally, material operation metadata is obtained, and the interface is used for obtaining operation metadata required by each material installation in the asset installation process. In one asset installation process, the asset HUB invokes the SPI interface to obtain the operational metadata required for the installation of the materials for subsequent installation operations. Asset material installation is a mating operation, and if a certain asset material needs to be operated in the asset installation process, a corresponding extension point needs to be registered. Thus, the installation operation mode and rules of the materials can be customized according to the requirements.

Optionally, asset materials are installed, and the interface is used for logic for actually operating a certain asset material in the asset installation process. In the primary asset installation process, when the asset HUB needs to install the specific material, the binary stream of the specific material is output to a specified system through the expansion point, and the system performs subsequent installation operation. According to the configuration of the asset material expansion points, the asset material can be installed by using an Operator prefabricated by the system, and can also be realized by the service provided by an external system. Therefore, a proper installation mode can be selected according to specific requirements, and the installation process of the asset is ensured to be carried out smoothly.

Through the realization of the two SPI interfaces, the material information in the asset installation process can be effectively processed by the asset HUB, and the operation metadata required by the material is acquired and installed, so that the smooth proceeding of the asset installation process is ensured. Meanwhile, by means of a customized installation operation mode, the system can adapt to asset installation scenes of different types and requirements, and flexibility and adaptability of the system are improved. The customized installation mode can meet specific business requirements, and the accuracy and the integrity of asset installation are ensured.

In this embodiment, in an asset HUB, the extension of the entire asset, i.e., custom asset types, is supported and is achieved primarily through the extensibility of asset metadata and asset DSL.

Optionally, the extensibility of asset metadata primarily refers to the extension of asset base metadata, i.e., in the overall description definition of the asset. In addition to the native information, the user may customize the presentation properties, operational properties, dependency properties, vending properties, etc. of the asset. The extended attributes can help the user to describe and define the assets more fully, and meanwhile, the asset management detail page customized by the user can be dynamically rendered in a metadata driven mode. Through expansion of asset metadata, a user can perfect description and attribute of assets according to specific requirements and business scenes, so that asset management is more flexible and personalized.

Alternatively, the asset DSL is an asset definition description language provided by the asset HUB, and uses Yaml syntax to describe the various components of an asset, including the underlying information, extension information, asset material composition, and supported asset operations, etc. of the asset. Through the DSL of the asset, the user can complete the definition of the asset through a concise grammar description mode, including the attribute, the structure, the operation logic and the like of the asset. Asset HUB will manage the full lifecycle of the asset according to asset DSL so that the user can conveniently manage and operate the asset.

Asset HUB provides users with flexible and powerful asset management capabilities through asset metadata extensibility and asset DSL functionality. The user can customize the metadata and definition of the extended assets according to the actual requirements, and personalized customization and extension of the assets are realized. At the same time, through the use of asset DSL, a user can describe and manage various aspects of the asset in a simple manner, improving operational efficiency and system flexibility. This scalability and customization capability enables the asset HUB to meet a variety of complex asset management requirements, improving the flexibility and adaptability of the system.

In this embodiment, fig. 7 is a schematic diagram of an asset extension point according to an embodiment of the present application, as shown in fig. 7, and as shown in fig. 7, in the asset management system, the scalability of the asset flow is also very important, and a user may need to customize and extend the asset flow according to the actual needs and business scenario. On a macroscopic level, the process of an asset includes operations of putting the asset on shelf, putting the asset off shelf, subscribing, synchronizing, installing, etc., which are optional, and the user can configure the process of the asset as required.

By arranging a series of extension points of asset operation, a user can customize the full life cycle of an asset, and the service requirement of the user can be met more flexibly. The user can choose whether to open and configure each operation step according to specific conditions, so that the asset management flow better accords with actual requirements and business scenes, and the flexibility and customization capability of the system are improved. In summary, the expandability of the asset flow enables the user to customize and configure operations such as putting on shelf, subscribing, synchronizing, installing and the like of the asset according to actual demands, and flexible control and customization of the asset management flow are achieved, so that adaptability and efficiency of the system are improved. The flexibility and the customization capability enable the asset management system to better meet the demands of users, and improve the working efficiency and the overall performance of the system.

FIG. 8 is a flow chart of an asset fabrication process according to an embodiment of the application, as shown in FIG. 8, which may include the steps of:

step S802, matching asset extension points to construct asset metadata.

In this embodiment, the asset HUB would first identify and match the asset extension point. Asset extension points are key mechanisms in asset HUB that define asset composition, metadata formats, and operational flows, which allow users to customize different aspects of an asset, such as material types, metadata fields, operational logic, etc. When an asset creation request enters the system, the HUB pulls all metadata associated with the asset, including base metadata and material metadata, according to predefined extension point rules.

Optionally, the base metadata contains basic information of the asset, such as the name, version, description, author, license agreement, etc. of the asset. The material metadata describes specific information of each asset material (such as dock mirror image, source code, document, etc.), such as type, version, source, dependency, etc. of the material. This metadata information is obtained from the upstream system through an SPI service interface, which is typically provided by users or partners of the asset HUB, to enable more flexible and personalized asset definition. Constructing asset metadata is the basis of the asset fabrication process, ensuring the integrity and consistency of asset information. In this step, the HUB system organizes the acquired metadata into an asset metadata structure through a metadata driving mechanism, and provides data support for subsequent material production and mirror assembly.

In step S804, the material metadata drives the asset material.

In this embodiment, the asset HUB initiates a material creation process based on 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 accomplished by invoking the SPI service of the material extension point, which contains specific logic to make the material, such as pulling the Docker image from a remote library, retrieving the source code file from the version control system, converting the document format, etc.

Optionally, for each material, the SPI service performs corresponding production operations based on information in the material metadata. For example, if the material metadata defines a Docker image, the SPI service may be responsible for pulling or building the 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 source code from the version control system and sorting it into a form that can be included in the asset image.

Optionally, the material making process is highly dependent on metadata, which not only defines the properties of the material, but also guides the making manner and content of the material. Through the invocation of SPI service, the asset HUB can support the material preparation of multiple different grade type, improves the flexibility and the expansibility of asset preparation.

Step S806, assembling an asset image file.

In this embodiment, after all asset materials are made and pass inspection, the asset HUB will enter the stage of final assembly of the asset image file. Asset mirroring is a special format file that contains asset metadata and all manufactured material data. The assembly of the image file is performed according to predefined rules and formats, ensuring that the structure and content of the image file complies with the storage and distribution standards of the asset HUB.

Optionally, during the assembly process, the HUB organizes different material entity metadata and binary streams into an image file according to a certain structure according to the material metadata. Material operation metadata, such as source repository address, user name password, etc., is not stored directly in the image file, but is used to guide operations in the image creation process, such as authentication information used to pull the Docker image.

Optionally, after assembly is completed, the asset image file may be stored in the asset HUB and marked as an on-shelf status awaiting subsequent distribution and installation operations. The storage and management of asset image files is based on the distributed architecture and metadata driven mechanisms of the asset HUB, ensuring the security, integrity and reusability of asset images.

In summary, the asset fabrication process is a key link in the asset HUB, and it constructs asset metadata by matching asset extension points, drives fabrication of asset materials by using the material metadata, and finally assembles into a structured asset image file, thus providing a solid foundation for distribution and reuse of assets. The process fully embodies the characteristics of metadata drive, expandability and distributed architecture of the asset HUB, and is an advanced practice in the IT asset management of modern enterprises.

Asset synchronization is an important element in asset lifecycle management that allows the transfer of assets and their image files from one HUB to another, thereby enabling sharing and multiplexing of assets among different environments or teams. FIG. 9 is a flow chart of an asset synchronization process according to an embodiment of the application, as shown in FIG. 9, which may include the steps of:

Step S902, downloading an asset image file.

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 involve obtaining an image file over a network transport, which typically requires access rights and network connectivity to the source HUB. The downloading operation may be a file download based on the hypertext transfer protocol (Hypertext Transfer Protocol, abbreviated HTTP) or may use a more specialized transfer protocol depending on the implementation details of the asset HUB.

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 preparing a data source for subsequent parsing and saving operations. It should be noted that since asset images may contain multiple pieces of material and metadata, the file size may be quite large, so an efficient and stable download mechanism is critical to ensure that the synchronization process proceeds smoothly.

Step S904, analyzing the asset image file and matching the asset expansion points.

In this embodiment, after the download is completed, the target HUB parses the content of the asset image file and extracts the asset metadata and material data therein. Parsing involves reading and understanding the structure and data format in the image file, often requiring a specialized parser or module to complete. The parsed asset metadata and material data are the basis for further processing and manipulation.

Optionally, the target HUB matches corresponding asset extension points based on the parsed asset metadata. The asset extension points define the composition, material type, operating 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. The matching asset extension point is the core of the intelligent and custom processing in asset synchronization, by which the target HUB can determine how to process and use the synchronized asset image file.

For example, if the asset image includes a Docker image, the target HUB may match the asset extension point of the Docker image, and thus call the corresponding SPI service to process the image data, which may include uploading the image to a local Docker repository, processing dependencies in the image, converting the image format, and so on.

Step S906, save the asset image file.

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

Optionally, saving the asset image file is a key step to ensure asset availability and durability. The target HUB may also need to perform some additional logic in saving the image file, such as checking the integrity and consistency of the file, updating metadata information for the asset, generating an index or metadata digest for the asset, etc., for subsequent querying and use.

At the same time, the save step may also include further processing of the parsed material data, such as pushing the Docker images to a local Docker warehouse, or processing other types of asset materials, to ensure that they are properly identified and used by the local environment. In addition, the target HUB may also utilize a callback mechanism to notify the source HUB or other related system of the synchronization results (including success or failure information) to ensure consistency of asset status and feedback of the synchronization operation.

Alternatively, once the asset image file is successfully saved, the target HUB may put it on shelf for local user or team subscription and use. By the 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.

Asset installation is an important element in the life cycle of an asset, the process by which an asset in an asset HUB is downloaded and deployed to a particular environment (e.g., local server, etc.). FIG. 10 is a flow chart of an asset installation process, as shown in FIG. 10, according to an embodiment of the application, which may include the steps of:

step S1002, downloading asset metadata.

In this embodiment, the first step in the asset installation process is to download asset metadata. The asset metadata contains key data describing the attributes, material information, operational rules, etc. of the asset image. This process is typically 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 is able to obtain complete and up-to-date asset information to properly install and configure the asset.

Step S1004, analyzing the asset metadata and matching the asset expansion points.

In this embodiment, after downloading asset metadata, the specific structure and dependencies of the asset are parsed and understood next. Parsing asset metadata involves reading a metadata file, parsing its format and content, extracting the underlying information of the asset, the bill of materials, operating metadata, and any custom attributes.

Optionally, after parsing, the target environment matches corresponding asset extension points based on information of asset metadata. Asset extension points define the composition of an asset, the type of material, and rules of how the asset is installed and configured in different environments. By matching asset extension points, the target environment is able to identify the specific type and materials of the asset and how to perform the installation operation.

For example, if a dock image is defined in the downloaded asset metadata, the target environment will match the corresponding dock image asset extension point, knowing how to download the image from the HUB, how to install and run this image in the local environment, and any metadata specific to the installation process (e.g., environment variables, port maps, etc.).

In step S1006, the asset metadata driver installs the asset image file.

In this embodiment, after parsing and matching is completed, the target environment initiates the installation process of the asset image file according to rules and information of the asset metadata. This typically involves downloading a complete asset image file from the asset HUB and then performing an installation operation based on the asset material metadata and the operation metadata.

Optionally, the installation process of the asset image file is highly dependent on metadata that not only contains the constituent information of the asset, but also provides guidance for the installation logic. For example, asset metadata may include installation scripts for a particular material, paths for configuration files, required system resources, etc., which may be used to guide a particular installation operation. During the installation process, the target environment may call the SPI service defined in the asset extension point to perform the installation operation of the material. The SPI service contains specific types of material installation logic, such as how to deploy the Docker image into the container environment, how to configure and launch HELM CHART, and so on. These operations may require interaction with external systems or services, such as a Docker warehouse, kubernetes API SERVER, etc., to complete the installation and configuration of the asset.

Optionally, after installation is complete, the target environment updates status information for the asset, indicating that the asset has been installed successfully, while some additional logic may be implemented, such as generating reports of asset usage, updating version information for the asset, etc. In addition, the target environment also uses a callback mechanism to notify the asset HUB and related business systems of the installation results, so as to ensure the consistency of the asset state and the feedback of the installation operation.

In summary, through the steps, the asset installation process realizes the deployment and configuration of the asset image file in the target environment, and ensures the normal operation and function implementation of the asset. This process leverages the metadata driven mechanism and extensibility of the asset HUB, enabling different types of assets to be flexibly installed and used in a variety of target environments.

In this embodiment, the orchestration of the asset HUB is primarily embodied in the orchestration of asset presentation and the orchestration of asset flow.

Optionally, for the orchestration of asset display, by using the above asset metadata definition and the extension point definition, a user may orchestrate a display page defining an asset, and by describing the asset display attribute, may define a homepage, logo, detail page, each attribute control, layout, etc. of the asset, so as to actually implement an asset display page meeting the needs of the enterprise itself.

Alternatively, for the orchestration of asset flows, as described above in the extension points, a user may customize the full life cycle of an asset, and may define the full life cycle of a material in an asset. Definition approval flows, etc. may be orchestrated for certain specific operations.

In this embodiment, for reusability of assets, the asset HUB is naturally serving the precipitation and reuse of assets, while the asset HUB is provided with a distributed deployment architecture, the asset can be freely circulated among multiple HUB, meeting different usage scenarios.

FIG. 11 is a schematic diagram of a distributed asset management and operation platform architecture according to an embodiment of the present application, where the subscription relationship between HUBs eventually forms a mesh relationship, as shown in FIG. 11. Public HUB (PublicHUB), the asset HUB provides an authoritative HUB in the public cloud that is subscribed to by other HUBs, but not any other HUB, which can only be maintained by the asset HUB authority. Enterprise HUB (Private HUB), the HUB deployed inside the enterprise is an enterprise-level HUB, the enterprise has complete control authority over the HUB, and the HUB can subscribe to Public HUB or other Private HUBs. The developer local HUB (Local HUB), the HUB is special and is directly deployed on the local of the developer, and one important reason for the HUB is that when the developer does not have internet access, the production and uploading of the assets can be carried out locally, then the local HUB and the enterprise HUB can be delivered after the network exists, and the asset mirroring can be automatically synchronized. Of course, local HUB could theoretically interact with Publich HUB directly. The CLI command line interface may be used to obtain an input command of a user and display an asset image, and through the CLI command line, a request may be sent to the Local HUB to push the asset image to the Private HUB, or a pull asset image may be displayed on the interface.

In this embodiment, the HUB not only has the management capability of the asset, but also has the operational capability of the asset for the asset to be operational. The method can manage and view operation information such as home page recommendation of the asset, asset scoring, asset operation statistics large screen, asset use detail and the like. The large asset operation screen comprises asset service condition statistics of multiple dimensions such as asset carding, asset type distribution, asset tag distribution, asset browsing, asset putting on shelf, asset subscription, asset installation and the like. Providing a rich asset operation function for asset administrators.

In the embodiment of the application, the HUB solves the problems that the product depth is bound with an upper business system, the asset and the material composition thereof cannot be flexibly expanded, the operation flow of the asset is solidified, the asset cannot be precipitated and quickly multiplexed, the business pain points such as an asset cannot be specifically evaluated, and the like, and a solid technical base is provided for customizing an apparent asset used by an own internal system for an enterprise through five dimensions of definable, extensible, arrangeable, reusable and operable assets. By combining the expansion point and the SPI mechanism, the problem of common service pain points in use of the asset center can be solved from five dimensions. Such as definable assets, extensible assets, programmable assets, reusable assets, operational assets.

According to an embodiment of the present application, there is also provided a resource processing apparatus for implementing the above-described resource processing method shown in fig. 2.

Fig. 12 is a schematic diagram of a processing apparatus for a resource according to an embodiment of the present application, and as shown in fig. 8, the processing apparatus 1200 for a resource may include a first determining unit 1202, a second determining unit 1204, a first expanding unit 1206, and a first executing unit 1208.

A first determining unit 1202, configured to determine a scene type of a scene where the resource to be processed is located. A second determining unit 1204, configured to determine an expansion policy matching the scene type, and metadata matching the scene type. The first expansion unit 1206 is configured to expand the resource to be processed on an expansion level by using metadata according to an expansion policy, so as to obtain a target resource. The first execution unit 1208 is configured to execute an operation corresponding to the scene type on the target resource, to obtain an operation result.

Here, the above-described first determining unit 1202, second determining unit 1204, first expanding unit 1206, and first executing unit 1208 correspond to steps S202 to S208 in the above-described embodiments, and the four units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in the above-described embodiments. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1604) and processed by one or more processors (e.g., the processors 1602a,1602b.

According to an embodiment of the present application, there is also provided an apparatus for processing an enterprise asset, which is used to implement the method for processing an enterprise asset shown in fig. 3.

Fig. 13 is a schematic diagram of an enterprise asset processing apparatus according to an embodiment of the present application, and as shown in fig. 13, the resource processing apparatus 1300 may include a third determining unit 1302, a fourth determining unit 1304, a second expanding unit 1306, and a second executing unit 1308.

A third determining unit 1302 is configured to determine a scene type of a scene in which the to-be-processed enterprise asset is located. A fourth determining unit 1304 for determining an extension point matching the scene type, and asset metadata matching the scene type. And a second expansion unit 1306, configured to expand the to-be-processed enterprise asset on an expansion level by using the asset metadata according to the expansion point, so as to obtain a target enterprise asset. And the second execution unit 1308 is configured to execute an operation corresponding to the scene type on the target enterprise asset, so as to obtain an asset image file of the target enterprise asset under the scene.

Here, it should be noted that the third determining unit 1302, the fourth determining unit 1304, the second expanding unit 1306 and the second executing unit 1308 correspond to steps S302 to S308 in the above embodiments, and the four units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the above embodiments. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1604) and processed by one or more processors (e.g., the processors 1602a,1602b.

According to an embodiment of the present application, there is also provided a resource processing apparatus for implementing the above-described resource processing method shown in fig. 4.

Fig. 14 is a schematic diagram of a processing apparatus for a resource according to an embodiment of the present application, and as shown in fig. 14, the processing apparatus 1400 for a resource may include a fifth determining unit 1402, a first display unit 1404, a second display unit 1406, and a second display unit 1408.

A fifth determining unit 1402, configured to determine a scene type of a scene in which the resource to be processed is located, in response to an operation instruction acting on the operation interface. A first display unit 1404, configured to display, on the operation interface, an expansion policy that matches the scene type, and metadata that matches the scene type. And a second display unit 1406, configured to display a target resource corresponding to the resource to be processed on the operation interface. The second display unit 1408 is configured to display, on the operation interface, an operation corresponding to the execution scene type on the target resource, and a result of the operation.

Here, it should be noted that the fifth determining 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 embodiments, and the four units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in the above embodiments. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1604) and processed by one or more processors (e.g., the processors 1602a,1602b.

Fig. 15 is a schematic diagram of a processing apparatus for a resource according to an embodiment of the present application, and as shown in fig. 15, the processing apparatus 1500 for a resource 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.

The first invoking unit 1502 is configured to determine, by invoking the first interface, a scene type of a scene where the resource to be processed is located. A sixth determining unit 1504 is configured to determine an expansion policy that matches the scene type, and metadata that matches the scene type. The third extension unit 1506 is configured to extend the resource to be processed on an extension level by using metadata according to an extension policy, so as to obtain a target resource. And a third execution unit 1508, configured to execute an operation corresponding to the scene type on the target resource, to obtain an operation result. The second calling unit 1510 is configured to output an operation result by calling the second interface.

Here, it should be noted that the first invoking unit 1502, the sixth determining unit 1504, the third extending unit 1506, the third executing unit 1508, and the second invoking unit 1510 correspond to steps S502 to S510 in the above embodiments, and the five units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in the above embodiments. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1604) and processed by one or more processors (e.g., the processors 1602a,1602b.

Embodiments of the present application may provide a computer terminal, which may be any one of a group of computer terminals. Alternatively, in the present embodiment, the above-described computer terminal may be replaced with a terminal device such as a mobile terminal.

Alternatively, in this embodiment, the above-mentioned computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

In this embodiment, the computer terminal may execute the program code of the above steps in the resource processing method.

Alternatively, fig. 16 is a block diagram of a computer terminal according to an embodiment of the present application. As shown in fig. 16, 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.

The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the resource processing method and apparatus in the embodiments of the present application, and the processor executes the software programs and modules stored in the memory, thereby executing various functional applications and data processing, that is, implementing the resource processing method described above. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further comprise a memory remotely located with respect to the processor, the remote memory being connectable to the computer terminal a through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

It will be appreciated by those skilled in the art that the structure shown in fig. 16 is merely illustrative, and the computer terminal a may be a terminal device such as a smart phone (e.g. an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a Mobile internet device (Mobile INTERNET DEVICES, abbreviated as MID), a PAD, etc. Fig. 16 does not limit the structure of the computer terminal a. For example, the computer terminal a may also include more or fewer components (such as a network interface, a display device, etc.) than shown in fig. 16, or have a different configuration than shown in fig. 16.

Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing a terminal device to execute the relevant hardware, and the program may be stored in a computer readable storage medium, where the storage medium may include a flash disk, a Read-only memory (ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disk.

Embodiments of the present application also provide a computer-readable storage medium. Alternatively, in this embodiment, the computer readable storage medium may be used to store the program code executed by the processing method for resources provided in the first embodiment.

Alternatively, in this embodiment, the above-mentioned computer-readable storage medium may be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.

Alternatively, in the present embodiment, a computer-readable storage medium is provided to store program code for performing the above steps.

Embodiments of the application may provide an electronic device that may include a memory and a processor.

Fig. 17 is a block diagram of an electronic device of a method of processing resources according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the applications described and/or claimed herein.

As shown in fig. 17, the apparatus 1700 includes a computing unit 1701 that 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 RAM1703, various programs and data required for the operation of the device 1700 may also be stored. The computing unit 1701, the ROM1702, and the RAM1703 are connected to each other via a bus 1704. An input/output (I/O) interface 1705 is also connected to the bus 1704.

Various components in the device 1700 are connected to I/O interfaces 1705, including an input unit 1706, e.g., keyboard, mouse, etc., an output unit 1704, e.g., various types of displays, speakers, etc., a storage unit 1708, e.g., magnetic disk, optical disk, etc., and a communication unit 1709, e.g., network card, modem, wireless communication transceiver, etc. The communication unit 1709 allows the device 1700 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunications networks.

The computing unit 1701 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 1701 include, but are not limited to, a Central Processing Unit (CPU), a graphics processing unit (Graphics Processing Unit, abbreviated as GPU), various specialized artificial intelligence (ARTIFICIAL INTELLIGENCE, abbreviated as AI) computing chips, various computing units running machine learning model algorithms, a digital signal Processor (DIGITAL SIGNAL Processor, abbreviated as DSP), and any suitable Processor, controller, microcontroller, etc. The computing unit 1701 performs the respective methods and processes described above, for example, a processing method of a resource. For example, in some embodiments, the method of processing resources may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 1708. In some embodiments, part or all of the computer program may be loaded and/or installed onto device 1700 via ROM 1702 and/or communication unit 1709. When the computer program is loaded into RAM 1703 and executed by computing unit 1701, one or more steps of the above-described method of processing resources may be performed. Alternatively, in other embodiments, the computing unit 1701 may be configured to perform the processing method of the resource in any other suitable manner (e.g., by means of firmware).

Embodiments of the present application also provide a computer program product. Alternatively, in this embodiment, the computer program product may include a computer program, where the computer program when executed by a processor implements the method for processing resources according to the embodiment of the present application.

The method embodiments provided by the embodiments of the present application may be performed in a mobile terminal, a computer terminal, or similar computing device. Fig. 18 is a hardware configuration block diagram of a computer terminal (or mobile device) for implementing a processing method of resources according to an embodiment of the present application, as shown in fig. 18, the computer terminal 180 (or mobile device) may include one or more processors 1802 (shown as 1802a, 1802b, 1802n in the figure), which may include, but are not limited to, a processing apparatus 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 apparatus 1806 for a communication function. Among other things, a display, an input/output interface (I/O interface), a universal serial BUS (Universal Serial Bus, simply 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 may be included. It will be appreciated by those skilled in the art that the configuration shown in fig. 18 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, the computer terminal 180 may also include more or fewer components than shown in fig. 18, or have a different configuration than shown in fig. 18.

The hardware block diagram shown in fig. 18 may be used not only as an exemplary block diagram of the computer terminal 180 (or mobile device) described above, but also as an exemplary block diagram of the server described above, and in an alternative embodiment, fig. 18 shows in block diagram form an embodiment that uses the computer terminal 180 (or mobile device) shown in fig. 18 described above as a computing node in the computing environment 1901.

FIG. 19 is a block diagram of a computing environment for a method of processing resources, as shown in FIG. 19, where the computing environment 1901 includes a plurality of computing nodes (e.g., servers) running on a distributed network (shown using 1910-1, 1910-2). The computing nodes each contain local processing and memory resources and the end user 1902 may run applications or store data remotely in the computing environment 1901. The application program may be provided as a plurality of services 1920-1,1920-2,1920-3 and 1920-4 in computing environment 1901, representing services "F", "G", "I", and "H", respectively.

The end user 1902 may provide and access services through a web browser or other software application on the client, in some embodiments, provisioning and/or requests of the end user 1902 may be provided to the portal gateway 1930. The ingress gateway 1930 may include a corresponding agent to handle provisioning and/or requests for services (one or more services provided in the computing environment 1901).

Services are provided or deployed in accordance with various virtualization techniques supported by the computing environment 1901. In some embodiments, services may be provided according to Virtual Machine (VM) based virtualization, container based virtualization, and/or the like. Virtual machine-based virtualization may be the emulation of a real computer by initializing a virtual machine, executing programs and applications without directly touching any real hardware resources. While the virtual machine virtualizes the machine, according to container-based virtualization, a container may be started to virtualize the entire operating system so that multiple workloads may run on a single operating system instance.

In one embodiment based on container virtualization, several containers of a service may be assembled into one Pod (e.g., kubernetes Pod). For example, as shown in FIG. 19, service 1920-2 may be equipped with one or more Pods 1940-1, 1940-2. The Pod may include an agent 1945 and one or more containers 1942-1,1942-2, 1942-M (collectively referred to as containers). One or more containers in the Pod handle requests related to one or more corresponding functions of the service, and the agent 1945 typically controls network functions related to the service, such as routing, load balancing, etc. Other services may also be equipped with Pod similar to Pod.

In operation, executing a user request from an end user 1902 may require invoking one or more services in the computing environment 1901, and executing one or more functions of one service may require invoking one or more functions of another service. As shown in FIG. 19, service "F"1920-1 receives a user request of end user 1902 from ingress gateway 1930, service "F"1920-1 may invoke service "G"1920-2, and service "G"1920-2 may request service "I"1920-3 to perform one or more functions.

The computing environment may be a cloud computing environment, and the allocation of resources is managed by a cloud service offering, allowing the development of functionality without requiring analysis to implement, adjust, or extend servers. The computing environment allows developers to execute code that responds to events without building or maintaining a complex infrastructure. Instead of expanding a single hardware device to handle the potential load, the service may be partitioned to a set of functions that can be automatically scaled independently.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit System, field Programmable Gate Array (FPGA), application specific integrated circuit (Application SPECIFIC INTEGRATED, abbreviated ASIC), application specific standard product (Application SPECIFIC STANDARD PARTS, abbreviated ASSP), system-on-a-Chip (abbreviated SOC), complex programmable logic device (Complex Programmable Logic Device, abbreviated CPLD), computer hardware, firmware, software, and/or combinations thereof. The various embodiments described above may include being implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be a special or general purpose programmable processor, operable to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for carrying out methods of the present application may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present application, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read-Only Memory, simply EPROM or flash Memory), an optical fiber, a portable compact disc read-Only Memory (Compact Disc Read-Only Memory, simply CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a Cathode Ray Tube (CRT) or Liquid CRYSTAL DISPLAY, LCD) monitor for displaying information to the user; other types of devices may also be used to provide interaction with the user, for example, 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, speech input, or tactile input).

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can 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 (Local Area Network, abbreviated LAN), a wide area network (Wide Area Network, abbreviated WAN), and the Internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application, which are also intended to be considered as protecting the scope of the present application.

Claims

1. A method for processing resources, comprising:

determining a scene type of a scene where a resource to be processed is located, wherein the scene type is used for representing the type of an operation executed on the resource to be processed under the scene;

Determining an expansion strategy matched with the scene type and metadata matched with the scene type, wherein the expansion strategy is used for representing a rule for expanding the resource to be processed according to an expansion hierarchy matched with the scene type, and the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type;

according to the expansion strategy, expanding the resource to be processed on the expansion level by utilizing the metadata to obtain a target resource;

and executing the operation corresponding to the scene type on the target resource to obtain an operation result.

2. The method according to claim 1, wherein the method further comprises:

determining an interface matched with the expansion strategy, wherein the expansion strategy comprises attribute information of the interface;

According to the expansion strategy, the metadata is utilized to expand the resources to be processed on the expansion level to obtain target resources, and the method comprises the steps of calling the interface, and according to the expansion strategy, utilizing the metadata to expand the resources to be processed on the expansion level to obtain the target resources.

3. The method of claim 1, wherein determining an extension policy that matches the scene type comprises:

And determining the expansion strategy matched with the scene type in an expansion strategy set, wherein the expansion strategy set comprises at least one of a material expansion strategy, a resource expansion strategy and a flow expansion strategy, the material expansion strategy is used for representing a rule for expanding an atomic product contained in the resource to be processed, the resource expansion strategy is used for representing a rule for expanding the resource to be processed as a whole, and the flow expansion strategy is used for representing a rule for expanding the operation flow of the resource to be processed.

4. The method of claim 3, wherein determining the extension policy that matches the scene type in an extension policy set comprises:

in the case that the operation corresponding to the scene type is a resource making operation, at least determining the material expansion strategy corresponding to the resource making operation and the resource expansion strategy corresponding to the resource making operation in the expansion strategy set;

Under the condition that the operation corresponding to the scene type is a resource synchronous operation, at least determining the material expansion strategy corresponding to the resource synchronous operation in the expansion strategy set;

In the case that the operation corresponding to the scene type is a resource installation operation, at least determining the material expansion strategy corresponding to the resource installation operation in the expansion strategy set;

and determining the flow expansion strategy matched with the expansion requirement information under the scene type in the expansion strategy set, wherein the expansion requirement information is used for representing the requirement of expanding the operation flow of the resource to be processed.

5. A method according to claim 3, wherein expanding the resource to be processed on the expansion hierarchy using the metadata according to the expansion policy to obtain a target resource comprises:

under the condition that the expansion strategy is the material expansion strategy, expanding the atomic products of different prefabrication types composing the resource to be processed by utilizing the metadata so as to obtain the target resource;

Under the condition that the expansion strategy is the resource expansion strategy, expanding the resource information of the resources to be processed as a whole by utilizing the metadata to obtain the target resource;

and under the condition that the expansion strategy is the flow expansion strategy, configuring flow information of the operation flow of the resource to be processed by utilizing the metadata so as to obtain the target resource.

6. The method of claim 5, wherein expanding the atomic artifacts of different prefabricated types that make up the resource to be processed using the metadata to obtain the target resource if the expansion policy is the material expansion policy, comprises:

And under the condition that the expansion strategy is the material expansion strategy, calling a controller corresponding to the prefabrication type by utilizing the metadata, and expanding the atomic product of the prefabrication type to obtain the target resource, wherein different prefabrication types correspond to different controllers.

7. The method of claim 5, wherein expanding the resource information of the resource to be processed as a whole with the metadata to obtain the target resource, in a case where the expansion policy is the resource expansion policy, comprises:

Expanding the metadata under the condition that the expansion strategy is the resource expansion strategy, wherein the expanded metadata is used for describing resource attribute information of the resource to be processed after being expanded, expanding the resource attribute information of the resource to be processed as a whole by utilizing the expanded metadata to obtain the target resource, and/or,

And under the condition that the expansion strategy is the resource expansion strategy, expanding a definition description language of the resource to be processed as a whole by utilizing the metadata to obtain the target resource, wherein the definition description language is used for describing resource composition information of the resource to be processed.

8. The method of claim 5, wherein configuring flow information of the operation flow of the resource to be processed with the metadata to obtain the target resource if the extended policy is the flow extended policy comprises:

determining at least one target operation flow in an operation flow set under the condition that the expansion strategy is the flow expansion strategy;

and configuring flow information of the target operation flow by utilizing the metadata so as to obtain the target resource.

9. A method according to claim 3, characterized in that the method further comprises:

Generating said resource extension policy in said extension policy set using resources from a three-way system, and/or,

And generating the material expansion strategy in the expansion strategy set by utilizing the resource materials from the three-party system, wherein the resource materials are used for representing the atomic products included in the resource image file of the three-party system.

10. The method of claim 9, wherein generating the material expansion policy in the expansion policy set using resource material from the three-way system comprises:

and generating the material expansion strategy in the expansion strategy set by utilizing the resource materials from the three-party system and the resource expansion strategy in the expansion strategy set.

11. A method according to claim 3, wherein determining metadata matching the scene type comprises:

Determining resource base metadata matched with the scene type, the resource expansion strategy and the definition description language of the resource to be processed, wherein the resource base metadata is used for describing base information of an asset image file of the resource to be processed in the scene, and the definition description language is used for describing resource composition information of the resource to be processed;

and determining resource material metadata matched with the scene type, the material expansion strategy and the definition description language, wherein the resource material metadata is used for describing an original product of the resource to be processed in the asset image file under the scene.

12. The method according to claim 11, wherein the resource base metadata comprises resource native information and/or resource extension detailed information, wherein resource native information is used for describing native information defined by the resource to be processed in the scene, resource extension detailed information is used for describing extension detailed information defined by the resource to be processed in the scene, and wherein the resource material metadata comprises material entity metadata and/or material operation metadata, wherein material entity metadata is used for describing entity properties of an atomic product defined by the resource to be processed in the scene, and material operation metadata is used for describing data required by the atomic product defined by the resource to be processed in the scene in operation.

13. The method of claim 1, wherein performing the operation corresponding to the scene type on the target resource results in an operation result, including at least one of:

the method comprises the steps of executing resource making operation corresponding to a resource making scene type on a target resource to obtain a plurality of atomic products of the target resource in the scene;

executing resource synchronization operation corresponding to a resource synchronization scene type on the target resource, and synchronizing a second asset image file corresponding to resource information of the target resource under the scene to a resource management and operation platform;

And executing resource installation operation corresponding to the resource installation scene type on the target resource, and installing a third asset image file of the target resource under the scene into a target project system or cluster.

14. A method for processing an enterprise asset, applied to an enterprise asset processing platform, comprising:

Determining a scene type of a scene in which an enterprise asset to be processed is located, wherein the scene type is used for representing the type of an operation performed on the enterprise asset to be processed under the scene;

determining an expansion point matched with the scene type and asset metadata matched with the scene type, wherein the expansion point is used for representing a rule for expanding the to-be-processed enterprise asset according to an expansion hierarchy matched with the scene type, and the asset metadata is used for describing a format and/or content defined by the to-be-processed enterprise asset under the scene of the scene type;

According to the expansion points, the asset metadata are utilized to expand the enterprise assets to be processed on the expansion level, and target enterprise assets are obtained;

and executing the operation corresponding to the scene type on the target enterprise asset to obtain an asset image file of the target enterprise asset in the scene.

15. A method for processing resources, comprising:

determining a scene type of a scene where a resource to be processed is located in response to an operation instruction acting on an operation interface, wherein the scene type is used for representing the type of an operation executed on the resource to be processed under the scene;

Displaying an expansion strategy matched with the scene type and metadata matched with the scene type on the operation interface, wherein the expansion strategy is used for representing a rule for expanding the resource to be processed according to an expansion hierarchy matched with the scene type, and the metadata is used for describing a format and/or content defined by the resource to be processed under the scene of the scene type;

displaying a 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 on the expansion hierarchy by utilizing the metadata according to the expansion strategy;

And displaying an operation result obtained by executing the operation corresponding to the scene type on the target resource on the operation interface.

16. A method for processing resources, comprising:

determining a scene type of a scene where a resource to be processed is located by calling a first interface, wherein the scene type is used for representing the type of an operation executed on the resource to be processed under the scene by calling the first interface;

executing the operation corresponding to the scene type on the target resource to obtain an operation result;

And outputting the operation result by calling a second interface, wherein the second interface comprises a second parameter, and the parameter value of the second parameter is the operation result.

17. A system for processing resources, comprising:

The client is used for uploading a resource processing request, wherein the resource processing request is used for requesting to process the resource to be processed;

The resource processing platform is used for responding to the resource processing request, determining a scene type of a scene where the resource to be processed is located, wherein the scene type is used for representing the type of operation executed on the resource to be processed in the scene, determining an expansion strategy matched with the scene type and metadata matched with the scene type, wherein the expansion strategy is used for representing a rule for expanding the resource to be processed according to an expansion hierarchy matched with the scene type, the metadata is used for describing the format and/or content defined by the resource to be processed in the scene of the scene type, expanding the resource to be processed on the expansion hierarchy by utilizing the metadata according to the expansion strategy to obtain a target resource, executing operation corresponding to the scene type on the target resource to obtain an operation result, and issuing the operation result to the client.

18. The system of claim 17, wherein a plurality of the resource processing platforms are constructed based on a distributed deployment architecture and are interconnected, the target resource allowing multiplexing among the plurality of the resource processing platforms.

19. A computer readable storage medium, characterized in that the computer readable storage medium comprises a stored executable program, wherein the executable program when run controls a device in which the storage medium is located to perform the method of any one of claims 1 to 16.

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