A configurable heterogeneous system integration method and system based on an adapter pattern

Abstract

The application relates to the technical field of inter-process communication data processing, and discloses a configurable heterogeneous system integration method and system based on an adapter mode, wherein the method comprises the following steps: acquiring heterogeneous system integration request data; initializing an integration task through an adapter registration mechanism; analyzing field mapping rules and establishing a field mapping relationship graph; expanding a directed type conversion graph according to mapping type constraints in combination with a type conversion rule library; reading field values and runtime actual types of to-be-integrated source data; forming a type conversion path set by using a Dijkstra minimum cost path search mechanism with precision attenuation punishment; executing responsibility chain type field value conversion and abnormality back-off processing according to the integration task data, the field mapping relationship graph and the type conversion path set; and outputting a heterogeneous system integration result. The application can make the field mapping, conversion capacity, path selection and adapter writing be connected with each other, and reduce integration interruption caused by type inconsistency or conversion abnormality.

Description

Technical Field

[0001] This invention relates to the field of inter-program communication data processing technology, and in particular to a configurable heterogeneous system integration method and system based on the adapter pattern. Background Technology

[0002] Currently, in the field of heterogeneous system integration, enterprises typically use the adapter pattern to achieve data flow between different systems. The conventional approach involves developers pre-defining field mapping rules based on the data dictionaries of the source and target systems, recording the correspondence between source and target field identifiers, and hard-coding the type conversion logic into the adapter's implementation class. At runtime, the adapter extracts the source field values ​​according to the mapping rules, directly calls the corresponding conversion function to process them, and then writes them to the target system. This processing path relies entirely on pre-written conversion code, lacking dynamic adaptability to unforeseen type differences. If the mapping rules only cover the correspondence between fields without declaring a type conversion strategy, the adapter cannot autonomously choose an appropriate conversion method when the source and target field types are inconsistent, greatly limiting its flexibility and versatility in complex integration scenarios.

[0003] For example, in the integration of a warehouse management system (WMS) and a financial system, the weight field in the WMS is typically stored as a numeric type, while the actual weight field in the target system requires a string type. If the mapping rules only describe the correspondence between fields without including any type conversion strategy, the runtime value will be directly assigned to the string field, triggering a type mismatch runtime exception and causing the data synchronization process to be interrupted. Even if hard-coded conversion logic for converting numeric values ​​to strings is written for this specific pairing, developers still need to modify the adapter code and redeploy it if a new business system needs to be integrated or the target field type changes, increasing the maintenance cost and failure risk of the integrated system. Especially in environments with complex integration relationships and the need to handle a large number of dynamic field mappings, hard-coded conversion methods are prone to data corruption and business process failures due to omissions or inconsistencies.

[0004] Therefore, there is an urgent need for a method that can automatically adapt parameter types based on a configurable type conversion rule library when the parameter types of the source system and the field types of the target system are inconsistent and the mapping rules do not declare a type conversion strategy during the dynamic mapping execution phase. This would enable heterogeneous system integration solutions to reliably complete type conversion without modifying the adapter code, thereby significantly improving the universality, maintainability, and ability to cope with frequent changes in business requirements of heterogeneous system integration. Summary of the Invention

[0005] To address the aforementioned technical shortcomings, the present invention aims to propose a configurable heterogeneous system integration method based on the adapter pattern. This method addresses the technical problem in existing technologies that rely on hard-coded conversion to handle inconsistent types, particularly when the source and target fields are of different types during the dynamic mapping execution phase and the mapping rules do not declare a conversion strategy. This results in the inability to achieve automatic type mapping, leading to call anomalies, reduced flexibility, and decreased versatility.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: The present invention provides a configurable heterogeneous system integration method based on the adapter pattern.

[0007] The configurable heterogeneous system integration method based on the adapter pattern includes: Step S10: Obtain heterogeneous system integration request data, and execute the integration task initialization task based on the heterogeneous system integration request data using the adapter registration mechanism, outputting integration task data including field mapping rules, type conversion rule base and source data to be integrated; Step S20: Based on the field mapping rules in the integrated task data, a field identifier parsing and directed association mechanism is used to perform a mapping relationship graph construction task, and the field mapping relationship graph is output. Step S30: Based on the field mapping relationship graph and the type conversion rule library in the integrated task data, the type conversion rule preprocessing task is executed using the directed graph expansion mechanism of mapping type constraints, and the directed type conversion graph is output. Step S40: Based on the field mapping relationship graph, the directed type conversion graph, and the source data to be integrated in the integration task data, the conversion path planning task is executed using the Dijkstra minimum cost path search mechanism with precision decay penalty, and the type conversion path set is output. Step S50: Perform chain-of-responsibility field value conversion and exception rollback processing based on the integrated task data, the field mapping relationship diagram, and the type conversion path set, and output the heterogeneous system integration result.

[0008] Preferably, step S10, which involves obtaining heterogeneous system integration request data, executing an integration task initialization task using an adapter registration mechanism based on the heterogeneous system integration request data, and outputting integration task data, specifically includes: Step S101: Obtain the field mapping rules configured by the user, and write the field mapping rules into the heterogeneous system integration request data. The field mapping rules include at least one field mapping record. Each field mapping record includes the source system field identifier, the target system field identifier, the source field declaration type, the target field expected type, and an optional forced conversion strategy identifier. Step S102: Obtain atomic type converter management data. For each atomic type converter, record the input data type, output data type, conversion function reference, precision loss, normalized computational complexity, and historical execution success rate within a preset statistical time window. Determine the conversion cost coefficient for each atomic type converter according to the following formula: in, Indicates an atom type converter. Atom type converter The conversion cost coefficient, Atom type converter Precision loss and meet , Atom type converter The normalized computational complexity is 0 to 1. Atom type converter The historical execution success rate within the preset statistical time window, with a value ranging from 0 to 1. , and These represent the precision loss weight, computational complexity weight, and execution failure weight, respectively. , and All are non-negative and satisfy The type conversion rule base is generated based on the input data type, output data type, conversion function reference, precision loss, and conversion cost coefficient of each atomic type converter, and the type conversion rule base is written into the heterogeneous system integration request data. Step S103: Obtain the source data to be integrated, the target system identifier, and the preset default type conversion strategy; write the source data to be integrated, the target system identifier, and the preset default type conversion strategy into the heterogeneous system integration request data; select a target adapter instance from the pre-established adapter registry according to the target system identifier, and encapsulate the heterogeneous system integration request data and the target adapter instance into the integration task data.

[0009] Preferably, step S20, which involves constructing a mapping graph based on the field mapping rules in the integrated task data and using a field identifier parsing and directed association mechanism, and outputting the field mapping graph, specifically includes: Step S201: Split the field mapping rule into at least one field mapping record, create a field mapping data object for each field mapping record, and write the source system field identifier, target system field identifier, source field declaration type, target field expected type, and forced conversion strategy identifier from the corresponding field mapping record into the field mapping data object; Step S202: Detect the type conversion strategy identifier in each field mapping data object. If the type conversion strategy identifier is empty, mark the corresponding field mapping data object as automatic path search mode; if the type conversion strategy identifier is not empty, mark the corresponding field mapping data object as type conversion strategy mode. Step S203: Set the source system field identifier and target system field identifier in each field mapping data object as the source field node and target field node respectively, establish a mapping edge between the source field node and the target field node, and use the corresponding field mapping data object as the edge attribute of the mapping edge to obtain the field mapping relationship graph.

[0010] Preferably, step S202, when the type casting strategy identifier is not empty, includes the step of marking the corresponding field mapping data object as a type casting strategy pattern, which includes: Based on the forced conversion strategy identifier, query the atomic type converter corresponding to the forced conversion strategy identifier in the type conversion rule base of the integrated task data; If a corresponding atomic type converter is found, the converter identifier of the found atomic type converter is written into the corresponding field mapping data object, and the corresponding field mapping data object is marked as a forced conversion strategy mode; If no corresponding atomic type converter is found, a forced conversion strategy configuration exception record is generated, and the corresponding field mapping data object is marked as a configuration exception state to prevent step S40 from performing a conversion path search for the field mapping data object in the configuration exception state.

[0011] Preferably, step S30, which involves performing a type conversion rule preprocessing task based on the field mapping relationship graph and the type conversion rule base in the integrated task data, using a directed graph expansion mechanism with mapping type constraints, and outputting a directed type conversion graph, specifically includes: Step S301: Parse the field mapping relationship graph, obtain the source field declaration type and target field expected type associated with each mapping edge in the field mapping relationship graph, and obtain the input data type and output data type corresponding to each atomic type converter from the type conversion rule base; perform deduplication processing on the obtained data types, set the deduplicated data types as type nodes respectively, and obtain the initial type conversion graph; Step S302: Traverse each atomic type converter in the type conversion rule base, add a directed edge between the type node corresponding to the corresponding input data type and the type node corresponding to the corresponding output data type, and write the converter identifier, conversion function reference, precision loss degree and conversion cost coefficient of the corresponding atomic type converter into the edge attribute of the directed edge; Step S303: If there is a composite type converter formed by combining at least two atomic type converters in the type conversion rule base, extract the atomic type converter sequence contained in the composite type converter; according to the connection relationship between the output data type of the previous atomic type converter and the input data type of the next atomic type converter in the atomic type converter sequence, supplement the intermediate type node and directed edge in the initial type conversion graph to obtain the directed type conversion graph.

[0012] Preferably, step S40, which involves performing a transformation path planning task based on the field mapping graph, the directed type conversion graph, and the source data to be integrated in the integration task data, using a Dijkstra minimum cost path search mechanism with precision decay penalty, and outputting a set of type conversion paths, specifically includes: Step S401: Parse the field mapping relationship diagram to obtain the source system field identifier and target field expected type corresponding to each field mapping record; read the source field value from the source data to be integrated according to the source system field identifier, obtain the runtime actual type of the source field value, and determine the type node corresponding to the runtime actual type as the starting type node and the type node corresponding to the target field expected type as the ending type node; Step S402: For the candidate transformation path from the starting type node to the ending type node, calculate the total path cost according to the following formula: in, Indicates candidate conversion paths, Indicates candidate transformation paths The total path cost, Indicates candidate transformation paths Number of atomic type converters included, Indicates candidate transformation paths The first in Atom type converter, This indicates the atom type converter determined according to step S102. The conversion cost coefficient, This indicates the atom type converter recorded in step S102. The degree of accuracy loss, This represents the non-negative path hop penalty coefficient. This represents the non-negative cumulative precision attenuation penalty coefficient. Represent the natural logarithm function; Step S403: For field mapping records where the forced conversion strategy identifier is empty, using the total path cost as the path search cost, a Dijkstra search is used to obtain the candidate conversion path with the minimum total path cost from the starting type node to the ending type node; for field mapping records where the forced conversion strategy identifier is not empty and a corresponding atomic type converter exists, a fixed conversion path is generated according to the atomic type converter corresponding to the forced conversion strategy identifier; the candidate conversion paths and the fixed conversion paths are aggregated into the type conversion path set.

[0013] Preferably, step S50, which involves performing chain-of-responsibility field value conversion and exception rollback processing based on the integration task data, the field mapping relationship diagram, and the type conversion path set, and outputting the heterogeneous system integration result, specifically includes: Step S501: Traverse each mapping relationship in the field mapping relationship graph, read the source system field identifier, target system field identifier, and target field expected type corresponding to the corresponding mapping relationship, obtain the source field value according to the source system field identifier, and select the type conversion path corresponding to the corresponding mapping relationship from the type conversion path set; call the corresponding conversion function in sequence according to the arrangement order of each atomic type converter in the type conversion path, and use the intermediate field value output by the previous atomic type converter as the input of the next atomic type converter to obtain the target field value; Step S502: If no type conversion path corresponding to the corresponding mapping relationship exists in the set of type conversion paths, or if any atomic type converter returns a conversion failure status or throws a conversion exception, perform exception rollback processing according to the preset default type conversion strategy; if the expected type of the target field has a string parsing function, call the string serialization function corresponding to the runtime actual type of the source field value to convert the source field value into a rollback string, and call the string parsing function corresponding to the expected type of the target field to convert the rollback string into a rollback target field value; if the expected type of the target field does not have a string parsing function, read the preset target field default value corresponding to the expected type of the target field from the preset default type conversion strategy, and determine the preset target field default value as the rollback target field value; Step S503: Based on the target system field identifier, write the target field value or the fallback target field value to the target field write position corresponding to the target adapter instance; in the event of a conversion exception, record the source system field identifier, the target system field identifier, the runtime actual type of the source field value, the expected type of the target field, the exception type, and the converter identifier of the atomic type converter that caused the exception; encapsulate the target system data with completed field writing and the corresponding conversion exception record into the heterogeneous system integration result.

[0014] The present invention also provides a configurable heterogeneous system integration system based on the adapter pattern, comprising: The integration task initialization module is used to obtain heterogeneous system integration request data, and execute the integration task initialization task based on the heterogeneous system integration request data using an adapter registration mechanism, and output integration task data including field mapping rules, type conversion rule base and source data to be integrated; The mapping graph construction module is used to perform the mapping graph construction task based on the field mapping rules in the integrated task data, using field identifier parsing and directed association mechanism, and output the field mapping graph. The type conversion graph preprocessing module is used to perform type conversion rule preprocessing tasks based on the field mapping relationship graph and the type conversion rule library in the integrated task data, using a directed graph expansion mechanism with mapping type constraints, and output a directed type conversion graph. The transformation path planning module is used to perform the transformation path planning task based on the field mapping relationship graph, the directed type transformation graph, and the source data to be integrated in the integration task data, using a Dijkstra minimum cost path search mechanism with precision decay penalty, and output a set of type transformation paths; The conversion execution module is used to perform chain-of-responsibility field value conversion and exception rollback processing based on the integrated task data, the field mapping relationship diagram and the type conversion path set, and output the heterogeneous system integration result.

[0015] The present invention also provides a configurable heterogeneous system integration device based on the adapter pattern, the configurable heterogeneous system integration device based on the adapter pattern includes: a memory, a processor, and a configurable heterogeneous system integration program based on the adapter pattern stored on the memory and executable on the processor, the configurable heterogeneous system integration program based on the adapter pattern being executed by the processor to implement the above method.

[0016] The present invention also provides a computer program product, the computer program product including a configurable heterogeneous system integration program based on the adapter pattern, the configurable heterogeneous system integration program based on the adapter pattern implementing the above method when executed by a processor.

[0017] The beneficial effects of this invention are as follows: This invention decouples type conversion logic from adapter code by abstracting both field mapping rules and atomic type converter libraries into configurable integrated configuration information. During integration execution, the system automatically searches the directed type conversion graph for the lowest-cost conversion path based on the actual runtime type of the source field and the expected type of the target field, thus avoiding type mapping failures due to the lack of pre-declared conversion strategies. The conversion cost comprehensively considers factors such as precision loss, computational complexity, and historical success rate, ensuring that the optimal path found better meets actual data quality requirements.

[0018] This invention utilizes Dijkstra's shortest path algorithm to calculate the type conversion sequence with minimum cost and employs a chain-of-responsibility conversion mechanism to sequentially call atomic converters along the path, ensuring the atomicity and traceability of the conversion process. Furthermore, in the event of a failed search or an abnormal conversion execution, a fallback strategy based on string representation ensures that the integration process will not be completely interrupted due to a single field conversion failure, thus improving the overall robustness and operational efficiency of heterogeneous system integration. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the first embodiment of a configurable heterogeneous system integration method based on the adapter pattern of the present invention. Detailed Implementation

[0020] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0021] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] Example 1: As Figure 1 The diagram shown is a flowchart of a first embodiment of a configurable heterogeneous system integration method based on the adapter pattern of the present invention, which presents a first embodiment of a configurable heterogeneous system integration method based on the adapter pattern of the present invention.

[0023] In the first embodiment, the configurable heterogeneous system integration method based on the adapter pattern includes: Step S10: Obtain heterogeneous system integration request data, and execute the integration task initialization task based on the heterogeneous system integration request data using the adapter registration mechanism, outputting integration task data including field mapping rules, type conversion rule base and source data to be integrated; Heterogeneous system integration request data is a complete request object carried by a data integration task when entering the processing flow. Its content is not only the business data to be transmitted, but also includes field mapping rules, atomic type converter management data, source data to be integrated, target system identifier, and preset default type conversion strategy. Field mapping rules answer which field in the source data should be written to which field in the target system; the type conversion rule library describes existing conversion capabilities; the source data to be integrated provides the field values ​​actually processed in this instance; the target system identifier locates the adapter instance responsible for communication and writing to the target system; and the preset default type conversion strategy provides a unified fallback basis for fields that cannot obtain normal conversion results later. These contents are placed within the same request scope, ensuring that subsequent steps process the same batch of mappings, the same source data, and the same target system, avoiding misalignment between configuration versions and business data batches.

[0024] A field mapping rule consists of at least one field mapping record. Each record stores the source system field identifier, target system field identifier, source field declaration type, target field expected type, and an optional type casting strategy identifier. The field identifier establishes a traceable correspondence between the source data structure and the write location of the target adapter; the declaration type describes the expected source field type during the configuration phase, and the expected type describes the types the target system is allowed to accept; when the type casting strategy identifier is empty, it indicates that the system is allowed to automatically plan the conversion path based on the actual type at runtime; when it is not empty, it indicates that the mapping should preferentially use the specified atomic type converter. The type casting strategy is not a piece of temporary execution code, but rather an identifier pointing to a converter registered in the type conversion rule base. Therefore, the same converter can be reused in different field mappings, and it is also convenient to confirm its actual existence during configuration checks.

[0025] Atomic type converter management data is used to form a searchable and evaluable type conversion rule base. For each atomic type converter, the input data type, output data type, conversion function reference, precision loss, normalized computational complexity, and historical execution success rate within a preset statistical time window are recorded. The conversion function reference provides the actual call entry point, the precision loss reflects the information retention before and after conversion, the normalized computational complexity reflects the relative processing overhead, and the historical execution success rate comes from the number of successful executions and the total number of executions of the converter within the statistical time window. The conversion cost coefficient is determined using a textual weighting rule: first, the precision loss weight, the computational complexity weight, and the execution failure weight are weighted separately for precision loss, normalized computational complexity, and the execution failure ratio obtained by subtracting the historical execution success rate from one; then, the three results are added together. All three weights are non-negative and sum to one, so the resulting cost can be compared between different converters on a uniform scale.

[0026] The type conversion rule base does not merely store converter names; instead, it organizes the input type, output type, function reference, precision loss, and conversion cost coefficient of each atomic type converter into rule records that can be directly read by the graph construction steps. When the same input type can yield the same output type through multiple converters, each converter retains its edge attributes, allowing subsequent path planning to compare quality and cost, rather than arbitrarily overwriting during the registration phase. Historical execution success rates are statistically analyzed according to the same preset statistical time window, preventing long-term accumulated data from obscuring recent converter states. When there are no execution records within the statistical time window, the registered initial success rate can be adopted according to preset management rules, ensuring that the conversion cost coefficient always has a usable value during task initialization. This initial value is part of the converter management data and does not change the cost composition defined in the claims.

[0027] The adapter registration mechanism uses the target system identifier as the retrieval key to select a target adapter instance from a pre-established adapter registry. The adapter instance is used to mask the differences between different target systems in terms of interface address, field writing method, and calling protocol. This step only identifies the instance corresponding to the target system in this case; field conversion is not performed at this time. Subsequently, the request object containing field mapping rules, type conversion rule base, source data to be integrated, and default conversion strategy, along with the target adapter instance, is encapsulated into integration task data. This integrated task data retains the rules and runtime data required for path planning and also carries the adapter object required for final writing, enabling steps S20 to S50 to pass processing results along the same task context.

[0028] By binding mapping configurations, converter capabilities, source data batches, and target adapters uniformly during the initialization phase, information previously scattered across configuration files, business code, and API call layers can be converged into a single, well-defined task object. Subsequent graph construction eliminates the need to query field relationships from the configuration center again, and conversions no longer require temporary determination of which target system to connect to, thus reducing the likelihood of reading different versions of data due to hot configuration updates, concurrent tasks, or adapter switching. Traditional integration methods often write field mappings and type conversions into the conditional branches of each adapter. When adding a new target system or adjusting a field type, the relevant code needs to be modified and redeployed. This step transforms the changed parts into rules and registration information, allowing the adapter to still handle system boundary communication, while field relationships and conversion capabilities can be uniformly interpreted within the task data.

[0029] In a scenario where a warehouse management system synchronizes outbound records with a financial system, a single request can include a mapping record from the source field `weightKg` to the target field `actualWeight`. The source field is declared as a decimal number, the target field is expected to be a string, and the type conversion strategy identifier is empty. In the source data to be integrated, the current value of `weightKg` is 75.50, and the target system identifier points to the financial system. The type converter management data registers atomic converters such as decimal to string, decimal to integer, and integer to string, and records their respective loss rates, complexity, and success rates over the past 24 hours. During initialization, the system forms a type conversion rule base based on this, selects the financial system adapter from the registry, and then encapsulates the above rules, data, default strategy, and adapter instance into the same integration task data. Subsequent steps processing `weightKg` therefore use mapping records, running values, and write endpoints all from this task, preventing the misuse of adapters from other batches of outbound data or other target systems.

[0030] Step S20: Based on the field mapping rules in the integrated task data, a field identifier parsing and directed association mechanism is used to perform a mapping relationship graph construction task, and the field mapping relationship graph is output. Field identifier resolution and directed association are processes that convert configured field mapping rules into a traversable graph structure. The system first splits the rule set according to the boundaries of the field mapping records, creates an independent field mapping data object for each record, and writes the source system field identifier, target system field identifier, source field declared type, target field expected type, and type conversion strategy identifier item by item. The field mapping data object retains all the context required for a mapping, preventing subsequent steps from guessing the type or conversion method solely based on field names. When the same source field is mapped to multiple target fields, multiple independent objects are also formed, allowing the expected type and strategy of each target field to be processed separately.

[0031] The detection of the forced conversion strategy identifier is used to determine how the path for each field mapping is obtained. Field mapping data objects with an empty identifier are marked as automatic path search mode, indicating that step S40 needs to search for candidate paths starting from the actual runtime type; objects with a non-empty identifier enter the forced conversion strategy verification. The system queries the atomic type converter in the type conversion rule base of the current integrated task data based on the identifier. When found, the converter identifier is written back to the field mapping data object and marked as forced conversion strategy mode. What is written back is the converter identifier confirmed by the rule base, not unverified user input, which allows the same converter to be directly located when generating fixed conversion paths later.

[0032] When the forced conversion strategy identifier cannot find a corresponding atomic type converter in the type conversion rule base, the system generates a forced conversion strategy configuration exception record and marks the data object mapped to that field as having a configuration exception status. The purpose of the configuration exception status is to distinguish configuration errors from normal automatic pathfinding failures and to prevent step S40 from performing a conversion path search for that object. If this status is ignored and other paths are automatically searched, the actual execution result will deviate from the user-specified strategy; if the entire batch of tasks is directly aborted, other valid fields will be unable to be processed. By retaining the exception object and exception record during the mapping resolution phase, a rollback value can be obtained along the predetermined rollback logic when processing the corresponding field in step S50, while continuing to process other valid mappings in the graph.

[0033] When constructing the field mapping graph, the source system field identifier and target system field identifier in each field mapping data object are set as the source field node and target field node, respectively, and a mapping edge is established between them, pointing from the source field to the target field. The field mapping data object is stored as an edge attribute along with the mapping edge. Therefore, an edge in the graph simultaneously expresses the field data flow direction, the type requirements at both ends, the processing mode, and the verified converter identifier or configuration exception status. Field nodes only serve to locate the fields, while edge attributes are responsible for recording the specific constraints of this mapping, avoiding mistaking fields with the same name but belonging to different systems for the same conversion task.

[0034] The field mapping graph provides a direct index for the subsequent two types of processing. Step S30 extracts the source field declaration type and the target field expected type from the mapping edge attributes, ensuring that the directed type conversion graph contains at least the type nodes involved in the current mapping requirement. Step S40 reads the source field identifier item by item along the mapping edge, and then obtains the actual value and runtime actual type from the source data to be integrated. Automatic mode, forced mode, and configuration exception states are all attached to the corresponding edges, so path planning does not need to reinterpret the original configuration, nor does it apply the forced strategy of a field to adjacent mappings. The graph structure thus serves as a stable intermediate layer between configuration parsing and type path planning.

[0035] Common key-value mapping tables can only express a static correspondence between source and target field names. Type requirements, conversion modes, and configuration exceptions are usually hidden in the execution code. As the number of fields increases, runtime exceptions become difficult to trace back to specific mapping records, and fields with the same name appearing in different systems can cause ambiguity. This step sets the field identifier as a directed node and the complete mapping object as an edge attribute, allowing runtime processing to revolve around a defined mapping edge. This organization method does not simply change the data storage format; rather, it pre-defines the object boundaries and exception boundaries of path planning, reducing the need for repeated configuration scanning, repeated validation strategies, and the reuse of conversion results across edges in step S40.

[0036] Following the synchronization task between the warehousing and financial systems, the record from weightKg to actualWeight will generate an automatic path search pattern object, forming a mapping edge between the two field nodes. For the other mapping from sourceStatus to voucherStatus, if a converter statusCodeToText is specified, the system will first verify the existence of the converter in the rule base, then write its converter identifier into the edge attribute and mark it as a forced conversion strategy mode. If the third mapping specifies the disabled oldDateParser, the rule base query result will be empty, and this mapping will leave a configuration error record and be marked as a configuration error state. After the graph is completed, the three fields are still in the same field mapping relationship graph, but subsequently enter the automatic pathfinding, fixed path, and prohibited search processing branches respectively. Other valid fields will not lose their processing basis due to the third configuration error.

[0037] Step S30: Based on the field mapping relationship graph and the type conversion rule library in the integrated task data, the type conversion rule preprocessing task is executed using the directed graph expansion mechanism of mapping type constraints, and the directed type conversion graph is output. The directed graph expansion of mapping type constraints organizes the field types actually involved in the current integration task and the conversion types that the rule base can handle into a unified type space. The system parses the field mapping relationship graph to obtain the source field declaration type and target field expected type associated with each mapping edge. At the same time, it obtains the input data type and output data type of each atomic type converter from the type conversion rule base. After deduplicating these type names according to the same type identification rule, only one type node is created for each data type, forming the initial type conversion graph. Deduplication avoids creating ten string nodes when ten mappings all involve string types, and also ensures that the same type from the mapping configuration and converter record falls on the same search node.

[0038] The set of nodes in the initial type conversion graph is not equal to the feasible conversion relationships; the conversion capability is given by directed edges. The system traverses the type conversion rule base, adds directional edges between the input data type nodes and output data type nodes of the atomic type converters, and writes the converter identifier, conversion function reference, precision loss, and conversion cost coefficient into the edge attributes. Directionality reflects that type conversions are usually irreversible; for example, parsing a string to a date and formatting a date to a string should be registered separately. Even if the input and output types of two converters are the same, they can be retained as different edges connecting the same pair of nodes, allowing step S40 to compare and select a specific conversion function based on their respective costs.

[0039] A composite type converter is a conversion capability formed by sequentially combining at least two atomic type converters. The system extracts the sequence of atomic type converters, checks whether the output data type of the previous converter can connect to the input data type of the next converter, and then supplements intermediate type nodes and directed edges according to this sequence. The composite converter itself is not compressed into an uninterpretable edge; each segment in the path still corresponds to an independently callable atomic converter that can record loss and cost. Therefore, after the composite relationship is expanded, it can participate in the unified minimum cost search and also locate the actual failed converter when an anomaly occurs in step S50.

[0040] The so-called mapping type constraint is reflected in the fact that the source of type nodes is limited by both field mapping requirements and transformation rule capabilities. The source field declaration type and the target field expected type ensure that the start and end types of the current task will not disappear from the graph due to the temporary lack of direct-connection converters in the rule base. The input and output types of the converters supplement the intermediate types required to implement multi-hop transformations. If a target type has formed a node but has no reachable incoming edges, the graph structure will truthfully retain its unreachable state for step S40 to determine that there are no candidate paths. The system will not arbitrarily create transformation relationships to make the graph appear connected, thus ensuring that each edge actually called subsequently has a function reference in the rule base as the basis for execution.

[0041] The output directed type conversion graph centralizes the topological relationships, single-step conversion entry points, single-step accuracy loss, and single-step cost required for path searching within a single data structure. Step S40 only needs to determine the starting and ending type nodes around the specific mapping to compare direct paths and multi-hop paths in the graph; step S50 can then construct a chain of responsibility based on the function references on the edges of the selected path. Type rule preprocessing is thus performed only once. When multiple fields have the same runtime type and target type, they can be searched separately on the same graph, eliminating the need to map a temporary converter list for each field.

[0042] Traditional implementations typically check converters in registration order, using them immediately if the input / output types match. This fails to identify feasible solutions with intermediate types and makes it difficult to compare the accuracy and overhead of multiple converters of the same type. Treating the composite converter as a black box means that any failure at any internal step can only be attributed to a composite conversion failure, lacking specific location information in maintenance logs. This step expands the converter into directed edges with attributes, expanding the searchable paths while preserving the identity and quality information of each atomic processing step. This provides directly usable data for subsequent path selection based on runtime type, cumulative accuracy decay, and logging of abnormal converters.

[0043] In the aforementioned task, the mapping edges involve types such as decimal numbers, strings, status codes, and dates. The rule base also registers converters for decimal to integer, integer to string, date to timestamp, and timestamp to string conversions. After deduplication, each type forms only one node. A direct converter for decimal to string conversion forms a single edge, while decimal to integer and integer to string conversions form two-hop paths through integer nodes. The composite converter for date via timestamp to string conversion is expanded into two edges: date to timestamp and timestamp to string. When the rule base contains two decimal to string converters, each edge retains its own function reference and cost, allowing the subsequent algorithm to select one without losing one conversion scheme due to identical nodes.

[0044] Step S40: Based on the field mapping relationship graph, the directed type conversion graph, and the source data to be integrated in the integration task data, the conversion path planning task is executed using the Dijkstra minimum cost path search mechanism with precision decay penalty, and the type conversion path set is output. The conversion path planning is performed separately for each valid mapping in the field mapping graph. The system first reads the source system field identifier and the target field's expected type corresponding to the mapping edge. Then, based on the source system field identifier, it retrieves the current source field value from the source data to be integrated. The node corresponding to the actual runtime type of this value is used as the starting type node, and the node corresponding to the target field's expected type is used as the ending type node. The actual runtime type may differ from the declared source field type in the configuration. For example, a field declared as a general numeric type may actually carry a decimal number object in this batch of data. Using the actual type as the search starting point avoids the first converter selected based on the declared type failing due to input type mismatch during actual invocation.

[0045] The total cost of the candidate conversion path is accumulated in three parts sequentially. The first part is the sum of the conversion cost coefficients of each atomic type converter in the path, reflecting the single-step accuracy loss, computational complexity, and recent failures. The second part is the number of atomic converters in the path multiplied by a non-negative path hop count penalty coefficient, used to suppress excessively long links when other conditions are similar. The third part, for each converter in the path, first subtracts the accuracy loss of that converter from one to obtain the accuracy retention ratio, then takes the negative of the natural logarithm of that retention ratio, adds the results of each step, and multiplies them by a non-negative cumulative accuracy decay penalty coefficient. Since each accuracy loss is less than one, the accuracy retention ratio is always positive, which satisfies the natural logarithm calculation condition.

[0046] Accuracy attenuation is accumulated using the natural logarithm, transforming the accuracy retention relationship of multiple transformations into additive penalties. When the accuracy loss at a certain step is close to zero, its contribution is small; when the loss at a certain step increases and the retention ratio approaches zero, the corresponding penalty increases rapidly, making it more difficult for paths containing high-loss converters to gain an advantage solely through lower computational complexity. Path hop count penalties and accuracy attenuation penalties constrain link length and information loss respectively, avoiding conflating them with the same weight. All three cost sources can be obtained from the converter records and preset coefficients formed in step S10, ensuring that path comparison does not rely on untraceable manual scoring.

[0047] For field mappings with an empty forced conversion strategy identifier, the system performs Dijkstra processing using the total path cost as the search cost. The search starts from the initial type node, progressively identifying unprocessed nodes with smaller cumulative costs, updating the candidate costs and predecessor edges of adjacent nodes along their outgoing edges, until the terminating type node is determined or all reachable nodes are processed. If the terminating type node is reached, the converter order is obtained by backtracking along the predecessor edges; if the terminating node is unreachable, the mapping does not generate a normal type conversion path, and subsequent steps in S50 perform an abnormal rollback according to the default type conversion strategy. The search results correspond to the field mapping records to avoid result mismatches when different fields have the same type pair.

[0048] For field mappings where the forced conversion strategy identifier is not empty and a corresponding atomic type converter has been found, the system does not perform automatic search but generates a fixed conversion path according to the confirmed converter. Mappings in a configuration error state have already been prevented from entering path search in step S20 and will not be replaced by automatic paths. Finally, the candidate conversion paths obtained by each automatic mapping and the fixed conversion paths obtained by each forced mapping are aggregated into a type conversion path set, and the correspondence between paths and mapping edges is preserved. This set may contain multi-step converter sequences or a single forced converter; mappings for which no path has been obtained are still preserved by the field mapping relationship graph so that step S50 can identify and backtrack.

[0049] Path planning transforms type conversion from "finding a callable function" to "determining an executable chain under the constraints of the current runtime value type, target type, and converter quality." Traditional first-match strategies are easily affected by the converter registration order; adding a new converter may even change the processing results of existing fields. Fixed selection based on the source field's declared type cannot handle runtime value type drift. This step determines the starting point based on the actual runtime type, while simultaneously considering single-step cost, link length, and cumulative accuracy decay, allowing the rationale for the selected path to be traced back to graph edge attributes and the calculation process. The mandatory strategy is still strictly retained; therefore, automatic selection will not cover explicit conversion requirements set by business users for specific fields.

[0050] When the running value of weightKg is the decimal number 75.50 and the target type is string, the graph can show a one-step path that directly converts the decimal number to a string, and a two-step path that first converts to an integer and then to a string. The direct path has lower conversion cost and fewer jumps, and retains the decimal part; the two-step path not only adds one conversion, but its decimal-to-integer conversion step also has a higher precision loss, and the total cost further increases after the cumulative penalty in the form of natural logarithm. Dijkstra therefore selects the direct path and writes it to the corresponding position in the weightKg mapping. For the sourceStatus field, if statusCodeToText has been specified and the converter exists, the fixed path constructed by the converter is directly stored in the type conversion path set; date fields marked as configuration exceptions do not have a normal path and are left for rollback processing in the next step.

[0051] Step S50: Perform chain-of-responsibility field value conversion and exception rollback processing based on the integrated task data, the field mapping relationship diagram, and the type conversion path set, and output the heterogeneous system integration result.

[0052] The chain-of-responsibility field value transformation uses the field mapping relationship graph as its traversal scope, rather than only traversing existing paths. For each mapping relationship, the system reads the source system field identifier, the target system field identifier, and the expected type of the target field. It then obtains the source field value based on the source system field identifier and selects the path corresponding to that mapping relationship from the set of type transformation paths. This approach can handle fields with successfully planned paths and also identify fields that do not have a corresponding path due to type unreachability or abnormal forced policy configuration. The mapping relationship serves as a common index for path selection and result writing, preventing the exchange of transformation results between fields of the same type.

[0053] The normal path forms a chain of responsibility according to the order of the atomic type converters. The first conversion function receives the source field value, and its output is passed as an intermediate field value to the next conversion function, until the last converter outputs a target field value that conforms to the expected type of the target field. Each call uses the conversion function reference stored in the edge attributes of the directed type conversion graph and checks the type connection between the previous output and the next input; the single-step path is called only once. Since step S30 has expanded the composite converter into an atomic sequence, the specific call order can be determined during execution, and the subsequent chain of calls for the current field can be stopped if any converter returns a failure status or throws an exception.

[0054] If a corresponding path does not exist in the type conversion path set, or if any atomic type converter in the chain returns a failure status or throws a conversion exception, the system processes the current field according to the preset default type conversion strategy in the integrated task data. If the target field's expected type has a string parsing function, the system first calls the string serialization function corresponding to the actual runtime type of the source field value to obtain a fallback string that can express the source value. Then, the system calls the string parsing function corresponding to the target type to convert the fallback string into the fallback target field value. This order cannot omit target type parsing: the fallback string is only an intermediate representation for cross-type conversion; only the value formed after successful parsing meets the type requirements of the target field.

[0055] If the expected type of the target field does not have a string parsing function, or if the default strategy configures the type to use a default value, the default value of the target field corresponding to the target type is read from the default type conversion strategy and determined as the fallback target field value. Default values ​​are configured according to the target type, allowing different target fields such as numeric, date, and custom objects to receive fallback content acceptable to their type, instead of always writing a string. The fallback process only replaces the currently occurring field value and does not change the normal target field values ​​already obtained by other mappings; therefore, a single field type problem will not automatically escalate into a conversion interruption for the entire batch of target data.

[0056] After obtaining the normal or rollback target field value, the system locates the corresponding write position in the target adapter instance based on the target system field identifier, and the adapter completes the target field writing. When a conversion exception occurs, the system simultaneously records the source system field identifier, target system field identifier, actual runtime type of the source value, expected type of the target field, exception type, and the identifier of the atomic type converter where the exception occurred. If the exception originates from a non-existent path or an invalid enforcement strategy, the exception record still retains the corresponding mapping identifier and known type information. After completing all mapping processing, the target system data and the conversion exception record are encapsulated together as a heterogeneous system integration result, ensuring that the business result and exception clues belong to the same task output.

[0057] This execution approach translates path planning results into a progressively invoked chain of responsibility, while incorporating exception rollback into the same field processing flow. Traditional adapters often throw exceptions and terminate the entire batch of writes when encountering type mismatches, or simply call the object string representation and write the string into any target field. The former amplifies the impact of a single-field failure, while the latter may continue to create inconsistencies in target types. This step first attempts to restore the required value using the target type resolution function. If resolution fails, it then uses the corresponding type's preset default value and retains the converter-level exception information. Therefore, the target data still adheres to the expected field type, and exceptions can be located to specific mappings and converters, providing factual basis for subsequent adjustments to the rule base or enforcement strategies.

[0058] When warehouse records are written to the financial system, the `weightKg` field converts the decimal number 75.50 to the string "75.50" using a direct conversion path, and the financial adapter writes it to `actualWeight`. If the source value of another field, `deliveryDate`, is actually a custom date object, and there is no path to the target date type in the diagram, the system first calls the string serialization function corresponding to that object to obtain "2026-08-04", then calls the string parsing function of the target date type to form the date value and writes it to the target field. If `remarkTarget` is a custom target type without a string parsing function, the default object registered for that type in the default strategy is used. Meanwhile, the exception record in the result stores the source field identifier, target field identifier, runtime type, expected type, and exception type for `deliveryDate` where no path is available. Other fields continue to be written along their respective responsibility chains, ultimately outputting a heterogeneous system integration result containing the written financial data and the exception record.

[0059] Example 2: Furthermore, the present invention provides a configurable heterogeneous system integration system based on the adapter pattern, employing a configurable heterogeneous system integration method based on the adapter pattern described in the above embodiments, which can solve the technical problem of configurable heterogeneous system integration based on the adapter pattern. The beneficial effects of the configurable heterogeneous system integration system based on the adapter pattern provided by the present invention are the same as those of the configurable heterogeneous system integration method based on the adapter pattern described in the above embodiments, and other technical features of the configurable heterogeneous system integration system based on the adapter pattern are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0060] Example 3: This invention provides a configurable heterogeneous system integration device based on an adapter pattern. The device includes at least one processor and a memory communicatively connected to the processor. The memory stores instructions executable by the processor, which are then executed to enable the processor to perform the adapter-pattern-based configurable heterogeneous system integration method described in Example 1. The adapter-pattern-based configurable heterogeneous system integration device in this invention can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. This adapter-pattern-based configurable heterogeneous system integration device is merely an example and should not limit the functionality or scope of the invention. A configurable heterogeneous system integration device based on an adapter pattern may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory or a program loaded from a storage device into random access memory. The random access memory also stores various programs and data required for the operation of the adapter-based configurable heterogeneous system integration device. The processing unit, read-only memory, and random access memory are interconnected via a bus. I / O interfaces are also connected to the bus. Typically, the following systems can be connected to the I / O interface: input devices including touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices including liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices including magnetic tapes, hard disks, etc.; and communication devices. The communication device allows the adapter-based configurable heterogeneous system integration device to communicate wirelessly or wiredly with other devices to exchange data. While an adapter-based configurable heterogeneous system integration device with various systems has been described, it should be understood that implementation or possession of all described systems is not required. It can be implemented alternatively or with more or fewer systems.

[0061] Example 4: This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described adapter-pattern-based configurable heterogeneous system integration method. The computer program product provided by this invention can solve a technical problem related to adapter-pattern-based configurable heterogeneous system integration. Compared with the prior art, the beneficial effects of the computer program product provided by this invention are the same as those of the adapter-pattern-based configurable heterogeneous system integration method provided in the above embodiments, and will not be repeated here.

[0062] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a read-only memory. When the computer program is executed by a processing device, it performs the functions defined in the methods of the embodiments disclosed in this invention.

[0063] It should be understood that the various parts disclosed in this invention can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0064] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the present invention and its equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A method for integrating configurable heterogeneous systems based on the adapter pattern, characterized in that, The method includes: Step S10: Obtain heterogeneous system integration request data, and execute the integration task initialization task based on the heterogeneous system integration request data using the adapter registration mechanism, outputting integration task data including field mapping rules, type conversion rule base and source data to be integrated; Step S20: Based on the field mapping rules in the integrated task data, a field identifier parsing and directed association mechanism is used to perform a mapping relationship graph construction task, and the field mapping relationship graph is output. Step S30: Based on the field mapping relationship graph and the type conversion rule library in the integrated task data, the type conversion rule preprocessing task is executed using the directed graph expansion mechanism of mapping type constraints, and the directed type conversion graph is output. Step S40: Based on the field mapping relationship graph, the directed type conversion graph, and the source data to be integrated in the integration task data, the conversion path planning task is executed using the Dijkstra minimum cost path search mechanism with precision decay penalty, and the type conversion path set is output. Step S50: Perform chain-of-responsibility field value conversion and exception rollback processing based on the integrated task data, the field mapping relationship diagram, and the type conversion path set, and output the heterogeneous system integration result.

2. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 1, characterized in that, Step S10, which involves obtaining heterogeneous system integration request data, executing an integration task initialization task using an adapter registration mechanism based on the heterogeneous system integration request data, and outputting integration task data, specifically includes: Step S101: Obtain the field mapping rules configured by the user, and write the field mapping rules into the heterogeneous system integration request data. The field mapping rules include at least one field mapping record. Each field mapping record includes the source system field identifier, the target system field identifier, the source field declaration type, the target field expected type, and an optional forced conversion strategy identifier. Step S102: Obtain atomic type converter management data. For each atomic type converter, record the input data type, output data type, conversion function reference, precision loss, normalized computational complexity, and historical execution success rate within a preset statistical time window. Determine the conversion cost coefficient for each atomic type converter according to the following formula: in, Indicates an atom type converter. Atom type converter The conversion cost coefficient, Atom type converter Precision loss and meet , Atom type converter The normalized computational complexity is 0 to 1. Atom type converter The historical execution success rate within the preset statistical time window, with a value ranging from 0 to 1. , and These represent the precision loss weight, computational complexity weight, and execution failure weight, respectively. , and All are non-negative and satisfy The type conversion rule base is generated based on the input data type, output data type, conversion function reference, precision loss, and conversion cost coefficient of each atomic type converter, and the type conversion rule base is written into the heterogeneous system integration request data. Step S103: Obtain the source data to be integrated, the target system identifier, and the preset default type conversion strategy; write the source data to be integrated, the target system identifier, and the preset default type conversion strategy into the heterogeneous system integration request data; select a target adapter instance from the pre-established adapter registry according to the target system identifier, and encapsulate the heterogeneous system integration request data and the target adapter instance into the integration task data.

3. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 1, characterized in that, Step S20, based on the field mapping rules in the integrated task data, employs a field identifier parsing and directed association mechanism to execute the mapping relationship graph construction task and outputs the field mapping relationship graph. This step specifically includes: Step S201: Split the field mapping rule into at least one field mapping record, create a field mapping data object for each field mapping record, and write the source system field identifier, target system field identifier, source field declaration type, target field expected type, and forced conversion strategy identifier from the corresponding field mapping record into the field mapping data object; Step S202: Detect the type conversion strategy identifier in each field mapping data object. If the type conversion strategy identifier is empty, mark the corresponding field mapping data object as automatic path search mode; if the type conversion strategy identifier is not empty, mark the corresponding field mapping data object as type conversion strategy mode. Step S203: Set the source system field identifier and target system field identifier in each field mapping data object as the source field node and target field node respectively, establish a mapping edge between the source field node and the target field node, and use the corresponding field mapping data object as the edge attribute of the mapping edge to obtain the field mapping relationship graph.

4. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 3, characterized in that, Step S202, in the case that the type casting strategy identifier is not empty, the step of marking the corresponding field mapping data object as the type casting strategy pattern includes: Based on the forced conversion strategy identifier, query the atomic type converter corresponding to the forced conversion strategy identifier in the type conversion rule base of the integrated task data; If a corresponding atomic type converter is found, the converter identifier of the found atomic type converter is written into the corresponding field mapping data object, and the corresponding field mapping data object is marked as a forced conversion strategy mode; If no corresponding atomic type converter is found, a forced conversion strategy configuration exception record is generated, and the corresponding field mapping data object is marked as a configuration exception state to prevent step S40 from performing a conversion path search for the field mapping data object in the configuration exception state.

5. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 1, characterized in that, Step S30, based on the field mapping relationship graph and the type conversion rule base in the integrated task data, employs a directed graph expansion mechanism with mapping type constraints to perform a type conversion rule preprocessing task and outputs a directed type conversion graph. This step specifically includes: Step S301: Parse the field mapping relationship graph, obtain the source field declaration type and target field expected type associated with each mapping edge in the field mapping relationship graph, and obtain the input data type and output data type corresponding to each atomic type converter from the type conversion rule base; perform deduplication processing on the obtained data types, set the deduplicated data types as type nodes respectively, and obtain the initial type conversion graph; Step S302: Traverse each atomic type converter in the type conversion rule base, add a directed edge between the type node corresponding to the corresponding input data type and the type node corresponding to the corresponding output data type, and write the converter identifier, conversion function reference, precision loss degree and conversion cost coefficient of the corresponding atomic type converter into the edge attribute of the directed edge; Step S303: If there is a composite type converter formed by combining at least two atomic type converters in the type conversion rule base, extract the atomic type converter sequence contained in the composite type converter; according to the connection relationship between the output data type of the previous atomic type converter and the input data type of the next atomic type converter in the atomic type converter sequence, supplement the intermediate type node and directed edge in the initial type conversion graph to obtain the directed type conversion graph.

6. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 2, characterized in that, Step S40, based on the field mapping graph, the directed type conversion graph, and the source data to be integrated in the integration task data, employs a Dijkstra minimum cost path search mechanism with precision decay penalty to perform the conversion path planning task and output a set of type conversion paths. Specifically, this includes: Step S401: Parse the field mapping relationship diagram to obtain the source system field identifier and target field expected type corresponding to each field mapping record; read the source field value from the source data to be integrated according to the source system field identifier, obtain the runtime actual type of the source field value, and determine the type node corresponding to the runtime actual type as the starting type node and the type node corresponding to the target field expected type as the ending type node; Step S402: For the candidate transformation path from the starting type node to the ending type node, calculate the total path cost according to the following formula: in, Indicates candidate conversion paths, Indicates candidate transformation paths The total path cost, Indicates candidate transformation paths Number of atomic type converters included, Indicates candidate transformation paths The first in Atom type converter, This indicates the atom type converter determined according to step S102. The conversion cost coefficient, This indicates the atom type converter recorded in step S102. The degree of accuracy loss, This represents the non-negative path hop penalty coefficient. This represents the non-negative cumulative precision attenuation penalty coefficient. Represent the natural logarithm function; Step S403: For field mapping records where the forced conversion strategy identifier is empty, using the total path cost as the path search cost, a Dijkstra search is used to obtain the candidate conversion path with the minimum total path cost from the starting type node to the ending type node; for field mapping records where the forced conversion strategy identifier is not empty and a corresponding atomic type converter exists, a fixed conversion path is generated according to the atomic type converter corresponding to the forced conversion strategy identifier; the candidate conversion paths and the fixed conversion paths are aggregated into the type conversion path set.

7. The configurable heterogeneous system integration method based on the adapter pattern as described in claim 2, characterized in that, Step S50, which involves performing chain-of-responsibility field value conversion and exception rollback processing based on the integration task data, the field mapping relationship diagram, and the type conversion path set, and outputting the heterogeneous system integration result, specifically includes: Step S501: Traverse each mapping relationship in the field mapping relationship graph, read the source system field identifier, target system field identifier, and target field expected type corresponding to the corresponding mapping relationship, obtain the source field value according to the source system field identifier, and select the type conversion path corresponding to the corresponding mapping relationship from the type conversion path set; call the corresponding conversion function in sequence according to the arrangement order of each atomic type converter in the type conversion path, and use the intermediate field value output by the previous atomic type converter as the input of the next atomic type converter to obtain the target field value; Step S502: If no type conversion path corresponding to the corresponding mapping relationship exists in the set of type conversion paths, or if any atomic type converter returns a conversion failure status or throws a conversion exception, perform exception rollback processing according to the preset default type conversion strategy; if the expected type of the target field has a string parsing function, call the string serialization function corresponding to the runtime actual type of the source field value to convert the source field value into a rollback string, and call the string parsing function corresponding to the expected type of the target field to convert the rollback string into a rollback target field value; if the expected type of the target field does not have a string parsing function, read the preset target field default value corresponding to the expected type of the target field from the preset default type conversion strategy, and determine the preset target field default value as the rollback target field value; Step S503: Based on the target system field identifier, write the target field value or the fallback target field value to the target field write position corresponding to the target adapter instance; in the event of a conversion exception, record the source system field identifier, the target system field identifier, the runtime actual type of the source field value, the expected type of the target field, the exception type, and the converter identifier of the atomic type converter that caused the exception; encapsulate the target system data with completed field writing and the corresponding conversion exception record into the heterogeneous system integration result.

8. A configurable heterogeneous system integration system based on the adapter pattern, applied to the configurable heterogeneous system integration method based on the adapter pattern according to any one of claims 1 to 7, characterized in that, The configurable heterogeneous system integration system includes: The integration task initialization module is used to obtain heterogeneous system integration request data, and execute the integration task initialization task based on the heterogeneous system integration request data using an adapter registration mechanism, and output integration task data including field mapping rules, type conversion rule base and source data to be integrated; The mapping graph construction module is used to perform the mapping graph construction task based on the field mapping rules in the integrated task data, using field identifier parsing and directed association mechanism, and output the field mapping graph. The type conversion graph preprocessing module is used to perform type conversion rule preprocessing tasks based on the field mapping relationship graph and the type conversion rule library in the integrated task data, using a directed graph expansion mechanism with mapping type constraints, and output a directed type conversion graph. The transformation path planning module is used to perform the transformation path planning task based on the field mapping relationship graph, the directed type transformation graph, and the source data to be integrated in the integration task data, using a Dijkstra minimum cost path search mechanism with precision decay penalty, and output a set of type transformation paths; The conversion execution module is used to perform chain-of-responsibility field value conversion and exception rollback processing based on the integrated task data, the field mapping relationship diagram and the type conversion path set, and output the heterogeneous system integration result.

9. A configurable heterogeneous system integration device based on the adapter pattern, characterized in that, The adapter-mode-based configurable heterogeneous system integration device includes: a memory, a processor, and an adapter-mode-based configurable heterogeneous system integration program stored in the memory and executable on the processor. When the adapter-mode-based configurable heterogeneous system integration program is executed by the processor, it implements an adapter-mode-based configurable heterogeneous system integration method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a configurable heterogeneous system integration program based on the adapter pattern, which, when executed by a processor, implements a configurable heterogeneous system integration method based on the adapter pattern according to any one of claims 1 to 7.

Images