Interface adaptation method and system for complex information system module reconstruction integration

Abstract

The application relates to an interface adaptation method and system for complex information system module reconstruction integration. The method comprises the following steps: acquiring protocol mapping rules and constructing a rule library; listening to a calling request sent by a source module through a transmission layer protocol of the source module, the calling request carrying source module side interface protocol format data; analyzing the request, stripping the source module side transmission layer protocol header to extract application layer data, and encapsulating the application layer data into an internal general data model; performing structural mapping, data conversion and dynamic logic processing on the model through a rule execution engine according to the request mapping rules of the rule library, reconstructing the model into target request data according to a target module interface format, and sending the target request data to the target module through a target side transmission layer protocol; receiving target response data, stripping the target response data to analyze the target response data into the internal general data model, and inversely converting the target response data according to response mapping rules to make the target response data conform to the source side interface format; and encapsulating the target response data into the source module side transmission layer protocol and returning the target response data to the source module. The method can improve adaptation flexibility and maintenance efficiency.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of information system integration, in particular to an interface adaptation method and system for complex information system module reconstruction integration. BACKGROUND

[0002] With the deepening of digital transformation, information system integration technology continues to evolve, and the information systems of enterprises and organizations gradually form heterogeneous complex architectures developed by different technical teams, different technical stacks, and different periods, covering various module forms such as early monolithic applications, SOA architecture Web services, and modern microservices. Such systems need to be integrated through module reconstruction and integration to realize function upgrade, new software introduction, and cross-system data service integration, which has become a normalized requirement in the digital process.

[0003] To solve the problem of incompatible interface protocols in the module reconstruction and integration process, the industry has formed mainstream solutions such as hard-coded direct connection adaptation, customized gateways or middleware, traditional enterprise service buses, and existing general adapter technologies. However, these traditional technologies all have significant defects: hard-coded direct connection adaptation is highly invasive, polluting business core code, destroying module encapsulation and independence, leading to high system coupling and poor maintainability, and accumulating a large amount of technical debt as incompatible interfaces increase; customized gateways or middleware are still essentially one-to-one hard-coded, with poor scalability, leading to an explosion in the number of gateways and middleware, increasing operational complexity and cost exponentially, and lacking a unified standard to form enterprise-level unified adaptation capabilities; traditional enterprise service bus architectures are heavy and easy to become single points of failure and performance bottlenecks, which contradicts the lightweight and decentralized philosophy of cloud-native and microservices, and are complex to configure, have a steep learning curve, and are not agile enough to respond to frequently changing interface needs; existing general adapter technologies have limited protocol support and weak conversion capabilities, and can only implement simple field mapping but cannot handle complex data structure conversion and dynamic logic embedding, and lack perfect monitoring, logging, and diagnostic functions, making it difficult to locate and troubleshoot exceptions during adaptation. These problems collectively result in high technical barriers, time and financial costs for complex information system module reconstruction and integration, making it difficult to achieve seamless integration between different protocol interfaces. SUMMARY

[0004] Therefore, it is necessary to provide an interface adaptation method and system for complex information system module reconstruction integration to solve the above technical problems.

[0005] An interface adaptation method for complex information system module reconstruction integration, the method comprising:

[0006] obtaining a preset protocol mapping rule from an external storage medium and constructing a rule library;

[0007] The calling request sent by the source module through a source module side transport layer protocol and carrying source module side interface protocol format data is listened to and received;

[0008] The calling request is parsed, the source module side transport layer protocol header is stripped to extract application layer data, and the application layer data is encapsulated into an internal common data model;

[0009] According to the request mapping rule in the rule library, the internal common data model is subjected to structure mapping, data conversion and dynamic logic processing through a rule execution engine, is reconstructed into target request data according to the structure requirement of the target module side interface protocol format, and is sent to the target module through a target module side transport layer protocol;

[0010] The response data returned by the target module is received, is parsed into the internal common data model after the target module side transport layer protocol header is stripped, and the internal common data model is subjected to reverse conversion according to the response mapping rule in the rule library, so that the response data conforms to the source module side interface protocol format;

[0011] The converted response data is encapsulated back into the source module side transport layer protocol and is returned to the source module.

[0012] An interface adaptation system for complex information system module reconstruction and integration, the system comprising:

[0013] A rule management module for obtaining preset protocol mapping rules from an external storage medium and constructing a rule library;

[0014] A request receiving module for listening to and receiving a calling request sent by a source module through a source module side transport layer protocol and carrying source module side interface protocol format data;

[0015] A request parsing module for parsing the calling request, stripping the source module side transport layer protocol header to extract application layer data, and encapsulating the application layer data into an internal common data model;

[0016] A request conversion module for, according to the request mapping rule in the rule library, subjecting the internal common data model to structure mapping, data conversion and dynamic logic processing through a rule execution engine, reconstructing the internal common data model into target request data according to the structure requirement of the target module side interface protocol format, and sending the target request data to the target module through a target module side transport layer protocol;

[0017] A reverse conversion module for receiving response data returned by the target module, parsing the response data into the internal common data model after the target module side transport layer protocol header is stripped, and subjecting the internal common data model to reverse conversion according to the response mapping rule in the rule library, so that the response data conforms to the source module side interface protocol format;

[0018] The response returning module is configured to encapsulate the converted response data into a transport layer protocol on the side of the proxy module and return the converted response data to the source module.

[0019] The beneficial effects of the present application are as follows:

[0020] The interface adaptation method and system for complex information system module reconstruction integration described above load protocol mapping rules from an external storage medium and construct a rule library, and separate the adaptation logic from the business logic by using an independent rule execution engine, without modifying the source / target module code, thereby significantly reducing the integration risk and protecting existing assets. By stripping the transport layer protocol header and implementing layered processing of application layer data analysis, the communication protocol and the interface protocol are decoupled, and different transmission protocols and interface formats of heterogeneous modules are flexibly adapted. With the internal general data model as an intermediate conversion carrier, combined with structure mapping, data conversion and dynamic logic processing, bidirectional adaptation of heterogeneous protocols is efficiently completed. The adaptation logic is driven by external configuration, and the core engine does not need to be modified to respond to protocol changes, thereby greatly improving the adaptation flexibility and maintenance efficiency, and effectively solving the problems of heterogeneous protocol compatibility, strong integration invasiveness and poor adaptation scalability in complex information system module reconstruction integration. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 FIG. 1 is a flowchart of an interface adaptation method for complex information system module reconstruction integration according to an embodiment of the present application.

[0022] Figure 2 FIG. 1 is a flowchart of an interface adaptation method for complex information system module reconstruction integration according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0024] In one embodiment, as shown in FIG. 1, an interface adaptation method for complex information system module reconstruction integration is provided, including the following steps: Figure 1

[0025] Step 102: obtaining pre-set protocol mapping rules from an external storage medium and constructing a rule library.

[0026] ​The external storage medium refers to a storage carrier independent of the interface adapter core program, used to store protocol mapping rules, and realizes physical separation of rules and codes. The protocol mapping rules are the collective term of request mapping rules and response mapping rules, and are the structured configuration of the interface protocol adaptation logic between the source module and the target module (such as field mapping relationship, data type conversion rule, dynamic logic script, etc.). The rule library is a logical unit for uniformly storing and managing protocol mapping rules.

[0027] It can be understood that by loading in an external configuration mode, the flexibility and configurability of the system are significantly improved. When the source / target module interface protocol changes, only the external configuration rules need to be updated to complete the adaptation adjustment, the response change speed is fast, and the maintenance cost is very low. On the other hand, the separation of rules and codes makes the adaptation logic completely independent of the business logic of the source / target module, avoiding modification of the original system source code, fully guaranteeing the high non-invasive advantage, protecting existing IT assets, and reducing the risk of changes in the complex system integration process.

[0028] Step 104, listening and receiving the calling request sent by the source module through the source module side transport layer protocol, carrying the source module side interface protocol format data.

[0029] The source module refers to the original system module (i.e. the to-be-adapted module that needs to be integrated with the target module) that initiates the interface call, and its interface protocol format may be heterogeneous with that of the target module. The source module side transport layer protocol is the network transport layer protocol (such as HTTP / 1.1, gRPC, Dubbo, MQ, etc.) used by the source module to send data. The source module side interface protocol format is the structured format (such as JSON, XML, custom binary format, etc.) of the application layer data in the source module call request, which contains field definitions, data types, organization methods, etc. The calling request is a business request (such as data query, function call, state synchronization, etc.) initiated by the source module to the target module, which needs to be adapted by the adapter before it can be recognized and processed by the target module.

[0030] Step 106, parsing the calling request, stripping the source module side transport layer protocol header to extract the application layer data, and encapsulating the application layer data into an internal general data model.

[0031] The transport layer protocol header is the header data of the source module side transport layer protocol used to describe the transmission control information, which functions to ensure the reliability and standardization of data transmission without participating in business logic processing. The internal general data model is a unified data abstraction model defined by the adapter, which serves as an intermediate language for heterogeneous protocol conversion, shielding the heterogeneity of the source / target module interface protocol and supporting standardized storage and calling of nested data structures and complex field types.

[0032] It can be understood that the heterogeneous source module interface protocol data is converted into a unified internal model, so that the subsequent mapping conversion process does not need to pay attention to the specific format of the source protocol, and only needs to be processed based on the unified model, which greatly improves the universality of the adaptation logic. This design not only provides a foundation for powerful complex scene processing capability (the unified model supports standardized processing of complex data structures), but also further strengthens the clear architecture and high scalability of the system through the modular analysis and encapsulation process, so that when adding an interface protocol adaptation, only the corresponding data analysis and model encapsulation logic needs to be extended, without changing the core conversion engine.

[0033] Step 108, according to the request mapping rule in the rule library, the internal general data model is mapped, converted and dynamically processed by the rule execution engine, and is reconstructed into target request data according to the structure requirements of the target module side interface protocol format, and is sent to the target module through the target module side transmission layer protocol.

[0034] The request mapping rule is a configuration in the rule library that defines the forward adaptation logic from the source module to the target module, and the rule execution engine is the core execution unit of the adapter, including a mapper, a data converter, an embedded script engine and a data model library, responsible for completing the adaptation processing of the internal general data model according to the request mapping rule. The target module is a system module that receives and processes the adapted request (i.e. the target system that the source module needs to integrate). The target module side transmission layer protocol / interface protocol format is the transmission layer protocol and application layer data format supported by the target module, which is the basis for reconstructing the target request data; the target request data is the final request data that meets the requirements of the target module interface protocol and can be directly recognized and processed by the target module.

[0035] Step 110, receiving the response data returned by the target module, parsing the internal general data model after stripping the target module side transmission layer protocol header, and according to the response mapping rule in the rule library, the internal general data model is reversely converted, so that the response data meets the source module side interface protocol format.

[0036] The response data is the result data returned by the target module after processing the request (such as processing success identifier, business return value, error information, etc.). The response mapping rule is a configuration in the rule library that defines the reverse adaptation logic from the target module to the source module, which is symmetrical to the request mapping rule, and includes reverse field mapping, data type conversion, response specific dynamic logic, etc. The reverse conversion is the process of converting the target module response data into the interface protocol format that can be recognized by the source module, which is symmetrical to the forward conversion logic.

[0037] Step 112, encapsulating the converted response data back into the source module side transmission layer protocol and returning it to the source module.

[0038] In the interface adaptation method for module reconstruction and integration of a complex information system, the protocol mapping rules are loaded through an external storage medium and a rule base is constructed, the separation of adaptation logic and business logic is realized in combination with a separate rule execution engine, the source / target module code does not need to be modified, the integration risk is significantly reduced, and the existing assets are protected. Through the layered processing of stripping the transmission layer protocol header and the application layer data analysis, the decoupling of the communication protocol and the interface protocol is realized, and the heterogeneous modules with different transmission protocols and interface formats are flexibly adapted. With the internal general data model as an intermediate conversion carrier, in combination with the structure mapping, data conversion and dynamic logic processing, the bidirectional adaptation of heterogeneous protocols is efficiently completed, the adaptation logic is driven through external configuration, the core engine does not need to be modified to respond to protocol changes, the adaptation flexibility and maintenance efficiency are greatly improved, and the problems of heterogeneous protocol compatibility, strong integration invasiveness and poor adaptation expansibility in the module reconstruction and integration of a complex information system are effectively solved.

[0039] In one embodiment, encapsulating the application layer data into the internal general data model comprises: extracting key elements in the application layer data; the key elements comprise a service name, an operation name, a parameter key-value pair and serialization format information; and performing standardized processing on the key elements according to a preset metadata specification, and encapsulating the standardized information into the internal general data model.

[0040] In one embodiment, the rule execution engine comprises a mapper, a data converter, an embedded script engine and a data model library.

[0041] In one embodiment, the structure mapping, data conversion and dynamic logic processing of the internal general data model through the rule execution engine comprises: the mapper maps the hierarchical path of the source field in the internal general data model to the target field path according to the field mapping table in the request mapping rule, establishes the corresponding relationship between the source field and the target field, the data converter performs type forced conversion on the mapped field value according to the data type conversion requirement in the rule, and calls a pre-defined function to complete string format standardization, numerical calculation or data desensitization processing, if the dynamic logic configuration is included in the protocol mapping rule, the embedded script engine loads and executes the pre-set script code to realize the loop iteration processing of list type data, the conditional branch judgment based on the field value, or the calling of an external data source to supplement business parameters, and finally generates a data structure conforming to the interface protocol format of the target module side.

[0042] In one embodiment, the reverse transformation of the internal general data model according to the response mapping rules in the rule base to make the response data conform to the source module side interface protocol format includes: according to the response mapping rules in the rule base, the internal general data model is structurally mapped, data is transformed, and dynamic logic is processed through the rule execution engine to make the response data conform to the source module side interface protocol format; the response mapping rules are symmetrical to the request mapping rules, including the reverse path mapping of the target module side interface protocol format fields and the source module side interface protocol format fields, the reverse transformation rules of the response data type, and the response-specific dynamic logic processing script.

[0043] In one embodiment, the protocol mapping rules are defined through an Extensible Markup Language (Extreme Markup Language) configuration file; the Extreme Markup Language configuration file includes at least one of field mapping rules, data type conversion rules, and interface function mapping rules.

[0044] In one embodiment, the method further includes: when building the rule base, classifying and storing the protocol mapping rules obtained from the external storage medium according to service identifier and interface identifier; when the protocol mapping rules need to be updated, only the rule file of the changed part is loaded, and the updated rules take effect immediately and the interface adapter service continues to run.

[0045] In one embodiment, the method further includes: before performing request transformation on the internal general data model through the rule execution engine, verifying whether the application layer data contains the required fields specified by the source module's interface protocol format, and whether the field values ​​meet the preset legality requirements; after performing response reverse transformation on the internal general data model through the rule execution engine, verifying whether the transformed response data matches the structural requirements of the source module's interface protocol format, and whether the field values ​​are consistent with the business expectations of the source module; if any verification fails, generating structured exception information containing the verification failure type, exception field name, and legality requirements, binding the exception information with the unique identifier of this adaptation request and recording it in the log system, and returning an error response containing the unique identifier to the source module.

[0046] In one specific embodiment, such as Figure 2 The diagram illustrates a flowchart of an interface adaptation method for the transformation and integration of modules in complex information systems. The method is executed by an interface adapter, and its flow includes:

[0047] (1) Initialization and configuration loading: When the interface adapter starts, it loads one or more protocol mapping rule configuration files (such as XML format) from external storage media and builds the rule base in memory. Incremental updates and hot reloading of configuration are supported without restarting the service.

[0048] Establish a unified configuration center or metadata repository to manage configuration files in a versioned manner, centrally store them, and control access. Configuration files can be stored hierarchically by module, system, interface, etc. XML is used as the configuration file format. When the adapter starts, it scans all XML configuration files under the preset configuration base path. Based on the size and update frequency of the configuration files, it selects the appropriate parsing technology from DOM parsing, SAX parsing, StAX parsing, and high-performance parsing technology for parsing. After parsing, the configuration rules are converted from XML nodes and cached in an efficient data structure in memory. The hierarchical storage of configuration files by module, system, and interface can directly support the requirement of quickly matching the corresponding protocol mapping rule set based on the request characteristics such as service name in the subsequent step (4), improving the accuracy and efficiency of rule matching. The selection of an appropriate XML parsing technology to build an efficient data structure in memory provides a performance foundation for the fast invocation of the rule execution engine.

[0049] (2) Protocol-independent request reception and listening: The interface adapter runs as a service, listens to a preset communication endpoint, and receives call requests from the source module. The request is carried by the first communication protocol (such as RESTfulHTTP), and its data payload is in the format of the first interface protocol (such as custom XML).

[0050] (3) Request parsing and unified data model construction: The received request is deeply parsed, stripping away its external communication protocol header and extracting its internal application layer data. Subsequently, the extracted key elements (such as service name, operation name, parameter key-value pairs, and serialization format) are standardized and encapsulated into an internal general data model. This model serves as an "intermediate language" for protocol conversion, achieving decoupling from specific protocols.

[0051] This internal general-purpose data model is a layered, abstract, metadata-driven structure. It includes a protocol metadata layer that records the source information of requests; a business semantic layer that abstracts specific interface calls into standard business operations and defines core business entities; a unified data layer that converts all input data into a series of standardized data type field-value pairs and describes their structure; and a control and context layer that transmits non-business system control information. This internal general-purpose data model extracts raw metadata from the source request. Through metadata-driven standardization governance, it maps these heterogeneous source structure information to standardized business operations and the unified data layer definition within the model. The parsed actual data is then loaded and initially type-converted according to the unified data layer specification. The conversion engine then uses this model as the sole input. Based on the target protocol requirements, mapping rules are applied to each layer of the model. A pre-built conversion function library is used to process the values ​​in the unified data layer to meet the target requirements. Finally, according to the target protocol specification, all information in the model is reserialized into a message in the target format.

[0052] This layered abstract metadata-driven structure corresponds precisely to the processing steps of structure mapping, data conversion, and dynamic logic execution in the subsequent steps (4). The protocol metadata layer supports the adaptation of communication protocols, the business semantic layer provides a standard basis for static structure mapping, the unified data layer is the core object of data purification and processing, and the control and context layer ensures the transmission of system information during dynamic logic execution, thus realizing deep coupling between the model and the conversion process.

[0053] (4) Intelligent Request Transformation Based on Mapping Rules: This is the core transformation step. Based on the characteristics in the request (such as the service name), the corresponding protocol mapping rule set is matched from the rule base, and the rule execution engine is driven to transform the internal general data model. This step specifically includes:

[0054] ①Structure mapping: Based on the field mapping table, map the field paths in the source model to new paths in the target model.

[0055] ② Data purification and transformation: Based on data type and value conversion rules, field values ​​are processed, such as: data type forced conversion, string format standardization, translation of enumerated values ​​using lookup tables, and data anonymization or calculation using predefined functions.

[0056] ③ Dynamic logic execution: For complex business logic that cannot be described by static rules, the built-in script engine component (such as Groovy, JavaScript) is called to execute the pre-configured script code to achieve advanced functions such as loop iteration, conditional branching, and external data source query.

[0057] ④ Request Model Reconstruction: Reconstruct the mapped, transformed, and processed data into a data object recognizable by the target module according to the structural requirements of the second interface protocol format.

[0058] (5) Target request sending and communication adaptation: The reconstructed request data is sent to the target module through a second communication protocol (such as gRPC or Dubbo) adapted to the target module.

[0059] (6) Target response reception: Receive the response data returned by the target module, which also follows the second interface protocol format.

[0060] (7) Reverse conversion of response data: This process is the reverse of (4). According to the predefined response mapping rules, the received response data is parsed into the internal general data model, and after steps such as structure mapping and data conversion, response data that conforms to the first interface protocol format is finally generated.

[0061] (8) Response return and transaction termination: The converted response data is encapsulated back into the first communication protocol and returned to the source module, thus completing a complete service call chain.

[0062] Preferably, in (4) and (7), data verification and consistency checks are also performed in parallel to ensure the integrity and legality of input and output data. If the verification fails, a structured exception is immediately thrown, and the entire link tracing information is recorded through the log system to facilitate problem location.

[0063] It is understood that this invention introduces an independent intelligent interface adapter as an intermediary layer. Through a pipelined processing mode of "protocol parsing - abstract modeling - mapping transformation - protocol encapsulation," it transforms the heterogeneous specific interface protocols between different modules into a unified configurable adaptation problem. Its core innovation is embodied in three major separation designs: separation of business logic and adaptation logic, making the adaptation rules completely independent of the source / target module code and avoiding intrusion into the original system; separation of communication protocol and interface protocol, handling transport layer protocols such as HTTP, TCP, and MQ and application layer data formats such as SOAP, JSON, and custom binary respectively, achieving layered decoupling; and separation of conversion rules and execution engine, driving the core conversion engine through external configuration, supporting dynamic updates and flexible expansion of the adaptation logic, and responding to changes in requirements without modifying the core code.

[0064] Compared with existing technologies, this invention has significant advantages: its highly non-intrusive design completely avoids modifying the source and target system source code, effectively protecting existing assets and reducing integration risks; its superior flexibility and configurability achieve "code as configuration" of adaptation logic through externalized and structured configuration, resulting in fast response to changes and extremely low maintenance costs; its combination of static mapping and dynamic script execution gives the system powerful capabilities to handle complex scenarios, easily handling various adaptation needs ranging from simple field name mapping to complex multi-step data processing; its built-in data verification, exception handling, and end-to-end monitoring mechanisms ensure enterprise-level robustness and maintainability, meeting the reliability and observability requirements of enterprise applications; and its modular device design makes the system hierarchy clear, with new protocol support achieved by extending the communication protocol adaptation layer and adding corresponding mapping rules, providing excellent scalability.

[0065] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0066] In one embodiment, an interface adaptation system for the transformation and integration of modules in complex information systems is provided, including:

[0067] The rule management module is used to obtain preset protocol mapping rules from external storage media and build a rule base;

[0068] The request receiving module is used to listen for and receive call requests sent by the source module through the source module's transport layer protocol, which carry data in the source module's interface protocol format.

[0069] The request parsing module is used to parse the call request, strip the transport layer protocol header from the source module to extract the application layer data, and encapsulate the application layer data into an internal general data model.

[0070] The request transformation module is used to perform structural mapping, data transformation and dynamic logic processing on the internal general data model according to the request mapping rules in the rule base through the rule execution engine. It reconstructs the data into target request data according to the structural requirements of the target module side interface protocol format, and then sends it to the target module through the target module side transport layer protocol.

[0071] The inverse conversion module is used to receive the response data returned by the target module, strip the transport layer protocol header of the target module, parse it into the internal general data model, and perform inverse conversion on the internal general data model according to the response mapping rules in the rule base so that the response data conforms to the interface protocol format of the source module.

[0072] The response return module is used to encapsulate the converted response data back to the source module's transport layer protocol and return it to the source module.

[0073] In one embodiment, an interface adapter device for the transformation and integration of modules in a complex information system is provided, comprising:

[0074] ① Configuration Management Module: Responsible for loading, parsing, caching, and hot-updating the protocol mapping rule configuration file. The protocol mapping rule configuration file (such as XML format) loaded by the configuration management module also contains the script declarations required by the core rule execution engine (embedded through specific tags or referenced by the src attribute), providing the configuration foundation for the dynamic logic execution of the embedded script engine.

[0075] ② Communication Protocol Adaptation Layer: Includes multi-protocol listeners and transmitters, used to interface with different communication protocols and achieve transparency in network communication.

[0076] ③ Request / Response Parsing and Encapsulation Module: Responsible for bidirectional conversion between the raw message and the internal general data model. The internal general data model is the core data source for the script engine embedded in the core rule execution engine. The source data required for script execution comes from the model encapsulated by this module, and the metadata definition of the model is uniformly maintained by the data model library.

[0077] ④ Core rule execution engine: This is the core of the device and includes:

[0078] 1) Mapper: Performs static field-to-structure mapping.

[0079] 2) Data converter: Performs conversions of data types and values.

[0080] 3) Embedded script engine: used to execute dynamic conversion logic.

[0081] In XML mapping rules, the required scripts are declared using specific tags. Scripts can be embedded in XML or referenced via the `src` attribute. Depending on the script language type, the rule engine calls the corresponding script engine factory to obtain a dedicated script engine instance. The script engine creates a binding object as the script's sandbox execution context. The rule engine then injects the data required for transformation from the internal general data model, an empty object or structure to store the transformation results, and utility class instances into this context. It then executes the script by calling the script engine instance methods of the binding object. Internally, the script autonomously accesses data from the internal general data model, processes it using the utility class instance, and assigns the results to the empty object or structure storing the transformation results or directly returns the processing results. After execution, the rule engine retrieves the object or structure storing the transformation results from the sandbox, or directly obtains the return value of the called method, and integrates it back into the main data stream.

[0082] 4) Data Model Library: Used to store and maintain internal general data models and various metadata definitions.

[0083] ⑤ Monitoring and logging module: Responsible for recording performance indicators, anomaly information and full-link logs during the adaptation process, providing system observability.

[0084] During the conversion process, a script engine is used to dynamically execute the data conversion logic.

[0085] Specific limitations regarding the interface adaptation system for the transformation and integration of modules in complex information systems can be found in the limitations of the interface adaptation method for the transformation and integration of modules in complex information systems mentioned above, and will not be repeated here. Each module in the aforementioned interface adaptation system for the transformation and integration of modules in complex information systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0086] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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.

[0087] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An interface adaptation method for the transformation and integration of modules in complex information systems, characterized in that, The method includes: Obtain preset protocol mapping rules from external storage media and build a rule base; Listen for and receive call requests sent by the source module through the source module's transport layer protocol, carrying data in the source module's interface protocol format; The call request is parsed, the transport layer protocol header on the source module side is stripped to extract the application layer data, and the application layer data is encapsulated into an internal general data model; Based on the request mapping rules in the rule base, the internal general data model is structured, converted, and dynamically processed by the rule execution engine. The data is then reconstructed into target request data according to the structural requirements of the target module side interface protocol format, and then sent to the target module through the target module side transport layer protocol. The system receives response data returned by the target module, strips the transport layer protocol header from the target module side, parses it into the internal general data model, and performs reverse conversion on the internal general data model according to the response mapping rules in the rule base to make the response data conform to the interface protocol format of the source module side. The converted response data is encapsulated back to the source module's transport layer protocol and returned to the source module; The process of performing structural mapping, data transformation, and dynamic logic processing on the internal general data model through the rule execution engine includes: The mapper maps the hierarchical path of the source field in the internal general data model to the target field path based on the field mapping table in the request mapping rules, thus establishing the correspondence between the source and target fields. The data converter performs type casting on the mapped field values ​​according to the data type conversion requirements in the rules, and calls predefined functions to complete string format standardization, numerical calculation or data desensitization. If the protocol mapping rules contain dynamic logic configuration, the embedded script engine loads and executes the pre-set script code to realize the loop iteration processing of list-type data, conditional branch judgment based on field values, or call external data sources to supplement business parameters, and finally generate a data structure that conforms to the interface protocol format of the target module.

2. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, Encapsulating the application layer data into an internal general data model includes: Extract key elements from application layer data; the key elements include service name, operation name, parameter key-value pairs, and serialization format information; Key elements are standardized according to preset metadata specifications, and the standardized information is then encapsulated into an internal general data model.

3. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, The rule execution engine includes a mapper, a data converter, an embedded script engine, and a data model library.

4. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, The internal general data model is reverse-converted according to the response mapping rules in the rule base to make the response data conform to the source module side interface protocol format, including: Based on the response mapping rules in the rule base, the internal general data model is structured, data transformed, and dynamically processed by the rule execution engine to make the response data conform to the source module side interface protocol format. The response mapping rules are symmetrical to the request mapping rules, including the reverse path mapping of the target module side interface protocol format fields and the source module side interface protocol format fields, the reverse conversion rules of the response data type, and the response-specific dynamic logic processing script.

5. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, The protocol mapping rules are defined through an Extensible Markup Language (Extreme Markup Language) configuration file; the Extreme Markup Language configuration file includes at least one of field mapping rules, data type conversion rules, and interface function mapping rules.

6. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, The method further includes: When constructing the rule base, the protocol mapping rules obtained from the external storage medium are classified and stored according to service identifier and interface identifier; When protocol mapping rules need to be updated, only the changed parts of the rule file are loaded, and the updated rules take effect immediately while the interface adapter service continues to run.

7. The interface adaptation method for the transformation and integration of modules in complex information systems according to claim 1, characterized in that, The method further includes: Before performing request transformation on the internal general data model through the rule execution engine, it verifies whether the application layer data contains the required fields specified by the source module's interface protocol format, and whether the field values ​​meet the preset legality requirements. After the internal general data model is reverse-transformed through the rule execution engine, it is verified whether the transformed response data matches the structural requirements of the source module's interface protocol format and whether the field values ​​are consistent with the business expectations of the source module. If any verification fails, a structured exception information containing the verification failure type, exception field name, and legal requirements is generated. The exception information is bound to the unique identifier of this adaptation request and recorded in the log system. An error response containing the unique identifier is then returned to the source module.

8. An interface adaptation system for the transformation and integration of modules in complex information systems, applied to the method described in any one of claims 1-7, characterized in that, The system includes: The rule management module is used to retrieve preset protocol mapping rules from external storage media and build a rule base; The request receiving module is used to listen for and receive call requests sent by the source module through the source module's transport layer protocol, which carry data in the source module's interface protocol format. The request parsing module is used to parse the call request, strip the transport layer protocol header from the source module to extract application layer data, and encapsulate the application layer data into an internal general data model. The request conversion module is used to perform structural mapping, data conversion and dynamic logic processing on the internal general data model according to the request mapping rules in the rule base through the rule execution engine, reconstruct the data into target request data according to the structural requirements of the target module side interface protocol format, and then send it to the target module through the target module side transport layer protocol. The inverse conversion module is used to receive the response data returned by the target module, strip the transport layer protocol header of the target module, parse it into the internal general data model, and perform inverse conversion on the internal general data model according to the response mapping rules in the rule base so that the response data conforms to the interface protocol format of the source module. The response return module is used to encapsulate the converted response data back to the source module's transport layer protocol and return it to the source module.

9. The interface adaptation system for the transformation and integration of modules in complex information systems according to claim 8, characterized in that, The rule execution engine includes a mapper, a data converter, an embedded script engine, and a data model library.

Images