Complex data model non-intrusive field conversion platform

Abstract

The invention provides a complex data model non-intrusive field conversion platform, which comprises a determination unit used for determining a source model and a target model; the configuration unit is used for configuring at least one mapping rule scheme, and an effective condition of the current mapping rule scheme and at least one field mapping rule in the current mapping rule scheme are defined in each mapping rule scheme; the distribution unit is used for determining a mapping rule scheme as an effective rule scheme; the mapping selection unit is used for selecting a source field needing to be mapped and a target field needing to be mapped, and selecting a field mapping rule between the source field and the target field from the effective rule scheme; and the execution unit is used for mapping the source field to the target field based on the field mapping rule. According to the scheme, multiple sets of mapping rule schemes are configured on the platform according to the source model and the target model, and the appropriate mapping rule scheme is selected to flexibly perform field conversion on the complex data model.

Description

Technical Field

[0001] The present application relates to the field of big data processing technology, and in particular to a non-intrusive field conversion platform for complex data models. Background Art

[0002] In today's digital age, data interactions between software systems are extremely frequent and diverse, and the complexity of data structures continues to rise, transforming from simple flat structures to complex structures with multiple nodes nested and multi-level associations. For example, financial transaction systems contain multi-dimensional and mutually nested data structures such as transaction details, account information, and risk assessments. However, each system has different development languages ​​and data format preferences. For example, Java systems often use XML, and Python systems mostly use JSON format. This causes the following problems in traditional data conversion solutions:

[0003] The disadvantages of hard-coding code are serious: When traditionally connecting multiple systems, it is often necessary to hard-code a large amount of conversion logic in the code for different data models. For example, when connecting trading systems of different financial institutions, due to differences in data structure and format, developers need to write a large amount of code for field matching, format conversion, and operation rules, which prolongs the project development cycle and increases costs dramatically. In addition, the code base is bloated and messy, making maintenance and upgrades difficult, and a modification can easily lead to chain errors.

[0004] Mapping configuration is scattered and chaotic: complex data model conversion lacks a unified planning and configuration environment. Each business system handles field mapping on its own, and the rules are scattered in different code modules, with no centralized management and maintenance. For example, in the supply chain system, the production, warehousing, and sales links are connected. Due to the lack of unified mapping configuration, data interaction is chaotic, data consistency and accuracy are difficult to guarantee, and system collaboration efficiency is low.

[0005] Limited format conversion capabilities: Faced with diverse data formats such as XML, JSON, and MAP, and data structure requirements in different languages, traditional methods are rigid. In cross-industry data sharing scenarios, data format and language incompatibility issues frequently occur, and format conversion and serialization and deserialization operations are complex and error-prone. Developers are often required to write a large amount of adaptation code, which increases the development burden and error risks, hinders smooth data interaction and efficient system collaboration, and restricts business development and innovation. Summary of the invention

[0006] An embodiment of the present application provides a non-intrusive field conversion platform for complex data models, which configures multiple mapping rule schemes based on source models and target models on the platform, and selects appropriate mapping rule schemes to flexibly perform field conversion on complex data models.

[0007] In a first aspect, an embodiment of the present application provides a non-intrusive field conversion platform for complex data models, including:

[0008] A determination unit, used for determining a source model including a plurality of source fields and a target model including a plurality of target fields that need to be converted;

[0009] A configuration unit, configured to configure at least one mapping rule scheme, each mapping rule scheme defining a validity condition of the current mapping rule scheme and at least one field mapping rule in the current mapping rule scheme;

[0010] An allocation unit determines a mapping rule scheme as an effective rule scheme based on a source model and a target model;

[0011] The mapping selection unit is used to select the source field to be mapped from the source model, select the target field to be mapped from the target model, and select the field mapping rule between the source field and the target field from the effective rule scheme;

[0012] The execution unit maps the source field to the target field based on the field mapping rules.

[0013] In a second aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute a non-intrusive field conversion platform for complex data models.

[0014] The main contributions and innovations of the present invention are as follows:

[0015] The embodiment of the present application configures multiple sets of mapping rule schemes in a non-invasive field conversion platform for complex data models, and selects appropriate mapping rule schemes to flexibly perform field conversion on complex data models; the embodiment of the present application uses effective rule expressions to select appropriate mapping rule schemes, thereby ensuring the flexibility of mapping rule scheme selection and meeting the needs of different application scenarios; the embodiment of the present application has built-in serialization and deserialization operations, fully supports conversion of multiple data formats such as SON, XML and MAP, is compatible with multiple programming languages ​​such as JAVA and .NET, and realizes efficient data conversion between different data models.

[0016] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0018] Figure 1 is a schematic diagram of a non-intrusive field conversion platform for a complex data model according to an embodiment of the present application;

[0019] Figure 2 It is a field conversion logic diagram of a flat structure according to an embodiment of the present application;

[0020] Figure 3 It is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0021] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0022] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0023] Embodiment 1

[0024] The embodiment of the present application provides a non-intrusive field conversion platform for complex data models, which configures multiple mapping rule schemes according to the source model and the target model on the platform, and selects the appropriate mapping rule scheme to flexibly convert the fields of the complex data model. Specifically, refer to Figure 1 , the platform comprises:

[0025] A determination unit, used for determining a source model including a plurality of source fields and a target model including a plurality of target fields that need to be converted;

[0026] A configuration unit, configured to configure at least one mapping rule scheme, each mapping rule scheme defining a validity condition of the current mapping rule scheme and at least one field mapping rule in the current mapping rule scheme;

[0027] An allocation unit determines a mapping rule scheme as an effective rule scheme based on a source model and a target model;

[0028] The mapping selection unit is used to select the source field to be mapped from the source model, select the target field to be mapped from the target model, and select the field mapping rule between the source field and the target field from the effective rule scheme;

[0029] The execution unit maps the source field to the target field based on the field mapping rules.

[0030] In some specific embodiments, the source model and the target model in this solution are both data models, which include multiple field element information, and each field represents an actual information, such as user name, user avatar, user account, etc.

[0031] It is worth mentioning that the complex data model non-intrusive field conversion platform in this solution is connected to multiple business systems, so the complex data model non-intrusive field conversion platform supports the conversion of data formats including SON, XML and MAP. In other words, users can select the input and output data formats in the complex data model non-intrusive field conversion platform, and the platform will automatically complete the format conversion to ensure seamless transmission of data between different systems.

[0032] In some specific embodiments, each mapping rule scheme includes built-in field mapping rules and custom field mapping rules.

[0033] Specifically, the built-in field mapping rules are built-in functions for Aviator scripts, such as string functions:

[0034]

[0035]

[0036] And the mathematical functions:

[0037] math.abs(d) Find the absolute value of d math.round(d) rounding math.floor(d) Round down math.ceil(d) Round up

[0038] The custom field mapping rules are operation rules customized according to the operation needs in actual applications. The custom field mapping rules can be encapsulated by writing custom functions in the Aviator script, and the custom functions are saved in the complex data model non-intrusive field conversion platform for use by other mapping rule solutions.

[0039] Specifically, fill in the name of the custom function, input parameters, and write the method body (function logic) to create a new custom function. At the same time, when writing a custom function, you can nest the built-in functions in the Aviator script to achieve nested function calls.

[0040] In some specific embodiments, a valid rule expression is constructed, and a mapping rule scheme is selected as the valid rule scheme based on the Boolean value judgment by using the valid rule expression.

[0041] In some specific embodiments, the effective rule expression is written using Aviator syntax, an effective rule is set for each mapping rule scheme, the effective rule expression is used to judge each effective rule and return a Boolean value, and the mapping rule scheme corresponding to the effective rule with a Boolean value of true is selected as the effective rule scheme.

[0042] Specifically, the core function of the effective rule expression is to act as a "switch". By judging the effective rules, it finally outputs a true or false result. Only when this result is true, it means that the corresponding mapping rule solution can be enabled and effective; if it is false, the corresponding mapping rule solution will not be used to perform data conversion operations.

[0043] For example, there is an effective rule modelAProperty>5&&modelBProperty<30. If the result obtained by using the effective rule expression to calculate the effective rule is true, then the field conversion can be performed according to the corresponding mapping rule solution. If the result is false, the field conversion cannot be performed according to the corresponding mapping rule solution.

[0044] Furthermore, if there are multiple Boolean values ​​corresponding to effective rules that are true, the mapping rule scheme corresponding to the first effective rule judged to be true is selected as the effective rule scheme.

[0045] For example, there are three sets of effective rules and corresponding mapping rule schemes between model A and model B. During a certain data processing, these three sets of effective rules are calculated to obtain the results of true, true, and true respectively, but the background will only select the mapping rule scheme corresponding to the first effective rule judged as true as the effective rule scheme to convert the data between model A and model B, and ignore the mapping rule schemes corresponding to other effective rules that are also true.

[0046] In some specific embodiments, when the source field and the target field are in a flat structure, the field mapping rule between the source field and the corresponding target field is: copying the content of the source field to the corresponding target field.

[0047] Specifically, the source fields and target fields of the flat structure are often queried from the database system. The biggest feature of the flat structure is that all fields are flat structures, so when configuring the segment mapping rules, you can accurately select a specific field.

[0048] For example, there is a system A user model as the source model, and a system B user model as the target model. The source field in the source model and the target field in the target model are in a flat structure. When the system A user model and the system B user model perform field conversion, the userAccount field in the system A user model can be directly mapped to the account field in the system B user model. In this case, since the meanings expressed in the two models are the same, only a simple value copy is required. The field conversion logic when the source model and the target model are in a flat structure is as follows: Figure 2 shown.

[0049] In some specific embodiments, when the source field and the target field are nested structures, the conversion logic between the source field and the corresponding target field is: determine whether the source field and the corresponding target field are fields of the same level and the same name. If so, directly copy the content of the source field to the corresponding target field; otherwise, use the Aviator script to perform logical conversion between the source field and the corresponding target field.

[0050] Specifically, in actual business scenarios, in addition to simple flat structures, there are more complex nested structures. In the nested structures, some fields representing a meaning often form an object node, which is mounted under a node at a certain level that represents a broader meaning.

[0051] In some embodiments, jsonpath is used to traverse the structure tree of the source model and the target model, and the field content in the source model is copied to the field with the same name at the same level in the target model.

[0052] Specifically, use the Jackson tool to obtain the mapped field position in the target model, then obtain the corresponding value from the source model, and map the value to the target model.

[0053] Specifically, for source fields and target fields of nested structures, the conversion between fields involves complex operations, such as adding the contents of two fields in the source model to a field in the target model, or performing other operations on several fields in the source model to obtain the value of a field in the target model. Therefore, this solution introduces the Aviator script engine to write Aviator scripts to implement complex logical operations between fields, thereby mapping the fields in the source model to the target model.

[0054] Furthermore, in the source field of the nested structure, if the source field is an array node, the Aviator script is used to perform field conversion on the array node itself.

[0055] Specifically, an array node may contain multiple data, such as [1, 2, 3]. When performing field conversion, if the conversion logic is also specified for the data in the array node, it may cause logical confusion and data deviation in different array nodes. Therefore, this solution performs field conversion on the array node itself when performing field conversion, that is, [1, 2, 3] is regarded as a whole.

[0056] In practical applications, it is inevitable to process the specific data in the array, so in this solution, a for loop is used to process the field information under the array node.

[0057] In some specific embodiments, after selecting a suitable mapping rule scheme, one-to-one, one-to-many, and many-to-many field mappings can be performed between specific fields of the source model and the target model based on the mapping rule scheme.

[0058] In some specific embodiments, the specific process of the execution unit performing field conversion is as follows:

[0059] 1. Initialize the conversion list

[0060] Create an empty ArrayListtransformDTOList to store the source model collection that needs to be converted.

[0061] 2. Traverse the model mapping cache

[0062] Use the forEach method to iterate over each entry in the modelMappingCacheMap.

[0063] Each entry contains a primary key pkModelMapping and a ModelMappingCache object modelMappingCache.

[0064] 3. Process each model mapping

[0065] Create a new TransformDTO object transformDTO. Set the source model code sourceModelCode and the target model code targetModelCode of transformDTO.

[0066] 4. Check the effective rules

[0067] Get the effective rule cache ruleCacheMap of the current model mapping.

[0068] If ruleCacheMap is empty, log the error and add the error record to errorList, then continue processing the next model mapping.

[0069] Initialize two atomic variables, pass and pkRule, which are used to mark whether the rule is passed and store the primary key of the effective rule respectively.

[0070] 5. Processing Effective Rules

[0071] If ruleCacheMap has only one effective rule:

[0072] If the expression of the effective rule is empty or the expression verification passes, set pass to true and record the primary key of the effective rule.

[0073] If ruleCacheMap has multiple effective rules:

[0074] Traverse each effective rule and bring the data in the dataMap into the expression of the effective rule for calculation.

[0075] If a valid rule is found that meets the conditions, set pass to true and record the primary key of the valid rule, then exit the loop.

[0076] 6. Get field mapping

[0077] If there is a valid rule that passes (i.e. pass is true):

[0078] Get the corresponding mapping rule scheme from EsbTransformCache and set it in transformDTO.

[0079] Add transformDTO to transformDTOList.

[0080] If no effective rules are passed, an error log is recorded and the error record is added to errorList.

[0081] The core logic of field conversion is:

[0082] 1. Loop through the transformation list (transformDTOList)

[0083] For each transformDTO, try to get the corresponding target model JSON string from EsbTransformCache.

[0084] Convert dataMap to JSON string sourceJson.

[0085] If the target model JSON does not exist, a warning log is logged and the current target model is skipped to continue processing the next model.

[0086] 2. Data replication between models

[0087] Use the JsonPathUtils.fastMapping method to quickly map sourceJson data to targetJson, that is, copy data directly from the source model to the target model.

[0088] 3. Processing field mapping

[0089] Get the field mapping list fieldMappingCacheList in the current transformation definition.

[0090] If the field mapping list is not empty, enter the field mapping process.

[0091] For each field mapping mapping, parse its mapping expression express.

[0092] Use AviatorEvaluator to evaluate the expression and store the result in variable v.

[0093] If the calculation fails, construct an error record TransFormErrorRecordResultDTO and add it to errorList.

[0094] Decide whether to stop the current model conversion or continue processing subsequent fields based on the configured strategy.

[0095] Fill the calculated value v into the specified path of the target model.

[0096] If the population fails, an error record is also constructed and the error is handled.

[0097] The error handling logic is the same as above.

[0098] Set the updated target model JSON string back into the value property of transformDTO.

[0099] 4. Processing without field mapping

[0100] If there is no field mapping rule (i.e. fieldMappingCacheList is empty), the target model JSON string is directly set back to the value property of transformDTO.

[0101] 5. Return the parsed JSON string.

[0102] In some specific embodiments, the complex data model non-intrusive field conversion platform of the present solution supports multiple programming languages ​​such as JAVA and .NET, and the publishing end can support different message formats when publishing source models and target models that require field conversion. For example, the publishing end can publish XML format message data to the platform, and the downstream end can receive JSON format data. For multiple systems connected to the platform, the requirements for the message format may also be different. System A may publish XML format messages, but when converting to the downstream system, the downstream system B is more compatible with the JSON format. In this case, the SDK provided by the platform provides various message format conversion capabilities, which can be converted into corresponding formats for data consumption.

[0103] In some specific embodiments, the non-intrusive field conversion platform for complex data models supports serialization and deserialization capabilities. When the publisher publishes the source model and the target model that require field conversion, the data models defined in different languages ​​can be converted into JSON messages for publication; when the subscriber consumes data, the SDK can convert the JSON message into the data model of the corresponding language, without the business developers having to manually serialize and deserialize the data. They only need to focus on their own business logic.

[0104] Embodiment 2

[0105] This embodiment also provides an electronic device, referring to Figure 3 , comprises a memory 404 and a processor 402, wherein the memory 404 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the above embodiments.

[0106] Specifically, the processor 402 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0107] Among them, the memory 404 may include a large capacity memory 404 for data or instructions. By way of example and not limitation, the memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 404 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 404 may be inside or outside the data processing device. In a specific embodiment, the memory 404 is a non-volatile memory. In a specific embodiment, the memory 404 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, PROM for short), an erasable PROM (Erasable Programmable Read-Only Memory, EPROM for short), an electrically erasable PROM (Electrically Erasable Programmable Read-Only Memory, EEPROM for short), an electrically alterable ROM (Electrically Alterable Read-Only Memory, EAROM for short) or a flash memory (FLASH) or a combination of two or more of these. Under appropriate circumstances, the RAM can be a static random access memory (Static Random-Access Memory, abbreviated as SRAM) or a dynamic random access memory (Dynamic Random Access Memory, abbreviated as DRAM), wherein the DRAM can be a fast page mode dynamic random access memory 404 (Fast Page Mode Dynamic Random Access Memory, abbreviated as FPMDRAM), an extended data output dynamic random access memory (Extended Date Out Dynamic Random Access Memory, abbreviated as EDODRAM), a synchronous dynamic random access memory (Synchronous Dynamic Random-Access Memory, abbreviated as SDRAM), etc.

[0108] The memory 404 may be used to store or cache various data files required for processing and / or communication, as well as possible computer program instructions executed by the processor 402 .

[0109] The processor 402 reads and executes the computer program instructions stored in the memory 404 to implement the construction of the non-intrusive field conversion platform for the complex data model in the above embodiment.

[0110] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408 , wherein the transmission device 406 is connected to the processor 402 , and the input / output device 408 is connected to the processor 402 .

[0111] The transmission device 406 can be used to receive or send data via a network. The specific examples of the above-mentioned network may include a wired or wireless network provided by a communication provider of the electronic device. In one example, the transmission device includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 406 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0112] The input / output device 408 is used to input or output information. In this embodiment, the input information may be a source model, a target model, etc., and the output information may be a field conversion result in the target model, etc.

[0113] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0114] In general, various embodiments may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow charts, or using some other graphical representation, it should be understood that, as non-limiting examples, the boxes, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0115] Embodiments of the present invention may be implemented by computer software that is executable by a data processor of a mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets and / or macros may be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer executable components configured to perform an embodiment when the program is run. One or more computer executable components may be at least one software code or a portion thereof. In addition, at this point, it should be noted that, for example, Figure 3 Any block of the logic flow in the program may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or storage blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. Physical media are non-transitory media.

[0116] Those skilled in the art should understand that the technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0117] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A non-intrusive field conversion platform for complex data models, characterized by: include: A determination unit, used for determining a source model including a plurality of source fields and a target model including a plurality of target fields that need to be converted; A configuration unit, configured to configure at least one mapping rule scheme, each mapping rule scheme defining a validity condition of the current mapping rule scheme and at least one field mapping rule in the current mapping rule scheme; An allocation unit determines a mapping rule scheme as an effective rule scheme based on a source model and a target model; The mapping selection unit is used to select the source field to be mapped from the source model, select the target field to be mapped from the target model, and select the field mapping rule between the source field and the target field from the effective rule scheme; The execution unit maps the source field to the target field based on the field mapping rules.

2. A non-intrusive field conversion platform for complex data models according to claim 1, characterized in that: Use each mapping rule scenario including built-in field mapping rules as well as custom field mapping rules.

3. The non-intrusive field conversion platform for complex data models according to claim 1, characterized in that: An effective rule expression is constructed, and a mapping rule scheme is selected as the effective rule scheme based on the effective rule expression and Boolean value judgment.

4. A non-intrusive field conversion platform for complex data models according to claim 3, characterized in that: An effective rule is set for each mapping rule scheme, and each effective rule is judged using the effective rule expression and a Boolean value is returned, and a mapping rule scheme corresponding to an effective rule with a Boolean value of true is selected as the effective rule scheme.

5. A non-intrusive field conversion platform for complex data models according to claim 4, characterized in that: If there are multiple Boolean values ​​corresponding to effective rules that are true, the mapping rule scheme corresponding to the first effective rule judged to be true is selected as the effective rule scheme.

6. The non-intrusive field conversion platform for complex data models according to claim 1, characterized in that: When the source field and the target field are in a flat structure, the field mapping rule between the source field and the corresponding target field is: copy the content of the source field to the corresponding target field.

7. The non-intrusive field conversion platform for complex data models according to claim 1, characterized in that: When the source field and the target field are nested structures, the conversion logic between the source field and the corresponding target field is: determine whether the source field and the corresponding target field are fields of the same level and the same name. If so, directly copy the content of the source field to the corresponding target field. Otherwise, use the Aviator script to perform logical conversion between the source field and the corresponding target field.

8. The non-intrusive field conversion platform for complex data models according to claim 1, characterized in that: When the source field and the target field are nested structures, the conversion logic between the source field and the corresponding target field is: determine whether the source field and the corresponding target field are fields of the same level and the same name. If so, directly copy the content of the source field to the corresponding target field. Otherwise, use the Aviator script to perform logical conversion between the source field and the corresponding target field.

9. The non-intrusive field conversion platform for complex data models according to claim 8, characterized in that: Use jsonpath to traverse the structure tree of the source model and the target model, and copy the field content in the source model to the field with the same name at the same level in the target model.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the complex data model non-intrusive field conversion platform of claim 1.

Images