A multi-system-oriented configurable metadata warehousing method

Abstract

The application discloses a configurable metadata warehousing method for multiple systems, which comprises the following steps: creating two tables of t_mapping and t_caltype in a database, and presetting specific values needing conversion; creating three java classes for reading data in the two tables; creating a CodeMappingGroup class and a hashmap collection; creating a ConvertService class and three attributes; using the ConvertService class to inherit an InitializingBean interface and implement an init() method; and using the ConvertService class to implement a convert method. The application provides an efficient, flexible and maintainable field value conversion solution by means of an annotation driven mode and a mapping relationship management based on a database.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a configurable metadata import method for multiple systems. Background Technology

[0002] In modern information systems, data exchange and integration between multiple systems is a common requirement. In practice, different systems may use different code structures to represent the same business fields. 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 one by one in the code and manually write logic to convert the code values. This method is not only inefficient and verbose, but also very difficult to maintain. Whenever the business logic changes, developers need to modify and redeploy the code. This approach clearly cannot meet the modern enterprise's needs for efficient, maintainable, and flexible system integration.

[0003] Currently, commonly used technical solutions in this field include the following four types: 1. Hard-coded transformation logic. Description: Developers hard-code the transformation logic for each field in the code. For example, manually performing code value transformation using if-else or switch-case statements. However, this method results in verbose and difficult-to-maintain code. Whenever business requirements change, the code must be modified again, and errors are easily introduced. 2. Configuration file-driven transformation. Description: Using configuration files (such as XML, JSON, YAML, etc.) to define field transformation rules. The code reads the configuration file and performs transformations according to the rules. Although this method is more flexible than the hard-coded method, management and maintenance become complex when there are too many configuration files. In addition, the synchronization problem between configuration files and code also needs to be solved. 3. Middleware solution. Description: Using specialized data exchange middleware (such as ETL tools) for code value transformation. The middleware can perform transformations according to predefined rules and realize data transmission. 4. Database-driven transformation. Description: Maintain a mapping table in the database to define the conversion relationships between code values. When the application needs to convert, it queries this table and performs the conversion. While this method is flexible, it requires frequent database queries, which may impact performance. Furthermore, the conversion logic for each field still needs to be written manually. Summary of the Invention

[0004] This invention provides a configurable metadata import method for multiple systems, aiming to solve the problem that existing technologies cannot meet the modern enterprise's needs for efficient, maintainable, and flexible system integration when exchanging and integrating data between multiple systems.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A configurable metadata import method for multiple systems includes the following steps: 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. Step 3: Create a CodeMappingGroup class and create a hashmap collection named mapping; Step 4: Create the ConvertService class and create 3 properties; Step 5: Use the ConvertService class to inherit the InitializingBean interface and implement the init() method; Step 6: Implement the convert method using the ConvertService class.

[0006] Further, in step 1, t_mapping represents the master data table, which defines the mapping relationship for code value conversion. t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode, and c_targetname. Here, c_type corresponds to the source data; codetype represents the mapping relationship the conversion program uses to find the mapping relationship; c_sourcecode represents the single-value code of the source data; c_sourcename represents the source data display name; c_targetcodetype represents the type of the converted single-value code; c_targetcode represents the converted single-value code; and c_targetname represents the converted display name.

[0007] Furthermore, t_caltype represents the calculation type mapping relationship. t_caltype is suitable for an entity Bean to have multiple mapping relationships. It calculates a string through the expression engine and finally uses the string to look up the corresponding type. The type found by the string is c_type in t_mapping.

[0008] Furthermore, the t_caltype includes c_key and c_type; where c_key is the calculated string and c_type is the corresponding type.

[0009] Furthermore, in step 2, ConvertConfiguration represents configuration data information 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.

[0010] Furthermore, MetaDataApi includes two interface methods: findAll() and findCalTypeMapping(); where findAll() represents reading data from the t_mapping table; and findCalTypeMapping() is used to read data from the t_caltype table in step 1.

[0011] Furthermore, the DataBaseMetaDataApi includes two interface methods: findAll() and findCalTypeMapping(). FindAll() represents the implementation method for reading data from the t_mapping table, while findCalTypeMapping() is the implementation method for reading data from the t_caltype table.

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

[0013] Furthermore, in step 5, the specific steps for implementing the init() method are as follows: Step 5-1: Call metaDataApi's findAll() method to read data from the t_mapping table in the database; Step 5-2: Call metaDataApi's findCalTypeMapping() to read data from the 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.

[0014] Furthermore, in step 6, the specific steps for implementing the convert method using the ConvertService class are as follows: Step 6-1: Pass the type and sourceCode to the convert method; Step 6-2: Based on the typeMapping collection, find the corresponding CodeMappingGroup; Step 6-3: Take a hashmap collection named mapping from CodeMappingGroup and retrieve the corresponding targetCode value.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention primarily defines the metadata types and rules for transformation by adding a custom annotation `@Mapping` to entity class fields. The annotation's `value` attribute defines the transformation type, which can be a raw value or an EL expression; the `cal` attribute indicates how the `value` string is calculated to produce the type value; and the `check` attribute defines the level of checking, achieving annotation-driven functionality. Furthermore, all mapping relationships can be centrally maintained in the `t_mapping` and `t_caltype` tables in the database. The transformation logic is uniformly managed and invoked through the `ConvertService`, avoiding lengthy hard-coding and achieving centralized management. Finally, separating entity classes and transformation logic makes the code more concise and easier to maintain. Simultaneously, transformation rules can be dynamically adjusted without modifying the code; only the mapping relationships in the database need to be updated. This enables efficient and flexible data exchange and integration between multiple systems. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the data initialization process in this invention.

[0018] Figure 2 This is a flowchart illustrating the user's logical process in this invention. Detailed Implementation

[0019] The present invention will be further described below with reference to embodiments. These embodiments are merely some, not all, of the embodiments of the present invention. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the protection scope of the present invention.

[0020] This embodiment discloses a method for storing configurable metadata in a database for multiple systems, including the following steps: 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. Step 3: Create a CodeMappingGroup class and create a hashmap collection named mapping; Step 4: Create the ConvertService class and create 3 properties; Step 5: Use the ConvertService class to inherit the InitializingBean interface and implement the init() method; Step 6: Implement the convert method using the ConvertService class; In some embodiments, in step 1, t_mapping represents the master data table, which defines the mapping relationship for code value conversion. t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode, and c_targetname. Here, c_type corresponds to the source data; codetype represents the mapping relationship the conversion program uses to find the mapping relationship; c_sourcecode represents the single-value code of the source data; c_sourcename represents the source data display name; c_targetcodetype represents the type of the converted single-value code; c_targetcode represents the converted single-value code; and c_targetname represents the converted display name.

[0021] The structure of the t_mapping table is as follows:

[0022]

[0023] In some embodiments, t_caltype represents a computational type mapping relationship. t_caltype is suitable for an entity Bean to have multiple mapping relationships. It calculates a string through an expression engine and finally uses the string to look up the corresponding type. The type found by the string is c_type in t_mapping.

[0024] The structure of the t_caltype table is as follows:

[0025]

[0026] In some embodiments, t_caltype includes c_key and c_type; where c_key is the calculated string and c_type is the corresponding type.

[0027] In some embodiments, in step 2, ConvertConfiguration represents configuration data information 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.

[0028] In some embodiments, MetaDataApi includes two interface methods: findAll() and findCalTypeMapping(); where findAll() represents reading data from the t_mapping table; and findCalTypeMapping() is used to read data from the t_caltype table in step 1.

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

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

[0031] In some embodiments, the specific steps for implementing the init() method in step 5 are as follows: Step 5-1: Call metaDataApi's findAll() method to read data from the t_mapping table in the database; Step 5-2: Call metaDataApi's findCalTypeMapping() to read data from the 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.

[0032] In some embodiments, the specific steps for implementing the convert method using the ConvertService class in step 6 are as follows: Step 6-1: Pass the type and sourceCode to the convert method; Step 6-2: Based on the typeMapping collection, find the corresponding CodeMappingGroup; Step 6-3: Take a hashmap collection named mapping from CodeMappingGroup and retrieve the corresponding targetCode value.

[0033] This invention primarily defines the metadata type and rules for transformation by adding a custom annotation `@Mapping` to entity class fields. The annotation's `value` attribute defines the transformation type, which can be a raw value or an EL expression; the `cal` attribute indicates how the `value` string is calculated to produce the type value; and the `check` attribute defines the level of checking, achieving annotation-driven functionality. Furthermore, all mapping relationships can be centrally maintained in the `t_mapping` and `t_caltype` tables in the database. The transformation logic is uniformly managed and invoked through the `ConvertService`, avoiding lengthy hard-coding and achieving centralized management. Finally, separating entity classes and transformation logic makes the code more concise and easier to maintain. Simultaneously, transformation rules can be dynamically adjusted without modifying the code; only the mapping relationships in the database need to be updated. This enables efficient and flexible data exchange and integration between multiple systems.

[0034] like Figure 1 As shown, as an optional implementation, this embodiment also includes a data initialization process, the specific method of which is as follows: Step A: Create tables t_mapping and t_caltype, and insert initialization data; The t_mapping table contains the following data:

[0035]

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

[0037]

[0038] Step B: Perform service initialization; Specifically, it also includes: Step B-1: The ConvertService class inherits from the InitializingBean class of the Spring framework and implements the init method. The program will automatically run the init method when it starts up. Step C: Load the t_mapping table data into typeMapping memory; Specifically, it also includes: Step C-1: Call the MetaDataApi.findAll() method to read data from the t_mapping table in the database.

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

[0040] Where ypeMapping is a Map<String, CodeMappingGroup> The data structure uses a string key and a CodeMappingGroup value to store the above table, with the following format:

[0041]

[0042] Step D: Load the data from the t_caltype table into the calTypeMap memory; Specifically, it also includes: Step D-1: Call the MetaDataApi.findCalTypeMapping() method to read t_caltype from the database.

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

[0044] Wherein, calTypeMap is a Map<String, String> The data structure uses string keys and string values. The table above is stored in this structure, with the following format:

[0045]

[0046] Step B also includes step B-2: the init method will run the logic of steps C and D.

[0047] like Figure 2 As shown, in some optional embodiments, this embodiment also discloses a process for a user to use the logic. When using it, the user inputs the values ​​of key, type and sourceCode, such as inputting key=orderStatus and sourceCode=100. The purpose is to realize code conversion based on the input key and sourceCode. The following steps are included when processing logic: Step a: 1. Call the convert method of ConvertService, passing in key=orderStatus and sourceCode=100; Step b: The calTypeMap memory returns the value based on key=orderStatus; Step c: Check the typeMapping memory. Based on the returned value, query the corresponding value, which is to obtain the corresponding CodeMappingGroup; Step d: Call CodeMappingGroup.mapping.get(sourceCode), passing in sourceCode=100 to get the target code Pending.

[0048] In the description of this invention, it should be understood that the terms "coaxial," "bottom," "one end," "top," "middle," "other end," "upper," "side," "top," "inner," "front," "center," "both ends," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0049] Furthermore, the terms “first,” “second,” “third,” and “fourth” are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as “first,” “second,” “third,” or “fourth” may explicitly or implicitly include at least one of those features.

[0050] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "setting," "connection," "fixing," "screw connection," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal connection of two components or the interaction between two components. Unless otherwise explicitly limited, those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0051] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for storing configurable metadata in a database for multiple systems, characterized in that, Includes the following steps: 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 data from the t_mapping and t_caltype tables in Step 1; DataBaseMetaDataApi is used to read the implementation methods 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: MetaDataAp, MetaDataApi, and Map.<String, CodeMappingGroup> typeMapping and Map<String, String> calTypeMap, where MetaDataApi is the interface class used to query database table data, and Map...<String, CodeMappingGroup> typeMapping is a cache collection used to store data from the t_mapping table.<String, String> calTypeMap is a cached collection used to store data from the t_caltype table; 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 t_mapping table and t_caltype table data in the storage collection of typeMapping and calTypeMap in step 4. Step 6: Implement the convert method using the ConvertService class; In step 1, t_mapping represents the master data table, which defines the mapping relationship for code value conversion. t_mapping includes c_type, codetype, c_sourcecode, c_sourcename, c_targetcodetype, c_targetcode, and c_targetname. Here, c_type represents the type of the source data; codetype represents the mapping relationship looked up by the conversion program based on c_type; c_sourcecode represents the single-value code of the source data; c_sourcename represents the name of the source data display; c_targetcodetype represents the type of the converted single-value code; c_targetcode represents the converted single-value code; and c_targetname represents the converted display name. t_caltype represents the calculation type mapping relationship. t_caltype is suitable for an entity Bean with multiple mapping relationships. It calculates a string through the expression engine and finally uses the string to look up the corresponding type. The type found by the string is c_type in t_mapping. The t_caltype includes c_key and c_type; where c_key is the calculated string and c_type is the corresponding type.

2. The method for storing configurable metadata for multiple systems according to claim 1, characterized in that: In step 2, ConvertConfiguration represents configuration data information 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.

3. The method for storing configurable metadata for multiple systems according to claim 1, characterized in that: MetaData API includes two interface methods: findAll() and findCalTypeMapping(). findAll() reads data from the t_mapping table, while findCalTypeMapping() reads data from the t_caltype table in step 1.

4. The method for storing configurable metadata for multiple systems according to claim 2, characterized in that: The DataBaseMetaDataApi includes two interface methods: findAll() and findCalTypeMapping(). findAll() represents the implementation method for reading data from the t_mapping table, while findCalTypeMapping() is the implementation method for reading data from the t_caltype table.

5. The method for configurable metadata storage for multiple systems according to claim 1, characterized in that: In step 5, the specific steps for implementing the init() method are as follows: Step 5-1: Call metaDataApi's findAll() method to read data from the t_mapping table in the database; Step 5-2: Call metaDataApi's findCalTypeMapping() to read data from the 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: Store the data read from the t_caltype table in the calTypeMap cache collection.

6. The method for storing configurable metadata for multiple systems according to claim 1, characterized in that: In step 6, the specific steps for implementing the convert method using the ConvertService class are as follows: Step 6-1: Pass the type and sourceCode to the convert method; Step 6-2: Based on the typeMapping collection, find the corresponding CodeMappingGroup; Step 6-3: Retrieve the corresponding targetCode value from the hashmap collection named mapping in CodeMappingGroup.

Images