Methods for storing and updating metadata, devices, and equipment

Abstract

This invention discloses a method, method, apparatus, and device for storing and updating metadata, relating to the field of cloud computing technology. A Software as a Service (SaaS) application server stores metadata model data. Using this metadata model data, the SaaS application server converts the received metadata of a first application into structured data, extracts the relationships between different metadata instances within the first application's metadata, forms instance data, and stores this instance data in a structured manner. In this way, by extracting the relationships between different metadata instances, the SaaS application server can obtain the relationships between application metadata instances, facilitating the analysis of the impact of multi-tenant application development and upgrades, ensuring backward compatibility of new application versions, and improving the reliability and stability of multi-tenant applications.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus, and device for storing and updating metadata. Background Technology

[0002] Metadata-driven multi-tenant applications refer to applications where tenants utilize metadata during development to create user interfaces, application programming interfaces (APIs), services, entities, processes, rules, application configurations, and user permissions. They then modify or add metadata to alter the application's business logic and behavior. Using a metadata-driven multi-tenant application architecture, different tenants can customize different applications based on the same set of common application procedures. This allows applications from different tenants to share platform infrastructure, resources, and application logic, while maintaining isolation between their applications.

[0003] In a metadata-driven multi-tenant application architecture, the application's metadata typically includes standard application metadata and tenant-customized metadata. The current method of storing application metadata makes it difficult to assess the impact of version upgrades on general functions and tenant-customized functions, and it is difficult to guarantee backward compatibility with new versions. Summary of the Invention

[0004] This application provides a method, method, apparatus, and device for storing and updating metadata. By structurally storing metadata and instances of relationships between metadata, it reduces the difficulty of version upgrades affecting general functions and tenant-customized functions, and ensures backward compatibility with new versions.

[0005] Firstly, this application provides a method for storing metadata, applied to a Software as a Service (SaaS) application server storing metadata model data. During the metadata storage process, the SaaS application server utilizes the metadata model data to convert the received metadata of a first application into structured data, extracts the relationships between different metadata instances in the first application's metadata to form instance data, and stores the instance data in a structured manner. The instance data is used to analyze the impact of updates to general functions in the first application on custom functions within the first application.

[0006] Compared to the metadata storage methods in related technologies, the method provided in the first aspect extracts relevant data from metadata and stores it in a structured manner. This facilitates metadata retrieval for SaaS application servers. Furthermore, by extracting the relationships between different metadata instances, the SaaS application server can obtain the relationships between application metadata instances, facilitating the analysis of the impact of multi-tenant application development and upgrades. This reduces the difficulty of assessing the impact of version upgrades on general functions and tenant-customized functions, ensures backward compatibility of new application versions, and improves the reliability and stability of multi-tenant applications.

[0007] In one alternative implementation, the association between different metadata instances includes multiple instance relationship data, with different instance relationship data corresponding to different associations.

[0008] Optionally, each instance relationship data in the multiple instance relationship data includes: instance relationship identifier, first instance identifier, second instance identifier, and class relationship identifier.

[0009] The first instance identifier is the instance identifier of the first metadata instance that initiated the association in the metadata, and the second instance identifier is the instance identifier of the second metadata instance that is associated with the first metadata instance.

[0010] Optionally, the second metadata instance may include a general metadata instance pre-set by the SaaS application server or a custom metadata instance uploaded by the user.

[0011] Based on this optional implementation method, the SaaS application server records the source metadata instance and target source data instance in each relationship in the instance relationship data storage, forming a multi-level metadata relationship of the first application. This allows the impact on the metadata instance to be assessed when the first application is governed or its general functions are upgraded. This ensures backward compatibility of the new version of the application and improves the reliability and stability of the multi-tenant application.

[0012] In one optional implementation, the instance data is stored in a structured manner, including: forming a metadata data table based on the instance data, and storing the metadata data table. This metadata data table is used to structure the relationships between different metadata instances across multiple metadata instances.

[0013] Based on this optional implementation, the SaaS application server stores instance data in a structured manner according to the data content defined in the metamodel and the data format of the metadata tables, converting unstructured metadata into structured metadata. This facilitates the retrieval of metadata instances and the analysis of their relationships, thereby providing a data foundation for subsequent metadata relationship analysis.

[0014] In one optional implementation, the instance data also includes multiple metadata instance data sets. The metadata data table is further used to structure and store multiple metadata instances. Different metadata instance data sets correspond to different metadata types.

[0015] Optionally, each metadata instance in the multiple metadata instance data includes: instance identifier, instance name, class code, application identifier, and tenant identifier. The class code indicates the code for the corresponding metadata type.

[0016] Based on this optional implementation method, when storing metadata instance data, the SaaS application server stores not only the identifier and name of the metadata instance, but also the metadata instance, the class code of the metadata type corresponding to the metadata instance, the tenant identifier, and the application identifier. It establishes the association between the metadata instance and the class code of the corresponding metadata type, the tenant identifier, and the application identifier, so that the SaaS application server can quickly determine the data format followed by the metadata instance, the functions implemented, the application to which it belongs, and the corresponding tenant based on the metadata instance data in the instance table, thereby realizing the governance of applications of different tenants.

[0017] In one alternative implementation, the instance data also includes multiple instance attribute data. The metadata data table is also used to structure and store these multiple instance attribute data.

[0018] Different instance attribute data correspond to different instance attributes, and each metadata instance data corresponds to one or more instance attribute data.

[0019] Optionally, each instance attribute data includes: instance identifier, instance attribute identifier, class attribute identifier, and the value of the instance attribute.

[0020] Based on this optional implementation, when storing instance attribute data of metadata instances, the SaaS application server stores not only the identifier and name of the instance attributes of the metadata instance, but also the identifier of the class attribute corresponding to the instance attribute of the metadata instance, as well as the instance identifier of the metadata instance itself. This establishes a relationship between metadata instance, instance attribute, and class attribute identifier. This allows the SaaS application server to quickly locate the data format followed by the instance attribute and the functionality implemented, based on the instance attributes of the metadata instance.

[0021] In one optional implementation, the metadata data tables include: an instance table, an attribute table, and a relationship table. Specifically: the instance table stores data for multiple metadata instances; the attribute table stores instance attribute data for each metadata instance; and the relationship table stores instance relationship data for the multiple metadata instances. Optionally, the instance table is associated with both the attribute table and the relationship table.

[0022] Based on this optional implementation, the SaaS application server uses instance tables, attribute tables, and relationship tables to store metadata instance data, instance attribute data, and instance relationship data between metadata instances, respectively. This facilitates subsequent hierarchical relationship analysis and metadata instance retrieval when there are a large number of metadata instances or when each metadata instance has many attributes.

[0023] In one optional implementation, the metadata is parsed based on the meta-model data table to extract instance data. Specifically, the SaaS application server uses the data from the meta-model to form a configuration table corresponding to the first application. The SaaS application server then extracts instance data from the metadata according to the parsing logic indicated by the configuration table.

[0024] Optionally, the configuration table is used to indicate the metadata parsing logic. The parsing logic indicates the location of metadata instances, their attributes, or relationships within the metadata.

[0025] Optionally, each association corresponds to a metadata type group, which includes the source metadata type and the target metadata type that are associated. The source metadata type indicates the metadata type that initiated the association, and the target metadata type is the metadata type that is associated.

[0026] Based on this optional implementation method, the SaaS application server uses configuration tables to guide the parsing of metadata, which improves the parsing efficiency while ensuring the parsing accuracy of metadata.

[0027] In one optional implementation, the configuration table includes multiple relationship data, each relationship data corresponding to a relationship class code. The relationship class code includes the class code of the metadata type that initiates the relationship or the class code of the metadata type that is being associated within the same relationship.

[0028] Optionally, each of the multiple relational data includes: a relational mapping identifier, a relational mapping value, a relational class identifier, and a mapping direction.

[0029] The relationship mapping value indicates the parsing logic for the relationship corresponding to each piece of related data. The direction of the mapping relationship includes initiating a relationship or being associated.

[0030] Based on this optional implementation method, the SaaS application server records the association relationships between different metadata in the configuration table and provides different parsing logic for the association relationships. In this way, the SaaS application server can quickly parse the association relationships between different metadata instances in the metadata based on the configuration table, thereby improving the parsing efficiency of the metadata.

[0031] In one alternative implementation, the configuration table also includes multiple mapping data, each corresponding to a different mapping object, which may include class code, attribute code, or relationship code.

[0032] Optionally, each of the multiple mapping data includes: mapping object type, mapping object, and parsing logic for the mapping object.

[0033] The types of mapped objects include: metadata types, attributes, or relationships.

[0034] Based on this optional implementation, the SaaS application server utilizes class data, class attribute data, and class relationship data of different metadata types in the metamodel to form parsing logic for different mapping objects. Then, the SaaS application server establishes the relationship between the parsing logic of different mapping objects and the code of the mapping objects, forming a configuration table. In this way, the SaaS application server can quickly extract the data corresponding to different mapping objects from the metadata based on the parsing logic of the mapping objects in the first configuration table, improving the efficiency of metadata parsing. Furthermore, using the mapping objects in the configuration table ensures the accuracy of the parsed data.

[0035] In one optional implementation, the configuration table includes a first configuration table and a second configuration table. The first configuration table provides multiple mapping data, and the second configuration table provides multiple association data.

[0036] In this way, the SaaS application server uses the first configuration table and the second configuration table to allocate the parsing logic for classes, attributes, and relationships that provide metadata, as well as the specific parsing logic for association relationships, to achieve fast parsing of metadata.

[0037] In one optional implementation, the SaaS application server extracts instance data from the metadata according to the parsing logic indicated by the configuration table. Specifically, this includes: the SaaS application server extracting metadata instance data of multiple metadata instances, instance attribute data of each metadata instance, and the association relationships among the multiple metadata instances, according to the parsing logic indicated by the first configuration table. The SaaS application server then extracts instance relationship data of the association relationships from the metadata based on the association relationships and the parsing logic indicated by the second configuration table; the relationship data includes the metadata instance that initiated the association and the associated metadata instance. Finally, the SaaS application server forms instance data based on the multiple metadata instance data, the instance attribute data of each metadata instance, and the instance relationship data of the association relationships.

[0038] Based on this optional implementation method, the SaaS application server uses configuration tables (such as the first configuration table and the second configuration table) to guide the parsing of metadata, thereby improving the parsing efficiency while ensuring the parsing accuracy of metadata.

[0039] In one optional implementation, multiple class-relationship data records are used to record the association relationships between different metadata types within various metadata types. Different class-relationship data correspond to different association relationships; each association relationship corresponds to a metadata type group; the metadata type group includes the source metadata type and the target metadata type that are associated, where the source metadata type indicates the metadata type that initiated the association, and the target metadata type is the metadata type being associated.

[0040] Optionally, each class-relation data in the multiple class-relation data includes: class-relation identifier, relation code, relation name, relation type, relation scope, and metadata type code.

[0041] The relationship type includes dependency relationships or composition relationships. The relationship scope indicates the respective types of the source metadata type and the target metadata type in the first metadata type group. Types include general metadata types or custom metadata types; the first metadata type group is the metadata type group corresponding to each class relationship data. The metadata type code includes the class code of the source metadata type and the class code of the target metadata type in the corresponding metadata type group.

[0042] Based on this optional implementation method, the SaaS application server can record the association between different metadata types through class relation data. This allows it to extract the association between different metadata instances from the metadata based on various class relation data. As a result, the SaaS application server can assess the impact of version upgrades on general functions and tenant-customized functions during application updates or general function updates, ensuring backward compatibility of new version applications and improving the reliability and stability of multi-tenant applications.

[0043] In one alternative implementation, the metamodel data also includes multiple class data. Different class data correspond to different metadata types.

[0044] Optionally, any one of the multiple class data types in the first class includes: metamodel identifier, class identifier, class name, and class code.

[0045] The metamodel identifier indicates the metamodel corresponding to the first metadata type; the metamodel is used to construct the metadata corresponding to the first metadata type; the first metadata type is the metadata type corresponding to the first type of data among multiple metadata types. The class identifier indicates the first metadata type, and the class name indicates the name of the first metadata type. The class code indicates the code of the first metadata type.

[0046] Based on this optional implementation, the SaaS application server stores class identifiers, class codes, and class names of different metadata types, so that the SaaS application server can display the internal structure of different applications in a structured way, which facilitates the retrieval of metadata types.

[0047] In one alternative implementation, the metamodel data also includes multiple class attribute data. Different class attribute data correspond to different attributes, and each metadata type corresponds to at least one class attribute data.

[0048] Optionally, each class attribute data in the multiple class attribute data includes: class identifier, class attribute identifier, attribute code, and attribute name.

[0049] Based on this optional implementation method, the SaaS application server stores attributes of different metadata types and associates the class attribute identifier of different attributes with the class identifier of the metadata type to which the attribute belongs, thus establishing a relationship between metadata types and attributes of metadata types, which facilitates the retrieval of attributes of different metadata types by the SaaS application server.

[0050] In one optional implementation, class data for multiple metadata types is stored in a metadata type table. Class attribute data for each metadata type is stored in an attribute table for that metadata type. Associations between different metadata types are stored in an association table between metadata types.

[0051] The metadata type table is associated with both the attribute table of the metadata type and the association table between metadata types.

[0052] In this way, the SaaS application server stores class data, class attribute data, and class relationship data in different tables, which facilitates the retrieval and viewing of data in the metamodel.

[0053] In one optional implementation, before receiving the metadata from the first application, the SaaS application server forms multiple meta-models based on the meta-meta-model. Based on these multiple meta-models, the SaaS application server creates multiple metadata types, attributes for each metadata type, and relationships between different metadata types. Based on these metadata types, the attributes for each metadata type, and the relationships between different metadata types, the SaaS application server creates the data for the meta-models.

[0054] Among them, meta-meta-model is used to describe the rules of different meta-models, and meta-model is used to describe the rules of different metadata types.

[0055] Based on this optional implementation, the SaaS application server does not use a fixed structure to define metadata types. Instead, it uses a meta-meta-model to define meta-models for different metadata types. These defined meta-models are used to obtain class data, class attribute data, and class relationship data for different metadata types. Because the meta-model is extensible, metadata types can be modified simply by changing the meta-model, thus reducing the complexity of metadata type modification. Furthermore, the meta-model definition defines class relationship data between different metadata types, allowing the SaaS application server to use this class relationship data to represent the application's internal structure, facilitating subsequent metadata updates and storage.

[0056] In one optional implementation, after storing instance data in a structured manner, the SaaS application server receives the metadata of a first general function and, based on the instance data, retrieves a first custom metadata instance that is associated with the metadata of the first general function from among multiple metadata instances. If the first custom metadata instance is compatible with the metadata of the first general function, the SaaS application server updates the first general function in the first application based on the metadata of the first general function. If the first custom metadata instance is incompatible with the metadata of the first general function, the SaaS application server modifies the metadata of the first general function and updates the first general function in the first application based on the modified metadata.

[0057] Optionally, the modified metadata is compatible with the first custom metadata instance.

[0058] Optionally, the first general function is a general function to be updated in the first application.

[0059] Based on this optional implementation method, compatibility testing before version release can identify the impact of current modifications on tenant customization functions, intercept incompatible behaviors in real time, and ensure application reliability.

[0060] Secondly, this application provides a method for updating metadata. This method is applied to a SaaS application server that stores instance data for different tenants. During the metadata update process, the SaaS application server receives metadata for a first general function, performs compatibility checks on the metadata of the first general function based on multiple instance data, and obtains the compatibility check results. Based on the compatibility check results and the metadata of the first general function, the SaaS application server updates the first application to obtain the second application.

[0061] Optionally, the first general function is the general function to be updated in the first application; the applications of different tenants are the first applications with added custom functions. The applications of different tenants correspond to different custom functions.

[0062] Optionally, the first application can be any application provided by the SaaS application server. For example, the first application can be the first application in the first aspect described above or any of the optional implementations of the first aspect. Alternatively, for example, the first application can also be an application other than the first application described above.

[0063] Based on the second aspect, compatibility testing before version release can identify the impact of current modifications on tenant customization functions, intercept incompatible behaviors in real time, and ensure application reliability.

[0064] In one optional implementation, the compatibility test result includes: the first custom metadata instance is compatible with the metadata of the first general function. Here, the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has an association with the metadata of the first general function.

[0065] Alternatively, the compatibility test results may include: the first custom metadata instance is incompatible with the metadata of the first general function.

[0066] Based on this optional implementation method, the impact of metadata changes of general functions on the functions corresponding to the first custom metadata instance is determined by using compatibility detection results, thereby intercepting incompatible behaviors and ensuring the reliability of the application.

[0067] In one optional implementation, the first application is updated based on the compatibility test results and the metadata of the first general function. Specifically, if the compatibility test results indicate that the first custom metadata instance is compatible with the metadata of the first general function, the SaaS application server updates the first application based on the metadata of the first general function. If the compatibility test results indicate that the first custom metadata instance is incompatible with the metadata of the first general function, the SaaS application server modifies the metadata of the first general function and updates the first application based on the modified metadata of the first general function. The modified metadata of the first general function is compatible with the first custom metadata instance.

[0068] Based on this optional implementation, the SaaS application server can intercept incompatible behaviors in real time and ensure that the metadata of the first general function is compatible with the first custom metadata instance by modifying the metadata of the first general function.

[0069] In one optional implementation, compatibility testing is performed on the metadata of the first general function based on multiple instance data to obtain compatibility test results. Specifically, this includes: determining whether the operation of the first custom metadata instance is normal based on the operation of the SaaS application server on the metadata of the first general function. The first custom metadata instance refers to a custom metadata instance in the instance data of different tenants that has a relationship with the metadata of the first general function.

[0070] If the operation of the first custom metadata instance is normal, the SaaS application server determines that the compatibility test result indicates that the first custom metadata instance is compatible with the metadata of the first general function. If the operation of the first custom metadata instance is abnormal, the SaaS application server determines that the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function.

[0071] Based on this optional implementation method, the SaaS application server uses relational analysis to perform multi-level compatibility testing on the metadata of the first general function, thus ensuring the stability of the updated first application.

[0072] In one optional implementation, the method specifically includes: after performing compatibility testing on the metadata of the first general function based on multiple instance data, and obtaining the compatibility test results, if the compatibility test results indicate that the first custom metadata instance is incompatible with the metadata of the first general function, the SaaS application server adds a first tag to the metadata of the first general function. Here, the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has an association relationship with the metadata of the first general function.

[0073] In this way, the SaaS application server can use the metadata of incompatible common functions to enable batch modification of the metadata of common functions, shorten the time for modifying the metadata of common functions, and improve the update efficiency of the primary application.

[0074] In one alternative implementation, the SaaS application server obtains a metadata package. If the metadata package contains first metadata, the first metadata is modified, and the first application is updated based on the modified first metadata and the second metadata in the metadata package.

[0075] The first metadata is the metadata carried by the first tag in the data packet, and the second metadata is the metadata that does not carry the first tag in the data packet. The first metadata includes the metadata of the first general function.

[0076] The metadata data package includes metadata for multiple general functions, and the metadata for the multiple general functions includes metadata for the first general function.

[0077] Based on this optional implementation, the SaaS application server, through compatibility analysis, can identify the impact of changes in metadata for common functions on tenant-customized functions before a new version is released, and intercept incompatible behaviors in real time, ensuring application reliability. Furthermore, by marking incompatible metadata for common functions, it enables batch modification of metadata for common functions, shortening the time required to modify metadata for common functions and improving the update efficiency of the primary application.

[0078] In one alternative implementation, after receiving the metadata of the first general function, if the metadata of the first general function meets the compatibility development specifications, the SaaS application server updates the first application based on the metadata of the first general function. If the metadata of the first general function does not meet the compatibility development specifications, the SaaS application server performs a compatibility test on the metadata of the first general function based on data from multiple instances to obtain the compatibility test result.

[0079] Based on this optional implementation method, the SaaS application server combines compatibility development specification detection and correlation analysis to perform multi-level compatibility testing on the metadata of the first general function, thus ensuring the stability of the updated first application.

[0080] In one alternative implementation, after updating the first application, the SaaS application server responds to the first tenant's update request and performs compatibility testing on the second application based on the first tenant's instance data. If the second application passes the compatibility test, the SaaS application server publishes the third application to the first tenant's tenant environment.

[0081] The third application is a second application with added custom functionality from the first tenant. The update request is used to request updates to the first tenant's application.

[0082] Based on this optional implementation method, after the SaaS application server releases a new version of the first application, it tests whether the tenant's custom functions are compatible with the general functions of the new version of the first application. This ensures that after the updated first application is released, the tenant's application can be smoothly upgraded to the new version of the first application, thus ensuring the stable operation of the tenant's application.

[0083] In one optional implementation, compatibility testing of the second application is performed based on the instance data of the first tenant. Specifically, the SaaS application server, based on the instance data of the first tenant, identifies a second custom metadata instance among multiple metadata instances of the first tenant that is incompatible with the general metadata of the second application. The SaaS application server outputs the second custom metadata instance so that the first tenant can modify it. The SaaS application server receives the modified second custom metadata instance, and if the modified second custom metadata instance is compatible with the general metadata, the SaaS application server determines that the compatibility test of the second application has passed.

[0084] Based on this optional implementation method, during the testing phase, the SaaS application server uses instance relationship data to perform multi-level relationship analysis, determine the impact of application version updates on tenants' custom metadata instances, and modify incompatible custom metadata instances to ensure smooth upgrades of tenants' applications.

[0085] In one optional implementation, updating the first application specifically includes: the SaaS application server obtaining multiple first metadata instances that depend on the metadata of the first general function from the multiple instance data. The SaaS application server then modifies each of the multiple first metadata instances based on the metadata of the first general function. Finally, the SaaS application server updates the first application based on each modified first metadata instance and second metadata instances from the multiple instance data.

[0086] The second metadata instance is a metadata instance that does not depend on the first general function among multiple instance data.

[0087] In this way, it is ensured that after the metadata of the first general function is modified, the metadata instance associated with the metadata of the first general function can be modified synchronously, thereby ensuring that the new version of the first application can run normally after the first general function is updated.

[0088] Thirdly, this application provides a metadata storage device, which includes a storage module, a communication module, and a processing module. The storage module stores metadata of a metamodel, including the relationships between different metadata types. The communication module receives metadata from a first application. The processing module parses the metadata based on the metamodel data, extracts instance data from the metadata, and stores the instance data in a structured manner. The instance data includes the relationships between different metadata instances among multiple metadata instances in the metadata.

[0089] In one optional implementation, the association between different metadata instances includes multiple instance relationship data, with different instance relationship data corresponding to different association relationships. Optionally, each instance relationship data includes: an instance relationship identifier, a first instance identifier, a second instance identifier, and a class relationship identifier. The first instance identifier is the instance identifier of the first metadata instance that initiated the association, and the second instance identifier is the instance identifier of the second metadata instance associated with the first metadata instance. Optionally, the second metadata instance includes a default generic metadata instance of the SaaS application server or a user-uploaded custom metadata instance.

[0090] In one optional implementation, the processing module is specifically used to: form a metadata data table based on instance data, and store the metadata data table. This metadata data table is used to structure and store the relationships between different metadata instances across multiple metadata instances.

[0091] In one optional implementation, the instance data also includes multiple metadata instance data sets. The metadata data table is further used to structure and store multiple metadata instances. Different metadata instance data sets correspond to different metadata types.

[0092] Optionally, each metadata instance in the multiple metadata instance data includes: instance identifier, instance name, class code, application identifier, and tenant identifier. The class code indicates the code for the corresponding metadata type.

[0093] In one optional implementation, the instance data further includes: multiple instance attribute data. The metadata table is also used to structure and store multiple instance attribute data. Different instance attribute data correspond to different instance attributes, and each metadata instance data corresponds to one or more instance attribute data. Optionally, each instance attribute data includes: an instance identifier, an instance attribute identifier, a class attribute identifier, and the value of the instance attribute.

[0094] In one optional implementation, the metadata data tables include: an instance table, an attribute table, and a relationship table. Specifically: the instance table stores data for multiple metadata instances; the attribute table stores instance attribute data for each metadata instance; and the relationship table stores instance relationship data for the multiple metadata instances. Optionally, the instance table is associated with both the attribute table and the relationship table.

[0095] In one optional implementation, the processing module is specifically used to: form a configuration table corresponding to the first application based on the data from the metamodel; and extract instance data from the metadata according to the parsing logic indicated by the configuration table. Optionally, the configuration table is used to indicate the parsing logic of the metadata. The parsing logic indicates the location of metadata instances, attributes of metadata instances, or relationships within the metadata. Optionally, each relationship corresponds to a metadata type group, which includes a source metadata type and a target metadata type with the relationship. The source metadata type indicates the metadata type that initiated the relationship, and the target metadata type is the metadata type being associated.

[0096] In one optional implementation, the configuration table includes multiple relationship data, each corresponding to a relationship class code. The relationship class code includes the class code of the metadata type initiating the association or the class code of the associated metadata type within the same relationship. Optionally, each relationship data includes: a relationship mapping identifier, a relationship mapping value, a relationship class identifier, and a mapping direction. The relationship mapping value indicates the parsing logic for the relationship corresponding to each relationship data. The mapping direction includes initiating or being associated.

[0097] In one optional implementation, the configuration table also includes multiple mapping data, each corresponding to a different mapping object. The mapping object includes class code, attribute code, or relationship code. Optionally, each of the multiple mapping data includes: a mapping object type, the mapping object itself, and the parsing logic for the mapping object. The mapping object type includes metadata type, attribute, or relationship.

[0098] In one optional implementation, the configuration table includes a first configuration table and a second configuration table. The first configuration table provides multiple mapping data, and the second configuration table provides multiple association data.

[0099] In one optional implementation, the processing module is specifically used to: extract metadata instance data of multiple metadata instances, instance attribute data of each metadata instance, and the association relationships of the multiple metadata instances from the metadata according to the parsing logic indicated by the first configuration table; and extract instance relationship data of the association relationships from the metadata according to the association relationships of the multiple metadata instances and the parsing logic indicated by the second configuration table. Finally, based on the multiple metadata instance data, the instance attribute data of each metadata instance, and the instance relationship data of the association relationships, instance data is formed.

[0100] In one optional implementation, multiple class-relationship data records are used to record the associations between different metadata types across various metadata types. Different class-relationship data correspond to different associations; each association corresponds to a metadata type group; the metadata type group includes the source metadata type and the target metadata type with the association, where the source metadata type indicates the metadata type initiating the association, and the target metadata type is the metadata type being associated. Optionally, each class-relationship data record includes: a class-relationship identifier, a relationship code, a relationship name, a relationship type, a relationship scope, and a metadata type code.

[0101] The relationship type includes dependency relationships or composition relationships. The relationship scope indicates the respective types of the source metadata type and the target metadata type in the first metadata type group. Types include general metadata types or custom metadata types; the first metadata type group is the metadata type group corresponding to each class relationship data. The metadata type code includes the class code of the source metadata type and the class code of the target metadata type in the corresponding metadata type group.

[0102] In one optional implementation, the metamodel data also includes multiple class data. Different class data correspond to different metadata types. Optionally, any one of the multiple class data, the first class data, includes: metamodel identifier, class identifier, class name, and class code.

[0103] The metamodel identifier indicates the metamodel corresponding to the first metadata type; the metamodel is used to construct the metadata corresponding to the first metadata type; the first metadata type is the metadata type corresponding to the first type of data among multiple metadata types. The class identifier indicates the first metadata type, and the class name indicates the name of the first metadata type. The class code indicates the code of the first metadata type.

[0104] In one alternative implementation, the metamodel data also includes multiple class attribute data. Different class attribute data correspond to different attributes, and each metadata type corresponds to at least one class attribute data.

[0105] Optionally, each class attribute data in the multiple class attribute data includes: class identifier, class attribute identifier, attribute code, and attribute name.

[0106] In one optional implementation, class data for multiple metadata types is stored in a metadata type table. Class attribute data for each metadata type is stored in an attribute table for that metadata type. Relationships between different metadata types are stored in an association table between metadata types. The metadata type table is associated with both the attribute table and the association table between metadata types.

[0107] In one optional implementation, the processing module is further configured to: before receiving the metadata from the first application, form multiple meta-models based on the meta-meta-model; based on the multiple meta-models, form multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types; and based on the multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types, create data for the meta-models. Here, the meta-meta-model is used to describe the rules of different meta-models, and the meta-model is used to describe the rules of different metadata types.

[0108] In one optional implementation, the processing module is further configured to: after storing instance data in a structured manner, receive the metadata of the first general function, and, based on the instance data, obtain a first custom metadata instance that is associated with the metadata of the first general function from among multiple metadata instances. If the first custom metadata instance is compatible with the metadata of the first general function, update the first general function in the first application based on the metadata of the first general function. If the first custom metadata instance is incompatible with the metadata of the first general function, the SaaS application server modifies the metadata of the first general function and updates the first general function in the first application based on the modified metadata.

[0109] Optionally, the modified metadata is compatible with the first custom metadata instance. Optionally, the first general function is a general function to be updated in the first application.

[0110] Fourthly, this application provides a metadata application apparatus, which includes a storage module, a communication module, and a processing module. The storage module stores multiple instance data; different instance data correspond to different tenant applications; each instance data is used to store the association relationships between different metadata instances among the multiple metadata instances of the corresponding tenant application. The communication module receives metadata for a first general function; the first general function is a general function to be updated in a first application; the applications of different tenants are first applications with added custom functions; different tenant applications correspond to different custom functions; the first application is any application provided by a SaaS application server. The processing module performs compatibility testing on the metadata of the first general function based on the multiple instance data, obtains the compatibility testing result, and updates the first application based on the compatibility testing result and the metadata of the first general function, thus obtaining a second application.

[0111] In one optional implementation, the compatibility test result includes: the first custom metadata instance is compatible with the metadata of the first general function. Here, the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has an association with the metadata of the first general function.

[0112] Alternatively, the compatibility test results may include: the first custom metadata instance is incompatible with the metadata of the first general function.

[0113] In one optional current approach, the processing module is specifically configured to: if the compatibility detection result indicates that the first custom metadata instance is compatible with the metadata of the first general function, update the first application based on the metadata of the first general function. If the compatibility detection result indicates that the first custom metadata instance is incompatible with the metadata of the first general function, modify the metadata of the first general function, and update the first application based on the modified metadata of the first general function. Wherein, the modified metadata of the first general function is compatible with the first custom metadata instance.

[0114] In one optional implementation, the processing module is specifically used to: determine whether the operation of the first custom metadata instance is normal based on the operation of the metadata of the first general function. Here, the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has a relationship with the metadata of the first general function.

[0115] If the operation of the first custom metadata instance is normal, the compatibility test result is determined to be that the first custom metadata instance is compatible with the metadata of the first general function. If the operation of the first custom metadata instance is abnormal, the compatibility test result is determined to be that the first custom metadata instance is incompatible with the metadata of the first general function.

[0116] In one optional implementation, the processing module is further configured to: after performing compatibility testing on the metadata of the first general function based on multiple instance data and obtaining the compatibility testing results, if the compatibility testing results indicate that the first custom metadata instance is incompatible with the metadata of the first general function, add a first tag to the metadata of the first general function. Here, the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has an association relationship with the metadata of the first general function.

[0117] In one alternative implementation, the processing module is further configured to: obtain a metadata packet; if the metadata packet contains first metadata, modify the first metadata; and update the first application based on the modified first metadata and the second metadata in the metadata packet.

[0118] The first metadata is the metadata carried by the first tag in the data packet, and the second metadata is the metadata that does not carry the first tag in the data packet. The first metadata includes the metadata of the first general function.

[0119] The metadata data includes metadata for multiple general functions, and the metadata for the multiple general functions includes metadata for the first general function.

[0120] In one optional implementation, the processing module is further configured to: after receiving the metadata of the first general function, if the metadata of the first general function meets the compatibility development specifications, update the first application based on the metadata of the first general function; and if the metadata of the first general function does not meet the compatibility development specifications, perform compatibility testing on the metadata of the first general function based on multiple instance data to obtain a compatibility test result.

[0121] In one alternative implementation, the processing module is further configured to: after updating the first application, in response to an update request from the first tenant, perform compatibility testing on the second application based on the instance data of the first tenant. If the compatibility test of the second application passes, publish the third application to the tenant environment of the first tenant.

[0122] The third application is a second application with added custom functionality from the first tenant. The update request is used to request updates to the first tenant's application.

[0123] In one optional implementation, the processing module is specifically configured to: based on the instance data of the first tenant, identify a second custom metadata instance among multiple metadata instances of the first tenant that is incompatible with the general metadata of the second application; output the second custom metadata instance so that the first tenant can modify the second custom metadata instance; receive the modified second custom metadata instance, and if the modified second custom metadata instance is compatible with the general metadata, determine that the second application compatibility test has passed.

[0124] In one optional implementation, the processing module is specifically configured to: obtain multiple first metadata instances that depend on the metadata of the first general function from the multiple instance data; modify each of the multiple first metadata instances based on the metadata of the first general function; and update the first application based on each modified first metadata instance and second metadata instances from the multiple instance data. The second metadata instances are metadata instances from the multiple instance data that do not depend on the metadata of the first general function.

[0125] Fifthly, this application provides a SaaS application service platform, which includes: a metamodel management module, a metadata generation module, a parsing engine, and a metadata storage module. Specifically: the metamodel management module stores metamodel data, which includes the relationships between different metadata types. The metadata generation module provides metadata for the first application. The parsing engine executes the methods provided in the first aspect or any optional implementation of the first aspect, based on the metadata provided by the metadata generation module, to form instance data. The metadata storage module stores the instance data in a structured manner.

[0126] In some alternative implementations, the SaaS application service platform may also include: a metadata consumption block, which executes the methods provided by the second aspect or any of the alternative implementations of the second aspect based on instance data stored in the metadata storage module.

[0127] In a sixth aspect, this application provides a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster executes the method in the first aspect or any optional implementation thereof, or the computing device cluster executes the method in the second aspect or any optional implementation thereof.

[0128] In a seventh aspect, this application provides a computer program product that, when an instruction is executed by a computing device cluster, causes the computing device cluster to execute the method in the first aspect or any optional implementation thereof, or the computing device cluster to execute the method in the second aspect or any optional implementation thereof.

[0129] Eighthly, this application provides a computer-readable storage medium including computer program instructions. When the computer program instructions are executed by a server, the server executes the instructions in the computer program stored in the computer-readable storage medium to perform the method in the first aspect or any optional implementation thereof, or to perform the method in the first aspect or any optional implementation thereof.

[0130] Regarding the technical effects of the third aspect or any implementation thereof, please refer to the technical effects of the first aspect or any optional implementation thereof. Regarding the technical effects of the fourth aspect or any implementation thereof, please refer to the technical effects of the second aspect or any optional implementation thereof. Regarding the technical effects of any implementation of the fifth to eighth aspects, please refer to the technical effects of the first aspect or any optional implementation thereof, or refer to the technical effects of the second aspect or any optional implementation thereof. Further details are omitted here. Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0131] Figure 1 A diagram illustrating a metadata-driven multi-tenant application;

[0132] Figure 2 Metadata-driven multi-tenant application system architecture diagram;

[0133] Figure 3 This is a diagram illustrating the storage of metadata.

[0134] Figure 4 This application provides a schematic diagram of the multi-tenant application system architecture.

[0135] Figure 5 This application provides a schematic diagram of the structure of a multi-tenant application development system within a multi-tenant application system. Figure 1 ;

[0136] Figure 6 A dependency diagram of the tenant's application provided in this application;

[0137] Figure 7 This application provides a schematic diagram of the structure of a multi-tenant application development system within a multi-tenant application system. Figure 2 ;

[0138] Figure 8 A diagram illustrating the different metadata types provided in this application;

[0139] Figure 9 A flowchart illustrating the data flow of the defined meta-model provided in this application;

[0140] Figure 10 Flowchart of the method for storing metadata provided in this application Figure 1 ;

[0141] Figure 11 A metadata diagram for the first application provided in this application;

[0142] Figure 12 A schematic diagram of the interface for obtaining metadata provided in this application;

[0143] Figure 13 A flowchart illustrating the process of creating the configuration table provided in this application;

[0144] Figure 14 A flowchart illustrating the metadata based on the configuration table provided in this application;

[0145] Figure 15 A flowchart illustrating the storage instance data provided in this application;

[0146] Figure 16 Flowchart of the method for storing metadata provided in this application Figure 2 ;

[0147] Figure 17 Flowchart of the method for updating metadata provided in this application Figure 1 ;

[0148] Figure 18 A flowchart illustrating the compatibility testing process provided for this application;

[0149] Figure 19 Flowchart of the method for updating metadata provided in this application Figure 2 ;

[0150] Figure 20 A flowchart illustrating the process of testing the compatibility of the first application with a new version provided in this application;

[0151] Figure 21 This is a flowchart illustrating the process of performing compatibility testing on custom metadata instances provided in this application.

[0152] Figure 22 A schematic diagram of the structure of the storage device for the metadata provided in this application;

[0153] Figure 23 A schematic diagram of the structure of the metadata update device provided in this application;

[0154] Figure 24 A schematic diagram of the computing device provided in this application;

[0155] Figure 25 This application provides a schematic diagram of the structure of a computing device cluster.

[0156] Figure 26 This is a schematic diagram illustrating the network connections between different computing devices in the computing device cluster provided in this application. Detailed Implementation

[0157] Metadata: Data that describes data, primarily used to identify, describe, evaluate, and locate resources, helping to achieve effective discovery, understanding, and organization of data resources. Metadata is a higher-level abstraction of data, providing a way to manage and understand data.

[0158] Software as a Service (SaaS) is an application model that provides application services over the internet. In this model, applications are deployed in the cloud, and tenants connect to and use the cloud-deployed applications via the internet.

[0159] Multi-tenancy application: A software architecture pattern that allows multiple independent user groups (i.e., tenants) to use the same application on shared computing resources, with their data and configurations completely isolated from each other.

[0160] Metadata-driven architect: A software architecture that refers to the creation of application components such as user interfaces, APIs, services, entities, processes, rules, application configurations, and user permissions around the data described by metadata when building multi-tenant applications, providing flexible customization capabilities.

[0161] In a metadata-driven approach, tenants can change the business logic and behavior of the software by modifying or adding metadata.

[0162] Metadata-driven multi-tenant architecture (also known as metadata-driven multi-tenant application architecture, metadata-driven multi-tenant application platform, or metadata-driven multi-tenant application system) is a software architecture that enables a high degree of sharing of infrastructure, platform resources, and application logic, while meeting the isolation requirements between tenants and allowing tenants to customize applications.

[0163] like Figure 1 As shown, Figure 1This diagram illustrates a metadata-driven multi-tenant application. The SaaS system includes versions 1.0 and 2.0. Taking version 1.0 as an example, this version provides common functions such as interface, API calls, services, entities, access control, and application configuration. Tenants 1 and 2 customize different applications within the same common functions of the SaaS system. Application 1 is a customized application for tenant 1, and Application 2 is a customized application for tenant 2. Both Application 1 and Application 2 share the infrastructure, platform resources, and application logic provided by the SaaS system.

[0164] In the process of providing application processing to tenants, the metadata-driven multi-tenant application system develops the application's user interface, data model, APIs, business processes, etc., using various development tools. This metadata is then registered as reusable and customizable interface / entity / API / process / rule metadata for tenants, and versions are released to them; this constitutes the application's standard functional metadata. After subscribing to the application, tenants can extend and orchestrate the standard functional metadata within their own scope, as well as create tenant-specific functionalities, using a visual customization platform; this is tenant-customized functional metadata. Once published, the tenant-customized functional metadata takes effect, forming the tenant's application. This tenant's application includes both the tenant's extended standard functionalities and the tenant's customized functionalities.

[0165] Standard feature metadata can also be called general metadata or metadata for general functions, while custom feature metadata can also be called custom metadata instances or metadata for custom functions. An application's metadata includes both standard feature metadata and custom feature metadata.

[0166] like Figure 2 As shown, Figure 2 This is a diagram illustrating the architecture of a metadata-driven multi-tenant application system. Tenants utilize the metadata-driven multi-tenant platform to design custom metadata instances, including those for user interfaces, APIs, services, entities, processes, rules, application configurations, and user permissions. The metadata-driven multi-tenant platform uses these tenant-provided metadata instances to build applications, such as user interface construction, entity construction, API construction, process construction, rule construction, service construction, application configuration construction, and user permission construction, forming the tenant's tenant application (APP). The metadata-driven multi-tenant platform runs the tenant's tenant APP and, during runtime, uses the metadata engine to store the metadata generated by the tenant APP, as well as the business data generated by the tenant APP.

[0167] The metadata engine is used to collect, maintain, store, manage, compute, and mine metadata.

[0168] Business data refers to various behavioral data generated when users interact with a product. Examples include user clicks, browsing activity data, and operational data such as user registration data and order data. In this application embodiment, the product includes applications (e.g., tenant apps), business systems, etc.

[0169] Currently, metadata-driven multi-tenant platforms typically use unstructured storage when storing metadata for applications from different tenants. This means storing metadata as files, separating metadata for standard functions from metadata for tenant-customized functions. Figure 3 As shown, Figure 3 This diagram illustrates metadata storage. A metadata-driven multi-tenant platform provides a metadata type table. Tenants upload metadata content, and the platform encodes this metadata type table to form unstructured data. Based on this unstructured data and the metadata type table, the platform creates a data instance table. This data instance table provides the metadata types involved in the metadata content and the corresponding data content for each metadata type.

[0170] like Figure 3 As shown, the data instance table directly uses the encoded unstructured data as the data content corresponding to the metadata type.

[0171] This storage model makes it difficult to analyze metadata, and the applications composed of metadata cannot present complex internal structures, thus failing to support application architecture governance and application asset management.

[0172] Furthermore, due to the lack of a correlation between generic metadata and tenants' custom metadata instances, it is difficult to assess the impact of generic metadata changes on custom metadata instances when upgrading applications provided by a metadata-driven multi-tenant platform. As mentioned above... Figure 1 As shown, after the SaaS system was updated from version 1.0 to version 2.0, the general functions in version 2.0 changed compared to version 1.0. Due to the lack of association between the general metadata in application 1 and the custom metadata instance of tenant 1, it is difficult to know whether the changes in general functions will affect the custom functions in application 1, and thus it is difficult to assess whether the custom functions in application 1 are compatible with the general functions of the SaaS, resulting in a decrease in the stability and reliability of application 1.

[0173] Based on this, to ensure backward compatibility with new versions, this application provides a metadata storage method. This method extracts relevant data from the application's metadata and stores it in a structured manner, facilitating metadata querying by the SaaS application server. Furthermore, by extracting the relationships between different metadata instances, the SaaS application server can obtain the relationships between application metadata instances, and then utilize these relationships to determine the relationships between general and custom functions within the application. Thus, when the application's general functions change, the SaaS application server can leverage the relationships between metadata instances to perform impact analysis on multi-tenant application development and upgrades, quickly identifying custom functions affected by general functions. This reduces the difficulty of assessing the impact of version upgrades on general functions and tenant-customized functions, thereby ensuring backward compatibility with new application versions and improving the reliability and stability of multi-tenant applications.

[0174] Based on the above Figure 1 For example, the technical solution provided in this application allows the SaaS application server to analyze whether changes in general functions will affect custom functions in application 1 after the SaaS system is updated from version 1.0 to version 2.0. This analysis is based on the association between the general metadata in application 1 and the custom metadata instance of tenant 1. In this way, the compatibility between the custom functions in application 1 and the general functions of SaaS can be evaluated.

[0175] Specifically, the SaaS application server stores metamodel data, which includes the relationships between different metadata types. Using this metamodel data, the SaaS application server converts the received metadata of the first application into structured data, extracts the relationships between different metadata instances within the first application's metadata to form instance data, and stores this instance data in a structured manner.

[0176] In an alternative approach, the association between different metadata instances may also be referred to as the instance relationship between different metadata instances, the instance association between different metadata instances, or other names. This application embodiment does not limit this.

[0177] The technical solution involved in this application can be used not only in the metamodel development stage to structurally store metadata instances corresponding to different metamodel types, but also in the design or runtime stages of multi-tenant applications. When applied to the design stage, the SaaS application server can achieve complete application development based on the relationships between metadata instances. When applied to the runtime stage, the SaaS application server can ensure that corresponding functions are loaded in batches on demand during application operation based on the relationships between metadata instances, avoiding performance issues caused by redundant function loading.

[0178] Furthermore, the technical solutions involved in this application can be applied not only to current SaaS application servers, multi-tenant application platforms, metadata-driven multi-tenant application system architectures, or metadata-driven application development technologies, but also to future application development technologies, multi-tenant application platforms, SaaS application servers, or cloud platforms, etc. The embodiments of this application do not limit this.

[0179] The terminology used in the implementation section of this application is only for explaining specific embodiments of this application and is not intended to limit this application. A brief introduction to some concepts that may be involved in this application is given below.

[0180] Metamodel: A model that describes a model. It defines the building blocks and rules for describing a model in a specific domain. For example, it defines elements such as classes, attributes, and relationships, as well as the constraints and rules between them. Metamodels allow the creation of a type of metadata, enabling better understanding and management of complex metadata types.

[0181] Meta-meta model: A model that describes a meta-model. A meta-model is a standardized way to describe and define the structure and rules of a meta-model. Different meta-models can be created using meta-meta-models.

[0182] Application suit development (also known as suit development) refers to the process of application development or design that utilizes a set of interrelated metadata instances to form a complete function.

[0183] Batch loading on demand (also known as lazy loading): This method improves application startup speed and performance. During application runtime, the application does not load all resources at once. Instead, it loads the corresponding resources gradually based on user actions and needs. In the process of gradually loading the corresponding resources, the application uses the relationships between metadata instances to identify the metadata instances that need to be used.

[0184] The terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0185] The following combination Figure 4 The multi-tenant application system architecture provided in this application is illustrated by example. Figure 4As shown, the multi-tenant application system 100 includes a client 20, a cloud service platform 30, and a cloud platform 10. This multi-tenant application system 100 can be used for application development, application design, software testing, or running applications. In some alternative embodiments, the multi-tenant application system 100 may also be referred to as a multi-tenant application platform, a multi-tenant platform, a metadata-driven multi-tenant platform, a metadata-driven multi-tenant application system, a SaaS system, or other names; this application embodiment does not limit this.

[0186] In a first optional implementation, the client 20 can be a computer running an application. This computer can be a physical machine or a virtual machine. For example, if the computer running the application is a physical computing device, it can be a host or a terminal. The terminal can also be called a terminal device, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. Terminals can be mobile phones, tablets, laptops, desktop computers, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in autonomous driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc. The embodiments of this application do not limit the specific technology or device form used by the client 20.

[0187] In the second optional implementation, client 20 can be an application, such as an application development application, application design application, cloud service application, etc. Alternatively, client 20 can be a web client. Client 20 runs on a terminal device. The terminal device includes, but is not limited to, mobile terminals, tablets, personal computers, or laptops.

[0188] The two implementation methods described above are merely different ways of implementing the client 20. In practical applications, the client 20 can also have other implementation methods. For example, the client 20 can be a software module running on any one or more hosts in the computing cluster 110. This application does not limit this.

[0189] In some optional implementations, client 20 can be divided into tenant clients and user clients. The user corresponding to a tenant client is a tenant, and the user corresponding to a user client is a user. Tenants use tenant clients to create applications on cloud platform 10, and users use the applications provided by cloud platform 10. One tenant client manages one or more applications, each application corresponds to one tenant client, and multiple user clients can access the same application. Management includes adding or deleting applications, modifying the application's user interface, APIs, entities, processes, rules, etc. This application embodiment does not limit the management permissions or specific management content of the tenant client.

[0190] In one optional implementation, a multi-tenant application development system 120 is deployed in the cloud platform 10. This multi-tenant application development system 120 is used to provide application development services and application runtime services to tenant clients, as well as application services to user clients. In some optional implementations, the multi-tenant application development system may also be referred to as a SaaS application service platform, a SaaS application server, a SaaS application service system, or other names; this application embodiment does not limit the specific name used.

[0191] In some embodiments, the multi-tenant application development system 120 can be deployed independently in one instance of the cloud platform 10.

[0192] In other embodiments, the multi-tenant application development system 120 can also be deployed in a distributed manner across multiple instances of the cloud platform 10.

[0193] like Figure 4 As shown, the multi-tenant application development system 120 is abstracted by the cloud service provider on the cloud service platform 30 into an application customization service and provided to tenants. After a tenant purchases the application customization service on the cloud service platform through a tenant client, the cloud environment utilizes the multi-tenant application development system 120 deployed on the cloud platform 10 to provide the application customization service to the user. When using the application customization service, tenants can design application functions through the API or graphical user interface (GUI) in the tenant client 20, generate metadata, and upload the metadata to the cloud environment. The multi-tenant application development system 120 in the cloud environment receives the tenant's metadata, creates the application, and stores the metadata. The multi-tenant application development system 120 returns creation results or status information during the creation process to the tenant through the API or GUI. Furthermore, after creating the application, the multi-tenant application development system 120 runs the application in the cloud environment and returns data during the application's operation to the tenant through the API or GUI.

[0194] In addition, in other embodiments, the functions of the multi-tenant application development system 120 may be performed by the cloud platform 10 or other components of the cloud platform 10, and this application does not limit its implementation.

[0195] Regarding the structure of the aforementioned multi-tenant application development system 120, the following section combines... Figure 5 and Figure 7 Two possible structural examples are provided to illustrate the structure of the multi-tenant application development system 120.

[0196] like Figure 5 As shown, the multi-tenant application development system 120 includes an application development component 53, a metadata management component 54, a metadata storage component 55, a metamodel storage component 52, and a metamodel management component 51.

[0197] The functions implemented by the application development component 53, the metadata management component 54, the metadata storage component 55, the metamodel storage component 52, and the metamodel management component 51 can be completed by the cloud platform 10 or other components of the cloud platform 10. This application does not limit their implementation methods.

[0198] The following provides an illustrative example of the connection relationships between the application development component 53, the metadata management component 54, the metadata storage component 55, the metamodel storage component 52, and the metamodel management component 51.

[0199] like Figure 5 As shown, the metamodel management component 51 is connected to the metamodel storage component 52, and the metadata storage component 55 is connected to the metadata management component 54. The metadata management component 54 is connected to the metadata storage component 55, the metamodel management component 51, and the application development component 53. The application development component 53 is connected to both the metamodel management component 51 and the metadata management component 54.

[0200] The functions and structures of the application development component 53, metadata management component 54, metadata storage component 55, metamodel storage component 52, and metamodel management component 51 are illustrated below.

[0201] Metamodel storage component 52 is used to store metamodel data. For example... Figure 5 As shown, the metamodel storage component 52 includes a metamodel storage unit 521, a class storage unit 522, a class attribute storage unit 523, a class relation storage unit 524, and a class relation type unit 525.

[0202] Metamodel storage unit 521 is connected to class storage unit 522. Class storage unit 522 is connected to metamodel storage unit 521, class attribute storage unit 523, and class relation storage unit 524. Class relation storage unit 524 is connected to class storage unit 522 and class relation type unit 525.

[0203] The metamodel storage unit 521 is used to store information about various metamodels. The information for each metamodel includes, but is not limited to: metamodel identifier, metamodel code, metamodel name, and metamodel description information. The metamodel code indicates the code language used to define the metamodel, and the metamodel description information describes one or more of the following: the functionality implemented by the metamodel, the type of the metamodel, or the definition rules.

[0204] Class storage unit 522 is used to store class data for each of the various metadata types. Each piece of class data includes, but is not limited to: metamodel identifier, class identifier, class code, and class name. The metamodel identifier indicates the metamodel defining the metadata type. The class code indicates the code language used to form the rules governing this metadata type.

[0205] The class attribute storage unit 523 is used to store the class attribute data included in each of the various metadata types. Each piece of class attribute data includes, but is not limited to: the class identifier of the metadata type to which the attribute belongs, the class attribute identifier, the class attribute code, and the class attribute name.

[0206] The class-relationship storage unit 524 is used to store class-relationship data between various metadata types. Each piece of class-relationship data may include, but is not limited to: class-relationship identifier, class-relationship name, source class identifier, target class identifier, relationship type identifier, relationship description, or relationship application scenario.

[0207] The source class identifier indicates the class identifier of the metadata type that initiates the association, while the target class identifier indicates the class identifier of the metadata type that is being associated. For example, taking tenant B's API as an example... Figure 6 As shown, the API's input parameters depend on entity A of the standard application in the multi-tenant application development system 120, and the API also depends on its own custom entity B. Therefore, in the API → input parameter relationship, the source class identifier is the API's class identifier, and the target class identifier is the input parameter's class identifier. Similarly, in the API → entity A relationship, the source class identifier is the API's class identifier, and the target class identifier is the entity A's class identifier. In the API → custom entity B relationship, the class identifier is the API's class identifier, and the target class identifier is the custom entity B's class identifier.

[0208] The standard application is used to provide common functions to tenants, and different tenants can develop different applications based on the standard application.

[0209] The relationship type identifier is used to indicate the type of association, where the type of association includes dependency or containment. For example, using... Figure 6 For example, in the provided example, in the relationship between API and input parameter, if API contains input parameter, then API and input parameter have an inclusion relationship. In the relationship between API and entity A, if API depends on entity A, then API and entity A have a dependency relationship.

[0210] The relationship description provides descriptive information about the association. The relationship application scenario provides information about the scenarios in which the association is applied or the functions it implements.

[0211] The class relation type unit 525 is used to store relation type data for various relation types provided by the multi-tenant application system. Each relation type data includes, but is not limited to, relation type identifier, relation type code, relation type name, or relation type description. For example, taking the relation types provided by the multi-tenant application system as including dependency and containment relationships, the class relation type unit 525 stores relation type data for dependency relationships and relation type data for containment relationships.

[0212] In some optional implementations, the functions implemented by the metamodel storage unit 521, class storage unit 522, class attribute storage unit 523, class relation storage unit 524, and class relation type unit 525 can be completed by the metamodel storage component 52 or other units in the metamodel storage component 52. This application does not limit its implementation.

[0213] Please continue reading. Figure 5 The metamodel management component 51 provides metamodel definition and metamodel query functions. The metamodel definition function refers to defining a new metamodel and writing its data to the metamodel storage component 52. The metamodel query function refers to accessing the metamodel storage component 52 to perform metamodel queries, metadata-type class data queries, metadata-type class attribute data queries, or metadata-type class relationship data queries, etc.

[0214] Metadata storage component 55 is used to store instance data for different tenants. For example... Figure 5 As shown, the metadata storage component 55 includes an instance storage unit 551, an instance attribute storage unit 552, and an instance relationship storage unit 553. The instance storage unit 551 is connected to the instance attribute storage unit 552 and the instance relationship storage unit 553, respectively.

[0215] The instance storage unit 551 is used to store metadata instance data of various metadata types generated by applications of different tenants. Each metadata instance data includes, but is not limited to: metadata instance identifier, metadata instance name, class code, metadata identifier, tenant identifier, and application identifier.

[0216] Here, class code refers to the class code of the metadata type corresponding to the metadata instance. Metadata identifier refers to the identifier of the metadata corresponding to the metadata instance. Tenant identifier refers to the identifier of the tenant corresponding to the application where the metadata instance resides. Application identifier is used to indicate the application where the metadata instance resides.

[0217] The instance attribute storage unit 552 is used to store instance attribute data included in each of the multiple metadata instances. Each instance attribute data includes, but is not limited to: metadata instance identifier, class attribute identifier, instance attribute identifier, attribute value, etc.

[0218] The class attribute identifier field refers to the identifier of the class attribute corresponding to the instance attribute. The instance attribute value refers to the value of the instance attribute in the application's metadata.

[0219] In an alternative approach, the attributes of a metadata instance may also be referred to as instance attributes of a metadata instance, instance attributes of metadata, or other names, and this application embodiment does not limit this.

[0220] The instance relationship storage unit 553 is used to store instance relationship data between various metadata instances. Each instance relationship data indicates an association relationship, and each instance relationship data may include, but is not limited to: instance relationship identifier, class relationship identifier, source instance identifier, and target instance identifier.

[0221] The source instance identifier can refer to the instance identifier of the metadata instance that initiated the association in the metadata. In some optional ways, the source instance identifier can also be called the first instance identifier or other names, and this application embodiment does not limit this.

[0222] The target instance identifier can refer to the instance identifier of the metadata instance associated with it in the metadata. In some alternative methods, the target instance identifier can also be called a second instance identifier or other names, which is not limited in this embodiment of the application.

[0223] In some alternative approaches, the functions implemented by instance storage unit 551, instance attribute storage unit 552 and instance relationship storage unit 553 can be performed by metadata storage component 55 or other components of metadata storage component 55, and this application does not limit its implementation method.

[0224] Please continue reading. Figure 5The metadata management component 54 provides metadata collection, parsing, storage, and querying capabilities. For example... Figure 5 As shown, the metadata management component 54 includes a metadata acquisition unit 541, a metadata parsing unit 542, a metadata storage unit 543, and a metadata query unit 544.

[0225] The metadata acquisition unit 541 is used to acquire the tenant's metadata and the metadata generated during the user's use of the application.

[0226] Metadata parsing unit 542 is used to parse metadata and obtain instance data of the different tenants mentioned above.

[0227] Metadata storage unit 543 is used to store instance data in a structured storage manner into metadata storage component 55.

[0228] Metadata storage unit 543 is used in conjunction with metadata storage component 55 to realize metadata instance query, metadata instance attribute query, or metadata instance association query.

[0229] In one alternative approach, the functions implemented by the metadata acquisition unit 541, the metadata parsing unit 542, the metadata storage unit 543, and the metadata query unit 544 can be performed by the metadata management component 54 or other components of the metadata management component 54. This application does not limit the implementation method.

[0230] Please continue reading. Figure 5 Application development component 53 is used to collaborate with metamodel management component 51 and metadata management component 54 to implement application development and management for different tenants.

[0231] The following is a combination of the above. Figure 5 The interaction flow between modules of the multi-tenant application development system 120 is illustrated below.

[0232] Phase ①: Metamodel Management Component 51 defines metamodels for different metadata types, including classes, class attributes, and class relationships for different metadata types.

[0233] Phase 2: Metamodel management component 51 writes class data, class attribute data, and class relationship data of different metadata types into metamodel storage component 52.

[0234] Phase 3: Application development component 53 and collaborative metamodel management component 51 provide tenants with a variety of different metadata types.

[0235] Phase 4: Tenants develop applications based on the various metadata types provided by application development component 53, forming the metadata of the tenant's application.

[0236] Phase 5: Metadata management component 54 acquires the tenant's metadata during the application development process.

[0237] Phase 6: The metadata management module, in collaboration with the metamodel management component 51, parses the metadata and extracts instance data from it.

[0238] Phase 7: The metadata management module stores instance data in a structured manner in the metadata storage component 55.

[0239] From the interaction flow between the multi-tenant application development systems 120 described above, it can be seen that in terms of the interaction logic of each component in the multi-tenant application development system 120, the multi-tenant application development system 120 parses instance data from the tenant's metadata and stores the instance data in a structured manner. The metadata storage method provided in this application can be implemented within the processing flow of the multi-tenant application development system 120 parsing instance data from the tenant's metadata. The implementation process of the metadata storage method can be referred to the following... Figures 8 to 16 The embodiments provided are not described in detail here.

[0240] In addition, the above Figure 5 The provided multi-tenant application development system 120 is merely exemplary and should not be construed as limiting the structure of the multi-tenant application development system 120. In other embodiments, the components in the multi-tenant application development system 120 may have other grouping methods, such as... Figure 7 As shown, Figure 7 The structural diagram of the multi-tenant application development system provided in this application Figure 2 .

[0241] Please see Figure 7 Unlike Figure 5 The provided multi-tenancy application development system 120, in Figure 7 In the multi-tenant application development system 120, it can also be divided into a metamodel management module 71, a metadata generation module 72, a parsing engine 73, a metadata storage module 74, and a metadata consumption module 75.

[0242] In some alternative implementations, the functions implemented by the metamodel management module 71, the metadata generation module 72, the parsing engine 73, the metadata storage module 74, and the metadata consumption module 75 can be performed by the cloud platform 10 or other components of the cloud platform 10, and this application does not limit their implementation methods.

[0243] The following provides an illustrative example of the connection relationships between the metamodel management module 71, the metadata generation module 72, the parsing engine 73, the metadata storage module 74, and the metadata consumption module 75.

[0244] like Figure 7 As shown, the metadata generation module 72 interacts with the parsing engine 73, the parsing engine 73 interacts with both the metadata storage module 74 and the metadata generation module 72, and the metadata consumption module 75 interacts with the metadata storage module 74. The metamodel management module 71 is connected to the parsing engine 73.

[0245] In an alternative approach, the metamodel management module 71, the metadata generation module 72, the parsing engine 73, the metadata storage module 74, and the metadata consumption module 75 can be deployed on the same device.

[0246] In another alternative approach, any one or more of the following modules—metamodel management module 71, metadata generation module 72, parsing engine 73, metadata storage module 74, and metadata consumption module 75—can be deployed on different devices. For example, the metamodel management module 71 can be deployed on device A, while the metadata generation module 72, parsing engine 73, metadata storage module 74, and metadata consumption module 75 can be deployed on device B, with communication connections between device A and device B. As another example, the metamodel management module 71, metadata generation module 72, parsing engine 73, and metadata storage module 74 can be deployed on device C, while the metadata consumption module 75 can be deployed on device D, with communication connections between device C and device D.

[0247] The functions and structures of the metamodel management module 71, metadata generation module 72, parsing engine 73, metadata storage module 74, and metadata consumption module 75 are described below by way of example.

[0248] Metamodel management module 71 has the above-mentioned features Figure 5 The metamodel management component 51 and metamodel storage component 52 enable the definition of metamodels and the storage of metamodel data. For example... Figure 7 As shown, the metamodel management module 71 includes a metamodel definition unit 711, a metamodel viewing unit 712, a metamodel extension unit 713, and a metamodel publishing unit 714.

[0249] The metamodel definition unit 711 is used to define metamodels of different metadata types, form metamodel data, and store metamodel data.

[0250] The metamodel viewing unit 712 is used to provide stored metamodel data to tenants or operations personnel, and based on the query information input by the tenants or operations personnel, to provide a metamodel that satisfies the query information. For example, the metamodel viewing unit 712 can refer to the following... Figure 12 The provided embodiments provide meta-model data in a user interface manner, and provide a meta-model that satisfies query information in the user interface.

[0251] The metamodel extension unit 713 is used to provide extension functionality for the metamodel, where "extension" can be an extension of one or more of the metamodel's metadata types, class attributes of metadata types, or class relation data. For example, as described above... Figure 6 In the provided embodiment, the metamodel extension unit 713 can add input parameters to the API data or customize entities.

[0252] The metamodel publishing unit 714 is used to publish the general functions corresponding to the metamodel in the multi-tenant application development system 120 according to the defined metamodel, so that tenants can develop custom metadata based on the general functions.

[0253] In some alternative approaches, the functions implemented by the metamodel definition unit 711, the metamodel viewing unit 712, the metamodel extension unit 713, and the metamodel publishing unit 714 can be completed by the metamodel management module 71 or other units in the metamodel management module 71. This application does not limit the implementation method.

[0254] Please continue reading. Figure 7 The metadata generation module 72 is used to provide application development functions to different tenants based on the different metadata types provided by the metadata management module 71, and to obtain different metadata instances defined by different tenants during the application development process. Different metadata instances include, but are not limited to, entities, interfaces, APIs, services, rules, processes, application configurations, or user permissions.

[0255] Parsing engine 73 has the above features Figure 5 The metadata management component 54 can collect different metadata instances defined by different tenants during application development, parse instance data based on the metadata model provided by the metadata model management module 71, and store the parsed instance data in a structured manner in the metadata storage module 74. For example... Figure 7 As shown, the parsing engine 73 provides functions for metadata collection, metadata adaptation, metadata parsing, and metadata version management.

[0256] Metadata storage module 74 and the above Figure 5The metadata storage component 55 has the same function as the parsing engine 73, storing instance data provided by the parsing engine 73 in a structured manner and providing data support for the metadata consumption module 75. For example... Figure 7 As shown, the metadata storage module 74 stores metadata instance data, instance attribute data, and instance relationship data.

[0257] The metadata consumption module 75 is used to realize metadata acquisition, metadata retrieval, metadata impact analysis, metadata quality operation, metadata operation, metadata specification check, multi-level relationship and metadata graph functions based on the data stored in the metadata storage module 74.

[0258] Metadata acquisition can be achieved by the metadata consumption module 75 obtaining metadata instances, instance attribute data, or instance relationship data from the metadata storage module 74. For example, the metamodel consumption module provides a metadata interface, in which it obtains metadata instances, instance attribute data, or instance relationship data from the metadata storage module 74 and displays these data on the interface.

[0259] Metadata retrieval can be performed by the metadata consumption module 75 based on the retrieval information provided by the tenant, to retrieve metadata instances, instance attribute data of metadata instances, or instance relationship data, and to provide the retrieval results to the tenant.

[0260] Metadata impact analysis can be performed by the metadata consumption module 75, in the event of a general function update, to analyze the impact of the update on custom functions in the custom applications of different tenants. For example, the metadata consumption module 75 may refer to the following... Figures 17 to 21 The provided examples implement metadata impact analysis.

[0261] Metadata operations can be a series of processes managed by the metadata consumption module 75 to manage the metadata lifecycle: defining metadata annotations and specifications, ensuring the consistency and accuracy of metadata, implementing metadata integration and interoperability, providing metadata access and search capabilities, and evaluating the quality of metadata.

[0262] Metadata quality management can be achieved by the metadata consumption module 75 managing the quality of metadata, including but not limited to: providing quality inspection rules and indicators, detecting metadata quality levels, and analyzing the causes of metadata errors.

[0263] Metadata specification checks can be performed by the metadata consumption module 75 to check the metadata for compliance.

[0264] Multi-level relationships can be obtained by the metadata consumption module 75 based on the instance relationship data stored in the metadata storage module 74 to obtain the relationships between different metadata instances.

[0265] Metadata graphs can be used by the metadata consumption module 75 to graphically display the relationships between different metadata instances. As described above... Figure 6 As shown, the metadata instance API provides the association between entity A, entity B, and input parameters.

[0266] The above Figure 7 The multi-tenant application development system 120 provided is merely an exemplary drawing and should not be construed as limiting the structure of the multi-tenant application development system 120. In other embodiments, the multi-tenant application development system 120 may have other structures, which are not limited in this application.

[0267] The following is in conjunction with the above. Figure 7 The interaction flow between modules in the multi-tenant application development system 120 is illustrated by an example. The interaction flow between modules in the multi-tenant application development system 120 includes stages ① to ⑦.

[0268] Phase ①: Metamodel Management Module 71 defines metamodels of different metadata types, including classes, class attributes, and class relationships of different metadata types, and stores class data, class attribute data, and class relationship data of different metadata types.

[0269] Phase ②: Metadata generation module 72 and collaborative metamodel management module 71 provide tenants with a variety of different metadata types.

[0270] Metamodel management component 51 writes class data, class attribute data, and class relationship data of different metadata types into metamodel storage component 52.

[0271] Phase 3: Tenants develop applications based on the various metadata types provided by the metadata generation module 72.

[0272] Phase 4: Metadata generation module 72 acquires the tenant's metadata during the application development process.

[0273] Phase 5: The parsing engine module 73, in collaboration with the metamodel management component 51, parses the metadata and extracts instance data from it.

[0274] Phase 6: The parsing engine module 73 stores the instance data in a structured manner in the metadata storage module 74.

[0275] Phase 7: The metadata consumption module 75 performs metadata operation and updates based on the instance data stored in the metadata storage module 74.

[0276] From the interaction flow between the modules in the multi-tenant application development system 120 above, it can be seen that in terms of the interaction logic of each component in the multi-tenant application development system 120, the multi-tenant application development system 120 parses instance data from the tenant's metadata and stores the instance data in a structured manner. The metadata storage method provided in this application can be implemented in the processing flow of the multi-tenant application development system 120 parsing instance data from the tenant's metadata. The implementation process of the metadata storage method can be referred to the following... Figures 8 to 16 The embodiments provided are not described in detail here. Furthermore, the multi-tenant application development system 120 can also assess the impact of general metadata updates on metadata instances based on the association relationships between different metadata instances in the instance data, and update the metadata based on the assessment results. Assessing the impact of general metadata updates on metadata instances within the multi-tenant application development system 120 can implement the metadata update method provided in this application. The implementation process of the metadata update method can be referred to the following... Figures 8 to 21 The embodiments provided are not described in detail here.

[0277] The system architecture and application scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0278] The following is based on the above Figure 4 , Figure 5 and Figure 7 The provided multi-tenancy application development system 120, firstly combines the following Figures 8 to 16 The method for storing metadata is illustrated by way of example. Then, based on the embodiments of the method for storing metadata, the following... Figures 17 to 21 An example is provided to illustrate the method for updating metadata.

[0279] In one optional implementation, to convert metadata into structured data during the metadata storage process, the multi-tenant application development system 120 predefines meta-models for different metadata types, forming structured meta-model data. Instance data is then extracted from the metadata based on this structured meta-model data, and the structured storage of this instance data is achieved. This ensures the reliability of the extracted instance data and guarantees its structured storage.

[0280] The following is combined Figures 8 to 9 This paper provides an exemplary description of how the data of the meta-model defined in the multi-tenant application development system 120 is implemented.

[0281] First, an example is given of how the data in the metamodel is stored.

[0282] Refer to the above Figure 5 The provided embodiments show that the data of the metamodel includes class data, class attribute data, and class relationship data.

[0283] In one alternative implementation, the multi-tenant application development system 120 stores the metamodel data in a structured manner in several possible ways, such as:

[0284] In one alternative implementation, the multi-tenant application development system 120 can store the meta-model data using a relational database. For example, the meta-model data can be stored in a table format.

[0285] For example, class data, class attribute data, and class relationship data of a metamodel can be stored in the same table, with each row in the table recording class data, class attribute data, and class relationship data of a metadata type.

[0286] For example, class data, class attribute data, and class relationship data in a metamodel can be stored in different tables, with the tables linked together by keys. For details on how to store class data, class attribute data, and class relationship data in separate tables, please refer to the following. Figure 13 The embodiments provided are not described in detail here.

[0287] In a second alternative implementation, the multi-tenant application development system 120 can store the metamodel data using column family storage. For example, the metamodel data can be stored in units of table columns.

[0288] For example, each column family records class data, class attribute data, and class relationship data of a metadata type.

[0289] For example, class data, class attribute data, and class relationship data of the same metadata type are recorded in different column families, and there are related relationships between different column families. Each column family includes multiple sets of related columns.

[0290] A third optional implementation is that the multi-tenant application development system 120 can store the metamodel data using a key-value store. For example, the metamodel data is stored using key-value pairs.

[0291] For example, the class identifier of each metadata type is the key, and the metamodel identifier, class code, class name, class attribute data, and class relationship data of that metadata type are the values ​​of the key, forming key-value pairs for different metadata types. Each key-value pair records the class data, class attribute data, and class relationship data of a metadata type.

[0292] For example, each metadata type uses a class identifier as the key, and the metamodel identifier, class code, and class name of that metadata type are the values ​​for that key, forming class data key-value pairs for different metadata types. In each class attribute data entry, the class attribute identifier is the key, and the class identifier, class attribute code, class attribute name, and data type are the values ​​for that key, forming class attribute key-value pairs for different class attribute data. Similarly, in each class relationship data entry, the class relationship identifier is the key, and the class relationship name, source class identifier, target class identifier, relationship type identifier, relationship description, and relationship application scenario are the values ​​for that key, forming class relationship key-value pairs for different class relationship data. Class identifiers are used to associate class data key-value pairs, class attribute key-value pairs, and class relationship key-value pairs with the same class identifier.

[0293] The above three optional implementation methods are only different ways of storing the data of the structured storage metamodel. In other embodiments, the multi-tenant application development system 120 may also use other structured storage methods to store the data of the metamodel. This application embodiment does not limit this.

[0294] In one optional implementation, when the number of metadata types in the multi-tenant application development system 120 is large, or when the metadata types include many class attributes, class data, class attribute data, and class relationship data can be stored in different tables to facilitate the retrieval and viewing of the metamodel data. For example, the multi-tenant application development system 120 sets up a metadata type table, a metadata type attribute table, and a relationship table between metadata types. The metadata type table, the metadata type attribute table, and the relationship table between metadata types are used to store class data, class attribute data, and class relationship data respectively.

[0295] The metadata type table can be located in the class storage unit 522, and the metadata type attribute table can be located in the class attribute storage unit 523. The association table between metadata types can be located in the class relationship storage unit 524. Alternatively, the metadata type table, the metadata type attribute table, and the association table between metadata types can also be located in the metadata model management module 71. This embodiment does not limit the location of the metadata type table, the metadata type attribute table, and the association table between metadata types.

[0296] Furthermore, the metadata type table can also be called a class data table, class table, or other names, and this application embodiment does not limit this. Similarly, the attribute table of the metadata type can also be called a class attribute data table, class attribute table, or other names, and this application embodiment does not limit this. The association table between metadata types can also be called a class relation data table, class relation table, or other names, and this application embodiment does not limit this.

[0297] Secondly, an illustrative explanation is provided of the metadata type table, the attribute table of metadata types, and the association table between metadata types.

[0298] 1) Metadata type table.

[0299] The metadata type table is used to store class data of various metadata types. As shown in Table 1 below, Table 1 is an example of the metadata type table provided in this application. The metadata type table includes a model identifier field, a class identifier field, a class code field, and a class name field.

[0300] The Model Identifier field provides the Package ID, the Class Identifier field provides the Class ID, the Class Code field provides the Class Code, and the Class Name field provides the Class Name.

[0301] Taking the class identifier field as an example, the content of the class identifier field is explained exemplarily. The content of the corresponding model identifier field, class code field, and class name field can be referred to the content of the class identifier field.

[0302] As shown in Table 1, the class identifier field includes the attribute name CLASSID, the converted physical field name CLASS_ID, the data type: number, the data length: 0, the primary key identifier: Y, and the business definition: class identifier.

[0303] The attribute name, which can be called the column name or field name, is used to describe the logical name of each column element in the metadata type table.

[0304] The converted physical field name is used to indicate the actual storage name used internally by the multi-tenant application development system 120.

[0305] The primary key identifier is used to indicate whether the key is the primary key of the metadata type table. For example, when the primary key identifier is Y, it indicates that the key is the primary key of the metadata type table, and when the primary key identifier is N, it indicates that the key is not the primary key of the metadata type table.

[0306] Table 1

[0307]

[0308] As can be seen from Table 1, the metadata type table uses the class identifier as the primary key.

[0309] Table 1 above is only one possible implementation of the metadata type table. In another embodiment, the metadata type table may include more fields than Table 1. This application does not limit this implementation.

[0310] For example, as shown in Table 2 below, Table 2 is another example of the metadata type table provided in this application. Compared with the metadata type table provided in Table 1, the metadata type table in Table 2 may also include a class description field, a parent class identifier TOP CLASS FLAG, a search identifier SEARCHABLE, a valid identifier ENABLE FLAG, a creator field CREATEDBY, a creation time field CREATION DATE, a modifier field LAST UPDATED BY, and a modification time field LASTUPDATE DATE.

[0311] The class description field is used to provide descriptive information for the metadata type, CLASSDESC.

[0312] The TOP CLASS FLAG indicates whether the metadata type is a top-level metadata type. A "top-level metadata type" can refer to a metadata type that has no parent class or is directly at the highest level, meaning it does not contain other metadata types. Specifically, the parent class identifier: N indicates that the metadata type is not a top-level metadata type, meaning it has a parent class. The parent class identifier: Y indicates that the metadata type is a top-level metadata type, meaning it does not have a parent class.

[0313] like Figure 8 As shown, Figure 8 This diagram illustrates the different metadata types provided in this application. Application A is the top-level metadata type, and the tenant corresponding to Application A is Tenant 1. Application A contains metadata types including: Entity, Service, API, Interface, Process, and Rule. Therefore, the metadata types Entity, Service, API, Interface, Process, and Rule all share the same parent class: Application A. Consequently, Entity, Service, API, Interface, Process, and Rule are not top-level metadata types.

[0314] The search identifier is used to indicate whether the metadata type supports searching. For example, a search identifier of 0 indicates that the class data of this metadata type does not support searching. A search identifier of 1 indicates that the class data of this metadata type supports searching. "Supports searching" means that tenants can search and view the class data of this metadata type within the multi-tenant application development system 120.

[0315] A valid identifier is used to indicate whether the class data of this metadata type is valid.

[0316] The Creator field indicates the creator of this metadata type, which can be a tenant or operations personnel. The Creation Time field indicates the time when this metadata type was created. The Modifier field indicates the tenant or operations personnel who last modified this metadata type. The Modification Time field indicates the time when this metadata type was last modified.

[0317] Table 2

[0318]

[0319]

[0320] Table 2 above is merely illustrative and should not be construed as limiting the metadata type table provided in this application. In practical applications, the metadata type table may include more or fewer fields than those in Table 2 above, and the name of each field may also have other forms, which are not limited in this embodiment.

[0321] For example, Table 1 provides a metadata type table, which defines the above... Figure 6 In the case of the metadata types shown, the multi-tenant application development system 120 defines the metadata type table shown in Table 3 below. As shown in Table 3, the class identifier of the metadata type API is 1, the class code is ENTITY, and the class name is API; the type identifier of the metadata type API input parameter is 2, the class code is API_INPUT, and the class name is API input parameter; the class identifier of the metadata type entity is 3, the class code is ENTITY, and the class name is entity. The metadata type API, API input parameter, and entity are each represented by a corresponding metamodel identifier of XXA.

[0322] Table 3

[0323]

[0324] As can be seen from Tables 1 to 3 above, the multi-tenant application development system 120 stores class identifiers, class codes, and class names of different metadata types, so that the multi-tenant application development system 120 can display the internal structure of different applications in a structured manner, which facilitates the retrieval of metadata types.

[0325] 2) Attribute tables of metadata type.

[0326] In one optional implementation, the attribute table of the metadata type is used to store class attribute data for each metadata type. As shown in Table 4 below, Table 4 is an example of the attribute table of the metadata type provided in this application. The attribute table of the metadata type records the class code field, class attribute identifier field, class attribute code field, and class attribute name field of the metadata type.

[0327] The metadata type's class identifier field provides the class code of the metadata type to which the class attribute belongs. The class attribute identifier field provides the class attribute ID. The class attribute code field provides the class attribute code (ATTR CODE). The class attribute name field provides the class attribute name (ATTR NAME).

[0328] Similar to the metadata type table mentioned above, each field in the attribute table of the metadata type (the class identifier field, class attribute identifier field, class attribute code field, or class attribute name field of the metadata type) includes the attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition. As shown in Table 4 below, the class attribute identifier field includes the attribute name CLASS ATTR ID, the converted physical field name CLASS_ATTR_ID, the data type: number, the data length: 0, the primary key identifier: Y, and the business definition: class attribute identifier.

[0329] Table 4

[0330]

[0331]

[0332] Table 4 above is only one possible implementation of the attribute table for metadata type. In another embodiment, the attribute table for metadata type may include more fields than those in Table 4. This application embodiment does not limit this.

[0333] For example, as shown in Table 5 below, Table 5 is a schematic diagram of the attribute table for the metadata type provided in this application. Compared with the attribute table for the metadata type provided in Table 4, the attribute table for the metadata type in Table 5 also includes the class attribute description field ATTR DESC, the class attribute type field ATTR TYPE, the class attribute key ATTR KEY, the class attribute default value ATTRDEFAULT VALUE, the search identifier, the valid identifier, the creator field, the creation time field, the modifier field, and the modification time field.

[0334] The class attribute description field provides descriptive information about the class attributes.

[0335] The class attribute type field is used to provide the type of the class attribute. The types of class attributes include: integer, floating-point, boolean, or character.

[0336] The key of a class attribute is used to indicate the key corresponding to the class attribute in the multi-tenant application development system 120. The default value of a class attribute is used to indicate the initial value of the class attribute corresponding to the class attribute in the multi-tenant application development system 120.

[0337] Table 5

[0338]

[0339] Table 5 above is merely illustrative and should not be construed as limiting the attribute table of the metadata type provided in this application. In practical applications, the attribute table of the metadata type may include more or fewer fields than those in Table 6 above, and the name of each field may also have other forms, which are not limited in this embodiment.

[0340] For example, as described above Figure 6 Taking the metadata types shown as an example, we define the class attribute names and type attribute identifiers for each metadata type in Table 3 above, forming the attribute table for the metadata types shown in Table 6 below. Table 6 records six class attribute data entries. Each class attribute data entry includes a class attribute identifier, class attribute name, class code, valid identifier, class attribute code, and tenant identifier. Taking entity attributes as an example: The class attributes of an entity with the class code ENTITY include an entity name attribute and an entity identifier attribute. Specifically, in the class attribute data of the entity identifier attribute, the class attribute identifier is 1, the class attribute name is entity asset ID, the valid identifier is 1, the class attribute code is ENTITY-ID, and the tenant identifier is XXA. In the class attribute data of the entity name attribute, the class attribute identifier is 2, the class attribute name is entity asset name, the valid identifier is 1, the class attribute code is ENTITY-NAME, and the tenant identifier is XXA.

[0341] Table 6

[0342]

[0343] Based on Tables 4 to 6 above, it can be seen that the multi-rent application development system 120 stores attributes of different metadata types and associates the class attribute identifiers of different attributes with the class identifiers of the metadata types to which the attributes belong, thus establishing a relationship between metadata types and attributes of metadata types, which facilitates the retrieval of attributes of different metadata types in the multi-rent application development system 120.

[0344] 3) Relationship table between metadata types.

[0345] In one optional implementation, the association table between metadata types is used to store class relationship data between different metadata types. As shown in Table 7 below, Table 7 is an illustration of the association table between metadata types provided in this application. The association table between metadata types includes the class relationship identifier field REL ID, the class relationship name field REL NAME, the class relationship code field REL CODE, the source class identifier FROM CLASSCODE, the target class identifier TO CLASS CODE, the relationship type identifier REL TYPE, and the relationship application scenario field SCOPE.

[0346] The class relationship identifier field provides the class relationship identifier. The class relationship name field provides the class relationship name. The relationship application scenario field provides the relationship application scenario. As shown in Table 7 below, the relationship application scenarios include inner scenarios and extend scenarios. In an inner scenario, both related metadata types can be standard metadata types, or both related metadata types can be custom metadata types. In an extend scenario, the two related metadata types can be a standard metadata type and a custom metadata type, respectively. Standard metadata types refer to the metadata types provided by the multi-tenant application development system 120 for implementing general functions. Custom metadata types refer to the metadata types customized by the tenant through the multi-tenant application development system 120.

[0347] In some alternative approaches, the application scenario of the relationship may also be referred to as the relationship scope or other names, which will not be simplified in the embodiments of this application.

[0348] Similar to the metadata type table above, in the association table between metadata types, each field (class relationship identifier field, class relationship name field, source class identifier, target class identifier, relationship type identifier, or relationship application scenario field) includes the attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition. As shown in Table 7 below, the class relationship identifier field includes the attribute name REL ID, the converted physical field name REL_ID, the data type: number, the data length: 0, the primary key identifier: Y, and the business definition: class relationship identifier.

[0349] Table 7

[0350]

[0351]

[0352] Table 7 above is only one possible implementation of the association table between metadata types. In another embodiment, the association table between metadata types may include more fields than Table 7. This application embodiment does not limit this.

[0353] For example, as shown in Table 8 below, Table 8 is a schematic diagram of the relationship table between metadata types provided in this application. Compared with the relationship table between metadata types provided in Table 7, the relationship table between metadata types in Table 8 may also include the class relationship description field REL DESC, the valid identifier, the creator field, the creation time field, the modifier field, and the modification time field.

[0354] The class relationship description field is used to provide class relationship description information.

[0355] Table 8

[0356]

[0357] Table 8 above is merely illustrative and should not be construed as limiting the association table between metadata types provided in this application. In practical applications, the association table between metadata types may include more or fewer fields than those in Table 8 above, and the name of each field may also have other forms, which are not limited in this embodiment.

[0358] For example, as described above Figure 6 Taking the metadata type shown above as an example, in the above Figure 6 The table includes three types of relationships: API type containing API input parameter metadata type, API input parameter metadata type dependent entity A, and API type dependent entity B. Based on Tables 3 and 6 above, the following Table 9 shows the relationship table between metadata types. Table 9 shows three class relationship data entries: R01, R02, and R03. Specifically, in R01, the class relationship code is R01, the class relationship name is API containing API input parameters, the source class code is API, the target class code is API_INPUT, the relationship type is composition, and the tenant identifier is XXA. In R02, the class relationship code is R02, the class relationship name is API input parameter dependent entity A, the source class code is API_INPUT, the target class code is ENTITY, the relationship type is dependency, the relationship application scenario is extend, and the tenant identifier is XXA. In R03, the class relationship code is R03, the class relationship name is API dependent entity B, the source class code is API, the target class code is ENTITY, the relationship type is dependency, the relationship application scenario is inner, and the tenant identifier is XXA.

[0359] Table 9

[0360]

[0361] Based on Tables 7 to 9 above, it can be seen that the multi-tenant application development system 120 records the relationships between different metadata types in the form of a relationship table between metadata types. In this way, it can extract the relationships between different metadata instances from the metadata based on the relationship table between metadata types. As a result, the multi-tenant application development system 120 can evaluate the impact of version upgrades on general functions and tenant customized functions during the application update or general function update process, ensure the backward compatibility of the new version application, and improve the reliability and stability of the multi-tenant application.

[0362] Based on Tables 1 to 9 above, the following combines... Figure 9 The implementation method of the data in the 120-defined metamodel of the multi-tenant application development system is illustrated by example.

[0363] Please see Figure 9 , Figure 9 The flowchart for the data of the definition meta-model provided in this application includes steps S111 to S113.

[0364] S111, the multi-tenancy application development system 120 is based on the meta-meta-model, forming multiple meta-models.

[0365] Meta-meta-models are used to describe the rules of different meta-models. Different meta-models provide different metadata structure definitions and metadata relationship definitions.

[0366] The metadata structure definition describes the various metadata types included in the application, the details of each metadata type, and the content that tenants can customize in the application.

[0367] "Tenant-customizable content" can be instances of metadata that tenants can customize. Details for each metadata type include its attributes or data validation rules.

[0368] like Figure 8 As shown, the multi-tenant application development system 120 defines the metadata types included in application A: entities, services, APIs, interfaces, processes, rules, and controls. Taking the metadata type entity as an example, it defines the entity attributes (attribute name, attribute type, and data length), data validation rules (rule name, triggering time, and rule description), and reserved fields (encoding, name, and description).

[0369] Metadata relationship definitions are used to describe the association between any two metadata types among multiple metadata types.

[0370] like Figure 8As shown, the multi-tenant application development system 120 defines the relationship between entities and entity attributes as entity "combination" entity attributes, the relationship between interfaces and spaces as interface "combination" controls, and the relationship between controls and APIs as controls "depending on" APIs. Tenant 1's application depends on application A.

[0371] like Figure 9 As shown, the multi-tenant application development system 120 forms N meta-models based on the meta-meta-model. Where N is a positive integer greater than 2.

[0372] S112, the multi-tenancy application development system 120 is based on multiple meta-models, forming multiple metadata types, the attributes of each metadata type in the multiple metadata types, and the association relationships between different metadata types.

[0373] In one optional implementation, for each metamodel, the multi-tenant application development system 120 obtains multiple metadata types corresponding to the metamodel, as well as the attributes of each metadata type, based on the metadata structure definition of the metamodel. The multi-tenant application development system 120 also obtains the association relationships between different metadata types among the multiple metadata types corresponding to the metamodel, according to the metadata relationship definition of the metamodel.

[0374] As mentioned above Figure 8 As shown, for application A, the multi-tenant application development system 120 uses the metadata structure definition of application A to obtain entities, services, APIs, interfaces, processes, rules, controls, and the attributes included in each entity, service, API, interface, process, rule, and control. It also obtains the relationships between entities, services, APIs, interfaces, processes, rules, and controls based on the metadata relationship definition of application A.

[0375] like Figure 9 As shown, the multi-tenant application development system 120 forms M metadata types based on N meta-models. Where M is an integer greater than 2.

[0376] S113, the multi-tenancy application development system 120 creates meta-model data based on multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types.

[0377] In one alternative implementation, the multi-tenant application development system stores multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types based on the data storage structure defined in Tables 1 to 9 above, thus obtaining the data of the meta-model.

[0378] Compared to defining metadata types using a fixed structure, in Figure 9In the provided embodiments, the multi-tenant application development system 120 does not use a fixed structure to define metadata types. Instead, it uses a meta-meta-model to define meta-models for different metadata types. Through these defined meta-models, it obtains class data, class attribute data, and class relationship data for different metadata types. Because the meta-model has extensibility, metadata types can be modified by altering the meta-model, thus reducing the complexity of metadata type modification. Furthermore, the meta-model definition defines class relationship data between different metadata types, allowing the multi-tenant application development system 120 to utilize this class relationship data to present the application's internal structure, facilitating subsequent metadata updates and storage.

[0379] Tables 1 to 9 above, and Figure 8 This document primarily provides an exemplary description of the data structure of the defined metamodel and metadata in the multi-tenant application development system 120. The following section, in conjunction with Tables 1 to 9 above, provides an exemplary description of how the multi-tenant application development system 120 stores metadata.

[0380] Please see Figure 10 , Figure 10 Flowchart of the method for storing metadata provided in this application Figure 1 The method for storing metadata shown includes steps S121 to S123.

[0381] S121, the multi-tenant application development system 120 receives the metadata of the first application.

[0382] In one alternative implementation, the first application can be an application custom-developed by the tenant on the multi-tenant application development system 120. (As described above.) Figure 6 APIs in, or the above Figure 8 Application A.

[0383] In one optional implementation, the metadata of the first application is used to describe the basic information of the first application and the data of its components. The basic information of the first application may include, but is not limited to, the application name, metadata name, metadata identifier, and metadata content. The components of the first application may include, but are not limited to, entities, services, APIs, interfaces, processes, rules, and controls used in the first application. In another optional implementation, the metadata of the first application includes metadata information and relationship information. The metadata information provides the basic information of the first application and the data of its components, while the relationship information provides the associations between the metadata elements in the first application.

[0384] In some alternative approaches, the metadata of the first application may also be referred to as the metadata of the first application or other names, and this application embodiment does not limit this.

[0385] In one alternative approach, both metadata and dependency information are unstructured data.

[0386] For example, the first application described above is used as an example. Figure 6 For example, in the API, such as Figure 11 As shown, the metadata of the first application includes API metadata information and API dependency information. The API metadata information includes: Application Name: qySaasTsetAPP_master, Metadata Type: Service, Metadata Identifier: tenantapi, Metadata Content {Service Name: tenantAPI, Metadata Identifier: tenantapi, Input Parameter Metadata: entity}. The API dependency information includes: the input parameter metadata of the API metadata tenantAPI depends on the entity entity of the standard application, and the API metadata tenantAPI depends on the custom entity tenantEntity in the API metadata tenantAPI.

[0387] In one alternative implementation, the metadata of the first application can be actively acquired by the multi-tenant application development system 120.

[0388] In one alternative approach, the multi-tenant application development system 120 provides different metadata types to tenants. Tenants then develop applications within the multi-tenant application development system 120 based on these different metadata types, forming the metadata of a first application. The multi-tenant application development system 120 then retrieves the metadata of the first application.

[0389] For example, such as Figure 12 As shown, the multi-tenancy application development system 120 provides, for example... Figure 12 The interface shown in Figure (a) is as follows. The interface displays a menu area, a search area, and a content area.

[0390] The menu area displays the application services that the application provides, such as... Figure 12 As shown in Figure (a), the menu area displays the fields "This Service," "Other Services," and "Public." Figure 12 The application provided in Figure (a) is the application provided by this service.

[0391] The search area provides application search functionality, such as searching by application name (or service name), or by API functionality. Figure 12 As shown in Figure (a), the search area displays a "Name", a search input box, and a "Search" control. The "Name" field indicates that the search area provides a search function based on the application name (or service name), the search input box is used to enter the name, and the "Search" control is used to provide an application search.

[0392] The content area is used to display different metadata types. In some methods, different types of metadata can be assigned and displayed according to their respective application names, such as... Figure 12 As shown in Figure (a), the application directory is displayed in the content area.

[0393] When a tenant clicks on the application directory, the Multi-Rent Application Development System 120 provides various fields for different applications in the interface. For example... Figure 12 As shown in Figure (b), in Figure 12 Figure (b) shows the content area displaying applications A, B, C, and D. When a tenant clicks on a field of any application, the content area displays identifiers for one or more metadata types included in that application. For example... Figure 12 As shown in Figure (c), when a tenant clicks on a field of application A, the content area displays the metadata types included in application A: user interface, API, service, and "custom" controls for each metadata type.

[0394] Additionally, in some implementations, the multi-tenant application development system 120 may also provide tenants with a subset of multiple metadata types. For example, the multi-tenant application development system 120 selects one or more metadata types from multiple metadata types that meet the tenant's needs. The multi-tenant application development system 120 then provides tenants with one or more recommended metadata types.

[0395] Tenant requirements can refer to metadata requirements, which may include, but are not limited to, application type, application name to which the metadata type belongs, and the functions implemented by the application.

[0396] Please continue reading. Figure 12 Tenants input customized operations based on the "customization" control in the interface, such as... Figure 12 As shown in Figure (c), tenants input custom operations using the API-based "customization" control. The multi-tenant application development system 120 responds to custom operations via the metadata type API, providing features such as... Figure 12 The metadata customization interface is shown in Figure (d). This interface displays the API name input box, API function input box, API call protocol input box, API parameter input box, API association input box, "Return" control, and "Confirm" control.

[0397] Tenants can click on the API name input box, API function input box, API call protocol input box, API parameter input box, or API relationship input box to enter the corresponding data content, and then click the "Confirm" control to confirm the operation. In response to the confirmation operation, the Multi-Tenant Application Development System 120 generates metadata for the API based on the data entered by the tenant.

[0398] The above Figure 12 The interface interaction method selected by the multi-tenant application development system 120 for obtaining the metadata of the first application is only one option. In other embodiments, the multi-tenant application development system 120 may also use other interface interaction methods to obtain the metadata of the first application. This application embodiment does not limit this. For example, the multi-tenant application development system 120 may provide tenants with multiple metadata types. Tenants can customize different components in the application through drag-and-drop operations and configure the detailed information of different components. The multi-tenant application development system 120 obtains the metadata of the application based on the different components customized by the tenant in the application, the detailed information of the different components, and the logical relationships between the different components.

[0399] In another alternative implementation, the multi-tenant application development system 120 obtains application description information uploaded by tenants. The multi-tenant application development system 120 provides candidate metadata types that match the application description information. Tenants then customize metadata based on these candidate metadata types to form the metadata for the first application.

[0400] The application description information describes the functions implemented by the tenant's first application to be developed, the environment in which it runs, etc.

[0401] In some optional ways, tenants can upload application description information to the multi-tenant application development system 120 through the aforementioned tenant client.

[0402] The two optional implementation methods described above are merely different ways for the multi-tenant application development system 120 to obtain the metadata of the first application. In other embodiments, the multi-tenant application development system 120 may also use other implementation methods to obtain the metadata of the first application, such as receiving a script of the first application uploaded by a tenant, parsing the data content in the script, and obtaining the metadata of the first application. For example, the multi-tenant application development system 120 may receive the metadata of the first application uploaded by a tenant. This application embodiment does not limit this.

[0403] S122, the multi-tenancy application development system 120 parses metadata based on the meta-model data and extracts instance data from the metadata.

[0404] In one optional implementation, the instance data includes the relationships between different metadata instances across multiple metadata instances. In another optional implementation, the instance data may further include multiple metadata instances, the attributes of each metadata instance, and the relationships between different metadata instances across multiple metadata instances.

[0405] In some alternative approaches, a metadata instance may refer to the actual metadata description of the corresponding metadata type extracted from the metadata of the first application.

[0406] In one alternative implementation, the multi-tenant application development system 120 can extract instance relationship data between metadata instances from the metadata of the first application based on various metadata types in the metadata model data to obtain instance data. Alternatively, the multi-tenant application development system 120 can extract multiple metadata instance data, instance attribute data included in each metadata instance, and instance relationship data between metadata instances from the metadata of the first application based on various metadata types in the metadata model data to obtain instance data.

[0407] For example, the multi-tenancy application development system 120 can refer to the following: Figure 14 and Figure 15 The provided embodiments extract multiple metadata instance data, instance attribute data included in each metadata instance, and instance relationship data between the metadata instances from the metadata of the first application to obtain instance data. The embodiments of this application will not be described in detail here.

[0408] S123, the multi-tenant application development system 120 stores instance data in a structured manner.

[0409] In one alternative implementation, the multi-tenant application development system 120 may store instance data in a structured manner in the aforementioned metadata storage component 55 or the aforementioned metadata storage module 74.

[0410] In one alternative implementation, similar to the structured storage method of the data in the meta-model described above, the multi-tenant application development system 120 can use one or more of the following methods to structure the instance data: relational database, column family storage, or key-value storage.

[0411] In one optional implementation, after storing instance data, the multi-tenant application development system 120 can assess the impact of the general function update on the tenant-defined metadata instances in the first application based on the instance relationship data between different metadata instances in the general metadata and instance data. This ensures compatibility between the updated general functions and the tenant-defined metadata instances, thereby ensuring the reliability of application operation and upgrades. The implementation method for the multi-tenant application development system 120 to assess the impact of the general function update on the tenant-defined metadata instances in the first application can be referenced below. Figures 17 to 21 The embodiments provided are not described in detail here.

[0412] based on Figure 10 In the provided embodiment, the multi-tenant application development system 120 extracts relevant data from the metadata of the first application and stores it in a structured manner. This facilitates metadata retrieval for the SaaS application server. Furthermore, by extracting the relationships between different metadata instances, the multi-tenant application development system 120 can obtain the relationships between application metadata instances, facilitating the analysis of the impact of multi-tenant application development and upgrades. This reduces the difficulty of assessing the impact of version upgrades on general functions and tenant-customized functions, ensures backward compatibility of new application versions, and improves the reliability and stability of multi-tenant applications.

[0413] The above Figure 9 , Figure 10 Taking the multi-tenant application development system 120 as the executing entity as an example, this application illustrates the method for storing metadata of the first application. In some optional implementations, the method for storing metadata of the first application provided in this application can also be executed by other computing devices. For example, such computing devices may include, but are not limited to: SaaS application servers, servers, virtual servers, cloud services with metadata-driven functions, cloud services with application development functions, network services, computing nodes, or other electronic devices or clusters capable of executing the method for storing metadata of the first application provided in this application.

[0414] Based on the above Figure 10 The method for storing metadata for the first application provided is described below. Figure 13 and Figure 14 This paper provides an exemplary description of how the multi-tenant application development system 120 parses the metadata of the first application. Based on this method, the paper also describes how the multi-tenant application development system 120 structures and stores instance data.

[0415] In one optional implementation, the multi-tenant application development system 120 can parse the metadata of the first application to obtain the classes, attributes, and relationships of the metadata. Based on the class data of various metadata types in the metamodel data, the multi-tenant application development system 120 obtains the target metadata type that matches the classes of the metadata. It processes the classes of the metadata according to the data rules of the class data of the target metadata type to form metadata instance data. It processes the attributes of the metadata according to the data rules of the class attribute data of the target metadata type to obtain instance attribute data of the metadata instance. It processes the relationships of the metadata according to the data rules of the class relationship data of the target metadata type to obtain instance relationship data of the metadata instance. The data instance data, instance attribute data, and instance relationship data are then used as instance data.

[0416] Here, the metadata class can refer to the metadata included in the metadata of the first application, and the metadata attribute can refer to the attribute included in each type of metadata in the first application. The metadata relationship can refer to the relationship included in the metadata of the first application. For example, as described above... Figure 11 Taking the metadata of the first application as an example, the metadata classes include: API instance and API input parameter instance. The metadata attributes include: the attribute name of the API instance, the attribute identifier of the API instance, the attribute name of the API input parameter instance, and the attribute identifier of the API input parameter instance. The metadata relationships include: the API instance contains the API input parameter instance, the API input parameter instance depends on the entity entity, and the API instance depends on the custom entity tenantEntity.

[0417] In a first optional implementation, the "target metadata type matching the class of metadata" can be a metadata type among multiple metadata types whose class name is the same as a field of the metadata class. For example, as described above... Figure 6 , Figure 11 For example, if the class of metadata is API instance and the field of API instance is API, then the target metadata type corresponding to API instance in Table 3 above is API. If the class of metadata is API input parameter and the field of API input parameter is input, then the target metadata type corresponding to API input parameter in Table 3 above is API input parameter.

[0418] In a second alternative implementation, the “target metadata type that matches the class of metadata” can also be a metadata type among multiple metadata types whose business meaning is the same as the meaning of the metadata.

[0419] In a third optional implementation, the "target metadata type matching the metadata class" can also be a metadata type that is associated with the metadata class among multiple metadata types. The metadata type associated with the metadata class can be determined with reference to the configuration table below, which will not be described in detail here.

[0420] The three optional implementation methods described above are merely different ways for the multi-tenant application development system 120 to obtain target metadata types that match the metadata class. In other embodiments, the multi-tenant application development system 120 may also use other implementation methods to obtain target metadata types that match the metadata class. This application embodiment does not limit this.

[0421] In an optional implementation, “processing the class of metadata according to the data rules of the class data of the target metadata type” can be that the multi-tenant application development system 120 refers to Table 1 or Table 2 above and fills the class name, identifier, metamodel identifier, and metadata identifier of the metadata into the class data of the target metadata type to form metadata instance data.

[0422] Similarly, "processing metadata attributes according to the data rules of the target metadata type's class attribute data" can also be that the multi-tenant application development system 120 fills the attribute identifier and attribute name of each attribute into the above-mentioned class attribute data to form instance attribute data.

[0423] "Processing metadata associations according to the data rules of class relationship data of target metadata type" can also mean that the multi-rent application development system 120 fills the table of the class of metadata that initiates the association and the class of the associated metadata into the above class relationship data to obtain the instance relationship data of the metadata instance.

[0424] The following is an example of how the multi-tenant application development system 120 parses the metadata of the first application.

[0425] In the first implementation, the multi-tenant application development system 120 can identify the data fields of the first application and extract the classes, attributes and relationships of the metadata.

[0426] In the second implementation, the multi-tenant application development system 120 can extract the classes, attributes, and relationships of metadata from the metadata of the first application based on the parsing logic of different metadata types.

[0427] The two implementation methods described above are merely different ways in which the multi-tenant application development system 120 parses the metadata of the first application. In other embodiments, the multi-tenant application development system 120 may also use other implementation methods to parse the metadata of the first application. This application embodiment does not limit this.

[0428] Regarding the first method of parsing the metadata of the first application, two optional implementation methods are provided below for illustration.

[0429] In a first alternative implementation, the multi-tenant application development system 120 can extract the classes, attributes, and relationships of metadata from the metadata of the first application based on the fields defined by the data in the aforementioned meta-model.

[0430] For example, the multi-tenancy application development system 120, based on the fields of each class of data defined in Table 1 or Table 2 above, from... Figure 11 The classes for extracting metadata from the metadata of the first application provided are: API instance and API input parameter instance.

[0431] The multi-tenancy application development system 120, based on the fields in each class attribute data defined in Table 4 or Table 5 above, from... Figure 11 Extract the attribute name and attribute identifier of the API instance, as well as the attribute name and attribute identifier of the API input parameter instance, from the metadata of the first application provided.

[0432] The multi-tenancy application development system 120, based on the fields in each class relation data defined in Table 7 or Table 8 above, from... Figure 11 The following three relationships are extracted from the metadata of the first application: API instance contains API input parameter instance, API input parameter instance depends on entity entity, and API instance depends on custom entity tenantEntity.

[0433] In a second alternative implementation, the multi-tenant application development system 120 can invoke a parsing tool to extract the classes, attributes, and relationships of metadata from the metadata of the first application. This application embodiment does not limit the specific type of parsing tool.

[0434] The two optional implementation methods described above are merely different ways of implementing the multi-tenancy application development system 120 to directly parse fields in the metadata. In other embodiments, the multi-tenancy application development system 120 may also use other implementation methods to parse fields in the metadata of the first application. This application embodiment does not limit this.

[0435] Regarding the second method of parsing metadata mentioned above, the following will combine... Figures 13 to 14 An example is provided.

[0436] In one optional implementation, the multi-tenant application development system 120 can predefine the parsing logic for each of the various metadata types. During the parsing process of the first application's metadata, the multi-tenant application development system 120 parses the first application's metadata based on the parsing logic for each of the various metadata types, extracting the metadata's class, attributes, and relationships from the first application's metadata.

[0437] The parsing logic includes parsing logic for each metadata type, parsing logic for attributes of each metadata type, and parsing logic for relationships. The metadata type parsing logic indicates the position of the metadata class within the metadata of the first application. The attribute parsing logic indicates the position of the metadata attribute within the metadata of the first application. For example, assuming the metadata of the first application is stored in JSON format, the name attribute of the entity metadata is located at the outermost layer of the JSON, and the corresponding field is: entityName. Therefore, the parsing logic for the entity metadata name attribute indicates: parse from entityName. The relationship parsing logic indicates the position of the metadata relationships within the metadata of the first application.

[0438] In one alternative approach, developers can configure parsing logic for different metadata types within the multi-tenant application development system 120. For example, the multi-tenant application development system 120 provides a parsing logic definition interface to obtain data input by developers based on this interface, thereby forming parsing logic for different metadata types.

[0439] In another alternative approach, the multi-tenant application development system 120 can automatically define parsing logic for different metadata types based on the data in the meta-model. For example, the multi-tenant application development system 120 can call a large model, using the data from the meta-model as input, and use the large model to generate parsing logic for different metadata types. As another example, the multi-tenant application development system 120 can call an expert model, using the data from the meta-model as input, and use the expert model to generate parsing logic for different metadata types. This application embodiment does not limit this approach.

[0440] The following two specific examples illustrate how the multi-tenant application development system 120 uses parsing logic to parse the metadata of the first application.

[0441] In the first example, for each metadata type among multiple metadata types, the multi-tenant application development system 120 executes the parsing logic for that metadata type to parse the metadata of the first application and obtains the parsing result. If the parsing result is empty, it is determined that the metadata corresponding to that metadata type does not exist in the metadata of the first application, and the metadata of the first application is parsed according to the parsing logic of the next metadata type. If the parsing result is not empty, attributes or relationships are extracted from the parsing result, and that metadata type is used as a class of metadata in the metadata of the first application, and the metadata of the first application is parsed according to the parsing logic of the next metadata type. This continues until the parsing logic for each of the multiple metadata types has obtained the corresponding parsing result.

[0442] In the second example, the multi-tenant application development system 120 can select candidate parsing logics from multiple parsing logics, and use the metadata type corresponding to the candidate parsing logic as the class of metadata in the first application's metadata. The multi-tenant application development system 120 executes each candidate parsing logic to parse the metadata of the first application and obtains the parsing result. It extracts the attributes or relationships of the metadata from the parsing result and then parses the metadata of the first application according to the next candidate parsing logic. This continues until all parsing logics have obtained their corresponding parsing results.

[0443] The candidate parsing logic can be the parsing logic of a metadata type that matches the metadata of the first application from among multiple metadata types. For example, the multi-tenant application development system 120 can identify the metadata types involved in the metadata of the first application and use the parsing logic (attribute parsing logic or association parsing logic) that contains the metadata type in the pre-set multi-parsing logic as candidate parsing logic.

[0444] The two examples above are just different implementations of how the multi-tenant application development system 120 uses parsing logic to parse the metadata of the first application. In other embodiments, the multi-tenant application development system 120 may also use other implementations to parse the metadata of the first application, and this application embodiment does not limit this.

[0445] In another alternative implementation, to improve the efficiency and accuracy of metadata parsing for the first application, the multi-tenant application development system 120 can form a configuration table based on the metadata of the first application, the data of the aforementioned meta-model, and the parsing logic for different metadata types. The multi-tenant application development system 120 then extracts the instance data from the metadata of the first application according to the parsing logic indicated in the configuration table. In this way, the multi-tenant application development system 120 can achieve rapid metadata parsing.

[0446] In some alternative approaches, the configuration table may also be called an adaptation table, a parsing adaptation table, or other names, and this application embodiment does not limit this.

[0447] The above configuration table is used to indicate the parsing logic of the metadata of the first application, including the parsing logic of metadata, attribute parsing logic, and association parsing logic in the metadata of the first application.

[0448] In some alternative approaches, the configuration table can be set in the parsing engine 73 or the metadata management component 54. This embodiment of the application does not limit the location of the configuration table.

[0449] The following is a combination of Tables 1 to 8 above. Figure 11 The metadata provided for the first application serves as an example of the configuration table.

[0450] In one optional implementation, the configuration table includes a first configuration table and a second configuration table. The first configuration table provides the parsing logic for each metadata type, attribute, and relationship among various metadata types. For example, as described above... Figure 11 Taking the metadata of the first application as an example, the first configuration table includes parsing logic for the metadata instance API, the API name, the API identifier, and the associated data of the API. The second configuration table is used to provide parsing logic for different relationships among various metadata types. For example, the second configuration table is used to provide parsing logic for inclusion relationships and dependency relationships. In this way, the multi-tenant application development system 120 uses the first and second configuration tables to allocate and provide parsing logic for the classes, attributes, relationships, and specific parsing logic of the associated relationships of the metadata, thereby achieving fast parsing of the metadata of the first application.

[0451] The following provides illustrative examples of the field contents in the first and second configuration tables.

[0452] 1) Illustrative description of the first configuration table.

[0453] In one optional implementation, the first configuration table includes multiple mapping data, each used to provide parsing logic for metadata classes, metadata attributes, or metadata relationships. Different mapping data correspond to different mapping objects, which can be class code, attribute code, or relationship code from the aforementioned meta-model data.

[0454] In one optional example, each piece of mapping data includes at least a mapping identifier field MAPPINGID, a mapping value field MAPPING VALUE, a mapping object type field TARGET TYPE, and a mapping object field MAPPINGTARGET.

[0455] The mapping identifier field provides an identifier for the mapping data. The mapping value field provides the location of the mapped object in the metadata of the first application, i.e., it provides the parsing logic.

[0456] The Mapping Object Type field is used to provide the type of the mapping objects included in the mapping data, where the type of the mapping object includes the class of metadata, the attribute of metadata, or the relationship of metadata.

[0457] The mapping object field is used to provide the mapping objects included in the mapping data.

[0458] In some optional methods, similar to Table 1 above, each field (mapping identifier field, mapping value field, mapping object type field, or mapping object field) in each piece of mapped data includes an attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition. Table 10 below is an example of the first configuration table provided in this application.

[0459] Table 10

[0460]

[0461] Table 10 above is only one optional example of the first configuration table. In other embodiments, the first configuration table may include more fields than those in Table 9 above. This application does not limit this. For example, relative to the first configuration table provided in Table 10 above, the first configuration table may also include an adapter encoding field, a mapping description field, a valid identifier field, a creator field, a creation time field, a modifier field, and a modification time field.

[0462] The adapter encoding field provides the adapter for resolving the mapping object. The mapping description field describes the mapping object.

[0463] The following section, in conjunction with Tables 3, 6, 9, and 10, uses the above... Figure 11 Taking the metadata of the first application as an example, a specific example of the first configuration table is provided. From the above... Figure 11 As can be seen from Tables 3, 6, and 9 above, the first configuration table needs to define the API type, attributes (API name, API identifier, API parameter name, and API parameter identifier) ​​and mapping values ​​of relationships. As shown in Table 11 below, Table 11 is a schematic diagram of the first configuration table provided in this application. Here, "root" indicates the outermost level in JSON format. Taking the mapping data of a metadata type API as an example, the mapping identifier of this API is adapter01, the mapping value is root, the mapping object type is metadata type, the mapping object is API, and the tenant identifier is XXA.

[0464] Table 11

[0465]

[0466] As shown in Tables 10 and 11 above, the multi-tenant application development system 120 utilizes class data, class attribute data, and class relationship data of different metadata types in the metamodel to form parsing logic for different mapping objects. Furthermore, the multi-tenant application development system 120 establishes the relationship between the parsing logic of different mapping objects and the code of the mapping objects based on the parsing logic of the mapping objects, forming a first configuration table. In this way, the multi-tenant application development system 120 can quickly extract the data corresponding to different mapping objects from the metadata of the first application based on the parsing logic of the mapping objects in the first configuration table, improving the efficiency of metadata parsing for the first application. Moreover, using the mapping objects in the first configuration table ensures the accuracy of the parsed data.

[0467] 2) Illustrative description of the second configuration table.

[0468] In one alternative implementation, the second configuration table is used to provide the parsing logic for composition relationships and dependency relationships, so that the multi-tenant application development system 120 can parse the relationships between various types of metadata from the metadata of the first application based on the second configuration table.

[0469] In one optional implementation, the second configuration table includes multiple relationship data, each relationship data including at least a relationship mapping identifier field, a mapping identifier field, a relationship mapping value field, a relationship class identifier field, and a mapping relationship direction field.

[0470] The Relationship Mapping Identifier field provides the Relationship Mapping ID (REL MAPPING ID), the Mapping Identifier field provides the Mapping Identifier, and the Relationship Mapping Value field provides the Relationship Mapping Value (REL DIRECTION). The Relationship Class Identifier field provides the Relationship Class Identifier (CLASSID), and the Mapping Relationship Method field provides the Mapping Relationship Direction (REL DIRECTION).

[0471] Among them, the relationship mapping identifier is used to indicate the identifier of the associated relationship data.

[0472] The mapping identifier indicates the mapping identifier of the association data in the first configuration table mentioned above.

[0473] The relationship mapping value indicates the resolution logic of the association. The relationship class identifier indicates the class identifier of the metadata in the association data; this metadata can be the metadata that initiated the association or the metadata that was associated. The mapping relationship direction indicates whether it is the initiating association (FORM) or the associated (TO). Accordingly, each association data corresponds to a source metadata type or a target metadata type.

[0474] In some optional methods, similar to Table 1 above, each field (relationship mapping identifier field, mapping identifier field, relationship mapping value field, relationship class identifier field, or mapping relationship direction field) in each piece of relational data includes the attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition. Table 12 below is an example of the second configuration table provided in this application.

[0475] Table 12

[0476]

[0477] Table 12 above is merely one optional example of the second configuration table. In other embodiments, the second configuration table may include more fields than those in Table 12 above. This application does not limit this. For example, relative to the second configuration table provided in Table 12 above, the second configuration table may also include a relationship mapping description field, a valid identifier field, a creator field, a creation time field, a modifier field, and a modification time field.

[0478] The following section, in conjunction with Tables 3, 6, 9, 10, and 12, uses the above... Figure 11 Taking the metadata of the first application as an example, a specific example of the second configuration table is provided. From the above... Figure 11 It can be seen that the API in the metadata of the first application has two relationships: the API contains API input parameters and API depends on entity B. The API input parameters in the metadata of the first application have one relationship: the API input parameters depend on entity A. Six relationship data are recorded in the second configuration table, as shown in Table Thirteen below.

[0479] Table Thirteen

[0480]

[0481]

[0482] As can be seen from Tables 12 and 13 above, the multi-tenant application development system 120 records the association relationships between different metadata in the metadata of the first application in the second configuration table, and provides different parsing logic for the association relationships. In this way, the multi-tenant application development system 120 can quickly parse the association relationships between different metadata instances in the metadata of the first application based on the second configuration table, thereby improving the parsing efficiency of the metadata of the first application.

[0483] The following description, in conjunction with Tables 10 to 13 above, illustrates the implementation method of creating the first configuration table and the second configuration table in the multi-tenancy application development system 120.

[0484] In one optional implementation, after defining multiple metadata types, the multi-tenant application development system 120 can define the parsing logic for the attributes of each metadata type and the parsing logic for the relationships between metadata types. Following the parsing logic for each metadata type, its attributes, and the relationships, the multi-tenant application development system 120 obtains an initial configuration table. After obtaining the metadata of the first application, the multi-tenant application development system 120 determines the metadata types included in the first application's metadata based on the metadata information within the first application's metadata. The multi-tenant application development system 120 selects candidate table data containing the corresponding metadata type from the initial configuration table according to the metadata type of the first application's metadata, and forms a configuration table based on this candidate table data.

[0485] The initial configuration table includes an initial first configuration table and an initial second configuration table. Correspondingly, the candidate table data includes candidate mapping data of the metadata type corresponding to the metadata of the first application, as well as candidate association data. "Forming a configuration table based on the candidate table data" can include: the multi-tenant application development system 120 forming a first configuration table based on the selected candidate mapping data, and forming a second configuration table based on the selected candidate association data.

[0486] In another optional implementation, after defining different metamodels and forming metamodel data (class data, class attribute data, and class relationship data), the multi-tenant application development system 120 defines the parsing logic for the attributes of different metadata types and the parsing logic for the relationships of metadata types under each metamodel. Based on the metamodel data of each metamodel and the parsing logic for the attributes of different metadata types and the parsing logic for the relationships of metadata types under each metamodel, the multi-tenant application development system 120 forms a configuration table.

[0487] like Figure 13 As shown, Figure 13 This is a schematic diagram illustrating the configuration table creation process provided in this application. The configuration table creation process includes stages ① to ③.

[0488] Phase ①, Multi-tenant Application Development System 120 defines meta-model FN01.

[0489] Phase ②: The multi-tenant application development system 120 defines multiple metadata types in the metamodel FN01, the class attributes of each metadata type, and the class relationships between multiple metadata types, forming a metadata type table, a metadata type attribute table, and a metadata type association table.

[0490] like Figure 13As shown, the metamodel FN01 includes various metadata types: Entity A, Attribute B, API, and User Interface. Attribute B's class attributes include: attribute name, field name, data type, length, etc. The class relationships between these metadata types include: Entity A combining Attribute B, API depending on Entity A, and User Interface depending on API.

[0491] exist Figure 13 The metadata type table records: Entity A's metamodel identifier FN01, class identifier Entity, and class name Entity A; Attribute B's metamodel identifier FN01, class identifier Attrib, and class name Attribute B; API's metamodel identifier FN01, class identifier API, and class name API; and User Interface's metamodel identifier FN01, class identifier UI, and class name User Interface.

[0492] exist Figure 13 The attribute table of the metadata type records the attributes of attribute B, which has the class identifier Attrib. These attributes include: the metamodel identifier FN01 of attribute B, the attribute name of attribute B, the class identifier Attrib of attribute B, and the class attribute data of attribute B. The class attribute data of attribute B includes: the class attribute identifier NAME for the attribute name, the class attribute type identifier PNAME for the field name, the class attribute type identifier DTYPE for the data type, and the class attribute type identifier Length for the length.

[0493] exist Figure 13 The metadata type association table records class relationship data with class relationship identifiers R01, R02, and R03. Specifically, the class relationship name for R01 is Entity A combined with Attribute B, with the source class identifier being Entity and the target class identifier being Attrib. The class relationship name for R02 is API dependent on Entity A, with the source class identifier being API and the target class identifier being Entity. The class relationship name for R03 is User Interface dependent on API, with the source class identifier being UI and the target class identifier being API.

[0494] Phase 3: The multi-tenant application development system 120 creates a configuration table based on the parsing logic of different metadata types, the metadata type table, the attribute table of metadata types, and the association table between metadata types.

[0495] The multi-tenant application development system 120 defines the parsing logic for metadata type entity A, the parsing logic for the name of attribute B, and the parsing logic for entity A combined with attribute B, forming the first configuration table. For example... Figure 13As shown, the first configuration table includes mapping data with mapping identifiers M1, M2, and M3. Mapping data M1 has a mapping object type of metadata, a mapping object of Entity, and a mapping value of XXX. Mapping data M2 has a mapping object type of class attribute, a mapping object of NAME, and a mapping value of XX1. Mapping data M3 has a mapping object type of class relationship, a mapping object of R01, and a mapping value of XX2.

[0496] The multi-tenant application development system 120 defines the relationship mapping values, mapping directions of entity A and attribute B in the association relationship between entity A and attribute B, forming a second configuration table. For example... Figure 13 As shown, the second configuration table includes relationship data with relationship mapping identifiers MM1 and MM2. In MM1, the mapping identifier is M3, the relationship mapping value is XXX, the relationship class identifier is Entity, and the mapping direction is form. In MM2, the mapping identifier is M3, the relationship mapping value is XX1, the relationship class identifier is Attrib, and the mapping direction is to.

[0497] based on Figure 13 As shown in the provided embodiments, the multi-tenant application development system 120 defines parsing logic for different metadata types and associates the parsing logic with fields in the metadata type table, the attribute table of metadata types, and the association table between metadata types to form a configuration table. By establishing the association between the parsing logic and the metadata types, the multi-tenant application development system 120 can quickly determine the parsing logic based on the metadata types contained in the metadata of the first application during the subsequent metadata parsing process of the first application, thereby improving the parsing efficiency of the first application's metadata.

[0498] Based on the above configuration tables (first configuration table and second configuration table) and the creation method of the configuration tables, taking instance data including metadata instance data, instance attribute data and instance relationship data as an example, the implementation method of the multi-tenant application development system 120 parsing the metadata of the first application is illustrated by way of example.

[0499] Please see Figure 14 , Figure 14This is a flowchart illustrating the process of parsing the metadata of a first application based on a configuration table, as provided in this application. The multi-tenant application development system 120 extracts multiple metadata instances, instance attributes of each metadata instance, and instance relationships between the multiple metadata instances from the metadata of the first application according to the parsing logic indicated by the first configuration table (S1221). The multi-tenant application development system 120 extracts relational data of these instance relationships from the metadata of the first application according to the relational relationships between the multiple metadata instances and the parsing logic indicated by the second configuration table (S1222). The multi-tenant application development system 120 forms instance data based on the multiple metadata instance data, the instance attribute data of each metadata instance, and the instance relationship data of the instance relationships (S1223).

[0500] In one alternative implementation, the multi-tenant application development system 120 extracts metadata instances, attributes of metadata instances, or associations from the metadata of the first application at the location corresponding to the parsing logic, based on the parsing logic indicated by the first configuration table.

[0501] For example, as described above Figure 11 Taking the metadata of the first application as an example, the first configuration table is shown in Table 11 above. The multi-tenant application development system 120 parses the metadata instance API from the "root" position of the first application's metadata, parses the input parameter of the metadata instance API from the "input parameter metadata" position in the "metadata content" of the first application's metadata, extracts the API identifier tenantapi from the "metadata identifier" position in the first application's metadata, and parses the API name tenantapi from the "service name" position in the "metadata content" of the first application's metadata. Similarly, it parses the API's input parameter name input and input parameter identifier input from the "input parameter metadata" position in the "metadata content" of the first application's metadata. It parses the association relationship (dependency relationship) from the "scope" position in the dependency relationship information of the first application's metadata, and parses the association relationship (inclusion relationship) from the "root" position of the first application's metadata.

[0502] In one alternative implementation, the multi-tenant application development system 120 parses the source metadata instance and target metadata instance in each association relationship from the metadata of the first application according to the parsing logic indicated by the second configuration table, and obtains the association relationship of multiple metadata instances.

[0503] Similar to the source metadata type mentioned above, a source metadata instance can refer to the metadata instance that initiates the association in an association relationship, and correspondingly, a target metadata instance can refer to the metadata instance that is being associated.

[0504] For example, still using the above... Figure 11 Taking the metadata of the first application as an example, the second configuration table is shown in Table 13 above. The multi-tenant application development system 120 parses the following relationships from the metadata of the first application: API dependent entity B, API input parameter dependent entity A, and API contains API input parameters.

[0505] based on Figure 14 In the provided embodiment, the multi-tenant application development system 120 uses configuration tables (a first configuration table and a second configuration table) to guide the parsing of the metadata of the first application, thereby improving the parsing efficiency of the metadata of the first application while ensuring the parsing accuracy of the metadata of the first application.

[0506] The above Figures 13 to 14 This document primarily illustrates the implementation method of the multi-tenant application development system 120 in parsing the metadata of the first application, using the example of extracting the classes, attributes, and relationships of metadata from the metadata of the first application based on parsing logic of different metadata types. In other embodiments, the multi-tenant application development system 120 may also employ other implementation methods to parse the metadata of the first application, such as parsing the metadata of the first application by calling a large model to obtain instance data. This application does not limit this approach.

[0507] Based on the parsing method of the example data described above, the following is an exemplary description of the structured storage method of the example data.

[0508] To better illustrate the metadata storage method of the first application provided in this application, a relational database is used as an example to exemplify the implementation of storing instance data in a multi-tenant application system. However, it should be noted that a relational database is only one implementation method for storing instance data. In other embodiments, instance data can be stored using other methods, such as storing instance data as key-value pairs, or storing instance data using column families. This application does not limit the scope of this implementation.

[0509] In one alternative implementation, the multi-tenant application development system 120 can store metadata instance data, instance attribute data, and instance relationship data in the same table, forming a metadata data table. Each row or column in the metadata data table records the metadata instance data, instance attribute data, and instance relationship data of a metadata instance.

[0510] In another optional implementation, when there are many metadata instances or many attributes of metadata instances, to facilitate subsequent hierarchical relationship analysis and metadata instance retrieval, the multi-tenant application development system 120 can store metadata instance data, instance attribute data, and instance relationship data between metadata instances in different tables. For example, the multi-tenant application development system 120 includes an instance table, an attribute table, and a relationship table. The multi-tenant application development system 120 uses the instance table, attribute table, and relationship table to store metadata instance data, instance attribute data, and instance relationship data between metadata instances, respectively.

[0511] The instance table can be stored in the instance storage unit 551, and the attribute table can be stored in the instance attribute storage unit 552. The relationship table can be stored in the instance relationship storage unit 553. Alternatively, the instance table, attribute table, and relationship table can be stored in the metadata storage module 74. This embodiment does not limit the location of the instance table, attribute table, and relationship table.

[0512] Additionally, an instance table can also be called an instance data table, a metadata instance table, or other names, and this application embodiment does not limit this. Similarly, an attribute table can also be called an instance attribute table or other names, and a relationship table can also be called an instance relationship table or other names, and this application embodiment does not limit this.

[0513] The following provides illustrative examples of the fields in the instance table, attribute table, and relation table.

[0514] 1) Example representation.

[0515] The instance table is used to store the metadata instance data for each metadata instance in the various metadata instances of the instance data.

[0516] In some optional implementations, as shown in Table 14 below, Table 14 is an example of an instance table provided in this application. In Table 14, each metadata instance data includes at least the following: metadata instance identifier field, metadata instance name field, class code field, metadata identifier field, tenant identifier field, and application identifier field.

[0517] The metadata instance identifier field provides the INSTANCE ID. The metadata instance name field provides the INSTANCE NAME. The class code field provides the class code for the metadata type corresponding to the metadata instance. The metadata identifier field provides the RESOURCE ID. The tenant identifier field provides the TENANT ID for the first application. The application identifier field provides the APP ID for the first application.

[0518] In an alternative approach, as shown in Table 14 below, each field (metadata instance identifier field, metadata instance name field, class code field of the metadata type corresponding to the metadata instance, metadata identifier field, tenant identifier field, or application identifier field) includes the attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition.

[0519] Table 14

[0520]

[0521] Table 14 above is only one optional form of the instance table. In other embodiments, the instance table may include more or fewer fields than those in Table 14. This application does not limit this. For example, based on the instance table provided in Table 14 above, the instance table may also include a creator field, a creation time field, a modifier field, and a modification time field. The content and corresponding functions of the creator field, creation time field, modifier field, and modification time field can be referred to the embodiments provided in Table 2 above, and this application will not elaborate further.

[0522] For example, as described above Figure 11 Taking the metadata of the first application as an example, the metadata of the first application includes two metadata instance APIs and API input parameters. The multi-tenant application development system 120 extracts the metadata instance API as tenantapi and the API input parameter as input from the metadata of the first application. Combining the class code corresponding to the metadata instance API and API input parameter in Table 3 above, the instance table shown in Table 15 is formed.

[0523] Table 15

[0524]

[0525] In Table 15 above, the tenant identifier is XXA, and the application identifier where the API is located is app1.

[0526] As can be seen from the example tables provided in Tables 14 and 15 above, when storing metadata instance data, the multi-tenant application development system 120 stores not only the identifier and name of the metadata instance, but also the metadata instance, the class code of the metadata type corresponding to the metadata instance, the tenant identifier, and the application identifier. This establishes the association between the metadata instance and the class code of the corresponding metadata type, the tenant identifier, and the application identifier, so that the multi-tenant application development system 120 can quickly determine the data format followed by the metadata instance, the functions implemented, the application to which it belongs, and the corresponding tenant based on the metadata instance data in the example table, thereby realizing the governance of applications of different tenants.

[0527] 2) Example of attribute representation.

[0528] In one optional implementation, the attribute table is used to store the instance attributes included in each of the multiple metadata instances. It includes multiple instance attribute data, and each instance attribute data corresponds to one instance attribute. As shown in Table 16 below, Table 16 is an example of the attribute table provided in this application. In Table 16, each instance attribute data includes at least: an instance identifier field, an instance attribute identifier field, a class attribute identifier field, and an instance attribute value field.

[0529] The instance identifier field provides the instance identifier INSTANCE ID of the metadata instance. The instance attribute identifier field provides the instance attribute identifier INST ATTR ID of the metadata instance. The class attribute identifier field provides the class attribute identifier CLASS ATTR CODE corresponding to the instance attribute. The instance attribute value field provides the value INST VALUE of the instance attribute in the metadata of the first application.

[0530] "The identifier of the class attribute corresponding to the instance attribute" can refer to the identifier of the class attribute that matches the instance attribute in the attribute table of the aforementioned metadata. For example, taking the attribute table of the metadata type provided in Table 6 above as an example, the class attribute identifier field of the name of the metadata instance API is the identifier API_NAME of the API asset name in the attribute table of the aforementioned metadata type.

[0531] In an alternative approach, as shown in Table 16 below, each field (Instance Identifier Field, Instance Attribute Identifier Field, Class Attribute Identifier Field, Instance Attribute Value Field) includes the attribute name, the converted physical field name, the data type, the data length, the primary key identifier, and the business definition.

[0532] Table 16

[0533]

[0534] Table 16 above is only one optional representation of the attribute table. In other embodiments, the attribute table may include more or fewer fields than those in Table 16. This application does not limit this. For example, based on the attribute table provided in Table 16, the attribute table may also include a metadata identifier field, a creator field, a creation time field, a modifier field, and a modification time field. The content and corresponding functions of the creator field, creation time field, modifier field, and modification time field can be referred to the embodiments provided in Table 2 above, and this application will not elaborate on them. The content of the metadata identifier field can be referred to the embodiments provided in Table 14 above, and this application will not elaborate on them.

[0535] For example, as described above Figure 11 Taking the metadata of the first application as an example, combined with the first configuration table provided in Table 11 above, we can see that the metadata of the first application includes four instance attributes: API name, API identifier, API input parameter name, and API input parameter identifier. Based on the class attribute identifiers of each attribute in the attribute table of the metadata types provided in Table 6 above, and the instance identifiers of each metadata instance in Table 15, the multi-tenant application development system 120 forms the attribute table shown in Table 17 below.

[0536] Table 17

[0537] INST_ATTR_ID INSTANCE_ID INST_VALUE CLASS_ATTR_ID Attr01 D01 tenantapi API-NAME Attr02 D01 tenantapi API-ID Attr04 D02 input API_INPUT_NAME Attr05 D02 input API_INPUT_ID

[0538] As shown in the example tables provided in Tables 16 and 17 above, when storing instance attribute data of metadata instances, the multi-tenant application development system 120 stores not only the identifier and name of the instance attributes of the metadata instance, but also the identifier of the class attribute corresponding to the instance attribute of the metadata instance in the metamodel data, as well as the instance identifier of the metadata instance. This establishes a relationship between metadata instance → instance attribute → class attribute identifier. This allows the multi-tenant application development system 120 to quickly locate the data format followed by the instance attribute and the functions implemented, based on the instance attributes of the metadata instance.

[0539] 3) Example of a relational table.

[0540] In one optional implementation, a relation table is used to store instance relationships between multiple metadata instances. This table includes multiple instance relationship data, with different instance relationship data corresponding to different associations. As shown in Table 18 below, which is an example of a relation table provided in this application, each instance relationship data in Table 18 includes at least: an instance relationship identifier field, a first instance identifier field, a second instance identifier field, and a class relationship identifier field.

[0541] The instance relationship identifier field provides the INST REL ID for the instance relationship. The first instance identifier field provides the FROM INST ID of the first metadata instance that initiated the association in the metadata of the first application. The second instance identifier field provides the TO INST ID of the second metadata instance associated with the first metadata instance. The class relationship identifier field provides the REL CODE of the class relationship that matches the association relationship corresponding to this instance relationship data in the association table between metadata types.

[0542] In some alternative approaches, the first metadata instance may also be referred to as the source metadata instance or other names, and this application embodiment does not limit this. Correspondingly, the second metadata instance may also be referred to as the target source data instance or other names, and this application embodiment does not limit this.

[0543] This application does not limit the specific type of the second metadata instance. In some embodiments, the second metadata instance can be any one of multiple metadata instances of the first application's metadata that is associated with the first metadata instance. In other embodiments, the second metadata instance can also be a general metadata instance provided by the multi-tenant application development system 120. Furthermore, in some embodiments, the second metadata instance can also be a custom metadata instance uploaded by a tenant to the multi-tenant application development system 120.

[0544] The "generic metadata instance" is used to implement the general functions of the first application. These general functions can be called by applications of different tenants. Accordingly, the generic metadata instance can be associated with the metadata instances of different tenants.

[0545] A "custom metadata instance" is used to implement custom functionality within the first application. This custom functionality cannot be invoked by applications other than the first application, or it can only be invoked by applications with the necessary permissions. Accordingly, the custom metadata instance supports association with metadata instances within the first application, but not with metadata instances from other applications. Alternatively, the custom metadata instance supports association with metadata instances that have the necessary permissions.

[0546] The “application with calling permission” can include the first application and other applications with calling permission besides the first application. The corresponding “metadata instance with associated permission” can include the metadata instance of the first application and the metadata instances of other applications with calling permission besides the first application.

[0547] In some optional methods, the setting of calling permissions and associated permissions is not limited. For example, calling permissions and associated permissions can be specified by the tenant when developing the first application. Alternatively, calling permissions and associated permissions can also be set by the multi-tenant application development system 120 itself. Furthermore, calling permissions and associated permissions can also be requested by tenants of applications other than the first application from the tenant of the first application. This application embodiment does not limit this.

[0548] Table 18

[0549]

[0550]

[0551] Table 18 above is only one optional representation of the relationship table. In other embodiments, the relationship table may include more or fewer fields than those in Table 18. This application does not limit this. For example, based on the relationship table provided in Table 18, the relationship table may also include a creator field, a creation time field, a modifier field, and a modification time field. The content and corresponding functions of the creator field, creation time field, modifier field, and modification time field can be referred to the embodiments provided in Table 2 above, and this application will not elaborate further.

[0552] For example, as described above Figure 11 Taking the metadata of the first application as an example, combined with the second configuration table provided in Table 12 above, we can see that the metadata of the first application includes three instance relationships: API dependency entity B, API input parameter dependency entity A, and API containing API input parameters. Based on the class identifiers of various relationships in the metadata type association table provided in Table 9 above, and the instance identifiers in Table 15, the multi-tenant application development system 120 forms the relationship table shown in Table 19 below.

[0553] Table 19

[0554] INST_REL_ID FROM_INST_ID TO_INST_ID REL_ID Rel01 D01 D02 R01 Rel02 D02 E03 R02 Rel02 D01 E04 R03

[0555] As can be seen from the example tables provided in Tables 18 and 19 above, the multi-tenant application development system 120 stores instance relationship data of metadata instances in a structured manner. In the instance relationship data storage, the source metadata instance and target source data instance in each relationship are recorded to form a multi-level metadata relationship of the first application. This allows the impact on the metadata instances to be assessed by utilizing the multi-level metadata relationship of the first application when the first application is governed or when the general function of the first application is upgraded. This ensures backward compatibility of the new version of the application and improves the reliability and stability of the multi-tenant application.

[0556] In one optional implementation, the multi-tenant application development system 120 refers to the data formats defined in Tables 14 to 19 above to perform structured storage of instance data, forming metadata. To better illustrate the relationship between the metadata and the data in the aforementioned meta-model, the following section combines... Figure 13 The provided configuration table creation process provides an exemplary illustration of the metadata processing logic for the first application stored in the multi-tenant application development system 120.

[0557] Please see Figure 15 , Figure 15 This is a schematic diagram illustrating the process of storing instance data provided in this application. The process of storing instance data shown is described above. Figure 13 The provided configuration table creation process also includes stages ④ to ⑤.

[0558] Phase 4: The multi-tenant application development system 120 receives the metadata of the first application.

[0559] Phase 5: The multi-tenant application development system 120 parses metadata instances, instance attributes, and instance relationships between metadata instances from the metadata of the first application based on the configuration table, forming an instance table, an attribute table, and a relationship table.

[0560] like Figure 15 As shown, the multi-tenant application development system 120 obtains the metadata instance corresponding to entity A from the outermost layer of the root corresponding JSON of the first application's metadata: customer A. The instance identifier of the metadata instance: inst01, the instance name: customer A, the class identifier of entity A: Entity, and the tenant identifier XXA are stored as a record in the instance table.

[0561] The multi-tenant application development system 120 is based on the parsing logic of attribute B in the first configuration table. It retrieves the metadata instance corresponding to attribute B (customer name) from the "fieldName" field of the "assetJson" metadata of the first application. The instance identifier (inst02), instance name (customer name), class identifier (Attrib) of attribute B, and tenant identifier (XXA) of the metadata instance are then stored as a single instance data entry in the instance table.

[0562] Furthermore, the multi-tenancy application development system 120 stores the instance attribute identifier: instAttri02, the class attribute identifier NAME of attribute B, the instance identifier of attribute B: inst02, the instance attribute value: customer name, and the tenant identifier XXA as a single instance attribute data in the attribute table.

[0563] Furthermore, based on the parsing logic of the association relationship between entity A and attribute B in the second configuration table, the multi-tenant application development system 120 parses the source metadata instance as entity A and the target metadata instance as attribute B from the metadata of the first application. The multi-tenant application development system 120 stores the instance relationship identifier instRel01, the class relationship identifier of the association relationship between entity A and attribute B in the metadata type association relationship table: R01, the first metadata instance identifier: inst01, the second metadata instance identifier: inst02, and the tenant identifier XXA as a single instance relationship data in the relationship table.

[0564] based on Figure 15As can be seen from the provided embodiments, during the process of extracting and storing instance data, the multi-tenant application development system 120 utilizes the data content defined in the meta-model and the parsing logic defined in the configuration table to extract instance data from the metadata of the first application. The instance data is then structured and stored according to the data content defined in the meta-model and the data format of the data tables (instance tables, attribute tables, or relationship tables), transforming the unstructured metadata of the first application into structured metadata. This facilitates the retrieval of metadata instances and the analysis of their relationships, thereby providing a data foundation for subsequent metadata relationship analysis.

[0565] To better illustrate the metadata storage method of the first application provided in this application, the following is combined with... Figure 16 An exemplary description is provided of the overall process for storing the metadata of the first application.

[0566] Please see Figure 16 , Figure 16 Flowchart of the metadata storage method provided in this application Figure 2 The metadata storage method includes steps S181 to S185.

[0567] S181, Metamodel Definition.

[0568] In one alternative implementation, the multi-tenant application development system 120 can refer to the above. Figure 9 The provided embodiments define different meta-models. This application's embodiments will not elaborate further on these.

[0569] S182, Meta-model parsing logic definition.

[0570] In one alternative implementation, for each metamodel, the multi-tenant application development system 120 defines the parsing logic for each metadata type in the metamodel, forming the configuration table (first configuration table or second configuration table) mentioned above.

[0571] S183, obtain the metadata of the first application.

[0572] In one alternative implementation, the tenant develops metadata based on the multi-tenant application development system 120 to form the metadata of the first application (S1831). The multi-tenant application development system 120 obtains the metadata of the first application (S1832).

[0573] In some methods, the multi-tenant application development system 120 passes the metadata of the first application to the parsing engine 73. The parsing engine 73 executes the following steps S184 and S185 to store the metadata of the first application.

[0574] S184, metadata parsing, to obtain instance data.

[0575] In one optional implementation, parsing engine 73 performs metadata class parsing (S1841), metadata attribute parsing (S1842), and metadata relationship parsing (S1843) to obtain parsing results containing metadata classes, attributes, and relationships. Parsing engine 73 adapts the parsing results to the corresponding metadata type (S1844). Based on the adapted metadata type's class identifier, class attribute identifier, class relationship identifier, and parsing results, parsing engine 73 forms instance data (S1845). The parsing results include metadata instance data, instance attribute data, and instance relationship data.

[0576] In some methods, parsing engine 73 can refer to the above. Figure 13 , Figure 14 The provided embodiment creates a configuration table and executes the above based on the parsing logic in the configuration table. Figure 15 The provided embodiments perform metadata class parsing (S1841), metadata attribute parsing (S1842), and metadata relationship parsing (S1843), which will not be elaborated upon in this application embodiment.

[0577] In some methods, the parsing engine 73 can retrieve class identifiers, class attribute identifiers, and class relationship identifiers from the data of the metamodel that are compatible with the metadata of the first application, according to the mapping objects in the adaptation table. Based on the class identifiers, class attribute identifiers, and class relationship identifiers, as well as the parsing results, the parsing engine 73, with reference to the data content of the aforementioned instance data, forms metadata instance data, instance attribute data, and instance relationship data.

[0578] S185, Structured Storage Instance Data.

[0579] In one alternative implementation, the parsing engine 73 refers to the data structures defined in Tables 14 to 19 above, stores the instance metadata instance data in the instance table, stores the instance attribute data in the attribute table, and stores the instance relationship data in the relationship table, thereby achieving structured storage of the instance data.

[0580] based on Figure 15In the provided embodiment, the multi-tenant application development system 120 does not use a fixed structure to define metadata types. Instead, it utilizes a meta-meta-model to define meta-models for different metadata types, obtaining class data, class attribute data, and class relationship data of different metadata types through these defined meta-models. Furthermore, during the metadata parsing process of the first application, the multi-tenant application development system 120 uses the data content defined in the meta-model and the parsing logic defined in the configuration table to extract instance data from the first application's metadata. This instance data is then structured and stored according to the data content defined in the meta-model and the data format of the data tables (instance table, attribute table, or relationship table), transforming the unstructured metadata of the first application into structured metadata data. This facilitates the retrieval of metadata instances and the analysis of their relationships, thereby providing a data foundation for subsequent metadata relationship analysis.

[0581] The above Figures 8 to 15 This section primarily describes the implementation method of storing metadata for the first application. To better implement the technical solution provided in this application, the implementation method of updating metadata for the first application will be described below, based on the aforementioned implementation method of storing metadata for the first application.

[0582] To facilitate understanding of the technical solutions provided in this application, the following description uses updating the metadata of the first application as an example to illustrate the implementation of the method for updating the metadata of the first application. In practical applications, the multi-tenant application development system 120 runs different applications from multiple tenants, meaning that the multi-tenant application development system 120 stores multiple instance data, with different instance data corresponding to different tenant applications. For any application among the multiple applications, the multi-tenant application development system 120 can execute the method for updating the metadata of the first application to update the application. For example, when updating any general function in any application to be updated among the multiple applications, the multi-tenant application development system 120 can execute the method for updating the metadata of the first application to update the application to be updated. The application to be updated can be the first application mentioned above, or it can be other applications among the multiple applications besides the first application; this embodiment of the application does not limit this.

[0583] Please see Figure 17 , Figure 17 Flowchart of the method for updating metadata provided in this application Figure 1 The method for updating the metadata of the first application shown includes steps S191 to S193.

[0584] S191, the multi-tenant application development system 120 receives metadata for the first general function.

[0585] Among them, the first general function is the general function to be updated in the first application, such as API call function, data interaction function, user permission detection function, etc.

[0586] In one alternative implementation, the multi-tenant application development system 120 can receive metadata for a first general function sent by an external device.

[0587] In some alternative approaches, the external device can be a tenant client used by the tenant, a development client used by the developer, an operations and maintenance client used by the operations and maintenance personnel, a host or other system in the cloud platform 10, or another cloud platform. This application embodiment does not limit the specific form of the external device.

[0588] For example, taking an external device as the development client, the developer uploads the metadata of the first general function to the multi-tenant application development system 120 through the development client. Alternatively, the developer sends an update request to the multi-tenant application development platform through the development client. The multi-tenant application development system 120 responds to the update request and requests the metadata of the first general function from the development client.

[0589] In another alternative implementation, the multi-tenant application development system 120 can also receive metadata for the first general function input by developers or operations personnel.

[0590] For example, the multi-tenant application development system 120 provides a general function update interface, through which developers or operations personnel input metadata for a first general function. The multi-tenant application development system 120 then obtains the metadata for the first general function input through the general function update interface.

[0591] The two optional implementation methods described above are merely different ways for the multi-tenant application development system 120 to receive the metadata of the first general function. In other embodiments, the multi-tenant application development system 120 may also use other implementation methods to receive the metadata of the first general function. This application embodiment does not limit this.

[0592] S192, the multi-tenant application development system 120 performs compatibility testing on the metadata of the first general function based on multiple instance data, and obtains the compatibility test results.

[0593] In one alternative implementation, the compatibility test result includes: the first custom metadata instance is compatible with the metadata of the first general function. Alternatively, the compatibility test result includes: the first custom metadata instance is incompatible with the metadata of the first general function.

[0594] The first custom metadata instance is a custom metadata instance that is associated with the metadata of the first general function among multiple metadata instances. These multiple metadata instances may be metadata instances included in the first application, metadata instances included in other applications besides the first application, or metadata instances included in all applications in the multi-application development system 120. This embodiment does not limit the specific scope of the multiple metadata instances.

[0595] In one alternative approach, the multi-tenant application development system 120 can utilize instance relationship data to obtain a first custom metadata instance from multiple metadata instances. For example, the multi-tenant application development system 120 can retrieve a relationship table using the instance identifier of the metadata instance of the first general function, obtain candidate instance relationship data from the relationship table, obtain instance identifiers other than the instance identifier of the first custom metadata instance from the candidate instance relationship data, and determine the metadata instance executed by the instance identifier as the first custom metadata instance.

[0596] Among them, the candidate instance relationship data is the instance relationship data of the instance identifier of the metadata instance of the first general function contained in the relationship table.

[0597] In one alternative approach, "compatibility" can mean that changes to the metadata of the first general function do not affect the function corresponding to the first custom metadata instance. For example, there is no conflict between the first general function and the function corresponding to the first custom metadata instance, or after the metadata of the first general function changes, the output of the function corresponding to the first custom metadata instance is the same as the output of the function corresponding to the first custom metadata instance before the metadata of the first general function changed. Alternatively, the first custom metadata instance does not exhibit any anomalies after the metadata of the first general function changes.

[0598] "Incompatibility" can mean that changes to the metadata of the first general function affect the function corresponding to the first custom metadata instance. For example, there is a conflict between the first general function and the function corresponding to the first custom metadata instance, or after the metadata of the first general function changes, the output of the function corresponding to the first custom metadata instance differs from the output of the function corresponding to the first custom metadata instance before the metadata of the first general function changes. Alternatively, the first custom metadata instance may exhibit anomalies after the metadata of the first general function changes.

[0599] In an alternative implementation, the multi-tenant application development system 120 may refer to the following: Figure 18 The provided embodiments perform compatibility testing on the metadata of the first general function. The embodiments in this application will not be described in detail here.

[0600] S193, the multi-tenant application development system 120 updates the first application based on the compatibility test results and the metadata of the first general function, and obtains the second application.

[0601] In one alternative implementation, the compatibility test result indicates that the first custom metadata instance is compatible with the metadata of the first general function. The multi-tenant application development system 120 updates the first application based on the metadata of the first general function.

[0602] In some optional methods, updating the first application based on the metadata of the first general function may include: the multi-tenant application development system 120 packages the metadata of the first general function and the metadata of other general functions besides the first general function into a metadata data package. The multi-tenant application development system 120 builds a new version of the first application based on the metadata data package and releases the new version of the first application. The new version of the first application is the first application after updating the first general function. In some optional methods, the new version of the first application may also be called the updated first application, the new version of the first application, the second application, or other names; this embodiment does not limit this.

[0603] In one alternative implementation, the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function. The multi-tenant application development system 120 modifies the metadata of the first general function, and if the modified metadata is compatible with the first custom metadata instance, the multi-tenant application development system 120 updates the first application based on the modified metadata.

[0604] In one optional implementation, if the multi-tenant application development system 120 is incompatible with the metadata of the first custom metadata instance and the first general function, it outputs a test report. This allows developers or operations personnel to modify the metadata of the first general function using the test report. The multi-tenant application development system 120 obtains the modified metadata, executes step S192 as described above based on the modified metadata, and updates the first application based on the modified metadata if the modified metadata is compatible with the first custom metadata instance. If the modified metadata is incompatible with the first custom metadata instance, the multi-tenant application development system 120 outputs a new test report. This allows developers or operations personnel to modify the metadata of the first general function again using the new test report.

[0605] The test report may include fields, parameters, attributes, or communication protocols in the metadata of the first general function that are incompatible with the first custom metadata instance. Alternatively, the test report may also include the reasons for the incompatibility and modification suggestions. The reasons for incompatibility include: fields, parameters, attributes, or communication protocols in the metadata of the first general function that are incompatible with the first custom metadata instance.

[0606] In another optional implementation, if the first custom metadata instance is incompatible with the metadata of the first general function, the multi-tenant application development system 120 modifies the metadata of the first general function to form candidate metadata for the first general function. The multi-tenant application development system 120 outputs the candidate metadata of the first general function and a test report. Upon receiving confirmation from the developer or operations personnel based on the candidate metadata and test report of the first general function, the multi-tenant application development system 120 uses the candidate metadata of the first general function as the modified metadata and updates the first application based on the modified metadata.

[0607] In some optional methods, upon receiving modification operations from developers or operations personnel based on candidate metadata and test report inputs for the first general function, or upon receiving rejection operations from developers or operations personnel based on candidate metadata and test report inputs for the first general function, the multi-tenant application development system 120 provides a modification interface for the metadata of the first general function. It then obtains the modified metadata input by the developers or operations personnel based on the modification interface. Based on the modified metadata, it executes the above-described S192. If the modified metadata is compatible with the first custom metadata instance, the multi-tenant application development system 120 updates the first application based on the modified metadata.

[0608] The two optional implementation methods described above are merely different ways in which the multi-tenant application development system 120 modifies the metadata of the first general function. In other embodiments, the multi-tenant application development system 120 may also use other implementation methods to modify the metadata of the first general function, and this application embodiment does not limit this.

[0609] In an alternative implementation, the multi-tenant application development system 120 can update the first application based on the modified metadata, referring to the above-described implementation method of updating the first application based on the metadata of the first general function. This embodiment of the application will not be described in detail here.

[0610] In one alternative implementation, after the first application is updated, the multi-tenant application development system 120 can release a new version of the first application so that tenants can update their applications based on the new version of the first application and release the updated application, thereby enabling users to use the updated application through their user clients.

[0611] In one optional implementation, to ensure the stability of the updated application, the tenant can test the new version of the first application through the multi-tenant application development system 120 after the new version is released. If the test passes, the tenant's application is updated based on the new version of the first application, and the updated application is released. For example, the multi-tenant application development system 120 can adopt the following... Figure 20 and Figure 21 The provided embodiments test a new version of the first application, and the embodiments in this application will not be described in detail here.

[0612] based on Figure 17 In the provided embodiment, the multi-tenant application development system 120 conducts compatibility testing before version release, which can identify the impact of current modifications on tenant customization functions, intercept incompatible behaviors in real time, and ensure the reliability of the application.

[0613] The following is combined Figures 18 to 19 The implementation method of compatibility testing of the metadata of the first general function in the multi-tenant application development system 120 is illustrated by example.

[0614] In a first optional implementation, the multi-tenant application development system 120 performs compatibility checks on the metadata of the first general function using a compatibility development specification detection method. For example, the multi-tenant application development system 120 performs compatibility development specification checks on the metadata of the first general function. If the metadata of the first general function meets the compatibility development specification, the multi-tenant application development system 120 updates the first application according to the metadata of the first general function. If the metadata of the first general function does not meet the compatibility development specification, the multi-tenant application development system 120 modifies the metadata of the first general function.

[0615] The compatibility development specification can be a compatibility development rule pre-set in the multi-tenant application development system 120, or it can be a compatibility development rule uploaded by developers or operations personnel. Alternatively, the compatibility development specification can also be a compatibility development rule provided by a compatibility testing tool. This application embodiment does not limit the specific form or setting method of the compatibility development specification.

[0616] Compatibility development specifications include: compatibility risk specifications and prohibition specifications. "Compatibility risk specifications" indicate operations that may cause incompatibility. "Prohibition specifications" indicate operations that will cause incompatibility.

[0617] "Meeting compatibility development specifications" can mean that there are no compatibility risk specifications or prohibited specifications in the metadata of the first general function.

[0618] "Meeting compatibility development specifications" can refer to operations in the metadata of the first general function that have compatibility risk specifications.

[0619] In some alternative approaches, if there are prohibited class specification operations in the metadata of the first general function, the multi-tenant application development system 120 will not perform the update operation of the first application, but will output a prompt message to remind the developer or operations personnel to resubmit the metadata of the first general function.

[0620] In the second optional implementation, the multi-tenant application development system 120 uses a relational analysis method to perform compatibility testing on the metadata of the first general function. For example, the multi-tenant application development system 120 uses the aforementioned relational table and the instance identifier of the metadata of the first general function to select a first custom metadata instance from multiple metadata instances. Based on the operation of the metadata of the first general function, the multi-tenant application development system 120 identifies whether the metadata of the first general function will affect the function corresponding to the first custom metadata instance, thus obtaining a compatibility test result.

[0621] The two optional implementation methods described above are merely different ways for the multi-tenant application development system 120 to perform compatibility testing on the metadata of the first general function. In other embodiments, the multi-tenant application development system 120 may also employ other implementation methods for compatibility testing. This application does not limit these methods. For example, the multi-tenant application development system 120 may combine the above-mentioned compatibility development specification detection method and correlation analysis method for compatibility testing.

[0622] Regarding the implementation method of compatibility testing that combines the above-mentioned compatibility development specification detection methods and correlation analysis methods, the following section will discuss... Figure 18 An example is provided.

[0623] like Figure 18 As shown, Figure 18 This is a flowchart illustrating the compatibility testing process provided in this application. The multi-tenant application development system 120 performs compatibility development specification testing on the metadata of the first general function (S1921). If the metadata of the first general function meets the compatibility development specification, the multi-tenant application development system 120 updates the first application based on the metadata of the first general function (S1922). If the metadata of the first general function does not meet the compatibility development specification, the multi-tenant application development system 120 selects a first custom metadata instance from multiple metadata instances using instance relationship data (S1923). Based on the operation of the metadata of the first general function and the first custom metadata instance, the multi-tenant application development system 120 obtains the compatibility test result (S1924).

[0624] In one optional implementation, if the metadata of the first general function does not meet the compatibility development specifications, there may be operations in the metadata of the first general function that could cause incompatibility. To further determine whether the metadata of the first general function may cause incompatibility risks, the multi-tenant application development system 120 performs hierarchical relationship analysis based on instance relationship data to determine whether a first custom metadata instance exists among multiple metadata instances. If no first custom metadata instance exists, changes to the metadata of the first general function will not affect other functions, so the multi-tenant application development system 120 updates the first application according to the metadata of the first general function. If a first custom metadata instance exists, changes to the metadata of the first general function may affect other functions. Therefore, to ensure the stability of the updated first application, the multi-tenant application development system 120 evaluates the impact of the metadata update of the first general function on the first custom metadata instance based on the operations of the metadata of the first general function, thereby obtaining the compatibility test results. In this way, the multi-tenant application development system 120 ensures the stability of the updated first application through multiple rounds of compatibility testing.

[0625] In one alternative implementation, the multi-tenant application development system 120 can determine whether the operation of the first custom metadata instance is normal based on the operation of the metadata of the first general function. If the operation of the first custom metadata instance is normal, the multi-tenant application development system 120 determines that the compatibility test result indicates that the first custom metadata instance is compatible with the metadata of the first general function. If the operation of the first custom metadata instance is abnormal, the multi-tenant application development system 120 determines that the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function.

[0626] In this context, "the operation of the first custom metadata instance is normal" means that changes to the metadata of the aforementioned first general function will not affect the function corresponding to the first custom metadata instance. Conversely, "the operation of the first custom metadata instance is abnormal" means that changes to the metadata of the aforementioned first general function will affect the function corresponding to the first custom metadata instance.

[0627] For example, if an operation on the metadata of the first general function causes a change in the output parameters of the operation of the first custom metadata instance, then the operation of the first custom metadata instance is determined to be abnormal. Conversely, if an operation on the metadata of the first general function causes a change in the input parameters of the operation of the first custom metadata instance, then the operation of the first custom metadata instance is determined to be normal.

[0628] In one alternative example, the multi-tenant application development system 120 can determine whether the operation of the first custom metadata instance is normal based on the operation of the metadata of the first general function and the association between the metadata of the first general function and the first custom metadata instance. For example, if the first custom metadata instance depends on the metadata of the first general function, and changes in the metadata of the first general function will cause changes in the operation of the first custom metadata instance, then the operation of the metadata of the first general function is determined to be abnormal. Conversely, if the metadata of the first general function depends on the first custom metadata instance, and changes in the metadata of the first general function will not cause changes in the operation of the first custom metadata instance, then the operation of the metadata of the first general function is determined to be normal.

[0629] based on Figure 18 In the provided embodiment, the multi-tenant application development system 120 combines the above-mentioned compatibility development specification detection method and correlation analysis method to perform multi-level compatibility detection on the metadata of the first general function, thereby ensuring the stability of the updated first application.

[0630] In one alternative implementation, for metadata of a first general function that is incompatible with the first custom metadata instance, the multi-tenant application development system 120, in addition to immediately modifying the metadata of the first general function as described in S193 above, may, in other embodiments, not immediately modify the metadata of the first general function, but instead add a first tag to the metadata of the incompatible first general function, and then batch modify the metadata of general functions carrying the first tag before the release of a new version of the first application. Thus, when the number of general functions that need to be updated is large, or when the metadata content of the first general function is large, the multi-tenant application development system 120 uses the method of tagging the metadata of incompatible general functions to achieve batch modification of the metadata of general functions, shortening the time for modifying the metadata of general functions and improving the update efficiency of the first application.

[0631] The first marker is used to indicate a risk of incompatibility in the metadata of the first general function. This application does not limit the specific form of the first marker.

[0632] In some alternative approaches, “adding a first tag to the metadata of an incompatible first general function” can be done when the multi-tenant application development system 120 identifies that the metadata of the first custom metadata instance is incompatible with the metadata of the first general function, and adds a first tag to the metadata of the first general function.

[0633] In other alternative methods, "adding a first tag to the metadata of the incompatible first general function" can also be used when the multi-tenant application development system 120 identifies that the first custom metadata instance is incompatible with the metadata of the first general function, and outputs a test report to the developer or operations personnel. When the multi-tenant application development system 120 receives input from the developer or operations personnel indicating that no modification is required, it adds a first tag to the metadata of the first general function.

[0634] For example, when the first custom metadata instance is incompatible with the metadata of the first general function, the first tag is added to the metadata of the first general function. This example illustrates how the multi-tenant application development system 120 can batch modify the metadata of general functions that carry the first tag.

[0635] Please see Figure 19 , Figure 19 Flowchart of the method for updating metadata provided in this application Figure 2 In contrast Figure 18 The process of providing metadata update methods, in Figure 19 In the above-mentioned S192, the process of updating metadata also includes steps S194 to S197.

[0636] S194, if the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function, the multi-tenant application development system 120 adds a first tag to the metadata of the first general function.

[0637] In one alternative implementation, such as Figure 19 As shown, if the compatibility test result indicates that the first custom metadata instance is compatible with the metadata of the first general function, the multi-tenant application development system 120 executes S195.

[0638] S195, the metadata of multiple common functions of the first application is packaged to obtain a metadata data package.

[0639] In one alternative implementation, the multi-tenant application development system 120 performs a compatibility analysis check on the metadata data to determine whether the metadata data carries first metadata with a first tag (S198).

[0640] In one alternative implementation, during the processing of S195, to achieve complete development of the first application, the multi-tenant application development system 120 can obtain multiple metadata instances that depend on the metadata of the first general function from multiple instance data. Based on the metadata of the first general function, the multi-tenant application development system 120 modifies each of the multiple metadata instances that depend on the metadata of the first general function. The multi-tenant application development system 120 packages each modified metadata instance and metadata instances from the multiple instance data that do not depend on the metadata of the first general function to obtain a metadata data package.

[0641] In some alternative ways, modifying each metadata instance can be done by the multi-tenant application development system 120 modifying the parameters, attributes, or fields of the metadata instance according to the metadata operation of the first general function, so as to ensure that after the metadata of the first general function is modified, the metadata instance associated with the metadata of the first general function can be modified synchronously, thereby ensuring that the new version of the first application can run normally after the first general function is updated.

[0642] S196, if the first metadata exists in the metadata packet, modify the first metadata, and update the first application based on the modified first metadata and the second metadata in the metadata packet.

[0643] The first metadata is the metadata in the data packet that carries the first tag, and the second metadata is the metadata in the data packet that does not carry the first tag.

[0644] The data packet includes one or more metadata carrying a first tag, which includes the metadata of the first general function described above.

[0645] In one alternative implementation, the multi-tenant application development system 120 can modify the first metadata by referring to the implementation method of modifying the metadata of the first general function in S193 above. This application embodiment will not elaborate on this.

[0646] S197, In the absence of first metadata in the metadata data package, the multi-tenant application development system 120 builds a new version of the first application based on the metadata data package and releases the new version of the first application.

[0647] based on Figure 19The provided implementation, through compatibility analysis, allows the Multi-Tencent Application Development System 120 to identify the impact of changes in metadata for common functions on tenant-customized functions before a new version is released. It also intercepts incompatible behaviors in real time, ensuring application reliability. Furthermore, by marking incompatible metadata for common functions, it enables batch modification of metadata for these functions, shortening the time required to modify such metadata and improving the update efficiency of the primary application.

[0648] In one alternative implementation, after the multi-tenant application development system 120 releases a new version of the first application, the multi-tenant application development system 120 can test whether the tenant's custom functions are compatible with the general functions of the new version of the first application, and modify the custom functions that are incompatible with the general functions of the new version of the first application so that the modified custom functions are compatible with the general functions of the new version of the first application. This ensures that after the updated first application is released, the tenant's application can be smoothly upgraded to the new version of the first application, ensuring the stable operation of the tenant's application.

[0649] The following combination Figure 20 and Figure 21 This paper provides an exemplary description of the implementation method of a new version of the first application of the multi-tenant application development system 120.

[0650] Please see Figure 20 , Figure 20 The flowchart for testing the compatibility of a new version of the first application provided in this application includes S221 to S222.

[0651] S221, the multi-tenant application development system 120 responds to the update request of the first tenant and performs compatibility testing on the new version of the first application based on the first instance data of the first tenant.

[0652] The update request is used to request an update to the first tenant's application. "Update the first tenant's application" can mean updating common features in the first tenant's application to the common features of a new version of the first application.

[0653] The first tenant can refer to any one of the multiple tenants that subscribe to the first application. "Subscribing to the first application" can mean that a tenant purchases the common functions of the first application from the multi-tenant application development system 120, adds custom functions to the common functions of the first application, and forms the tenant's application.

[0654] The first instance data can be instance data from different tenants stored in the multi-tenant application development system 120 whose tenant identifier matches the tenant identifier of the first tenant. For example, if the tenant identifier of the first tenant is XXA, the first instance data is the instance data composed of Tables 14 to 19 above.

[0655] In one alternative implementation, the multi-tenant application development system 120 can refer to the above. Figure 18 S1923 to S1924 conduct compatibility testing on the new version of the first application.

[0656] For example, the multi-tenant application development system 120, based on the instance data of the first tenant, detects whether there is a second custom metadata instance among the multiple metadata instances of the first tenant that is incompatible with the general metadata instance of the new version of the first application. If it is determined that a second custom metadata instance exists, the multi-tenant application development system 120 modifies the second custom metadata instance to ensure that the modified second custom metadata instance is compatible with the general metadata instance of the new version of the first application.

[0657] like Figure 21 As shown, Figure 21 This is a flowchart illustrating the compatibility testing process for a custom metadata instance provided in this application. The process for performing compatibility testing on a custom metadata instance includes steps S2211 to S2215.

[0658] S2211, based on the instance relationship data in the first instance data and the general metadata instance in the new version of the first application, obtain the second custom metadata instance in the first instance data that is associated with the general metadata instance.

[0659] In one alternative implementation, the multi-tenant application development system 120 may refer to the above-described method for obtaining the first custom metadata instance to obtain the second custom metadata instance. This application embodiment does not limit this.

[0660] S2212, the multi-tenancy application development system 120 performs compatibility testing based on the second custom metadata instance and the general metadata instance.

[0661] In one alternative implementation, the multi-tenant application development system 120 can refer to the above. Figure 18 The provided embodiments undergo compatibility testing, which will not be elaborated upon in this application.

[0662] S2213 If the second custom metadata instance is incompatible with the general metadata instance, then modify the second custom metadata instance.

[0663] In one alternative implementation, the multi-tenant application development system 120 may output a second custom metadata instance that is incompatible with the generic metadata instance, so that the first tenant can modify the second custom metadata instance.

[0664] In another alternative implementation, the multi-tenant application development system 120 can refer to the above-described implementation method of modifying the metadata of the first general function to modify the second custom metadata instance. This embodiment of the application will not elaborate further on this.

[0665] S2214, assuming the modified second custom metadata instance is compatible with the general metadata instance, confirm that the new version compatibility test of the first application has passed.

[0666] S2215, if the second custom metadata instance is compatible with the general metadata instance, then the new version compatibility test of the first application is confirmed to have passed.

[0667] based on Figure 21 In the provided embodiment, the multi-tenant application development system 120, during the testing phase, utilizes instance relationship data to perform multi-level association analysis, determines the impact of application version updates on tenants' custom metadata instances, and modifies incompatible custom metadata instances to ensure smooth upgrades of tenants' applications.

[0668] S222, if the new version of the application passes the compatibility test for the first application, release the new version of the application to the tenant environment of the first tenant.

[0669] The new version of the application refers to a new version of the first application with added custom functions for the first tenant. In some optional ways, the new version of the application may also be called a third application or other names, which is not limited in this embodiment.

[0670] In one alternative implementation, the multi-tenant application development system 120 can refer to the aforementioned method for releasing a new version of the first application to the tenant environment of the first tenant. Alternatively, the multi-tenant application development system 120 can refer to the aforementioned method... Figure 19 The provided embodiments publish a new version of the application to the tenant environment of the first tenant. This application will not elaborate further on this aspect.

[0671] based on Figure 20 In the provided embodiment, after the multi-tenant application development system 120 releases a new version of the first application, the multi-tenant application development system 120 tests whether the tenant's custom functions are compatible with the general functions of the new version of the first application, ensuring that after the updated first application is released, the tenant's application can be smoothly upgraded to the new version of the first application, and ensuring the stable operation of the tenant's application.

[0672] In one optional implementation, to improve application update efficiency, the multi-tenant application development system 120 determines whether the first tenant is subscribing to the first application for the first time before receiving the first tenant's update request. If the first tenant is subscribing to the first application for the first time, the multi-tenant application development platform performs the above... Figure 21 Compatibility testing is performed, and if the compatibility test passes, the application for the first tenant is released. If the first tenant is not subscribing to the first application for the first time, the multi-tenant application development system 120 outputs a version difference notification to the first tenant based on the version of the first application already subscribed to by the first tenant and the new version of the first application. It also receives an update request from the first tenant based on the version difference notification and executes steps S221 and S222 to release the new version of the first tenant's application. Thus, for first tenants subscribing to the first application for the first time, directly performing compatibility testing between the custom metadata instance and the general metadata instance improves the efficiency of application release. For first tenants who are not subscribing to the first application for the first time, the multi-tenant application development system 120 outputs a version difference notification to the first tenant and receives the first tenant's update request, ensuring that tenants who have already subscribed to the first application can promptly obtain information about the differences between the first application and its new version.

[0673] In some alternative approaches, after the multi-tenant application development system 120 outputs a version difference notification to the first tenant, the tenant can enter a "do not update" option based on the version difference notification. In response to the "do not update" option, the multi-tenant application development system 120 continues to provide general functionality to the first tenant according to the version of the first application already subscribed to by the first tenant.

[0674] To achieve the functions described in the above embodiments, the multi-tenant application development system 120 includes hardware components and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and method steps of the examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed via hardware or computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0675] The above Figures 4 to 21This application details the multi-tenant application development system 120, the metadata storage method, and the metadata update method provided. The multi-tenant application development system 120 stores the metadata of the first application using a structured storage method, presenting the metadata of the first application to tenants in a structured manner to assist tenants in customizing their solutions and improve customization efficiency. Furthermore, the multi-tenant application development system 120 can generate multi-level metadata instance relationships within the metadata of the first application, enabling the application and the relationships between its components to be displayed in metadata form, facilitating application architecture governance. In addition, utilizing multi-level metadata instance relationships, the multi-tenant application development system 120 ensures complete application development without omissions, allowing for dynamic minimum-scale on-demand building and deployment of applications without requiring full package building, thus improving deployment efficiency. Moreover, during application updates, the multi-level metadata instance relationships are used to analyze the impact of metadata instance associations, assessing the impact of application version updates on tenants' custom metadata instances and improving the operational stability of the released application.

[0676] This application embodiment can group the multi-tenant application development system 120 into functional modules according to the above method example. For example, each functional group can be assigned to a specific functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the grouping and naming of modules in this application embodiment are illustrative. In other embodiments, the multi-tenant application development system 120 may have other naming methods.

[0677] For example, the multi-tenant application development system 120 can also be named a storage device for the metadata of the first application. Figure 22 As shown, Figure 22 This is a schematic diagram of the structure of the metadata storage device provided in this application. The metadata storage device 22 includes a storage module 223, a communication module 221, and a processing module 222. Wherein:

[0678] Storage module 223 is used for executable program code, and metadata storage device 22 for data in the metadata storage process, such as metamodel data, instance data, etc.

[0679] The communication module 221 is used to receive metadata from the first application.

[0680] The processing module 222 is used to parse the metadata of the first application based on the meta-model data, extract instance data from the metadata of the first application, and store the instance data in a structured manner in the storage module 223.

[0681] The communication module 221, processing module 222, and storage module 223 can be implemented in software or in hardware. For example, the implementation of processing module 222 will be described below. Similarly, the implementation of communication module 221 and storage module 223 can refer to the implementation of processing module 222.

[0682] As an example of a software functional unit, processing module 222 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the computing instance may be one or more. For example, processing module 222 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0683] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0684] As an example of a hardware functional unit, the processing module 222 may include at least one computing device, such as a server. Alternatively, the processing module 222 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0685] The processing module 222 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the communication module 221 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing module 222 includes multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0686] It should be noted that, in other embodiments, the processing module 222 can be used to execute any step in the metadata storage method. The communication module 221 can be used to execute any step in the metadata storage method. The storage module 223 can be used to execute any step in the metadata storage method. The communication module 221, processing module 222, and storage module 223 can all be used to execute any step in the metadata storage method. The steps implemented by the communication module 221, processing module 222, and storage module 223 can be specified as needed. By implementing different steps in the metadata storage method through the communication module 221, processing module 222, and storage module 223, all functions of the metadata storage device 22 are realized.

[0687] For example, the multi-tenant application development system 120 could also be named a metadata update device. For example... Figure 23 As shown, Figure 23 A schematic diagram of the structure of the metadata updating device provided in this application is shown above. Figure 22 Similar to the metadata storage device 22 shown, the metadata updating device 23 may also include a storage module 233, a communication module 231, and a processing module 232. The storage module 233 stores instance data for different tenants and executable program code. The communication module 231 receives metadata for the first general function. The processing module 232 performs compatibility testing on the metadata of the first general function based on multiple instance data, obtains the compatibility testing result, and updates the first application based on the compatibility testing result and the metadata of the first general function.

[0688] The implementation methods of the storage module 233, the communication module 231 and the processing module 232 can refer to the implementation method of the processing module 222 described above, and will not be repeated here in the embodiments of this application.

[0689] Furthermore, the grouping of modules in the multi-tenant application development system 120 in this embodiment is only illustrative and represents only one logical function grouping. In actual implementation, there may be other grouping methods.

[0690] For example, the multi-tenant application development system 120 may also include the aforementioned metadata storage device 22 and metadata updating device 23. The metadata storage device 22 provides instance data of different tenants to the metadata updating device 23, and the metadata updating device 23 updates the application based on the instance data of different tenants.

[0691] The implementation of the metadata storage device 22 and the metadata update device 23 can refer to the implementation of the above-mentioned processing module, and will not be described in detail in this embodiment.

[0692] This application also provides a computing device for performing the above-described method for storing metadata and / or method for updating metadata.

[0693] In one example, the computing device may include, for example: Figure 22 The metadata storage device 22 shown includes a communication module 221, a processing module 222, and a storage module 223.

[0694] In another example, the computing device may include, for example: Figure 23 The metadata updating device 23 shown includes a communication module 231, a processing module 232, and a storage module 233.

[0695] In another example, the computing device may include the aforementioned metadata storage device 22 and metadata updating device 23.

[0696] In another example, such as Figure 24 As shown, the computing device 24 includes a bus 242, a processor 244, a memory 246, and a communication interface 248. The processor 244, the memory 246, and the communication interface 248 communicate with each other via the bus 242. The computing device 24 can be a server or a terminal device. It should be understood that this application does not limit the number of processors 244 and memory 246 in the computing device 24.

[0697] Bus 242 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 24 The bus 242 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 242 may include a path for transmitting information between various components of the computing device 24 (e.g., memory 246, processor 244, communication interface 248).

[0698] The processor 244 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0699] In this application, processor 244 can perform the above-described... Figure 10 The method for storing metadata provided. For example, receiving metadata from the first application, parsing the metadata based on the data in the metamodel, obtaining instance data, and storing the instance data in a structured manner.

[0700] In this application, processor 244 can also perform the above-mentioned... Figure 16 The method for updating metadata is provided. For example, the metadata of a first general function is received, a compatibility test is performed on the metadata of the first general function based on multiple instance data, a compatibility test result is obtained, and the first application is updated based on the compatibility test result and the metadata of the first general function.

[0701] Memory 246 may include volatile memory, such as random access memory (RAM). Processor 244 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0702] The memory 246 stores executable program code, which the processor 244 executes to implement the functions of the aforementioned communication module 221, processing module 222, and storage module 223, thereby implementing a method for storing metadata. That is, the memory 246 stores instructions for executing the method for storing metadata. Alternatively, the executable program code can be executed to implement the functions of the aforementioned communication module 231, processing module 232, and storage module 233, thereby implementing a method for updating metadata. That is, the memory 246 stores instructions for executing a method for updating metadata.

[0703] The communication interface 248 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 24 and other devices or communication networks.

[0704] The interface testing method disclosed in the above embodiments can be applied to or implemented by the processor 244. The processor 244 can be an integrated circuit chip with signal processing capabilities.

[0705] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 244 or by instructions in software form. The processor 244 can be a general-purpose processor, including a CPU, a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete vacuum tubes or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of the hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 246, and the processor 244 reads the information in memory 246 and completes the steps of the above method in combination with its hardware.

[0706] In one possible implementation, the processor 244 can also be used to execute a metadata storage method. Specific implementations can be found in the embodiments provided above regarding the metadata storage method, and will not be repeated here. Furthermore, the processor 244 can also be used to execute a metadata update method. Specific implementations can be found in the embodiments provided above regarding the metadata update method, and will not be repeated here.

[0707] In this embodiment of the application, the chip system may be composed of chips or may include chips and other discrete devices.

[0708] This application embodiment also provides a computing device cluster 25 for performing the above-described metadata update method and / or metadata storage method.

[0709] In one example, the computing device cluster 25 may include the aforementioned metadata storage device 22 and metadata update device 23.

[0710] In another instance, such as Figure 25 As shown, the computing device cluster 25 includes at least one such Figure 24The computing device 24 shown includes a bus 242, a processor 244, a memory 246, and a communication interface 248. The processor 244, the memory 246, and the communication interface 248 communicate with each other via the bus 242. The computing device 24 can be a server or a terminal device.

[0711] In one possible implementation, one or more computing devices in the computing device cluster 25 can be connected via a network. This network can be a wide area network (WAN), a local area network (LAN), or similar. Figure 26 One possible implementation is shown. For example... Figure 26 As shown, computing devices 24A and 24B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 246 in computing device 24A stores instructions for performing the functions of the metadata storage device 22. Simultaneously, the memory 246 in computing device 24B stores instructions for performing the functions of the metadata update device 23.

[0712] Figure 26 The connection method between the computing device clusters shown can be considered because the method provided in this application needs to store metamodel data and instance data of different tenants during the metadata storage process, which requires a large amount of storage resources. Therefore, it is considered that the function implemented by the metadata storage device 22 is performed by the computing device 24A, and the function of the metadata update device 23 is performed by the computing device 24B.

[0713] It should be understood that Figure 26 The functions of computing device 24A shown can also be performed by multiple computing devices 24. Similarly, the functions of computing device 24B can also be performed by multiple computing devices 24.

[0714] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to execute the aforementioned metadata storage method or metadata update method.

[0715] For example, when a computer program product is run on at least one computing device, it causes the at least one computing device to perform... Figure 10 The method for storing metadata is shown.

[0716] For example, when a computer program product is run on at least one computing device, it causes the at least one computing device to perform... Figure 16 The method for updating metadata is shown.

[0717] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be implemented by a computer program instructing related hardware. This program can be stored in the computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be a terminal of any of the foregoing embodiments, such as an internal storage unit including a data transmission end and / or a data receiving end, like a hard disk or memory of the terminal. The computer-readable storage medium can also be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal. Further, the computer-readable storage medium can include both the internal storage unit and the external storage device of the terminal. The computer-readable storage medium is used to store the computer program and other programs and data required by the terminal. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0718] It should be noted that the terms "first" and "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0719] It should be understood that in this application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0720] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A. For example, B can be determined based on A. It should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information. Furthermore, the term "connection" in the embodiments of this application refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices, and the embodiments of this application do not impose any limitations on this.

[0721] Unless otherwise specified, the term "transmission" in the embodiments of this application refers to bidirectional transmission, encompassing the actions of sending and / or receiving. Specifically, "transmission" in the embodiments of this application includes sending data, receiving data, or both sending and receiving data. In other words, data transmission here includes uplink and / or downlink data transmission. Data may include channels and / or signals; uplink data transmission refers to uplink channel and / or uplink signal transmission, and downlink data transmission refers to downlink channel and / or downlink signal transmission.

[0722] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for storing metadata, characterized in that, The method is applied to a Software as a Service (SaaS) application server, which stores metamodel data, including the association relationships between different metadata types among various metadata types. The method includes: Receive metadata from the first application; Based on the data of the meta-model, the metadata is parsed to extract instance data; the instance data includes: the association relationship between different metadata instances in multiple metadata instances; The instance data is stored in a structured manner; the instance data is used to analyze the impact of general function updates in the first application on custom functions in the first application.

2. The method according to claim 1, characterized in that, The association relationships between different metadata instances in the plurality of metadata instances include: multiple instance relationship data, with different instance relationship data corresponding to different association relationships; Each instance relationship data in the plurality of instance relationship data includes: instance relationship identifier, first instance identifier, second instance identifier, and class relationship identifier; the first instance identifier is the instance identifier of the first metadata instance that initiates the association in the metadata, and the second instance identifier is the instance identifier of the second metadata instance that is associated with the first metadata instance; the second metadata instance includes a general metadata instance preset by the SaaS application server or a custom metadata instance uploaded by the user.

3. The method according to claim 1 or 2, characterized in that, The storage of the instance data in a structured manner includes: Based on the instance data, a metadata data table is formed and the metadata data table is stored; the metadata data table is used to structure and store the association relationships between different metadata instances among the multiple metadata instances.

4. The method according to claim 3, characterized in that, The instance data further includes: multiple metadata instance data and multiple instance attribute data; the metadata data table is also used to structure and store the multiple metadata instance data and the multiple instance attribute data. Different metadata instance data correspond to different metadata types; different instance attribute data correspond to different instance attributes, and each metadata instance data corresponds to one or more instance attribute data. Each metadata instance in the plurality of metadata instance data includes: instance identifier, instance name, class code, application identifier, and tenant identifier; the class code is used to indicate the code of the corresponding metadata type; Each instance attribute data in the plurality of instance attribute data includes: instance identifier, instance attribute identifier, class attribute identifier, and the value of the instance attribute.

5. The method according to any one of claims 1 to 4, characterized in that, The parsing of the metadata based on the meta-model, and the extraction of instance data from the metadata, includes: Based on the data from the meta-model, a configuration table corresponding to the first application is formed; the configuration table is used to indicate the parsing logic of the metadata. Instance data is extracted from the metadata according to the parsing logic indicated by the configuration table.

6. The method according to claim 5, characterized in that, The configuration table includes multiple relationship data, which are used to extract the relationship between different metadata instances from the metadata; Each association data corresponds to an association class code, which includes the class code of the metadata type that initiates the association or the class code of the metadata type that is associated within the same association. Each association data includes: a relationship mapping identifier, a relationship mapping value, a relationship class identifier, and a mapping direction. The relationship mapping value is used to indicate the parsing logic of the association corresponding to each association data. The mapping direction includes initiating an association or being associated.

7. The method according to any one of claims 1 to 6, characterized in that, The association relationships between different metadata types among the various metadata types include: multiple class relationship data, with different class relationship data corresponding to different association relationships; each association relationship corresponds to a metadata type group; the metadata type group includes source metadata types and target metadata types that are associated, the source metadata type indicates the metadata type that initiates the association, and the target metadata type is the metadata type that is associated. Each of the multiple class relationship data includes: class relationship identifier, relationship code, relationship name, relationship type, relationship scope, and metadata type code; The relationship types include dependency relationships or composition relationships; The relational range is used to indicate the types corresponding to the source metadata type and the target metadata type in the first metadata type group; the types include general metadata types or custom metadata types; the first metadata type group is the metadata type group corresponding to each class relation data; The metadata type code includes the class code of the source metadata type and the class code of the target metadata type in the corresponding metadata type group.

8. The method according to claim 7, characterized in that, The data in the meta-model also includes: multiple class data and multiple class attribute data; different class data correspond to different metadata types, different class attribute data correspond to different attributes, and each metadata type corresponds to at least one class attribute data; Any one of the multiple data types in the first category includes: a metamodel identifier, a metadata type identifier, a metadata type name, and a class code; wherein, the metamodel identifier is used to indicate the metamodel corresponding to the first metadata type; the metamodel is used to construct the metadata corresponding to the first metadata type; the first metadata type is the metadata type corresponding to the first data type among the multiple metadata types; the metadata type identifier is used to indicate the first metadata type, the metadata type name is used to indicate the name of the first metadata type; and the class code is used to indicate the code of the first metadata type. Each of the multiple class attribute data includes: metadata type identifier, class attribute identifier, attribute code, and attribute name.

9. The method according to any one of claims 1 to 8, characterized in that, Before receiving the metadata of the first application, the method further includes: Based on the meta-meta-model, multiple meta-models are formed; the meta-meta-model is used to describe different meta-models. Based on the multiple meta-models, multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types are formed. The data of the meta-model is created based on the multiple metadata types, the attributes of each metadata type, and the relationships between different metadata types.

10. The method according to any one of claims 1 to 9, characterized in that, After storing the instance data in a structured manner, the method further includes: Receive metadata for a first general function; the first general function is a general function to be updated in the first application; Based on the instance data, obtain the first custom metadata instance that is associated with the metadata of the first general function among the plurality of metadata instances; If the first custom metadata instance is compatible with the metadata of the first general function, then update the first general function in the first application according to the metadata of the first general function; If the first custom metadata instance is incompatible with the metadata of the first general function, then the metadata of the first general function is modified, and the first general function in the first application is updated based on the modified metadata; the modified metadata is compatible with the first custom metadata instance.

11. A method for updating metadata, characterized in that, The method is applied to a Software as a Service (SaaS) application server, which stores multiple instance data in a structured manner, and different instance data in the multiple instance data correspond to different tenant applications; Each instance data is used to store the association relationship between different metadata instances in multiple metadata instances of the corresponding tenant's application; The method includes: Receive metadata for a first general function; the first general function is a general function to be updated in a first application; the applications of different tenants are first applications with added custom functions; the applications of different tenants correspond to different custom functions; the first application is any application provided by the SaaS application server; Based on the multiple instance data, a compatibility test is performed on the metadata of the first general function to obtain the compatibility test results; Based on the compatibility test results and the metadata of the first general function, the first application is updated to obtain the second application.

12. The method according to claim 11, characterized in that, The compatibility test results include: the first custom metadata instance is compatible with the metadata of the first general function, or the first custom metadata instance is incompatible with the metadata of the first general function; the first custom metadata instance is a custom metadata instance in the instance data of the different tenants that has an association with the metadata of the first general function.

13. The method according to claim 12, characterized in that, Based on the compatibility test results and the metadata of the first general function, update the first application, including: If the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function, then modify the metadata of the first general function. The first application is updated based on the modified metadata of the first general function; the modified metadata of the first general function is compatible with the first custom metadata instance.

14. The method according to any one of claims 11 to 13, characterized in that, After performing compatibility testing on the metadata of the first general function based on the multiple instance data and obtaining the compatibility testing results, the method further includes: If the compatibility test result indicates that the first custom metadata instance is incompatible with the metadata of the first general function, then a first tag is added to the metadata of the first general function; the first custom metadata instance is a custom metadata instance in the instance data of different tenants that has an association with the metadata of the first general function.

15. The method according to claim 14, characterized in that, The method further includes: Obtain a metadata data packet, wherein the metadata data packet includes metadata of multiple general functions, and the metadata of the multiple general functions includes the metadata of the first general function; If at least one first metadata exists in the metadata packet, the at least one first metadata is modified, and the first application is updated based on the at least one modified first metadata and the second metadata in the metadata packet; the first metadata is metadata in the data packet that carries the first tag, the second metadata is metadata in the data packet that does not carry the first tag, and the at least one first metadata includes metadata of the first general function.

16. The method according to any one of claims 11 to 15, characterized in that, After updating the first application, the method further includes: In response to the update request from the first tenant, a compatibility test is performed on the second application based on the instance data of the first tenant; the update request is used to request an update to the application of the first tenant. If the second application compatibility test is passed, a third application is released to the first tenant's tenant environment; the third application is a second application with added custom functions of the first tenant.

17. The method according to claim 16, characterized in that, The compatibility testing of the second application based on the instance data of the first tenant includes: Based on the instance data of the first tenant, a second custom metadata instance that is incompatible with the general metadata of the second application is identified among the multiple metadata instances of the first tenant; Output the second custom metadata instance so that the first tenant can modify the second custom metadata instance; If the modified second custom metadata instance is compatible with the general metadata, the second application compatibility test is deemed to have passed.

18. The method according to any one of claims 11 to 17, characterized in that, The update of the first application includes: Based on the multiple instance data, obtain multiple first metadata instances that depend on the first general function in the multiple instance data; Based on the metadata of the first general function, each of the plurality of first metadata instances is modified; The first application is updated based on each modified first metadata instance and the second metadata instance in the plurality of instance data; the second metadata instance is a metadata instance in the plurality of instance data that does not depend on the metadata of the first general function.

19. A metadata storage device, characterized in that, The device includes: The storage module is used to store the data of the metamodel, which includes the association relationships between different metadata types among various metadata types; A communication module for receiving metadata from the first application; The processing module is used to parse the metadata based on the data of the meta-model, extract instance data from the metadata, and store the instance data in a structured manner. The instance data includes the relationships between different metadata instances in multiple metadata instances; the instance data is used to analyze the impact of general function updates in the first application on custom functions in the first application.

20. A metadata updating device, characterized in that, The device includes: A storage module is used to store multiple instance data; wherein, different instance data in the multiple instance data correspond to applications of different tenants; each instance data is used to store the association relationship between different metadata instances in the multiple metadata instances of the corresponding tenant's application; A communication module is used to receive metadata of a first general function; the first general function is a general function to be updated in a first application; the applications of different tenants are first applications with added custom functions; the applications of different tenants correspond to different custom functions; the first application is any application provided by the SaaS application server. The processing module is used to perform compatibility testing on the metadata of the first general function based on the multiple instance data, obtain a compatibility testing result, and update the first application based on the compatibility testing result and the metadata of the first general function to obtain a second application.

21. A Software as a Service (SaaS) application service platform, characterized in that, The platform includes: a metamodel management module, a metadata generation module, a parsing engine, and a metadata storage module; The metamodel management module is used to store metamodel data, which includes the association relationships between different metadata types among various metadata types. The metadata generation module is used to provide metadata for the first application; The parsing engine is used to execute the method of any one of claims 1 to 10 based on the metadata provided by the metadata generation module to form instance data; The metadata storage module is used to store the instance data in a structured manner.

22. The platform according to claim 21, characterized in that, The platform also includes: The metadata consumption block is used to execute the method of any one of claims 11 to 18 based on the instance data stored in the metadata storage module.

23. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 18.

24. A computer-readable storage medium, characterized in that, Includes computer program instructions that, when run by a cluster of computing devices, cause the cluster of computing devices to perform the method as described in any one of claims 1 to 18.

25. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the method as described in any one of claims 1 to 18.

Images