CN112860948B - Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment - Google Patents
Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment Download PDFInfo
- Publication number
- CN112860948B CN112860948B CN202110451566.6A CN202110451566A CN112860948B CN 112860948 B CN112860948 B CN 112860948B CN 202110451566 A CN202110451566 A CN 202110451566A CN 112860948 B CN112860948 B CN 112860948B
- Authority
- CN
- China
- Prior art keywords
- metadata
- layer
- change
- tenant
- merging
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
Abstract
The invention provides a metadata management method, a metadata management system and electronic equipment based on a multi-tenant SaaS (software as a service) architecture, belonging to the technical field of data processing, wherein the method comprises the steps of carrying out layered processing on metadata based on the multi-tenant SaaS architecture to obtain a first layer of metadata and a second layer of metadata which are stored in an isolated mode; according to the received change requirement of the tenant on the second metadata and the custom rule of the meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata; and merging the second metadata of the second layer of metadata before the change and the third metadata of the second layer of metadata after the change based on a user-defined rule according to a received query request of the tenant to obtain the fourth metadata of the second layer of metadata after the merging. The invention realizes that the metadata of different layers support different life cycle management modes through layered processing, and realizes the change and combination processing of the layered metadata.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to a metadata management method and system based on a multi-tenant SaaS architecture and electronic equipment.
Background
SaaS (Software-as-a-Service), that is, providing Software services through a network. The SaaS platform supplier uniformly deploys the application software on the server of the SaaS platform supplier, and tenants can order the required application software service from a manufacturer through the Internet according to the actual working requirement, pay the cost to the manufacturer according to the amount and time of the ordered service, and obtain the service provided by the SaaS platform supplier through the Internet.
Metadata (Metadata), also called intermediary data and relay data, is data (data about data) describing data, and is mainly information describing data attribute (property) for supporting functions such as indicating storage location, history data, resource search, file record, and the like.
Under the multi-tenant SaaS framework, all tenants have shared metadata and metadata unique to each tenant; in addition, in the use process of the metadata, the metadata ranges maintained by personnel in different roles are different, and the storage modes and the life cycle management modes of the metadata in different layers are different. Therefore, a technical solution for managing metadata is needed to be provided for a metadata hierarchy based on a multi-tenant architecture.
Disclosure of Invention
The invention provides a metadata management method, a metadata management system and electronic equipment based on a multi-tenant SaaS (software as a service) architecture, which are used for solving the problem of managing a metadata system in the prior art and realizing a management mechanism for layering metadata and changing and combining the layered metadata.
The invention provides a metadata management method based on a multi-tenant SaaS framework, which comprises the following steps:
performing layered processing on metadata based on a multi-tenant architecture to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, wherein the first-layer metadata comprise first metadata unique to each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
according to the received change requirement of a tenant on second metadata and a custom rule of a meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata;
according to a received query request of a tenant, merging the second metadata of the second layer of metadata before change and the third metadata of the second layer of metadata after change based on the user-defined rule to obtain the fourth metadata of the second layer of metadata after merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
According to the metadata management method based on the multi-tenant SaaS architecture, after the second metadata before the change and the third metadata after the change are merged to obtain the merged fourth metadata, the method further includes:
acquiring first metadata of the first layer metadata;
merging the first metadata of the first layer metadata and the merged fourth metadata of the second layer metadata;
judging whether the first metadata and the merged fourth metadata have the same unique identifier or not;
and if the first metadata and the merged fourth metadata have the metadata with the same unique identification, overwriting the merged fourth metadata with the first metadata corresponding to the same unique identification.
According to the metadata management method based on the multi-tenant SaaS framework, the second metadata is changed according to the change requirement of a received tenant on the second metadata and the custom rule of the metadata model to which the second metadata belongs, and the third metadata of the changed second-layer metadata is obtained, and the method comprises the following steps:
and carrying out corresponding change processing on the second metadata according to change modes defined by the custom rule of the meta-model to which the second metadata belongs, wherein the change modes comprise three modes of attribute increment change, record increment change and abandon increment change.
According to the metadata management method based on the multi-tenant SaaS framework, the change processing is performed on the second metadata according to the change mode defined by the custom rule of the meta-model to which the second metadata belongs, and the method comprises the following steps:
if the attribute increment is changed, changing the attribute corresponding to the second metadata to generate third metadata of the attribute increment;
if the record increment is changed, changing the record of the second metadata, and generating new third metadata based on the second metadata;
and if the change is the discarding increment change, discarding the second metadata.
According to the metadata management method based on the multi-tenant SaaS framework, the merging of the second metadata of the second layer of metadata before the change and the third metadata of the second layer of metadata after the change is performed to obtain the fourth metadata of the second layer of metadata after the merging, and the method comprises the following steps:
judging whether the second metadata and the merged third metadata have the same unique identifier or not;
and if the second metadata and the merged third metadata have the same metadata with the unique identifier, covering the record increment of the third metadata with the second metadata to obtain the fourth data of the merged second-layer metadata.
According to the metadata management method based on the multi-tenant SaaS framework, the step of covering the record increment of the third metadata with the second metadata to obtain the fourth data of the merged second-layer metadata comprises the following steps:
if the attribute increment is changed, replacing the changed value of the attribute in the attribute increment of the third metadata with the value of the same attribute of the second metadata to obtain fourth metadata of the attribute increment;
if the record increment is changed, covering the record increment of the third metadata with the second metadata with the same unique identifier to obtain fourth metadata of the record increment;
and if the discarding increment is changed, discarding the second metadata to obtain fourth metadata which has been discarded.
The invention also provides a metadata management system based on the multi-tenant SaaS architecture, which comprises the following steps:
the system comprises a layering module, a data processing module and a data processing module, wherein the layering module is used for performing layering processing on metadata based on a multi-tenant SaaS framework to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, the first-layer metadata comprise first metadata unique to each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
the change module is used for carrying out change processing on the second metadata according to received change requirements of tenants on the second metadata and custom rules of the meta-model to which the second metadata belongs, so as to obtain third metadata of the changed second-layer metadata;
the merging module is used for merging the second metadata of the second layer of metadata before the change and the third metadata of the second layer of metadata after the change to obtain the fourth metadata of the second layer of metadata after the merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
According to the metadata management system based on the multi-tenant SaaS architecture, the merging module is further configured to:
acquiring first metadata of the first layer metadata;
merging the first metadata of the first layer metadata and the merged fourth metadata of the second layer metadata;
judging whether the first metadata and the merged fourth metadata have the same unique identifier or not;
and if the first metadata and the merged fourth metadata have the metadata with the same unique identification, overwriting the merged fourth metadata with the first metadata corresponding to the same unique identification.
The invention also provides a server which comprises the metadata management system based on the multi-tenant SaaS framework.
The invention also provides an electronic device, which comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the processor realizes the steps of the metadata management method based on the multi-tenant SaaS framework when executing the program.
The present invention also provides a non-transitory computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the steps of the multi-tenant SaaS architecture-based metadata management method as described in any of the above.
According to the metadata management method, system and electronic equipment based on the multi-tenant SaaS framework, the metadata is processed in a layered mode, the metadata of different layers support different life cycle management modes, incremental change processing of the layered metadata and merging processing of the layered metadata are provided after the metadata is layered, the tenant can change the layered metadata, and the layered and merged metadata are returned to a terminal user based on a custom rule of a meta model when the tenant inquires the metadata.
Drawings
In order to more clearly illustrate the technical solutions of the present invention or the prior art, the drawings needed for the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and those skilled in the art can also obtain other drawings according to the drawings without creative efforts.
Fig. 1 is a schematic flowchart of a metadata management method based on a multi-tenant SaaS architecture according to the present invention;
FIG. 2 is a schematic diagram of a first and second layer metadata layering process provided by the present invention;
FIG. 3 is a schematic diagram of a change process for second-level metadata provided by the present invention;
FIG. 4 is a flow diagram of a change process for second tier metadata provided by the present invention;
FIG. 5 is a schematic diagram of incremental change of attributes for a second level of metadata provided by the present invention;
FIG. 6 is a schematic diagram of incremental change of records for second layer metadata provided by the present invention;
FIG. 7 is a diagram illustrating obsolete incremental changes to second tier metadata provided by the present invention;
FIG. 8 is a diagram illustrating a merging process of first and second layers of metadata according to the present invention;
FIG. 9 is a flow diagram of a second tier metadata merge process provided by the present invention;
FIG. 10 is a flow chart of a merge process of first and second layers of metadata provided by the present invention;
fig. 11 is a schematic structural diagram of a metadata management system based on a multi-tenant SaaS architecture provided in the present invention;
fig. 12 is a schematic structural diagram of an electronic device provided in the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings, and it is obvious that the described embodiments are some, but not all embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terms "first," "second," and the like in the description and in the claims, and in the drawings described above, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein.
Based on a metadata system of a multi-tenant architecture in the prior art, the invention needs to provide a metadata layering mechanism which can support different life cycle management modes aiming at metadata of different layers; meanwhile, after the metadata supports layering, the incremental change capability of the layered metadata and the merging capability of the layered metadata are provided; based on the incremental change and merging mechanism after metadata layering, a tenant can change the layered metadata, and returns the layered and merged metadata to an end user based on the unified custom rules (such as layered change rules and layered merging rules) of the metadata when querying the metadata.
The method, the system and the electronic device for managing metadata based on a multi-tenant SaaS architecture according to the present invention are described below with reference to fig. 1 to 12.
Fig. 1 is a schematic flowchart of a metadata management method based on a multi-tenant SaaS architecture provided by the present invention, and fig. 2 is a schematic diagram of a first and second layer metadata layered process provided by the present invention, as shown in fig. 1 and fig. 2. A metadata management method based on a multi-tenant SaaS architecture comprises the following steps:
The first-tier metadata in fig. 2 includes first metadata of a tenant, first metadata a represents the first metadata of tenant a, and first metadata b represents the first metadata of tenant b.
Preferably, under the multi-tenant SaaS architecture, all metadata is divided into two layers: the first-layer metadata comprises first metadata unique to each Tenant and can be set as Tenant-level metadata; the second layer of metadata, including metadata shared by all tenants, may be set to Common level metadata. Therefore, the metadata of the present invention includes Tenant-level metadata and Common-level metadata. The Tenant level metadata and the Common level metadata can respectively manage the respective life cycles through layering.
Preferably, the Tenant-level metadata and the Common-level metadata are stored in a mutually isolated mode by adopting different namespaces.
Preferably, the Tenant-level metadata and the Common-level metadata have upper and lower hierarchical levels, only the upper layer depends on the lower layer, and the lower layer cannot depend on the upper layer, namely only the upper layer refers to the lower layer, for example, Tenant a needs to construct a form in the Tenant-level metadata, and the form can use field items of the Common-level metadata.
102, according to the change requirement of a tenant on second metadata and a user-defined rule of a meta-model to which the second metadata belongs, changing the second metadata to obtain third metadata of the changed second-layer metadata.
Preferably, the second layer of metadata, that is, Common level metadata, is shared by all tenants, but different tenants may have different change requirements for Common level metadata, and metadata changes caused by the change requirements can only affect the tenant initiating the change (because each tenant can perform its own unique Delta based on Common), and cannot affect other tenants. For example, tenant b initiates a change requirement, the change requirement cannot affect tenant c.
Preferably, different metadata corresponds to different meta-models, for example, metadata a corresponds to meta-model a, and the rules in meta-model a can be customized, including customized hierarchical change rules, customized hierarchical merge rules, and the like. Which metadata allows incremental changes, what manner of incremental changes are allowed, etc. are determined by the custom rules of the meta-model to which the metadata belongs.
Preferably, when defining the meta-model to which the metadata belongs, the metadata is defined to have a unique identification attribute, and the value of the unique identification attribute is the unique identification of the metadata. According to the unique identification, the metadata can be automatically merged in a layered mode.
For example, if a custom rule in a meta-model is defined as not changeable, all Common level metadata under the meta-model is not changeable. If the definition is changeable, the mode of change is further judged.
Preferably, the Common-level metadata modification methods include: an attribute increment (Delta) change, a record increment (Delta) change and a discard increment (Delta) change.
The attribute Delta is a change to the Common level metadata attribute level, that is, the Common level metadata record is unchanged, only part of the attribute is changed, and the attribute Delta is generated.
Wherein, the record Delta is a change of the Common level metadata record level, namely, a new Common level metadata record is generated based on the original Common level metadata.
The discarding Delta is a discarding operation on Common level metadata, i.e. the tenant no longer uses the Common level metadata.
In the Tenant-level metadata, some of Delta (increment) generated by the Tenant changing the Common-level metadata; and another part is metadata customized by the tenant, the metadata is irrelevant to Common-level metadata, the metadata is not Delta, when the tenant modifies the metadata, the original metadata can be directly replaced, the Delta is not generated, for example, the tenant-level metadata, name = a, and after the tenant changes to b, the name is changed to b, and the original a is directly replaced. Delta is based on Common level, and the tenant modifies Common level metadata to generate Delta.
Since Common-level metadata is shared for all tenants, all tenants on the upper layer (namely, Tenant level) are immediately affected after being changed, for example, when Common-level metadata needs to be upgraded, all tenants on the upper-layer Tenant level immediately take effect; for another example, when new metadata is added to Common, all tenants can obtain the latest information instantly. The Tenant-level metadata is private metadata of each Tenant, and changes of the metadata do not affect other tenants.
And 103, merging the second metadata of the second layer metadata before the change and the third metadata of the second layer metadata after the change based on the user-defined rule according to the received query request of the tenant to obtain the fourth metadata of the second layer metadata after the merging.
Preferably, the Top-Win principle is adopted when the same metadata are merged, namely, the principle that the lower layer (Common level metadata) is covered by the upper layer (Tenant level metadata).
Preferably, the metadata hierarchical merging is independent of the type of the specific metadata, and the metadata hierarchical automatic merging is realized according to a custom rule (such as a hierarchical merging rule) of the meta model to which the metadata belongs.
Preferably, the merging of metadata hierarchies includes merging between Common level metadata and incremental changes of Common level metadata, and/or merging Common level metadata and Tenant level metadata.
In summary, the present invention implements metadata hierarchical change rules based on a metadata-driven manner, provides change manners with different granularities (for example, taking orders as granularities) and ranges according to different business requirements, is independent of a specific certain metadata type, implements unified merging of metadata hierarchies based on the metadata hierarchical change rules, and developers only need to define the hierarchical change rules without deeply understanding the internal logic of metadata hierarchy change and merging.
The steps 102 to 103 will be described with reference to fig. 3 to 10.
Fig. 3 is a schematic diagram of a change process of second-layer metadata provided by the present invention, as shown in fig. 3. Fig. 3 shows a change process that requires changing Common level metadata. The Common level metadata automatically generates corresponding Delta according to the attribute defined in the rule (such as a hierarchical change rule), namely, the attribute Delta change, the recorded Delta change or the abandoned Delta change is automatically performed. Meta-models, unique identifiers, allowed deltas, Delta modes, attributes and the like are defined in the hierarchical change rule list. Wherein the meta-models are, for example, meta-models model _ a, model _ b, model _ c.
The first piece of data represents that the meta model is model _ a, the unique identifier of the model _ a is apiKey, the value of the allowed Delta is true, the meta model represents that the change is allowed, the type of the allowed change is the change of the attribute Delta, and the attribute of the change is prop1 and prop 2.
The second piece of data represents that the meta model is model _ b, the unique identifier of the model _ b is apiKey, the value of the allowed Delta is true, the meta model represents that the change is allowed, the allowed change type is the change of recording Delta, the attribute of the change is null, the meta model represents that the change of the attribute Delta is not allowed, and only the change of recording Delta is allowed.
The third piece of data represents that the meta model is model _ c, the unique identifier of the model _ c is apiKey, the value of allowed Delta is false, the meta model represents that no change is allowed, the type of change is allowed to be null, and the attribute of the change is null, which represents that no limitation exists.
Fig. 4 is a flowchart of a change process of second-layer metadata provided by the present invention, and as shown in fig. 4, in the step 102, the changing process of the second metadata according to the received change requirement of the tenant on the second metadata and the custom rule of the meta model to which the second metadata belongs to obtain third metadata of the changed second-layer metadata includes:
and carrying out corresponding change processing on the second metadata according to change modes defined by the custom rule of the meta-model to which the second metadata belongs, wherein the change modes comprise three modes of attribute increment change, record increment change and abandon increment change.
It should be noted that, the meta-model to which the metadata belongs may define a rule, such as a customizable hierarchical change rule, according to which it may be specified whether all Common level metadata under the meta-model may be changed, and it may further define what types of changeable change, what metadata allow incremental change, what type of incremental change is allowed, and so on.
An example of the attribute increment change is shown in fig. 5, and fig. 5 is a schematic diagram of the attribute increment change of the second-layer metadata provided by the present invention. The left box shows id number 100, unique identifier apiKey as accountName, label as client name, Length as 50. Now, the client name of the label attribute of the left box needs to be changed to generate the deltaValue company name in the right box. The right box shows id number 100, deltaKey as accountName, property as label, deltaValue as company name. The vertical direction represents the attribute Delta.
An example of incremental change of record is shown in fig. 6, and fig. 6 is a schematic diagram of incremental change of record of second layer metadata provided by the present invention. The left box shows that the id number is 200, the unique identifier apiKey is accountType1, the code is 1, label is a domestic client, default is true, and the default value of the record is true. The right box shows that the id number is 12345, the unique identifier apiKey is accountType1, the code is 1, label is a domestic client, and default is false, which means that the left record with the default value of true is changed into the default value of false. The horizontal direction represents the recorded Delta.
In step 403, if the discarding increment is changed, discarding the second metadata.
Fig. 7 shows an example of discarding incremental change, and fig. 7 is a schematic diagram of discarding incremental change of second-tier metadata according to the present invention. The left box shows id number 300, unique identifier apiKey as postCode, label as zip code, length as 50. The right box shows id number 300, deltaKey postCode, prediction true, indicating that this record of postCode zip code needs to be discarded, value true.
It can be seen that Delta described above is based on Common level, and a tenant modifies Common level metadata to generate Delta, and while Common level metadata is shared by all tenants, different tenants have different change requirements for Common level metadata, and the change can only affect the tenant initiating the change, but cannot affect other tenants.
Fig. 8 is a schematic diagram of the merging process of the first and second layers of metadata provided by the present invention, as shown in fig. 8. The merging of metadata layers comprises merging between Common level metadata and incremental changes of Common level metadata (see the right arrow in fig. 8) and/or merging Common level metadata and Tenant level metadata (see the left arrow in fig. 8).
Preferably, the metadata hierarchical merging is independent of the specific metadata type, and the metadata hierarchical automatic merging is realized according to a uniform hierarchical merging rule. When the meta-model to which the metadata belongs is customized, the unique identification attribute of the metadata is defined, and the value on the unique identification attribute is the unique identification of the metadata, so that when two pieces of metadata are combined, if the unique identifications of the two pieces of metadata are the same, the Tenant-level metadata covers the Common-level metadata, and the record Delta of the Common-level metadata covers the Common-level metadata.
The metadata layered combination of the invention comprises the following two steps:
the first step is to acquire Common level metadata, then acquire corresponding Delta based on the Common level according to the change rule defined by the meta model, and combine the Delta and the Common level metadata in advance. And for the attribute Delta, replacing the value of the Common-level metadata same attribute with the value of the changed attribute in the attribute Delta. For the record Delta, Common level metadata of the same unique identification is covered by the record Delta. For obsolete deltas, the Common level metadata is removed.
And in the second step, Tenant-level metadata is acquired and merged with Common-level metadata with merged deltas. When the existing metadata have the same unique identification, Common-level metadata is preferentially overwritten in Tenant level.
The following will describe two steps for the combination in fig. 8 by fig. 9 and 10.
Fig. 9 is a flowchart of the merging process of the second-layer metadata provided by the present invention, as shown in fig. 9. In step 103, the merging the second metadata of the second layer metadata before the change and the third metadata of the second layer metadata after the change to obtain the fourth metadata of the second layer metadata after the merging, includes:
And step 902, if the second metadata and the merged third metadata have the same metadata with the unique identifier, covering the record increment of the third metadata with the second metadata to obtain fourth data of the merged second-layer metadata.
Specifically, if the attribute increment is changed, the changed value of the attribute in the attribute increment of the third metadata is substituted for the value of the same attribute of the second metadata, so as to obtain the fourth metadata of the attribute increment.
Specifically, if the record increment is changed, the record increment of the third metadata is covered with the second metadata with the same unique identifier, so as to obtain the fourth metadata of the record increment.
Specifically, if the discarding increment is changed, the second metadata is discarded to obtain fourth metadata that has been discarded.
Fig. 10 is a flowchart of the merging process of the first and second layers of metadata according to the present invention, as shown in fig. 10. In step 103, after the merging the second metadata before the change and the third metadata after the change to obtain the fourth metadata after the merging, the method further includes:
The first metadata belongs to a first layer of metadata, namely Tenant-level metadata, and the second to fourth metadata belong to a second layer of metadata, namely Common-level metadata, wherein the merging of the second to third metadata obtains fourth metadata, and the fourth metadata belongs to the merging between the Common-level metadata and the incremental change of the Common-level metadata; the merging of the fourth metadata with the first metadata belongs to the merging of Common level metadata and Tenant level metadata.
Principle of layered combination: when two pieces of metadata are merged, if the unique identifiers of the two pieces of metadata are the same, the records Delta of the Common level metadata cover the Common level metadata and the Tenant level metadata cover the Common level metadata.
In summary, the present invention implements metadata hierarchical management based on a metadata-driven manner, provides modification manners with different granularities and ranges according to different business requirements, is independent of a specific certain metadata type, and can implement unified merging of metadata hierarchies based on metadata hierarchical modification rules.
The metadata management system based on the multi-tenant SaaS architecture provided by the present invention is described below, and the metadata management system based on the multi-tenant SaaS architecture described below and the metadata management method based on the multi-tenant SaaS architecture described above may be referred to each other correspondingly.
Fig. 11 is a schematic structural diagram of a metadata management system based on a multi-tenant SaaS architecture, as shown in fig. 11. A metadata management system 1100 based on a multi-tenant SaaS architecture includes a layering module 1110, a changing module 1120, and a merging module 1130. Wherein the content of the first and second substances,
the hierarchical module 1110 is configured to perform hierarchical processing on metadata based on a multi-tenant SaaS architecture to obtain first-layer metadata and second-layer metadata that are stored in an isolated manner, where the first-layer metadata includes first metadata unique to each tenant, and the second-layer metadata includes second metadata shared by all tenants;
the changing module 1120 is configured to perform changing processing on second metadata according to a received change requirement of a tenant on the second metadata and a user-defined rule of a meta model to which the second metadata belongs, so as to obtain third metadata of changed second-layer metadata;
a merging module 1130, configured to merge the second metadata of the second layer metadata before the change and the third metadata of the second layer metadata after the change to obtain fourth metadata of the second layer metadata after the merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
Preferably, the merging module 1130 is further configured to:
acquiring first metadata of the first layer metadata;
merging the first metadata of the first layer metadata and the merged fourth metadata of the second layer metadata;
judging whether the first metadata and the merged fourth metadata have the same unique identifier or not;
and if the first metadata and the merged fourth metadata have the metadata with the same unique identification, overwriting the merged fourth metadata with the first metadata corresponding to the same unique identification.
Preferably, the changing module 1120 is further configured to:
and carrying out corresponding change processing on the second metadata according to change modes defined by the custom rule of the meta-model to which the second metadata belongs, wherein the change modes comprise three modes of attribute increment change, record increment change and abandon increment change.
Preferably, the changing module 1120 is further configured to:
if the attribute increment is changed, changing the attribute corresponding to the second metadata to generate third metadata of the attribute increment;
if the record increment is changed, changing the record of the second metadata, and generating new third metadata based on the second metadata;
and if the change is the discarding increment change, discarding the second metadata.
Preferably, the merging module 1130 is further configured to:
judging whether the second metadata and the merged third metadata have the same unique identifier or not;
and if the second metadata and the merged third metadata have the same metadata with the unique identifier, covering the record increment of the third metadata with the second metadata to obtain the fourth data of the merged second-layer metadata.
The merge module 1130 is further configured to:
if the attribute increment is changed, replacing the changed value of the attribute in the attribute increment of the third metadata with the value of the same attribute of the second metadata to obtain fourth metadata of the attribute increment;
if the record increment is changed, covering the record increment of the third metadata with the second metadata with the same unique identifier to obtain fourth metadata of the record increment;
and if the discarding increment is changed, discarding the second metadata to obtain fourth metadata which has been discarded.
Fig. 12 illustrates a physical structure diagram of an electronic device, which may include, as shown in fig. 12: a processor (processor)1210, a communication Interface (Communications Interface)1220, a memory (memory)1230, and a communication bus 1240, wherein the processor 1210, the communication Interface 1220, and the memory 1230 communicate with each other via the communication bus 1240. Processor 1210 may invoke logic instructions in memory 1230 to perform the multi-tenant SaaS architecture based metadata management method comprising:
performing layered processing on metadata based on a multi-tenant Saas architecture to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, wherein the first-layer metadata comprise first metadata unique to each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
according to the received change requirement of a tenant on second metadata and a custom rule of a meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata;
according to a received query request of a tenant, merging the second metadata of the second layer of metadata before change and the third metadata of the second layer of metadata after change based on the user-defined rule to obtain the fourth metadata of the second layer of metadata after merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
In addition, the logic instructions in the memory 1230 may be implemented in software functional units and stored in a computer readable storage medium when the logic instructions are sold or used as a stand-alone product. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
In another aspect, the present invention further provides a computer program product, where the computer program product includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions, and when the program instructions are executed by a computer, the computer is capable of executing the method for managing metadata based on a multi-tenant SaaS architecture, provided by the above methods, including:
performing layered processing on metadata based on a multi-tenant SaaS framework to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, wherein the first-layer metadata comprise unique first metadata of each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
according to the received change requirement of a tenant on second metadata and a custom rule of a meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata;
according to a received query request of a tenant, merging the second metadata of the second layer of metadata before change and the third metadata of the second layer of metadata after change based on the user-defined rule to obtain the fourth metadata of the second layer of metadata after merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
In another aspect, the present invention further provides a non-transitory computer-readable storage medium, on which a computer program is stored, where the computer program is implemented by a processor to execute the above-mentioned metadata management method based on a multi-tenant SaaS architecture, and the method includes:
performing layered processing on metadata based on a multi-tenant SaaS framework to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, wherein the first-layer metadata comprise unique first metadata of each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
according to the received change requirement of a tenant on second metadata and a custom rule of a meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata;
according to a received query request of a tenant, merging the second metadata of the second layer of metadata before change and the third metadata of the second layer of metadata after change based on the user-defined rule to obtain the fourth metadata of the second layer of metadata after merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.
Claims (10)
1. A metadata management method based on a multi-tenant SaaS architecture is characterized by comprising the following steps:
performing layered processing on metadata based on a multi-tenant SaaS framework to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, wherein the first-layer metadata comprise unique first metadata of each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
according to the received change requirement of a tenant on second metadata and a custom rule of a meta-model to which the second metadata belongs, carrying out change processing on the second metadata to obtain third metadata of the changed second-layer metadata;
according to a received query request of a tenant, merging the second metadata of the second layer of metadata before change and the third metadata of the second layer of metadata after change based on the user-defined rule to obtain the fourth metadata of the second layer of metadata after merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
2. The method for managing metadata based on a multi-tenant SaaS architecture according to claim 1, wherein after the merging of the second metadata before the change and the third metadata after the change is performed to obtain the fourth metadata after the merging, the method further comprises:
acquiring first metadata of the first layer metadata;
merging the first metadata of the first layer metadata and the merged fourth metadata of the second layer metadata;
judging whether the first metadata and the merged fourth metadata have the same unique identifier or not;
and if the first metadata and the merged fourth metadata have the metadata with the same unique identification, overwriting the merged fourth metadata with the first metadata corresponding to the same unique identification.
3. The method for managing metadata based on a multi-tenant SaaS framework according to claim 1, wherein the step of performing change processing on second metadata according to received change requirements of tenants on the second metadata and custom rules of a meta model to which the second metadata belongs to obtain third metadata of changed second-layer metadata comprises:
and carrying out corresponding change processing on the second metadata according to change modes defined by the custom rule of the meta-model to which the second metadata belongs, wherein the change modes comprise three modes of attribute increment change, record increment change and abandon increment change.
4. The method for managing metadata based on a multi-tenant SaaS framework according to claim 3, wherein the changing the second metadata according to a changing manner defined by a custom rule of a meta model to which the second metadata belongs includes:
if the attribute increment is changed, changing the attribute corresponding to the second metadata to generate third metadata of the attribute increment;
if the record increment is changed, changing the record of the second metadata, and generating new third metadata based on the second metadata;
and if the change is the discarding increment change, discarding the second metadata.
5. The method for managing metadata based on a multi-tenant SaaS architecture according to claim 1, wherein the merging the second metadata of the second-layer metadata before the change and the third metadata of the second-layer metadata after the change to obtain the fourth metadata of the second-layer metadata after the merging includes:
judging whether the second metadata and the merged third metadata have the same unique identifier or not;
and if the second metadata and the merged third metadata have the same metadata with the unique identifier, covering the record increment of the third metadata with the second metadata to obtain the fourth data of the merged second-layer metadata.
6. The method for managing metadata based on a multi-tenant SaaS architecture according to claim 5, wherein the step of overlaying the record increment of the third metadata on the second metadata to obtain fourth data of the merged second-layer metadata includes:
if the attribute increment is changed, replacing the changed value of the attribute in the attribute increment of the third metadata with the value of the same attribute of the second metadata to obtain fourth metadata of the attribute increment;
if the record increment is changed, covering the record increment of the third metadata with the second metadata with the same unique identifier to obtain fourth metadata of the record increment;
and if the discarding increment is changed, discarding the second metadata to obtain fourth metadata which has been discarded.
7. A metadata management system based on a multi-tenant SaaS architecture is characterized by comprising:
the system comprises a layering module, a data processing module and a data processing module, wherein the layering module is used for performing layering processing on metadata based on a multi-tenant SaaS framework to obtain first-layer metadata and second-layer metadata which are stored in an isolated mode, the first-layer metadata comprise first metadata unique to each tenant, and the second-layer metadata comprise second metadata shared by all tenants;
the change module is used for carrying out change processing on the second metadata according to received change requirements of tenants on the second metadata and custom rules of the meta-model to which the second metadata belongs, so as to obtain third metadata of the changed second-layer metadata;
the merging module is used for merging the second metadata of the second layer of metadata before the change and the third metadata of the second layer of metadata after the change to obtain the fourth metadata of the second layer of metadata after the merging;
each meta-model defines a unique identification attribute for metadata of the meta-model, and the value of the unique identification attribute is the unique identification of the metadata.
8. The multi-tenant SaaS architecture-based metadata management system of claim 7, wherein the merging module is further configured to:
acquiring first metadata of the first layer metadata;
merging the first metadata of the first layer metadata and the merged fourth metadata of the second layer metadata;
judging whether the first metadata and the merged fourth metadata have the same unique identifier or not;
and if the first metadata and the merged fourth metadata have the metadata with the same unique identification, overwriting the merged fourth metadata with the first metadata corresponding to the same unique identification.
9. A server characterized by comprising the multi-tenant SaaS architecture-based metadata management system according to any one of claims 7 to 8.
10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the steps of the method for metadata management based on a multi-tenant SaaS architecture of any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110451566.6A CN112860948B (en) | 2021-04-26 | 2021-04-26 | Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110451566.6A CN112860948B (en) | 2021-04-26 | 2021-04-26 | Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112860948A CN112860948A (en) | 2021-05-28 |
| CN112860948B true CN112860948B (en) | 2021-07-27 |
Family
ID=75992937
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110451566.6A Active CN112860948B (en) | 2021-04-26 | 2021-04-26 | Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112860948B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114238420B (en) * | 2022-02-24 | 2022-06-14 | 北京仁科互动网络技术有限公司 | Method and device for using metadata based on multi-tenant architecture and electronic equipment |
| CN117390030B (en) * | 2023-12-12 | 2024-03-08 | 北京仁科互动网络技术有限公司 | Multidimensional parameter mapping configuration method and device and electronic equipment |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102591666A (en) * | 2012-01-04 | 2012-07-18 | 浪潮集团山东通用软件有限公司 | Metadata management method for version of hierarchy structure |
| CN103455512A (en) * | 2012-05-31 | 2013-12-18 | 上海博腾信息科技有限公司 | Multi-tenant data management model for SAAS (software as a service) platform |
| CN106777097A (en) * | 2016-12-14 | 2017-05-31 | 济南浪潮高新科技投资发展有限公司 | A kind of merging method during metadata delamination |
| CN111125025A (en) * | 2019-12-23 | 2020-05-08 | 用友网络科技股份有限公司 | Metadata storage system, metadata storage method, metadata calling device and readable storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180351870A1 (en) * | 2017-05-30 | 2018-12-06 | Red Hat, Inc. | On demand data volume provisioning |
-
2021
- 2021-04-26 CN CN202110451566.6A patent/CN112860948B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102591666A (en) * | 2012-01-04 | 2012-07-18 | 浪潮集团山东通用软件有限公司 | Metadata management method for version of hierarchy structure |
| CN103455512A (en) * | 2012-05-31 | 2013-12-18 | 上海博腾信息科技有限公司 | Multi-tenant data management model for SAAS (software as a service) platform |
| CN106777097A (en) * | 2016-12-14 | 2017-05-31 | 济南浪潮高新科技投资发展有限公司 | A kind of merging method during metadata delamination |
| CN111125025A (en) * | 2019-12-23 | 2020-05-08 | 用友网络科技股份有限公司 | Metadata storage system, metadata storage method, metadata calling device and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112860948A (en) | 2021-05-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103380423B (en) | For the system and method for private cloud computing | |
| US11663033B2 (en) | Design-time information based on run-time artifacts in a distributed computing cluster | |
| EP2477355B1 (en) | Method and device for managing association of network resources | |
| US20190095241A1 (en) | Managing user data in a multitenant deployment | |
| US10911324B2 (en) | Declarative and reactive data layer for component-based user interfaces | |
| US8775425B2 (en) | Systems and methods for massive structured data management over cloud aware distributed file system | |
| US7886028B2 (en) | Method and system for system migration | |
| CN112860948B (en) | Metadata management method and system based on multi-tenant SaaS architecture and electronic equipment | |
| US9471294B2 (en) | Extensions for deployment patterns | |
| US10019293B2 (en) | Enhanced command selection in a networked computing environment | |
| CN104423968B (en) | It designs the method for service logic, execute its server and storage medium | |
| US20200186619A1 (en) | Extraction and Distribution of Content Packages in a Digital Services Framework | |
| CN114791846B (en) | Method for realizing observability aiming at cloud-originated chaos engineering experiment | |
| CN104899077A (en) | Process information acquiring method and device based on container technology | |
| EP3186708A1 (en) | Workflow customization | |
| US11615061B1 (en) | Evaluating workload for database migration recommendations | |
| CN112395340B (en) | Data asset management method and device | |
| CN111813880B (en) | Homeland space planning project management method, system and storage medium | |
| US11394626B2 (en) | Digital services framework | |
| CN114329561A (en) | Method, device and medium for configuring data permission | |
| TWI620134B (en) | Integration device and integration method thereof | |
| CN113760863A (en) | Database configuration method and device, computer equipment and readable storage medium | |
| KR20130134888A (en) | Method for event processing using hierarchical structure and event processing system thereof | |
| CN117112654B (en) | City data display method, device, computer equipment and storage medium | |
| US20230177090A1 (en) | Systems, methods, and devices for dynamic record filter criteria for data objects of computing platforms |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |