Method and device for realizing expansibility of assembly process

Abstract

The embodiment of the invention provides an implementation method and device for assembly process expansibility, and the method comprises the steps: selecting a reusable functional unit, and obtaining a first definition file set based on the reusable functional unit; analyzing the first definition file set to obtain a first arrangement object; performing arrangement processing on the first arrangement object to obtain a second arrangement object; obtaining a second definition file set based on the second arrangement object; and obtaining a target plug-in based on the second definition file set, so that the target plug-in provides expansibility for the component. Through the method and the device, the problem that the codes of the components need to be modified when the package or the version package is modified in the prior art is solved, and the efficiency of modifying the package or the version package is further improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of enterprise application development. Specifically, the embodiments of the present application relate to a method and device for implementing the scalability of the assembly process. Background Art

[0002] Traditional application development faces many challenges: First, there is not enough development capacity; second, it is easy to choose the wrong technical direction; third, the delivery is not fast enough. To solve these problems, a common technical solution is to use the technology of "assembled applications" to save time and improve the delivery speed.

[0003] In the related art, the basic object of the "assembled application" technology is components, and a package or version package is constructed by selecting components with fixed functions.

[0004] However, when there is a lack of functions in the components with fixed functions, it is often necessary to modify the code of the components, recompile and package to output a new component version, and then use the new component version to construct a package or version package. The process is relatively complex and has low flexibility. Summary of the Invention

[0005] The embodiments of the present application provide a method and device for implementing the scalability of the assembly process, so as to at least solve the problem in the related art that the code of the components needs to be modified when modifying a package or version package.

[0006] According to an embodiment of the present application, a method for implementing the scalability of the assembly process is provided, including:

[0007] Select reusable function units, and obtain a first set of definition files based on the reusable function units;

[0008] Parse the first set of definition files to obtain a first orchestration object;

[0009] Perform orchestration processing on the first orchestration object to obtain a second orchestration object;

[0010] Obtain a second set of definition files based on the second orchestration object;

[0011] Obtain a target plugin based on the second set of definition files, so that the target plugin provides the scalability ability for the components.

[0012] According to another embodiment of the present application, a device for implementing the scalability of the assembly process is provided, including:

[0013] An assembly module, configured to select reusable function units and obtain a first set of definition files based on the reusable function units;

[0014] The plugin orchestration module is used to parse the first definition file set to obtain a first orchestration object; and,

[0015] perform an orchestration process on the first orchestration object to obtain a second orchestration object;

[0016] The plugin generation module is used to obtain a second definition file set based on the second orchestration object; and,

[0017] is used to obtain a target plugin based on the second definition file set, so that the target plugin provides an extensible ability for the component.

[0018] According to another embodiment of the present application, there is also provided a computer-readable storage medium in which a computer program is stored. Among them, the computer program is set to execute the steps in any one of the above method embodiments when running.

[0019] According to another embodiment of the present application, there is also provided an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is set to run the computer program to execute the steps in any one of the above method embodiments.

[0020] One of the above technical solutions has the following advantages or beneficial effects: When it is necessary to modify a package or version package, by selecting and combining reusable function units, the plugin generated by the reusable function unit is used to expand the capabilities of the component, avoiding the operation of modifying the component code, and improving the efficiency of modifying the package or version package. This can enable faster application development and solve some challenges and problems in traditional development. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a flowchart of the application assembly according to the related art;

[0022] Figure 2 is a flowchart of the implementation method for the extensibility of the assembly process according to the embodiment of the present application;

[0023] Figure 3 is a flowchart of the method for plugin - plugin orchestration - plugin for the API plugin according to the embodiment of the present application;

[0024] Figure 4 is a flowchart of the method for obtaining a first orchestration object based on the first definition file according to the embodiment of the present application;

[0025] Figure 5 is a flowchart of the method for obtaining a second orchestration object based on the first orchestration object according to the embodiment of the present application;

[0026] Figure 6 It is a schematic framework of the implementation method for the scalability of the assembly process according to the embodiments of the present application. Figure 1 ;

[0027] Figure 7 It is a schematic framework diagram of the assembly process according to the embodiments of the present application;

[0028] Figure 8 It is a schematic framework diagram of the plug-in orchestration process according to the embodiments of the present application;

[0029] Figure 9 It is a schematic framework diagram of the parsing and orchestration process for API type plug-ins according to the embodiments of the present application;

[0030] Figure 10 It is a schematic framework diagram of the orchestration process for configuration type plug-ins according to the embodiments of the present application;

[0031] Figure 11 It is a schematic framework diagram of the orchestration process for script type plug-ins according to the embodiments of the present application;

[0032] Figure 12 It is a schematic framework diagram of the accumulation of expansion capabilities according to the embodiments of the present application;

[0033] Figure 13 It is a schematic framework diagram of the information interaction among the client, script, and server according to the embodiments of the present application;

[0034] Figure 14 It is a schematic framework diagram of the selected APIs and the generated APIs during the conversion between the web service protocol and the rest protocol according to the embodiments of the present application;

[0035] Figure 15 It is a schematic structural diagram of the implementation device for the scalability of the assembly process according to the embodiments of the present application. Detailed implementation manners

[0036] In the following, the embodiments of the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to describe a specific order or sequence.

[0038] In the related art, traditional application development faces many challenges: first, there is not enough development ability; second, the wrong technical direction is chosen; third, the delivery is not fast enough. To solve these problems, a common technical solution is "code reuse", that is, reusing existing and relatively mature code. In this way, time can be saved and the delivery speed can be improved.

[0039] The "assembled application" proposed by Gartner solves the above problems by introducing a new architecture. It hopes to introduce the concept of modularization so that technology and business teams can reuse code more agilely and effectively. By means of assembled thinking, assembled platform, and assembled architecture, enterprise-level applications are developed to promote the deep integration of digital technology and business applications. In complex and ever-changing situations, the "assembled application" can enhance the enterprise's adaptability and innovation ability. By formulating relevant specifications for component integration and decoupling, it provides a standard basis for the integrated development of components, and promotes work such as component standardization and certification governance.

[0040] The core of the "assembled application" is called "Packaged Business Capability (PBC)". PBC is a software-defined minimal business function. Gartner's official definition of PBC states that: PBC is a well-defined software component that can be functionally recognized by users. PBC is a bounded set, and the elements of this set are data schemas (a collection of database objects), a set of services, a set of APIs (Application Programming Interface), and event channels.

[0041] Figure 1 It is a flowchart assembled according to the application of relevant technologies, such as Figure 1 shown

[0042] When PBC is applied to application assembly, the complete process of application assembly is divided into the following four stages:

[0043] Production stage: Professional developers (Pro-Code) use local programming language tools to develop various capability components and build and deploy PBC components or applications.

[0044] Operation stage: Asset operators are responsible for operating PBC component assets and maintaining and managing business description metadata information, asset categories, life cycles, versions, authorizations, SLAs (Service Level Agreements), etc. of component assets.

[0045] Assembly stage: Non-professional developers (Business-IT) use low-code or no-code tools to assemble and develop business applications or solutions to meet business innovation needs.

[0046] Usage stage: Users solve business problems and achieve business goals through business applications or solutions.

[0047] The assembly technologies in the related art mainly focus on components. By selecting components to build a package or version package, when there are functional deficiencies in existing components, it is often necessary to modify the code, recompile and package to output a component version, which is a complex process with low flexibility. For the configurations used by components, there is no flexible mechanism to adjust them without modifying the components, or to provide different business configurations for components in different business scenarios.

[0048] The assembly stage is in the design stage of the entire application assembly process. This stage assembles and develops enterprise applications or solutions based on existing component assets. The "scalability" mentioned in the present invention specifically refers to the "scalability of the assembly process". It means that based on existing components, new component business capabilities can be quickly built. Achieving scalability can greatly improve the adaptability of assembled applications to different enterprises and complex business scenarios, and can also provide users with more rich component integration and component operation and maintenance functions. Currently, there is no method in the industry to achieve the scalability of the assembly process, which is also a major problem in the implementation of assembled applications.

[0049] Figure 2 It is a flowchart of an implementation method for the scalability of the assembly process according to an embodiment of the present application, as Figure 2 shown,

[0050] In this embodiment, an implementation method for the scalability of the assembly process is provided. The method includes the following steps:

[0051] Step S201, select reusable function units, and obtain a first set of definition files based on the reusable function units;

[0052] In one implementation, the reusable function units include at least one of the following: components, plugins.

[0053] In an exemplary implementation, a first set of definition files can be obtained based on at least one set of components, or a first set of definition files can be obtained based on at least one set of plugins, or a first set of definition files can be obtained based on the combination of at least one set of components and at least one set of plugins.

[0054] Step S202, parse the first set of definition files to obtain a first orchestration object;

[0055] Step S203, perform an orchestration process on the first orchestration object to obtain a second orchestration object;

[0056] Step S204, obtain a second set of definition files based on the second orchestration object;

[0057] Step S205, obtain a target plugin based on the second set of definition files, so that the target plugin provides scalability capabilities for the components.

[0058] Among them, the difference between the first layout object and the second layout object lies in the different values of the fields.

[0059] Through the above steps, when it is necessary to modify the package or version package, by selecting and combining reusable functional units, and using the plug-ins generated by the reusable functional units to expand the capabilities of the components, the operation of modifying the component code is avoided, and the efficiency of modifying the package or version package is improved. This can enable faster application development and solve some challenges and problems in traditional development.

[0060] In one implementation, before selecting the reusable functional unit and obtaining the first set of definition files based on the reusable functional unit, it further includes:

[0061] Taking the target plug-in as the plug-in of the reusable functional unit.

[0062] In an exemplary implementation, after taking the target plug-in as the plug-in of the reusable functional unit, steps S201 to S205 are repeated to facilitate the loop process of plug-in - plug-in orchestration - plug-in for the target plug-in, so as to facilitate generating a new plug-in using the target plug-in, or a new plug-in can be generated based on the component and the target plug-in, thereby realizing the reuse of the extension capabilities of the plug-ins. Therefore, in the process of generating a new plug-in, the plug-in of the reusable functional unit can select the target plug-in generated by the above steps S201 to S205, or can select a known plug-in with specific functions.

[0063] In one implementation, after obtaining the target plug-in based on the second set of definition files so that the target plug-in provides extensibility capabilities for the component, it further includes:

[0064] Obtaining a package or version package based on the target plug-in and the component of the reusable functional unit.

[0065] In an exemplary implementation, combining the target plug-in and the component of the reusable functional unit is beneficial to supplementing the functions not covered by the component through the plug-in without modifying the code of the component, thereby facilitating generating a package or version package that meets the performance requirements based on the target plug-in and the component.

[0066] In an exemplary implementation, the method of combining the target plug-in and the component of the reusable functional unit is as follows:

[0067] Introducing the plug-in: Introducing the plug-in file into the code of the component, and the script file of the plug-in can be introduced through the import statement or by using the script tag in HTML.

[0068] Register the plugin: Depending on how the plugin is used, it may be necessary to register the plugin in the component. Some plugins may be registered automatically, while others require manual execution of the registration function.

[0069] Use the plugin functionality: Attach the functionality of the plugin to the component by calling the API or method provided by the plugin. At the appropriate time, call the method provided by the plugin to implement the corresponding functionality.

[0070] Form a new component: When the functionality of the plugin is successfully attached to the component, the component can be regarded as a new component with that functionality. The use and configuration of the plugin functionality can be controlled through the props or state of the component.

[0071] Package as a package or version package: Package the component and provide the corresponding parameters and configuration options. Tools or scripts can be used to package and release the component package or version.

[0072] In one embodiment, the first orchestration object or the second orchestration object includes: an API object, a configuration object, a script object; wherein,

[0073] For the first orchestration object: the API object includes API definition information obtained by parsing the first set of definition files, and the configuration object and the script object are both null values;

[0074] For the second orchestration object: the API object includes API definition information generated by orchestration, the configuration object includes configuration file information set by orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by orchestration.

[0075] Figure 3 It is a flowchart of a method for API plugin - plugin orchestration - plugin according to an embodiment of the present application, as Figure 3 shown,

[0076] In one embodiment, the method further includes:

[0077] S301, obtain the API plugin based on the API object;

[0078] S302, perform orchestration processing again based on the API plugin to obtain a new API plugin.

[0079] In an exemplary embodiment, the input of the API type plugin orchestration is the definition file of the component. After the plugin orchestration process and the plugin generation process, the output is the API plugin, and the API plugin contains the definition file and can be used for plugin orchestration again, that is, the API plugin orchestration can perform a "plugin - plugin orchestration - plugin" loop process.

[0080] The configuration type plugin orchestration and the script type plugin orchestration do not rely on the component definition file. Both add functions during the orchestration process. There is no input in the orchestration process, and the outputs are the configuration type plugin and the script type plugin respectively. Therefore, neither of them supports the loop process of "plugin - plugin orchestration - plugin".

[0081] In one implementation, parsing the first set of definition files to obtain a first orchestration object includes:

[0082] Performing a dependency analysis on the reusable functional units based on the first set of definition files to select the dependent components or plugins.

[0083] Figure 4 is a flowchart of a method for obtaining a first orchestration object based on a first definition file according to an embodiment of the present application, as Figure 4 shown

[0084] In one implementation, parsing the first set of definition files to obtain a first orchestration object includes:

[0085] S401, parsing the API fields, configuration fields, and script fields of the first definition file to obtain a parsing result;

[0086] S402, performing an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing result.

[0087] In an exemplary implementation, for the first definition file of a component or plugin, the detailed information of the API interface (exposed APIs) and the dependent APIs and dependent components / plugins can be identified according to the API fields. These information are the detailed descriptions of the APIs provided by the component / plugin. The parsing results of the parsed configuration fields and script fields are null values and need to be written manually.

[0088] Figure 5 is a flowchart of a method for obtaining a second orchestration object based on the first orchestration object according to an embodiment of the present application, as Figure 5 shown

[0089] In one implementation, performing an orchestration process on the first orchestration object to obtain a second orchestration object includes:

[0090] S501, in the case where the first orchestration object is an API object, obtaining a second orchestration object in response to a call operation of API parameters; wherein, the API parameters include: API protocol, request method, request path, request parameters, and response parameters;

[0091] S502. When the first orchestration object is a configuration object, in response to the editing operations of the configuration parameters and the reusable functional units on which it depends, obtain a second orchestration object;

[0092] S503. When the first orchestration object is a script object, in response to the editing operations of the script parameters and the script file name, obtain a second orchestration object.

[0093] In an exemplary embodiment, the operation of performing orchestration processing on the first orchestration object to obtain a second orchestration object can be understood as freely combining the API fields of different components / plugins of the first orchestration object according to business requirements, and writing the configuration fields of the configuration object or the script fields of the script object to form new configuration content and script content.

[0094] In one embodiment, obtaining a target plugin based on the second definition file set includes:

[0095] When the first orchestration object is an API object or a configuration object, obtain a target plugin based on the second definition file set.

[0096] In one embodiment, obtaining a target plugin based on the second definition file set includes:

[0097] When the first orchestration object is a script object, obtain a target plugin based on the second definition file set and the script parameters.

[0098] The above method is explained and illustrated with examples as follows:

[0099] Generally speaking, the method of the present invention uses three processes: an assembly process, an orchestration process of plugins, and a generation process of plugins.

[0100] The assembly process is a process of component combination. In the assembly process, the user selects components according to business requirements, and the assembly tool performs dependency analysis on the components and automatically selects the dependent components.

[0101] Both components and plugins need to provide definition files with a unified specification. The definition files have a certain fixed format and are complete information descriptions of components or plugins. The content includes basic information, component / plugin dependency relationships, topology information, resource information, business configurations, and API definitions. In the present invention, the API definition part in the definition file is mainly concerned.

[0102] The API definition completely describes the API information of a component / plugin, including the details of the APIs provided externally, the dependent APIs, and the dependent components.

[0103] Plugin orchestration process: The orchestrator imports the definition file and generates an orchestration object. The orchestration object is the visual representation of a component or plugin in the orchestrator. The user uses the interface in the orchestrator to combine the orchestration objects to complete the orchestration. The plugin orchestration process generates orchestration objects, and the generated orchestration objects include API objects, configuration objects, and script objects. The API object contains the API definition information generated by the orchestration, the configuration object contains the configuration file information set by the orchestration, and the script object describes the file address, execution engine, and running parameters of the orchestration script.

[0104] Plugin publishing process: According to the plugin orchestration output, construct the definition file, and finally publish the definition file and the plugin orchestration output to the assembly tool to become a new plugin.

[0105] The method described in the present invention uses the definition file as a resource, constructs the extension ability through the plugin orchestration process, and finally publishes the extension ability as a plugin for subsequent assembly processes to use, realizing the method for the extensibility of the application assembly process.

[0106] Figure 6 It is a schematic diagram of the framework of the implementation method for the extensibility of the assembly process according to the embodiments of the present application, as Figure 6 shown,

[0107] The complete steps for constructing the extension ability of the assembly process described in the present invention are shown in the following figure, including the following 5 steps:

[0108] Step 1: The user selects components and generates a definition file.

[0109] Figure 7 It is a schematic diagram of the framework of the assembly process according to the embodiments of the present application, as Figure 7 shown,

[0110] The user selects components in the assembly tool according to actual needs. Each component needs to provide a definition file. After the user selects the components, the assembly process will output a set of these definition files (i.e., the first definition file set).

[0111] The definition file is the description specification of components and plugins, with a fixed format. It is the complete information description of components or plugins and is also the basis for the assembly tool to identify components and plugins. The definition file content includes basic information, component / plugin dependencies (dependent), topology information (topo), resource information (resource), script information (script), business configuration (config), and API definition (api).

[0112] The API definition includes the detailed information of the APIs exposed by the component (exposed APIs), the dependent APIs and the dependent components. It is a detailed description of the APIs provided by the component. Among them, the APIs provided by the component can be various application layer protocols, such as the rest protocol, the web service protocol, and the rpc protocol, etc. The method and url fields describe the http layer method and address of an interface, the protocol describes the type of the application layer protocol of the interface, and the specification is the address of the protocol file, which is the complete definition of a group of interfaces. For the rest protocol interface, the specification is the address of the swagger file; for the web service protocol interface, the specification is the address of the wsdl file; for the rpc protocol interface, the specification is the address of the proto file.

[0113] Dependent APIs are the components and interfaces that the component depends on. Among them, the name and kind describe the dependent component or plugin, and the kind type indicates that the object is a component or a plugin. The apiName is the name of the dependent API. The meanings of the method, url, specification under dependent APIs are similar to the fields with the same names under exposed APIs, which are used to describe an API.

[0114] Steps 2 to 3: Parse the component definition to generate an orchestration object; Orchestrate the plugin by the user to generate an orchestration object.

[0115] This step is mainly responsible for the plugin orchestrator, which is the specific implementation of the plugin orchestration process. Taking the definition file output in Step 1 as the data source, parsing the specific fields of the definition file, constructing the orchestration object and presenting it in the orchestration interface. The user uses the plugin orchestrator interface for function orchestration, and the finally output is the orchestration object.

[0116] Figure 8 It is a schematic diagram of the framework of the plugin orchestration process according to the embodiment of the present application, as Figure 8 shown

[0117] The first orchestration object generated by parsing the definition file and the second orchestration object generated by plugin orchestration both comply with the definition specification of the orchestration object, and the two are equivalent. For example, if the first orchestration object generated by the definition file is "API type orchestration object A", then the second orchestration object generated by orchestration is "orchestration object B of API type", and the two have the same definition format, only the specific field values are different.

[0118] The plug-in orchestrator can orchestrate three types of objects: APIs, configurations, and scripts.

[0119] Orchestrating APIs is applicable to scenarios where additional extended functionality is added to components. For example, when a single API in an existing component cannot meet the requirements, but combining multiple APIs can meet the requirements, multiple component APIs are combined in the plug-in orchestrator and business logic is added to finally generate an API that meets the requirements. Another typical application scenario is API forwarding. The plug-in orchestration generates a new API as a proxy for the component API. During the process of forwarding requests from the new API to the component API, business functions can be orchestrated, such as adding authentication, monitoring, request filtering, and statistics. In both of the above scenarios, plug-in orchestration can be used to provide extended capabilities for existing components without invasive modification to the components, without affecting the existing functions and APIs of the components.

[0120] Orchestrating configurations is applicable when providing multi-business scenario configurations for components. When a component needs to use different configurations according to different business scenarios, multiple sets of configurations can be provided through plug-in orchestration, that is, configuration type plug-ins. When users assemble different business scenario version packages, they can select these configuration plug-ins to achieve the purpose of dynamically assembling configurations during the assembly process.

[0121] Script orchestration is applicable to scenarios where tool scripts, auxiliary functions, or sidecar capabilities (the ability to separate an application function from the application itself as a separate process) are provided for components. For example, when a version package is deployed, it is necessary to set common environment variables and file permissions for components. These functions are not something that a certain component should provide and are not related to the business. It is more suitable to use separate tool scripts to implement. The plug-in orchestrator provides a convenient method for orchestrating scripts in these scenarios without invasive modification to the components.

[0122] Before user orchestration, the plug-in orchestrator imports the definition file, parses the definition file, generates the first orchestration object, and the first orchestration object will be displayed in the orchestrator interface for users to use.

[0123] The parsing process of API type plug-ins: Import the definition file, parse the API definitions (api fields) in it. The orchestrator obtains the swagger file according to the exposed API fields, downloads and parses the swagger file to obtain the detailed information of the API, and constructs an orchestration object for each API. The orchestration object contains the definition and dependencies of this API.

[0124] The specific parsing fields are: Traverse all APIs under exposed APIs in the definition file, parse swagger to obtain the detailed information of the API, generate the api field in the component object, and take the dependent APIs field of the definition file to generate the dependent field in the component object.

[0125] The dependent field in the orchestration object describes the dependency relationship, and this field corresponds to the dependent in the definition file. For example, for an API orchestration object, the dependent describes the dependent API and the component corresponding to the dependent API. When the orchestration is completed, the dependent field in the definition file is generated based on the dependent field of the orchestration object, that is, the dependency relationship of the plugin. When the user selects a plugin during the assembly process, the assembly tool can automatically check the components on which the plugin depends according to the dependent field in the plugin definition file.

[0126] Figure 9 It is a framework schematic diagram of the parsing and orchestration process for API type plugins according to an embodiment of the present application, as Figure 9 shown

[0127] Orchestration process of API type plugins: The user selects an API in the orchestrator interface, fills in the request parameters for calling the API, and defines a new API, including the API protocol, request method, request path, request parameters, and response parameters. The output of the API type plugin orchestration is the API orchestration object.

[0128] Figure 10 It is a framework schematic diagram of the orchestration process for configuration type plugins according to an embodiment of the present application, as Figure 10 shown

[0129] Orchestration object of configuration type plugins: The initial content of the orchestration object corresponding to the configuration is empty and there is no fixed definition. The specific data is filled in by the user in the orchestrator.

[0130] Orchestration process of configuration type plugins: The user directly writes the business configuration in the orchestrator, fills in the information of the dependent components and plugins, and finally the orchestrator generates the configuration orchestration object.

[0131] Among them, the supported configuration file formats include json, xml, toml, yaml, and csv, etc.

[0132] Figure 11 It is a framework schematic diagram of the orchestration process for script type plugins according to an embodiment of the present application, as Figure 11 shown

[0133] Orchestration object of script type plugins: The initial content of the orchestration object corresponding to the script is empty and there is no fixed definition. The specific script is filled in by the user in the orchestrator.

[0134] Orchestration process of script type plugins: The user directly writes the script in the orchestrator, fills in the file name of the script, the running engine, and the running parameters. Finally, the orchestrator generates the script orchestration object.

[0135] There are no strict restrictions on the file formats and programming languages supported by the script. It only requires that the component can provide an execution engine for the corresponding format, such as shell scripts, Python scripts, JavaScript scripts, Lua scripts, etc.

[0136] Step 4: Generate a definition file.

[0137] After the orchestration is completed, generate a definition file based on the orchestration objects output by the orchestration.

[0138] During the process of generating a definition file from the orchestration objects, the basic information part is the same for the three types of orchestration objects (API, configuration, and script), which is filled in by the user during orchestration and includes the plugin name (name), description (description), version (version). The type field (kind) is automatically generated as the plugin type (plugin), and the dependent components and plugins (dependent) are generated from the dependent field (dependent) of the orchestration object.

[0139] For the API orchestration object, use the API definition field (api) of the orchestration object to generate the API definition field (api) of the definition file. Since it is an API orchestration object and does not involve the orchestration of configuration type and script type, the configuration field (config) and script field (script) are null values.

[0140] For the configuration orchestration object, use the configuration field (config) of the orchestration object to generate the configuration field (config) of the definition file. Since it is a configuration type orchestration object and does not involve the orchestration of API type and script type, the API definition field (api) and script field (script) are null values.

[0141] For the script orchestration object, use the script field (script) of the orchestration object to generate the script field (script) of the definition file. Since it is a script type orchestration object and does not involve the orchestration of API type and configuration type, the API definition field (api) and configuration field (config) are null values.

[0142] Step 5: Publish the plugin.

[0143] Package and publish the plugin definition file generated in Step 4 and the orchestration output file to the assembly tool to become a plugin.

[0144] For the plugins of API type and configuration type, in addition to the definition file, there is no additional orchestration output file. For the script type plugin, in addition to the definition file, there is also the script written by the user in the orchestration output file.

[0145] The above three types of arrangements will generate definition files. As the common definition specification for components and plugins, the definition files contain complete information about the components. Based on the definition files, the arrangement output can be published as plugins.

[0146] The plugin provides a definition file, which can be used in the component assembly and arrangement process in the same way as components. Repeating steps 1 to 5 can form a cyclic process of "component / plugin - assembly - arrangement - publish plugin". Each cycle generates new APIs, configurations, and scripts based on existing components and plugins, providing an extension ability for the assembly process. When the functions or configurations of existing components / plugins cannot meet the requirements, the above process can be used to build the extension ability.

[0147] Figure 12 It is a schematic diagram of the framework for the accumulation of extension ability according to the embodiments of the present application. As Figure 12 shown,

[0148] In the first cycle process, the user selects components A and B, and arranges plugin X according to steps 1 to 5. When arranging for the second time, select components C and plugin X, and arrange plugin Y. Subsequently, assembly that meets the user's needs can still be performed based on components A, B, C and plugins X, Y.

[0149] In an exemplary implementation, when assembling a user management system of a certain company, it is found that the old version of the client uses a web service interface, and the new version of the client uses a rest interface. The old version of the server provides a web service interface, and the new version of the server provides a rest interface. Now it is necessary to take the old version of the server offline, but it is not possible to ensure that all clients are updated to the new version in a short time. Therefore, a compatibility layer is required, that is, the client uses the web service interface to send requests to the server rest interface, and the compatibility layer is responsible for protocol conversion. This requirement can be met by using the present invention in the assembly process. The plugin arrangement process provides a function to forward the web service interface to the rest interface so that the old version of the client can continue to be used, and the old version of the server can be taken offline. The entire assembly process does not require modifying the component code.

[0150] Figure 13 It is a schematic diagram of the framework for information interaction between the client, script, and server according to the embodiments of the present application. As Figure 13 shown,

[0151] The above-mentioned component server is divided into two components, and each service provides an interface: Component A provides the GET / user / :id interface to query the basic information of the user. Component B provides the GET / role / :id interface to query the user role.

[0152] Step 1: The user selects components to generate a definition file.

[0153] Select two components, A and B, in the assembly tool, and merge the component definitions during the assembly process.

[0154] The name of component A is user-manager (name), the type (kind) is component type (component), the version is v1 (version), it provides the user-info interface (GET / user / :id), and depends on component x (dependent).

[0155] The name of component B is role-manager (name), the type is component type (kind), the version is v1 (version), it provides the role-info interface (GET / user / :id), and depends on component y (dependent).

[0156] Obtain two swagger files, user-info-swagger.json and role-info-swagger.json, from the two definition files respectively.

[0157] The swagger.json file describes the interface name, protocol, input parameter structure, and output parameter structure.

[0158] Step 2: Parse the component definitions to generate an orchestration object; after step 1, import the definition files of the two components into the plugin orchestrator. The plugin orchestrator reads the definition files to generate an orchestration object. Each API corresponds to an orchestration object, which is displayed on the orchestrator interface.

[0159] Step 3: User orchestration to generate an orchestration output.

[0160] Figure 14 It is a framework schematic diagram of the selected API and the generated API during the conversion between the web service protocol and the rest protocol according to the embodiments of the present application, as Figure 14 shown

[0161] The user selects the above two interfaces in the orchestrator for invocation, provides the web service protocol interface, and the web service protocol and rest protocol conversion function to provide a new web service interface definition.

[0162] After the orchestration is completed, the orchestrator generates an orchestration object.

[0163] The orchestrated API provides the web service protocol. When a web service request is received, it will convert the request into a rest request, call the corresponding interface, and then return.

[0164] Step 4: Generate the definition file.

[0165] Based on the orchestration objects output in Step 3, the plugin release process constructs the definition file.

[0166] The basic information of the definition file is filled in by the user during orchestration, including the plugin name, description, version. The configuration field (config) and script field (script) are empty, and the type field is automatically generated as the plugin type (plugin). The dependent components and plugins (dependent) are generated from the dependent field of the orchestration object. It depends on two components, user-manager and role-manager. Since these two components depend on component x and component y respectively, the web service-api plugin also needs to depend on components x and y. The API definition field (api) in the definition file is generated from the orchestration object.

[0167] Step 5: Release the plugin. Package and release the plugin definition file generated in Step 4 and the orchestration output file to the assembly tool to become a plugin.

[0168] In the subsequent assembly process, Component A, Component B, and this plugin can be used to provide the interface compatibility function from the web service client to the rest server. The code of Component A and B does not need to be modified throughout the process.

[0169] Summary: This embodiment demonstrates the use of assembly, orchestration, and plugin release to achieve the extended function of interface protocol conversion without modifying the code of the original components.

[0170] In another exemplary embodiment, when assembling the components of a company's assessment system, the user needs to provide different error code configurations according to different scenarios. The error codes are packaged together with the code and are not easy to modify. By using the method of the present invention, multiple error code configurations can be orchestrated during the assembly process to meet the requirements.

[0171] The assessment system mainly consists of two components, namely Component A and Component B.

[0172] Step 1: The user selects components and generates the definition file.

[0173] Since the configuration orchestration does not require the component definition file as input, the configuration orchestration does not need to select components, and Step 1 is not required for the configuration type of plugin orchestration.

[0174] Step 2: Parse the component definition and generate the orchestration object.

[0175] The configuration orchestration does not rely on the component definition file, but directly generates the orchestration object with default values by the orchestrator. Among them, Step 2 is not required for the configuration type of plugin orchestration.

[0176] Step 3: The user arranges components to generate arranged output.

[0177] The user directly edits the service configuration in the orchestrator and writes the service configuration data into a configuration file named business - scene - a.yaml. The configured data format only needs to satisfy the key - value pair, and the orchestrator has no additional requirements for the configuration format. After generating the configuration plugin, it only needs to be recognized by the components used in the configuration.

[0178] Step 4: Generate a definition file.

[0179] The plugin publishing process constructs a definition file based on the arranged object output in Step 3.

[0180] The basic information of the definition file is filled in by the user during orchestration, including the plugin name, description, version. The API field (api) and script field (script) are empty, and the type field is automatically generated as the plugin type (plugin). The dependent components and plugins (dependent) are generated from the dependent field of the arranged object. The dependencies are filled in by the user during orchestration and depend on the component user - score - manager. The config field in the definition file is generated from the config field of the arranged object.

[0181] Step 5: Publish the plugin.

[0182] Package and publish the plugin definition file generated in Step 4 and the arranged output file to the assembly tool to become a plugin. The plugin provides the configuration under scenario A (sceneA). Similarly, plugins for configurations in other scenarios can be generated based on components A and B. In the subsequent assembly process, by selecting components A and B and combining different configuration plugins, the function of dynamically selecting configurations during the assembly process of the assessment system is achieved without invading the existing component code.

[0183] Summary: This implementation example demonstrates the use of assembly, orchestration, and plugin publishing to achieve the configuration plug - in function without modifying the original component code, providing an extended ability to dynamically switch configurations for existing components.

[0184] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software adding the necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to enable a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present application.

[0185] In this embodiment, an implementation device for the scalability of the assembly process is further provided. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0186] Figure 15 is a schematic structural diagram of an implementation device for the scalability of the assembly process according to an embodiment of the present application. As Figure 15 shown, the device includes:

[0187] An assembly module 151, configured to select reusable function units and obtain a first set of definition files based on the reusable function units;

[0188] A plug-in orchestration module 152, configured to parse the first set of definition files to obtain a first orchestration object; and,

[0189] perform an orchestration process on the first orchestration object to obtain a second orchestration object;

[0190] A plug-in generation module 153, configured to obtain a second set of definition files based on the second orchestration object; and,

[0191] used to obtain a target plug-in based on the second set of definition files, so that the target plug-in provides scalability capabilities for components.

[0192] Among them, the difference between the first orchestration object and the second orchestration object lies in the different values of the fields.

[0193] Further, the reusable function units include at least one of the following: components, plug-ins.

[0194] Further, the device is further configured to: before selecting reusable function units and obtaining a first set of definition files based on the reusable function units, further include:

[0195] A plug-in that takes the target plug-in as a reusable functional unit.

[0196] Further, the device is also used for: obtaining a target plug-in based on a second set of definition files, so that after the target plug-in provides extensibility capabilities for components, it further includes:

[0197] Obtaining a package or version package based on the target plug-in and the components of the reusable functional unit.

[0198] Further, the device is also used for: the first orchestration object or the second orchestration object includes: API object, configuration object, script object; where

[0199] For the first orchestration object: the API object includes API definition information obtained by parsing the first set of definition files, and the configuration object and the script object are both null values;

[0200] For the second orchestration object: the API object includes API definition information generated by orchestration, the configuration object includes configuration file information set by orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by orchestration.

[0201] Further, the device is also used for: obtaining an API plug-in based on the API object;

[0202] Performing orchestration processing on the API plug-in again to obtain a new API plug-in.

[0203] Further, the device is also used for: parsing the first set of definition files to obtain a first orchestration object, including:

[0204] Performing dependency analysis on the reusable functional unit based on the first set of definition files to select dependent components or plug-ins.

[0205] Further, the device is also used for: parsing the first set of definition files to obtain a first orchestration object, including:

[0206] Parsing the API field, configuration field, and script field of the first definition file to obtain a parsing result;

[0207] Performing an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing result.

[0208] Further, the device is also used for: performing orchestration processing on the first orchestration object to obtain a second orchestration object, including:

[0209] In the case where the first orchestration object is an API object, in response to a call operation of API parameters, obtaining a second orchestration object; where the API parameters include: API protocol, request method, request path, request parameters, and response parameters;

[0210] When the first orchestration object is a configuration object, in response to the editing operations of configuration parameters and dependent reusable functional units, a second orchestration object is obtained.

[0211] When the first orchestration object is a script object, in response to the editing operations of script parameters and script file names, a second orchestration object is obtained.

[0212] Further, the apparatus is further configured to: obtain a target plug-in based on a second definition file set, including:

[0213] When the first orchestration object is an API object or a configuration object, obtain a target plug-in based on the second definition file set.

[0214] Further, the apparatus is further configured to: obtain a target plug-in based on a second definition file set, including:

[0215] When the first orchestration object is a script object, obtain a target plug-in based on the second definition file set and script parameters.

[0216] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above-mentioned modules are all located in the same processor; or, the above-mentioned various modules are separately located in different processors in any combination form.

[0217] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, and the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0218] In an exemplary embodiment, the above-mentioned computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical disks that can store computer programs.

[0219] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0220] In an exemplary embodiment, the above-mentioned electronic device may further include a transmission device and an input / output device, where the transmission device is connected to the above-mentioned processor, and the input / output device is connected to the above-mentioned processor.

[0221] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary embodiments, and details thereof will not be repeated here.

[0222] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a sequence different from that here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present application is not limited to any specific combination of hardware and software.

[0223] The above are only the preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included within the protection scope of the present application.

Claims

1. A method for implementing the scalability of an assembly process, characterized in that Including: Select reusable functional units and obtain a first set of definition files based on the reusable functional units; Parse the first set of definition files to obtain a first orchestration object; Perform an orchestration process on the first orchestration object to obtain a second orchestration object; Obtain a second set of definition files based on the second orchestration object; Obtain a target plugin based on the second set of definition files, so that the target plugin provides extensibility capabilities for components.

2. The method according to claim 1, wherein The reusable functional units include at least one of the following: components, plugins.

3. The method according to claim 2, wherein Before selecting reusable functional units and obtaining a first set of definition files based on the reusable functional units, it further includes: Regarding the target plugin as the plugin of the reusable functional unit.

4. The method according to claim 2, wherein After obtaining a target plugin based on the second set of definition files, so that the target plugin provides extensibility capabilities for components, it further includes: Obtain a package or version package based on the target plugin and the components of the reusable functional unit.

5. The method according to claim 1, characterized in that, The first orchestration object or the second orchestration object includes: API object, configuration object, script object; where For the first orchestration object: the API object includes API definition information parsed from the first set of definition files, and the configuration object and script object are both null values; For the second orchestration object: the API object includes API definition information generated by orchestration, the configuration object includes configuration file information set by orchestration, and the script object includes the file address, execution engine, and running parameters of the script set by orchestration.

6. The method according to claim 5, characterized in that, It also includes: Obtain an API plugin based on the API object; Perform an orchestration process again based on the API plugin to obtain a new API plugin.

7. The method according to claim 1, wherein Parsing the first set of definition files to obtain a first orchestration object includes: Perform a dependency analysis on the reusable functional units based on the first set of definition files to select the dependent components or plugins.

8. The method according to claim 1, wherein Parsing the first set of definition files to obtain a first orchestration object includes: Parse the API fields, configuration fields, and script fields of the first set of definition files to obtain a parsing result; Perform an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing result.

9. The method according to claim 8, wherein Performing an orchestration operation on the first orchestration object as an API object or a configuration object or a script object based on the parsing result includes: In the case where the first orchestration object is an API object, in response to a call operation of API parameters, obtain the second orchestration object; where the API parameters include: API protocol, request method, request path, request parameters, and response parameters; In the case where the first orchestration object is a configuration object, in response to an edit operation of configuration parameters and the dependent reusable functional units, obtain the second orchestration object; In the case where the first orchestration object is a script object, in response to an edit operation of script parameters and the script file name, obtain the second orchestration object.

10. The method according to claim 9, wherein Obtaining a target plugin based on the second set of definition files includes: In the case where the first orchestration object is an API object or a configuration object, a target plugin is obtained based on the second definition file set.

11. The method according to claim 9, wherein Obtaining a target plugin based on the second definition file set includes: In the case where the first orchestration object is a script object, a target plugin is obtained based on the second definition file set and the script parameters.

12. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein when the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 11 are implemented.

13. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method described in any one of claims 1 to 11 are implemented.

Images