Multi-system-oriented configurable metadata storage method

Abstract

The invention discloses a multi-system-oriented configurable metadata storage method, which comprises the following steps of: creating a tmapping table and a tcaltype table in a database, and presetting a specific value which needs to be converted; creating three java classes which are respectively used for reading the data in the two sheets of the table; the method comprises the following steps: creating a CodeMappingGroup class, and creating a hashmap set; the method comprises the following steps: creating a ConvertService class, and creating three attributes; the method comprises the following steps of: inheriting an InitializingBean interface by using a ConvertService class, and realizing an init () method; and a Convert Service class is used for realizing a Convert method. According to the invention, an efficient, flexible and maintainable field value conversion solution is provided in combination with database-based mapping relation management in an annotation-driven manner.

Description

Technical Field

[0001] The present invention relates to the technical field of silicon tetrachloride production, and in particular to a multi-system configurable metadata warehousing method. Background Art

[0002] In modern information systems, data exchange and integration between multiple systems is a common requirement. In practice, different systems may use different code systems to represent the same business field. For example, in one system, the code value for "yes" might be "1: yes; 2: no," while in another system, it might be "0: yes; 1: no." To achieve seamless data exchange and integration, these code values ​​must be converted. Traditionally, developers would check each field individually in their code and manually write logic to perform the code value conversion. This approach is not only inefficient and verbose, but also extremely difficult to maintain. Every time the business logic changes, developers need to modify and redeploy the code. This approach clearly fails to meet the demands of modern enterprises for efficient, maintainable, and flexible system integration.

[0003] Currently, the following four technical solutions are commonly used in this field: 1. Hard-coded Conversion Logic. Description: Developers hardcode the conversion logic for each field in the code. For example, manually converting code values ​​using if-else or switch-case statements results in lengthy and difficult-to-maintain code. Every time business requirements change, the code must be re-edited, which can easily introduce errors. 2. Configuration File-Driven Conversion. Description: Field conversion rules are defined using configuration files (such as XML, JSON, or YAML). The code reads the configuration files and performs conversions based on the rules. While this approach is more flexible than hard-coding, it can be complex to manage and maintain when there are too many configuration files. Furthermore, synchronization between the configuration files and the code needs to be addressed. 3. Middleware Solution. Description: Code value conversion is performed using specialized data exchange middleware (such as ETL tools). The middleware performs conversions based on predefined rules and enables data transmission. This approach uses specialized data exchange middleware (such as ETL tools) to perform code value conversions. The middleware performs conversions based on predefined rules and enables data transmission. 4. Database-Driven Conversion. Description: Maintain a mapping table in the database to define the conversion relationships between code values. When the application needs a conversion, it queries this table and performs the conversion. While this method is flexible, it requires frequent database queries, which may affect performance. Furthermore, the conversion logic for each field still needs to be manually written. Summary of the Invention

[0004] The present invention provides a configurable metadata storage method for multiple systems, aiming to solve the problem in the prior art that when performing data exchange and integration between multiple systems, it cannot meet the needs of modern enterprises for efficient, maintainable and flexible system integration.

[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0006] A configurable metadata storage method for multiple systems includes the following steps:

[0007] Step 1: Create two tables, t_mapping and t_caltype, in the database and preset the specific values ​​that need to be converted;

[0008] Step 2: Create three Java classes: ConvertConfiguration, MetaDataApi, and DataBaseMetaDataApi.

[0009] Step 3: Create a CodeMappingGroup class and create a hashmap collection named mapping;

[0010] Step 4: Create the ConvertService class and create three properties;

[0011] Step 5: Use the ConvertService class to inherit the InitializingBean interface and implement the init() method;

[0012] Step 6: Implement the convert method using the ConvertService class.

[0013] Further, in step 1, t_mapping represents the main data table, which defines the mapping relationship of code value conversion, and the t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode and c_targetname; wherein, the c_type is equivalent to the source data; the codetype represents the conversion program looking for the mapping relationship according to the value; the c_sourcecode represents the single-value code value of the source data, and the c_sourcecode represents the single-value code value of the source data; the c_sourcename represents the display name of the source data; the c_targetcodetype represents the single-value code value type after conversion; the c_targetcode represents the single-value code value after conversion; the c_targetname represents the display name after conversion.

[0014] Furthermore, t_caltype represents a calculated type mapping relationship. t_caltype is applicable to an entity bean with multiple mapping relationships, and a string is calculated through the expression engine. Finally, the string is used to find the corresponding type. The type found by the string is c_type in the t_mapping.

[0015] Furthermore, the t_caltype includes c_key and c_type; wherein c_key is a calculated character string, and c_type is a corresponding type.

[0016] Furthermore, in step 2, ConvertConfiguration represents configuration data information, which is used to query specific SQL statements, MetaDataApi represents the interface class for querying database tables, and DataBaseMetaDataApi represents the implementation class for querying database tables.

[0017] Furthermore, MetaDataApi includes two interface methods, namely findAll() and findCalTypeMapping(); among them, findAll() represents reading the data of the t_mapping table; findCalTypeMapping() is to read the data of the t_caltype table in step 1.

[0018] Furthermore, the DataBaseMetaDataApi includes two interface methods, namely findAl l() and findCalTypeMapping(), wherein findAl l() represents the implementation method of reading data from the t_mapping table; findCalTypeMapping() is the implementation method of reading data from the t_caltype table.

[0019] Furthermore, in step 4, the three properties created in the ConvertService class are MetaDataApi metaDataApi, Map<String,CodeMappingGroup> typeMapping and Map<String,String> calTypeMap, where MetaDataApi metaDataApi is the interface class for querying database table data; Map<String,CodeMappingGroup> typeMapping is a cache collection that stores t_mapping table data; Map<String,String> calTypeMap is a cache collection that stores t_caltype table data.

[0020] Furthermore, in step 5, the specific steps for implementing the init() method are as follows:

[0021] Step 5-1: Call findAll() of metaDataApi to read the data of t_mapping table in the database;

[0022] Step 5-2: Call findCalTypeMapping() of metaDataApi to read the data of t_caltype table in the database;

[0023] Step 5-3: Store the data read from the t_mapping table in the typeMapping cache collection;

[0024] Step 5-4: The data read from the t_caltype table is stored in the calTypeMap cache collection.

[0025] Furthermore, in step 6, the specific steps for implementing the convert method using the ConvertService class are as follows:

[0026] Step 6-1: Pass type and sourceCode to the convert method;

[0027] Step 6-2: Find the corresponding CodeMappingGroup in the typeMapping collection;

[0028] Step 6-3: CodeMappingGroup takes the hashmap collection named mapping and extracts the corresponding targetCode value.

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] The present invention mainly defines the metadata type and rules of conversion by adding a custom annotation @Mapping to the entity class field. At the same time, the value attribute of the annotation defines the type of conversion, which can be a primitive value or an EL expression. The cal attribute identifies how the value string calculates the type value. The check attribute defines the level of checking, thereby achieving the purpose of annotation-driven. All mapping relationships can also be centrally maintained in the t_mapping and t_caltype tables of the database. At the same time, the conversion logic is uniformly managed and called through the conversion service ConvertService, avoiding lengthy hard coding and achieving centralized management. Finally, the entity class and the conversion logic are separated, making the code more concise and easy to maintain. At the same time, the conversion rules can be dynamically adjusted without modifying the code. Only the mapping relationship in the database needs to be updated, thereby achieving efficient and flexible data exchange and integration between multiple systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 This is a flow chart of data initialization in the present invention.

[0033] Figure 2 It is a flow chart of the logical process used by users in the present invention. DETAILED DESCRIPTION

[0034] The present invention will be further described below with reference to the embodiments. The embodiments described are only a part of the embodiments of the present invention and are not all embodiments. Based on the embodiments of the present invention, other embodiments obtained by ordinary technicians in this field without making creative work are all within the scope of protection of the present invention.

[0035] This embodiment discloses a configurable metadata storage method for multiple systems, including the following steps:

[0036] Step 1: Create two tables, t_mapping and t_caltype, in the database and preset the specific values ​​that need to be converted;

[0037] Step 2: Create three Java classes: ConvertConfiguration, MetaDataApi, and DataBaseMetaDataApi.

[0038] Step 3: Create a CodeMappingGroup class and create a hashmap collection named mapping;

[0039] Step 4: Create the ConvertService class and create three properties;

[0040] Step 5: Use the ConvertService class to inherit the InitializingBean interface and implement the init() method;

[0041] Step 6: Use the ConvertService class to implement the convert method;

[0042] In some embodiments, in step 1, t_mapping represents the main data table, which defines the mapping relationship of code value conversion, and the t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode and c_targetname; wherein, the c_type is equivalent to the source data; the codetype represents the conversion program looking for the mapping relationship based on the value; the c_sourcecode represents the single-value code value of the source data, and the c_sourcecode represents the single-value code value of the source data; the c_sourcename represents the display name of the source data; the c_targetcodetype represents the single-value code value type after conversion; the c_targetcode represents the single-value code value after conversion; and the c_targetname represents the display name after conversion.

[0043] The t_mapping table structure is as follows:

[0044] Field Name Data Type illustrate c_type VARCHAR(255) The type of source data, required c_sourcecode VARCHAR(255) Source data code value, required c_sourcename VARCHAR(255) Source data display name, not required c_targetcodetype VARCHAR(255) Target data type, optional c_targetcode VARCHAR(255) Target code value, required c_targetname VARCHAR(255) Target data display name, not required

[0045] In some embodiments, t_caltype represents a calculated type mapping relationship. t_caltype is applicable to an entity bean with multiple mapping relationships, and a string is calculated through the expression engine. Finally, the string is used to find the corresponding type. The type found by the string is c_type in the t_mapping. The t_caltype table structure is as follows:

[0046]

[0047] In some embodiments, the t_caltype includes c_key and c_type; wherein c_key is a calculated string and c_type is the corresponding type.

[0048] In some embodiments, in step 2, ConvertConfiguration represents configuration data information used to query a specific SQL statement, MetaDataApi represents an interface class for querying a database table; and DataBaseMetaDataApi represents an implementation class for querying a database table.

[0049] In some embodiments, MetaDataApi includes two interface methods, namely findAl l() and findCalTypeMapping(); wherein, findAl l() represents reading the data of the t_mapping table; findCalTypeMapping() is reading the data of the t_caltype table in step 1.

[0050] In some embodiments, the DataBaseMetaDataApi includes two interface methods, namely findAll() and findCalTypeMapping(), where findAll() represents the implementation method for reading data from the t_mapping table; findCalTypeMapping() is the implementation method for reading data from the t_caltype table.

[0051] In some embodiments, in step 4, the three properties created in the ConvertService class are MetaDataApi metaDataApi, Map<String,CodeMappingGroup> typeMapping and Map<String,String> calTypeMap, where MetaDataApi metaDataApi is the interface class for querying database table data; Map<String,CodeMappingGroup> typeMapping is a cache collection that stores t_mapping table data; Map<String,String> calTypeMap is a cache collection that stores t_caltype table data.

[0052] In some embodiments, in step 5, the specific steps of implementing the init() method are as follows:

[0053] Step 5-1: Call findAll() of metaDataApi to read the data of t_mapping table in the database;

[0054] Step 5-2: Call findCalTypeMapping() of metaDataApi to read the data of t_caltype table in the database;

[0055] Step 5-3: Store the data read from the t_mapping table in the typeMapping cache collection;

[0056] Step 5-4: The data read from the t_caltype table is stored in the calTypeMap cache collection.

[0057] In some embodiments, in step 6, the specific steps of implementing the convert method using the ConvertService class are as follows:

[0058] Step 6-1: Pass type and sourceCode to the convert method;

[0059] Step 6-2: Find the corresponding CodeMappingGroup in the typeMapping collection;

[0060] Step 6-3: CodeMappingGroup takes the hashmap collection named mapping and extracts the corresponding targetCode value.

[0061] The present invention mainly defines the metadata type and rules of conversion by adding a custom annotation @Mapping to the entity class field. At the same time, the value attribute of the annotation defines the type of conversion, which can be a primitive value or an EL expression. The cal attribute identifies how the value string calculates the type value. The check attribute defines the level of checking, thereby achieving the purpose of annotation-driven. All mapping relationships can also be centrally maintained in the t_mapping and t_caltype tables of the database. At the same time, the conversion logic is uniformly managed and called through the conversion service ConvertService, avoiding lengthy hard coding and achieving centralized management. Finally, the entity class and the conversion logic are separated, making the code more concise and easy to maintain. At the same time, the conversion rules can be dynamically adjusted without modifying the code. Only the mapping relationship in the database needs to be updated, thereby achieving efficient and flexible data exchange and integration between multiple systems.

[0062] like Figure 1 As shown, as an optional implementation, this embodiment also includes a data initialization process, the specific method is as follows:

[0063] Step A: Create tables t_mapping and t_caltype and insert initialization data;

[0064] The data in the t_mapping table is as follows:

[0065]

[0066] The data in the t_caltype table is as follows:

[0067] c_key c_type orderStatus orderStatus userStatus userStatus

[0068] Step B: Initialize the service;

[0069] Specifically also include:

[0070] Step B-1: The ConvertService class inherits the InitializingBean class of the Spring framework and implements the init method. The program will automatically run the init method when it starts.

[0071] Step C: Load t_mapping table data into typeMapping memory;

[0072] Specifically also include:

[0073] Step C-1: Call the MetaDataApi.findAll() method to read the data of the t_mapping table from the database.

[0074] Step C-2: Save the read data into the typeMapping memory.

[0075] Among them, typeMapping is a Map<String,CodeMappingGroup> The data structure of the key is string type and the value is CodeMappingGroup type. The above table is stored in it. The specific format is as follows:

[0076]

[0077] Step D: Load t_caltype table data into calTypeMap memory;

[0078] Specifically also include:

[0079] Step D-1: Call MetaDataApi.findCalTypeMapping() method to read t_caltype from the database.

[0080] Step D-2: Save the read data into the calTypeMap memory.

[0081] Among them, calTypeMap is a Map<String,String> The data structure of key is string type, value is string type, and the above table is stored in it. The specific format is as follows:

[0082] Key(String) Value(string) "orderStatus" "orderStatus" "userStatus" "userStatus"

[0083] Among them, step B also includes step B-2: the init method will run the logic of step C and step D.

[0084] like Figure 2 As shown, in some optional embodiments, this embodiment further discloses a process of user using logic, when using, the user inputs the values ​​of key, type and sourceCode, such as inputting key=orderStatus, sourceCode=100, the purpose of which is to implement code conversion according to the input key and sourceCode;

[0085] The processing logic includes the following steps:

[0086] Step a: 1. Call the convert method of ConvertService, passing in key = orderStatus and sourceCode = 100;

[0087] Step b: calTypeMap memory returns value according to key = orderStatus;

[0088] Step c: Check the typeMapping memory and query the corresponding value according to the value returned above, that is, to obtain the corresponding CodeMappingGroup;

[0089] Step d: Call CodeMappingGroup.mapping.get(sourceCode), pass in sourceCode=100 to obtain the target code Pending.

[0090] In the description of the present invention, it should be understood that the terms "coaxial", "bottom", "one end", "top", "middle", "the other end", "upper", "one side", "top", "inside", "front", "center", "two ends", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention.

[0091] In addition, the terms "first", "second", "third" and "fourth" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first", "second", "third" and "fourth" may explicitly or implicitly include at least one such feature.

[0092] In the present invention, unless otherwise clearly stipulated and limited, the terms such as "installation", "setting", "connection", "fixation" and "screw-on" should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integrated connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, it can be the internal connection of two elements or the interaction relationship between two elements. Unless otherwise clearly defined, ordinary technicians in this field can understand the specific meanings of the above terms in the present invention according to the specific circumstances.

[0093] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A configurable metadata storage method for multiple systems, characterized by: The following steps are involved: Step 1: Create two tables, t_mapping and t_caltype, in the database and preset the specific values ​​that need to be converted; Step 2: Create three Java classes: ConvertConfiguration, MetaDataApi, and DataBaseMetaDataApi. MetaDataApi is used to read the data in the t_mapping and t_caltype tables in step 1; DataBaseMetaDataApi is used to read the implementation method of the data in the t_mapping and t_caltype tables in step 1. Step 3: Create a CodeMappingGroup class and create a hashmap collection named mapping; Step 4: Create the ConvertService class and create three properties, namely MetaDataApi, MetaDataApi, Map<String,CodeMappingGroup> typeMapping and Map<String,String> calTypeMap, the MetaDataApi metaDataApi is an interface class used to query database table data, the Map<String,CodeMappingGroup> typeMapping is used to store the cache collection of t_mapping table data.<String,String> Cache collection used to store t_caltype table data; Step 5: Use the ConvertService class to inherit the InitializingBean interface and implement the init() method. The init() method is used to call the metaDataApi in step 4 to read the data of the t_mapping table and t_caltype table in step 1, and to store the read data of the t_mapping table and t_caltype table in the storage collection of typeMapping and calTypeMap in step 4; Step 6: Implement the convert method using the ConvertService class.

2. The multi-system configurable metadata storage method according to claim 1, characterized in that: In step 1, t_mapping represents the main data table and defines the mapping relationship of code value conversion. The t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode and c_targetname; wherein, the c_type is the source data; the codetype represents that the conversion program searches for the mapping relationship according to the value; the c_sourcecode represents the single-value code value of the source data, and the c_sourcecode represents the single-value code value of the source data; the c_sourcename represents the display name of the source data; the c_targetcodetype represents the type of the single-value code value after conversion; the c_targetcode represents the single-value code value after conversion; and the c_targetname represents the display name after conversion.

3. The multi-system configurable metadata storage method according to claim 2, characterized in that: t_caltype represents the calculation type mapping relationship. t_caltype is applicable to an entity bean with multiple mapping relationships, and calculates a string through the expression engine. Finally, the string is used to find the corresponding type. The type found by the string is c_type in the t_mapping.

4. The multi-system configurable metadata storage method according to claim 3, characterized in that: The t_caltype includes c_key and c_type; wherein c_key is a calculated string and c_type is the corresponding type.

5. The multi-system configurable metadata storage method according to claim 1, characterized in that: In step 2, ConvertConfiguration represents configuration data information, which is used to query specific SQL statements. MetaDataApi represents the interface class for querying database tables. DataBaseMetaDataApi represents the implementation class for querying database tables.

6. The multi-system configurable metadata storage method according to claim 1, characterized in that: MetaDataApi includes two interface methods, namely findAll() and findCalTypeMapping(); among them, findAll() represents reading the data of the t_mapping table; findCalTypeMapping() is to read the data of the t_caltype table in step 1.

7. The multi-system configurable metadata storage method according to claim 5, characterized in that: The DataBaseMetaDataApi includes two interface methods, namely findAll() and findCalTypeMapping(), wherein findAll() represents the implementation method for reading data from the t_mapping table; findCalTypeMapping() is the implementation method for reading data from the t_caltype table.

8. The multi-system configurable metadata storage method according to claim 1, characterized in that: In step 4, MetaDataApi metaDataApi is the interface class for querying database table data; Map<String,CodeMappingGroup> typeMapping is a cache collection that stores t_mapping table data; Map<String,String> calTypeMap is a cache collection that stores t_caltype table data.

9. The multi-system configurable metadata storage method according to claim 1, characterized in that: In step 5, the specific steps to implement the init() method are as follows: Step 5-1: Call findAll() of metaDataApi to read the data of t_mapping table in the database; Step 5-2: Call findCalTypeMapping() of metaDataApi to read the data of t_caltype table in the database; Step 5-3: Store the data read from the t_mapping table in the typeMapping cache collection; Step 5-4: The data read from the t_caltype table is stored in the calTypeMap cache collection.

10. The multi-system configurable metadata storage method according to claim 1, characterized in that: In step 6, the specific steps to implement the convert method using the ConvertService class are as follows: Step 6-1: Pass type and sourceCode to the convert method; Step 6-2: Find the corresponding CodeMappingGroup in the typeMapping collection; Step 6-3: CodeMappingGroup takes the hashmap collection named mapping and extracts the corresponding targetCode value.

Images