Unified model verification method based on metadata driving
Through the unified model verification method driven by metadata, the problems of inconsistent front-end verification rules, difficulty in maintaining hard coding and complex model verification are solved, data consistency and system stability are achieved, and multi-environment isolation is supported.
Patent Information
- Application Number
- CN202411501629.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-25
- Publication Date
- 2025-02-18
AI Technical Summary
Inconsistent front-end and back-end verification rules in existing systems lead to data inconsistency and system instability. Hard-coded verification rules are too scattered and difficult to maintain, model verification is complex and inefficient, and differences in isolation of multiple environments lead to data confusion or abnormal functions. .
Adopt a unified model verification method based on metadata drive, metadata warehouse service is performed through Meta-Repository, metadata definition and verification are used by JSON Schema, and namespace is used to distinguish multiple services and multiple environments, realizing the classification management of metadata. and cache management.
Ensure the consistency of front-end verification rules, avoid rule dispersion caused by hard coding, improve the efficiency and stability of model verification, realize multi-environment isolation, and ensure data consistency and system stability.
Smart Images

Figure CN119474229A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data processing, and in particular to a unified model verification method based on metadata drive. Background Art
[0002] Inconsistent front-end and back-end validation rules: In many systems, the front-end and back-end validation rules are often inconsistent, which may lead to data inconsistency and system instability.
[0003] Hard-coded validation rules are too scattered and difficult to maintain: In existing systems, validation rules are usually hard-coded in the code, which makes the rules too scattered and difficult to maintain and update.
[0004] Complexity and efficiency issues of model validation: Existing technologies may encounter complexity and efficiency issues of model validation when dealing with a large number of different types of models.
[0005] Multi-environment isolation problem: In many systems, there are usually many environments: development, test, and production environments. There may be differences in the configurations between these environments, such as database connection information, file paths, etc. If problems occur during the deployment and configuration process, it may lead to data confusion, functional abnormalities, or performance degradation. Therefore, a unified model verification method based on metadata drive is proposed. Summary of the invention
[0006] In view of this, an embodiment of the present invention hopes to provide a unified model verification method based on metadata drive to solve or alleviate the technical problems existing in the prior art, and at least provide a beneficial option.
[0007] The technical solution of the embodiment of the present invention is implemented as follows: a unified model verification method based on metadata drive, comprising the following steps:
[0008] S1. The metadata is processed by the service layer through the entrance of PC, app and web. The service layer provides metadata warehouse service through Meta-Repository, realizes metadata classification management, metadata cache management, basic metadata reading and writing capabilities, and uses JSON Schema for metadata definition and verification;
[0009] S2: The processed metadata is transmitted to the storage layer. The storage layer uses Redis to cache the metadata, DB to store metadata definitions, OSS to actually store file-type metadata, and ES to implement an indexing mechanism for search fields based on Schema configuration.
[0010] S3 and MetaSchema are used to define the type of metadata using the JSON Schema specification and support verification of the metadata instance MetaEntity;
[0011] S4, MetaKind defines the kind of metadata type definition based on the value type EntityValue of the metadata instance, and determines the metadata instance content storage mechanism;
[0012] S5, MetaCategory is based on the classification of application scenarios, which determines the purpose of metadata;
[0013] S6. MetaType defines the metadata type and is the core of metadata. It supports namespace and implements various logical isolations. Namespace is mainly used to distinguish multiple businesses and multiple environments.
[0014] In some embodiments, in the S3, the steps of verifying the metadata instance MetaEntity are as follows:
[0015] S31. Define metadata model:
[0016] Define model structure metadata;
[0017] S32. Generate model checker:
[0018] Generate a model checker based on the metadata model;
[0019] The model checker code includes the model structure check logic and the check rule check logic;
[0020] S33, perform model verification:
[0021] Input the model to be verified into the model verifier;
[0022] The model checker performs structural verification and verification rule verification on the model;
[0023] If the model verification passes, the verification success information is output;
[0024] If the model fails to pass the verification, the verification failure information and error information will be output.
[0025] In some embodiments, in S6, a multi-business supporting business module classification mechanism is distinguished, and the business module classification mechanism includes order.XyzLayout and marketing.XyzLayout.
[0026] In some embodiments, in S6, multiple business support environments are differentiated, and different environments obtain different data through configuration, such as dev.abc.XyzLayout and prod.abc.XyzLayout.
[0027] In some embodiments, in S6, the multi-service support version distinction is distinguished, and the version distinction includes abc.v1.XyzLayout and abc.v2.XyzLayout.
[0028] In some embodiments, in S31, the model structure metadata includes information of model name, model type and model rules.
[0029] The embodiment of the present invention has the following advantages due to the adoption of the above technical solution:
[0030] The present invention is used for the creation, conversion and verification of the model, as well as the isolation of multiple environments of data, to ensure the consistency of the front-end and back-end verification rules, so that the hard-coded verification rules are not dispersed, which is easy to maintain and improves the stability of use.
[0031] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present invention will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0033] Figure 1 is a flow chart of the present invention;
[0034] Figure 2 is a system diagram of the present invention;
[0035] Figure 3 It is a model diagram of the present invention;
[0036] Figure 4 It is a display diagram of the detailed process of the present invention. DETAILED DESCRIPTION
[0037] In the following, only some exemplary embodiments are briefly described. As those skilled in the art will appreciate, the described embodiments may be modified in various ways without departing from the spirit or scope of the present invention. Therefore, the drawings and descriptions are considered to be exemplary and non-restrictive in nature.
[0038] It should be noted that the terms "first", "second", "symmetrical", "array", etc. are only used to distinguish between description and position description purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the definition of "first", "symmetrical", etc. can explicitly or implicitly include one or more of these features; similarly, when the quantity of certain features is not limited in the form of words such as "two" or "three", it should be noted that this feature also explicitly or implicitly includes one or more feature quantities;
[0039] In the present invention, unless otherwise clearly specified and limited, the terms such as "installation", "connection", "fixation" and the like should be understood in a broad sense; for example, it can be a fixed connection, a detachable connection, or an integral molding; it can be a mechanical connection, a direct connection, welding, or an indirect connection through an intermediate medium, or it can be the internal connection of two elements or the interaction relationship between two elements. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood based on the description and drawings combined with specific circumstances.
[0040] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.
[0041] Embodiment 1
[0042] like Figure 1-Figure 4 As shown, an embodiment of the present invention provides a unified model verification method based on metadata drive, comprising the following steps:
[0043] S1. The metadata is processed by the service layer through the entrance of PC, app and web. The service layer provides metadata warehouse service through Meta-Repository, realizes metadata classification management, metadata cache management, basic metadata reading and writing capabilities, and uses JSON Schema for metadata definition and verification;
[0044] S2: The processed metadata is transmitted to the storage layer. The storage layer uses Redis to cache the metadata, DB to store metadata definitions, OSS to actually store file-type metadata, and ES to implement an indexing mechanism for search fields based on Schema configuration.
[0045] S3 and MetaSchema are used to define the type of metadata using the JSON Schema specification and support verification of the metadata instance MetaEntity;
[0046] S4, MetaKind defines the kind of metadata type definition based on the value type EntityValue of the metadata instance, and determines the metadata instance content storage mechanism;
[0047] S5, MetaCategory is based on the classification of application scenarios, which determines the purpose of metadata;
[0048] S6. MetaType defines the metadata type and is the core of metadata. It supports namespace and implements various logical isolations. Namespace is mainly used to distinguish multiple businesses and multiple environments.
[0049] In this embodiment, specifically, in S3, the steps of verifying the metadata instance MetaEntity are as follows:
[0050] S31. Define metadata model:
[0051] Define model structure metadata;
[0052] S32. Generate model checker:
[0053] Generate a model checker based on the metadata model;
[0054] The model checker code includes the model structure check logic and the check rule check logic;
[0055] S33, perform model verification:
[0056] Input the model to be verified into the model verifier;
[0057] The model checker performs structural verification and verification rule verification on the model;
[0058] If the model verification passes, the verification success information is output;
[0059] If the model fails to pass the verification, the verification failure information and error information will be output.
[0060] In this embodiment, specifically, in S6, a multi-business supporting business module classification mechanism is distinguished, and the business module classification mechanism includes order.XyzLayout and marketing.XyzLayout.
[0061] In this embodiment, specifically, in S31, the model structure metadata includes information on the model name, model type, and model rules.
[0062] In this embodiment, specifically, metadata driven: metadata driven is a design pattern that uses metadata (data about data) to drive the behavior of an application. In this case, metadata is used to drive the verification method of the model.
[0063] Unified Model Verification Method: This is a verification method that can handle various types of models, including but not limited to Unified Modeling Language (UML), Extensible Markup Language (XML), and Common Object Request Broker Architecture (CORBA).
[0064] Hardcoding: This is a programming practice where validation rules are encoded directly in the program code rather than stored in some configurable external resource. This can result in rules that are too fragmented and difficult to maintain and update.
[0065] Embodiment 2
[0066] like Figure 1-Figure 4 As shown, an embodiment of the present invention provides a unified model verification method based on metadata drive, comprising the following steps:
[0067] S1. The metadata is processed by the service layer through the entrance of PC, app and web. The service layer provides metadata warehouse service through Meta-Repository, realizes metadata classification management, metadata cache management, basic metadata reading and writing capabilities, and uses JSON Schema for metadata definition and verification;
[0068] S2: The processed metadata is transmitted to the storage layer. The storage layer uses Redis to cache the metadata, DB to store metadata definitions, OSS to actually store file-type metadata, and ES to implement an indexing mechanism for search fields based on Schema configuration.
[0069] S3 and MetaSchema are used to define the type of metadata using the JSON Schema specification and support verification of the metadata instance MetaEntity;
[0070] S4, MetaKind defines the kind of metadata type definition based on the value type EntityValue of the metadata instance, and determines the metadata instance content storage mechanism;
[0071] S5, MetaCategory is based on the classification of application scenarios, which determines the purpose of metadata;
[0072] S6. MetaType defines the metadata type and is the core of metadata. It supports namespace and implements various logical isolations. Namespace is mainly used to distinguish multiple businesses and multiple environments.
[0073] In this embodiment, specifically, in S3, the steps of verifying the metadata instance MetaEntity are as follows:
[0074] S31. Define metadata model:
[0075] Define model structure metadata;
[0076] S32. Generate model checker:
[0077] Generate a model checker based on the metadata model;
[0078] The model checker code includes the model structure check logic and the check rule check logic;
[0079] S33, perform model verification:
[0080] Input the model to be verified into the model verifier;
[0081] The model checker performs structural verification and verification rule verification on the model;
[0082] If the model verification passes, the verification success information is output;
[0083] If the model fails to pass the verification, the verification failure information and error information will be output.
[0084] In this embodiment, specifically, in S6, multiple business support environments are distinguished, and different environments obtain different data through configuration, such as dev.abc.XyzLayout and prod.abc.XyzLayout.
[0085] In this embodiment, specifically, in S31, the model structure metadata includes information on the model name, model type, and model rules.
[0086] In this embodiment, specifically, metadata driven: metadata driven is a design pattern that uses metadata (data about data) to drive the behavior of an application. In this case, metadata is used to drive the verification method of the model.
[0087] Unified Model Verification Method: This is a verification method that can handle various types of models, including but not limited to Unified Modeling Language (UML), Extensible Markup Language (XML), and Common Object Request Broker Architecture (CORBA).
[0088] Hardcoding: This is a programming practice where validation rules are encoded directly in the program code rather than stored in some configurable external resource. This can result in rules that are too fragmented and difficult to maintain and update.
[0089] Embodiment 3
[0090] like Figure 1-Figure 4 As shown, an embodiment of the present invention provides a unified model verification method based on metadata drive, comprising the following steps:
[0091] S1. The metadata is processed by the service layer through the entrance of PC, app and web. The service layer provides metadata warehouse service through Meta-Repository, realizes metadata classification management, metadata cache management, basic metadata reading and writing capabilities, and uses JSON Schema for metadata definition and verification;
[0092] S2: The processed metadata is transmitted to the storage layer. The storage layer uses Redis to cache the metadata, DB to store metadata definitions, OSS to actually store file-type metadata, and ES to implement an indexing mechanism for search fields based on Schema configuration.
[0093] S3 and MetaSchema are used to define the type of metadata using the JSON Schema specification and support verification of the metadata instance MetaEntity;
[0094] S4, MetaKind defines the kind of metadata type definition based on the value type EntityValue of the metadata instance, and determines the metadata instance content storage mechanism;
[0095] S5, MetaCategory is based on the classification of application scenarios, which determines the purpose of metadata;
[0096] S6. MetaType defines the metadata type and is the core of metadata. It supports namespace and implements various logical isolations. Namespace is mainly used to distinguish multiple businesses and multiple environments.
[0097] In this embodiment, specifically, in S3, the steps of verifying the metadata instance MetaEntity are as follows:
[0098] S31. Define metadata model:
[0099] Define model structure metadata;
[0100] S32. Generate model checker:
[0101] Generate a model checker based on the metadata model;
[0102] The model checker code includes the model structure check logic and the check rule check logic;
[0103] S33, perform model verification:
[0104] Input the model to be verified into the model verifier;
[0105] The model checker performs structural verification and verification rule verification on the model;
[0106] If the model verification passes, the verification success information is output;
[0107] If the model fails to pass the verification, the verification failure information and error information will be output.
[0108] In this embodiment, specifically, in S6, multiple services are distinguished and supported by version distinction, and the version distinction includes abc.v1.XyzLayout and abc.v2.XyzLayout.
[0109] In this embodiment, specifically, in S31, the model structure metadata includes information on the model name, model type, and model rules.
[0110] In this embodiment, specifically, metadata driven: metadata driven is a design pattern that uses metadata (data about data) to drive the behavior of an application. In this case, metadata is used to drive the verification method of the model.
[0111] Unified Model Verification Method: This is a verification method that can handle various types of models, including but not limited to Unified Modeling Language (UML), Extensible Markup Language (XML), and Common Object Request Broker Architecture (CORBA).
[0112] Hardcoding: This is a programming practice where validation rules are encoded directly in the program code rather than stored in some configurable external resource. This can result in rules that are too fragmented and difficult to maintain and update.
[0113] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of various changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.
Claims
1. A unified model verification method based on metadata drive, characterized in that: The following steps are involved: S1. The metadata is processed by the service layer through the entrance of PC, app and web. The service layer provides metadata warehouse service through Meta-Repository, realizes metadata classification management, metadata cache management, basic metadata reading and writing capabilities, and uses JSON Schema for metadata definition and verification; S2: The processed metadata is transmitted to the storage layer. The storage layer uses Redis to cache the metadata, DB to store metadata definitions, OSS to actually store file-type metadata, and ES to implement an indexing mechanism for search fields based on Schema configuration. S3 and MetaSchema are used to define the type of metadata using the JSON Schema specification and support verification of the metadata instance MetaEntity; S4, MetaKind defines the kind of metadata type definition based on the value type EntityValue of the metadata instance, and determines the metadata instance content storage mechanism; S5, MetaCategory is based on the classification of application scenarios, which determines the purpose of metadata; S6. MetaType defines the metadata type and is the core of metadata. It supports namespace and implements various logical isolations. Namespace is mainly used to distinguish multiple businesses and multiple environments.
2. The metadata-driven unified model verification method according to claim 1, characterized in that: In the S3, the steps for verifying the metadata instance MetaEntity are as follows: S31. Define metadata model: Define model structure metadata; S32. Generate model checker: Generate a model checker based on the metadata model; The model checker code includes the model structure check logic and the check rule check logic; S33, perform model verification: Input the model to be verified into the model verifier; The model checker performs structural verification and verification rule verification on the model; If the model verification passes, the verification success information is output; If the model fails to pass the verification, the verification failure information and error information will be output.
3. The metadata-driven unified model verification method according to claim 1, characterized in that: In S6, a multi-service supporting service module classification mechanism is distinguished, and the service module classification mechanism includes order.XyzLayout and marketing.XyzLayout.
4. The metadata-driven unified model verification method according to claim 1, characterized in that: In S6, multiple business support environments are distinguished, and different environments obtain different data through configuration, such as dev.abc.XyzLayout and prod.abc.XyzLayout.
5. The metadata-driven unified model verification method according to claim 1, characterized in that: In S6, the multi-service support version distinction is distinguished, and the version distinction includes abc.v1.XyzLayout and abc.v2.XyzLayout.
6. The metadata-driven unified model verification method according to claim 2, characterized in that: In the S31, the model structure metadata includes information of the model name, model type and model rules.