Dynamic interface contract mapping method and system based on external configuration and program product

Abstract

The invention discloses a dynamic interface contract mapping method based on external configuration, which comprises the following steps: obtaining routing information and mapping rules of a target interface in an external configuration source, the mapping rules comprising a request mapping rule and a response mapping rule; and dynamically registering the HTTP path according to the routing information to receive the original request data. And after original request data is received, executing a first mapping operation according to the request mapping rule, and generating first service entity data. And after the first service entity data is subjected to core service logic processing to obtain second service entity data, executing a second mapping operation according to a response mapping rule, generating target response data and outputting the target response data. Through external configuration and dynamic processing, flexible configuration and hot update of interface routing and mapping logic are realized, interface change can be adapted without code modification, the problems of high development and maintenance cost, slow response and poor flexibility of interface mapping in the prior art are effectively solved, and the system efficiency and expandability are remarkably improved.

Description

Technical Field

[0001] The present application relates to the technical field of computer interface data processing, and in particular to a dynamic interface contract mapping method, system and program product based on external configuration. Background Art

[0002] In scenarios requiring frequent data interaction with multiple heterogeneous third-party systems, such as real-time bidding (RTB) systems in the advertising technology (AdTech) sector, demand-side platforms (DSPs) need to interface with different ad exchanges (ADXs). Existing techniques typically employ customized coding for each ADX's interface contract. This involves developing and maintaining a large amount of "glue code" to map data fields, convert values, and adapt formats between the DSP's internal business data model and the interface contracts defined by each ADX.

[0003] However, this prior art has the following problems:

[0004] High development and maintenance costs: Custom coding is required for each ADX interface contract, which not only requires a huge initial development workload, but also requires corresponding code modification, testing, and deployment when the ADX interface changes or a new ADX is added, resulting in high manpower and time costs.

[0005] Inefficient development and response: Any code changes involving mapping logic usually require following the complete CI / CD process. This makes the system slow to respond to changes in business requirements or updates to ADX interface contracts, and cannot meet the needs of rapid business iteration.

[0006] Insufficient system flexibility and scalability: Hard-coded mapping logic and fixed routing configurations make it difficult for the system to quickly adapt to new ADX access or frequent adjustments to existing ADX contracts, making the system rigid and scalable.

[0007] Configuration change lag: When mapping rules need to be adjusted, they cannot take effect in real time and must wait for the next code release. This is unacceptable in scenarios where strategies need to be adjusted quickly to respond to market changes.

[0008] Duplication of work and code redundancy: The mapping logic of different ADXs often contains similar or reusable parts, but using independent coding can easily lead to a large amount of duplicate code, increasing the complexity of the code base and the difficulty of maintenance.

[0009] Therefore, the existing technology lacks a mechanism that can get rid of hard coding and dynamically complete interface contract mapping based on external configuration to improve development efficiency, reduce costs, and enhance system flexibility and response speed.

[0010] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to ordinary technicians in this field.

[0011] Application Contents

[0012] In view of this, this application provides a dynamic interface contract mapping method based on external configuration to solve the problems in the prior art of hard-coding a large amount of field mapping and value conversion logic for each external interface, as well as the dynamic registration, loading, and real-time updating of interface routing and mapping rules, which require code modification and redeployment. This application aims to implement a flexible mapping rule system that can be driven by external configuration, and to build a mechanism that can dynamically generate or select mapper instances, thereby ensuring the accuracy of data conversion and the efficiency of the mapping process based on dynamic mapping.

[0013] The present invention provides a method for dynamic interface contract mapping based on external configuration, comprising the following steps:

[0014] Obtaining interface routing information of at least one target interface and mapping rules associated with the target interface stored in a preset external configuration source, the mapping rules including a request mapping rule for converting original request data into first business entity data and a response mapping rule for converting second business entity data into target response data;

[0015] Dynamically register one or more HTTP paths based on the obtained interface routing information. The HTTP path is used to receive the original request data for the target interface.

[0016] When original request data is received through the dynamically registered HTTP path, a first mapping operation is performed on the original request data according to the obtained request mapping rule for the target interface to generate first business entity data;

[0017] Submitting the first business entity data to a preset core business logic for processing to obtain second business entity data;

[0018] performing a second mapping operation on the second business entity data according to the acquired response mapping rule for the target interface to generate target response data;

[0019] Output target response data.

[0020] In some optional embodiments, obtaining interface routing information of at least one target interface and a mapping rule associated with the target interface stored in a preset external configuration source includes:

[0021] Periodically pull interface routing information and mapping rules from external configuration sources;

[0022] When it is detected that the version of the mapping rule associated with the target interface in the external configuration source is inconsistent with the version of the corresponding mapping rule cached in the current application memory, the mapping rule cached in the application memory is updated to the mapping rule newly pulled from the external configuration source.

[0023] In some optional embodiments, the step of updating the mapping rules cached in the application memory to the mapping rules newly pulled from the external configuration source uses a compare-and-swap operation to ensure the atomicity of the mapping rule update.

[0024] In some optional embodiments, the request mapping rule includes request body field path mapping information, where the request body field path mapping information defines a correspondence between a source field JSON path in the original request data and a target field path in the first business entity data;

[0025] Performing a first mapping operation includes copying the field value specified by the source field JSON path in the original request data to the field specified by the target field path in the first business entity data according to the request body field path mapping information.

[0026] In some optional embodiments, the request mapping rule further includes additional mapping information of the request body;

[0027] Executing the first mapping operation also includes performing a preset conversion operation on the field value of a specific source field in the original request data based on the additional mapping information of the request body, and the conversion operation is selected from at least one of: enumeration value conversion, data type format conversion, or default value filling.

[0028] In some optional embodiments, the request body additional mapping information includes a list conversion rule for a list-type source field;

[0029] Executing the first mapping operation also includes: when the original request data contains a list-type source field corresponding to the list conversion rule, traversing each source list element in the list-type source field, and extracting one or more sub-field values from each source list element according to the sub-field extraction path defined in the list conversion rule to construct a target list in the first business entity data.

[0030] In some optional embodiments, the response mapping rule includes response body field path mapping information, where the response body field path mapping information defines a correspondence between a source field path in the second business entity data and a target field JSON path in the target response data;

[0031] Performing a second mapping operation includes copying the field value specified by the source field path in the second business entity data to the field specified by the target field JSON path in the target response data according to the response body field path mapping information.

[0032] In some optional embodiments, the response mapping rule further includes additional mapping information of the response body;

[0033] Executing the second mapping operation further includes performing a preset conversion operation on the field value of a specific source field in the second business entity data according to the additional mapping information of the response body, or setting a predefined default value for a specific target field in the target response data.

[0034] In some optional embodiments, before performing the first mapping operation, the following steps are further included:

[0035] Dynamically instantiate one or more mapper objects according to configuration information for a target interface obtained from an external configuration source, the mapper objects including a request mapper for performing a first mapping operation and a response mapper for performing a second mapping operation;

[0036] The first mapping operation is performed by the instantiated request mapper;

[0037] In step S500 , the instantiated response mapper performs a second mapping operation.

[0038] In some optional embodiments, dynamically instantiating one or more mapper objects includes:

[0039] Check whether the configuration information for the target interface obtained from the external configuration source contains the predefined custom mapper class identifier;

[0040] If a custom mapper class identifier is included, the custom mapper class specified by the custom mapper class identifier is loaded and instantiated through the reflection mechanism as a request mapper and / or response mapper;

[0041] If the custom mapper class identifier is not included, a preset general mapper class is instantiated and the obtained mapping rules are passed to the general mapper class for configuration as a request mapper and / or response mapper.

[0042] In some optional embodiments, the external configuration source is a Redis database.

[0043] In some optional embodiments, the original request data and the target response data are data in JSON format.

[0044] In some optional embodiments, the method is applied to interface data mapping between a demand-side platform and an advertising exchange platform in a real-time bidding system.

[0045] An embodiment of the present invention further provides a dynamic interface contract mapping system based on external configuration, comprising:

[0046] A configuration acquisition module is used to obtain interface routing information and mapping rules of at least one target interface stored in an external configuration source, where the mapping rules include request mapping rules and response mapping rules;

[0047] The routing registration module is used to dynamically register the HTTP path for receiving the original request data for the target interface according to the interface routing information;

[0048] The request processing module is configured to, upon receiving the original request data transmitted via the HTTP path, map the original request data into first business entity data according to the request mapping rule corresponding to the target interface obtained by the configuration acquisition module;

[0049] A core business logic processing module, configured to receive and process first business entity data to obtain second business entity data;

[0050] The response processing module is used to convert the second business entity data into target response data according to the response mapping rule corresponding to the target interface obtained by the configuration acquisition module, and output the target response data.

[0051] In some optional embodiments, the configuration acquisition module is further configured to:

[0052] Periodically poll interface routing information and mapping rules from external configuration sources;

[0053] When a change in the mapping rules in the external configuration source is detected, a compare-and-swap (CAS) algorithm is used to update the mapping rules cached in the application memory to the changed mapping rules.

[0054] In some optional embodiments, the request mapping rules include request body path mapping rules and request body additional mapping rules; the request body path mapping rules are used to define the correspondence between the field path in the original request data and the field path of the first business entity data; the request body additional mapping rules are used to define the conversion logic of specific field values in the original request data, and the conversion logic includes enumeration value mapping or data type conversion.

[0055] An embodiment of the present invention further provides a dynamic interface contract mapping program product based on external configuration. The program product includes computer instructions. When the computer instructions are executed by a processor, the steps of the above-mentioned dynamic interface contract mapping method based on external configuration are implemented.

[0056] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

[0057] The present invention provides a method, system, and program product for dynamic interface contract mapping based on external configuration, which have the following beneficial effects:

[0058] The dynamic interface contract mapping method based on external configuration provided in this application effectively avoids hard-coding extensive field mapping and value conversion logic for each external interface by dynamically registering HTTP paths and externalizing configuration mapping rules. This method enables dynamic registration, loading, and real-time updates of interface routing and mapping rules without requiring code modifications or redeployment. This method supports a flexible, externally configured mapping rule system and establishes a mechanism for dynamically generating or selecting mapper instances. This ensures data conversion accuracy and efficient mapping processes based on dynamic mapping, while also supporting complex customization requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Other features, objects and advantages of the present application will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings.

[0060] Figure 1 This is a flow chart of a dynamic interface contract mapping method based on external configuration according to an embodiment of the present application;

[0061] Figure 2 It is a structural diagram of a dynamic interface contract mapping system based on external configuration according to an embodiment of the present application. DETAILED DESCRIPTION

[0062] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0063] In addition, the accompanying drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0064] The flowcharts shown in the accompanying drawings are merely exemplary and do not necessarily include all steps. For example, some steps may be decomposed, while some steps may be combined or partially combined. Therefore, the actual execution order may change according to actual circumstances.

[0065] Interface contract mapping refers to the process of converting and adapting source data according to the specifications of the target interface due to differences in interface definitions or data structures when exchanging data between different systems or services. The key to dynamic interface contract mapping is to decouple the mapping logic from the code and manage it through external configuration, thereby achieving dynamic loading and updating of the configuration without modifying and redeploying the code. This approach enables the system to quickly adapt to changes in external interfaces, reduce maintenance costs, and improve the flexibility and scalability of the system. Through pre-defined mapping rules, the received data is converted into a format that can be recognized and processed within the system, and the processed data is converted according to the requirements of the target interface, ultimately achieving data interaction between different systems and solving many problems caused by hard coding.

[0066] like Figure 1 As shown, the invention provides a dynamic interface contract mapping method based on external configuration. The method decouples the various links of interface contract mapping and drives the entire mapping process through external configuration. Specifically, the method includes the following steps:

[0067] S100. Obtain interface routing information of at least one target interface stored in a preset external configuration source and mapping rules associated with the target interface. The mapping rules include request mapping rules for converting original request data into first business entity data and response mapping rules for converting second business entity data into target response data. The purpose is to obtain necessary information of the target interface, which is the basis for subsequent dynamic routing registration and data mapping. Among them, interface routing information refers to the address used to locate a specific interface, such as an HTTP path, and mapping rules define how to convert original request data into first business entity data that can be processed within the system, and how to convert second business entity data processed by the core business logic into response data that meets the requirements of the target interface. Mapping rules include request mapping rules and response mapping rules. These rules may include field path mapping, value conversion rules, data type conversion rules, etc. This information is stored in a preset external configuration source, which can be a data storage medium in various forms, such as a Redis database, a distributed configuration center (such as Apollo or Nacos), or a JSON or YAML file in a file system.

[0068] S200. Dynamically register one or more HTTP paths based on the obtained interface routing information. These HTTP paths are used to receive original request data for the target interface. Based on the obtained interface routing information, dynamically register one or more HTTP paths. These HTTP paths serve as entry points for receiving original request data. Dynamic registration means that these paths are not pre-hardcoded in the system but are dynamically added to the system's routing table at runtime based on configuration information, thereby enhancing the system's flexibility and scalability.

[0069] S300. When original request data is received via the dynamically registered HTTP path, a first mapping operation is performed on the original request data based on the request mapping rules obtained for the target interface to generate first business entity data. When original request data is received via the dynamically registered HTTP path, a first mapping operation is performed on the original request data using the request mapping rules for the interface obtained in step S100 to convert the original data into first business entity data. This mapping operation includes a series of data processing steps, such as field mapping and value conversion, ultimately converting heterogeneous original data into a unified data format within the system.

[0070] S400: Submit the first business entity data to the preset core business logic for processing to obtain second business entity data. The converted first business entity data is submitted to the preset core business logic for processing. The core business logic performs various operations on the data based on business requirements and generates second business entity data.

[0071] S500: Perform a second mapping operation on the second business entity data based on the response mapping rules obtained for the target interface to generate target response data. Based on the response mapping rules obtained from the external configuration source, the second mapping operation is performed on the second business entity data to convert the second business entity data into target response data that conforms to the target interface specification, including field mapping, value conversion, and format conversion.

[0072] S600: Output target response data. The generated target response data is output and can be directly returned to the requesting party to achieve interface interconnection and interoperability.

[0073] Through the above steps, the method of the present invention can realize dynamic interface contract mapping based on external configuration, thereby avoiding writing a large amount of duplicate code for each external interface, reducing development and maintenance costs, and improving the flexibility and scalability of the system, so that the system can quickly adapt to changes in external interfaces.

[0074] In some embodiments, step S100 further includes a dynamic update mechanism for the configuration to ensure that the system can reflect the latest status of the external interface in real time. Interface routing information and mapping rules are periodically pulled from the external configuration source. The periodic pulling here can be implemented through a scheduled task. For example, the pulling operation can be configured to be performed once every minute, hourly, or daily. The purpose of periodic pulling is to monitor changes in configuration information in the external configuration source in real time. When it is detected that the version of the mapping rule associated with the target interface in the external configuration source is inconsistent with the version of the corresponding mapping rule cached in the current application memory, it indicates that the configuration information has changed. The mapping rule cached in the application memory needs to be updated to the mapping rule newly pulled from the external configuration source to ensure that the system uses the latest mapping rules. The version number can be identified in the form of an integer, a string, or a timestamp. By comparing the version number, it can be determined whether the configuration information has changed. The external configuration source can be a Redis database, a distributed configuration center (such as Apollo or Nacos), or a JSON or YAML file in the file system. This dynamic update mechanism can achieve real-time effectiveness of configuration information without restarting the system or redeploying the code. By periodically pulling and comparing versions, combined with dynamic updating of configuration information, this embodiment improves the flexibility and real-time performance of the system while ensuring the contract mapping function, enabling the system to adapt to changes in external interfaces in a timely manner, reducing manual intervention and maintenance costs, and avoiding data mapping errors caused by inconsistent configurations.

[0075] In some embodiments, the step of updating the mapping rules cached in the application memory with newly retrieved mapping rules from an external configuration source utilizes a compare and swap (CAS) operation to ensure the atomicity of the mapping rule update. In this embodiment, the CAS operation is a key technical means for implementing hot configuration updates. Since configuration updates can occur at any time, to avoid data races and configuration inconsistencies in a multi-threaded environment, this embodiment utilizes a CAS operation to ensure the atomicity of the update process. The CAS operation is a lock-free atomic operation that consists of three operands: the memory location to be read or written (V), the expected value to be compared (A), and the new value to be written (B). The CAS operation proceeds as follows: First, the current value of memory location V is read and compared with the expected value A. If the value of V is equal to the value of A, the value of memory location V is atomically updated to the new value B. If the value of V is not equal to the value of A, indicating that another thread has modified the value of the memory location in the meantime, the operation for the current thread fails, and no action is taken. Typically, a CAS operation returns a Boolean value indicating whether the operation was successful. In this embodiment, CAS operations can be implemented using methods such as `computeIfPresent` or `replace(key, oldValue, newValue)` of `ConcurrentHashMap`, or using an atomic reference `AtomicReference`, ensuring the atomicity of the mapping rule update process. This atomicity ensures that no matter how many concurrent threads attempt to update the configuration, only one thread will succeed; the other threads will need to retry or abandon the update. This ensures thread-safety of configuration updates, effectively avoids data inconsistencies caused by configuration updates, and improves system stability and reliability.

[0076] In some embodiments, the request mapping rule includes request body field path mapping information, which defines the correspondence between the source field JSON path in the original request data and the target field path in the first business entity data; a first mapping operation is performed in step S300, including copying the field value specified by the source field JSON path in the original request data to the field specified by the target field path in the first business entity data based on the request body field path mapping information. Specifically, the request body field path mapping information defines how to extract data from the original request data (usually in JSON format) and fill it into the corresponding field of the first business entity data (i.e., the business object within the system). The JSON path uses a dotted path representation, for example, `user.device.geo.lat`, which means to obtain the values of the `lat` fields under the `geo` objects under the `device` objects under the `user` objects in the JSON data in sequence. The target field path specifies which field in the first business entity data the value needs to be filled into, and also uses a dotted path notation, such as `rtbRequest.device.latitude`, which means that the value needs to be filled into the `latitude` field under the `device` object of the `rtbRequest` object. The process of copying field values can be implemented through a high-performance object mapping framework (such as Orika, BeanUtils), or by manually parsing the JSON path and setting the field value. It is worth noting that this embodiment not only supports the copying of fields of basic data types, but also supports the copying of nested objects and lists, thereby meeting the mapping requirements of complex data structures. Through this configuration, this embodiment achieves accurate field-level mapping of the original request data to the first business entity data, avoids the maintenance difficulties and code redundancy caused by hard coding, and improves the flexibility and configurability of data mapping.

[0077] In some embodiments, the request mapping rule further includes additional mapping information for the request body; performing the first mapping operation in step S300 further includes performing a preset conversion operation on the field value of a specific source field in the original request data based on the additional mapping information for the request body, where the conversion operation is selected from at least one of enumeration value conversion, data type format conversion, or default value filling. The additional mapping information for the request body is intended for complex data conversion scenarios that cannot be implemented solely through field path mapping.

[0078] 1. Enumeration value conversion: Different API specifications may represent the same concept differently. For example, a gender field may use an integer (1 for male, 2 for female), a string ("M" for male, "F" for female), or another custom enumeration type. Enumeration value conversion rules define how to convert these different representations into a unified enumeration type used internally by the system. The configuration can be `{"source_field_path":{"target_enum_class":"com.example.GenderEnum","mappings":{"1":"MALE","M":"MALE"}}}`.

[0079] 2. Data type format conversion: The field types in the original request data may differ from those in the first business entity data. For example, the price field is a string in the original request data, but a floating-point number in the first business entity data. Therefore, data type conversion is required. Data type format conversion includes string to number, date format conversion, and Boolean value conversion.

[0080] 3. Default value filling: In some cases, some fields may be missing in the original request data, but these fields are required in the first business entity data. In this case, you can set default value filling rules to set default values for these missing fields.

[0081] The above conversion operations can be implemented through hard coding, but they lack flexibility and are difficult to adapt to changes in the interface. Therefore, this embodiment configures these conversion operations and manages them in an external configuration manner. By adding additional mapping information to the request mapping rules, the conversion operations to be performed and their parameters can be flexibly specified, allowing the system to flexibly adapt to data formats, significantly improving the flexibility of data processing, reducing dependence on interface modifications, and improving the stability of the entire system.

[0082] In some embodiments, the additional mapping information of the request body includes a list conversion rule for a list-type source field; the first mapping operation is performed in step S300, and further includes: when the original request data contains a list-type source field corresponding to the list conversion rule, traversing each source list element in the list-type source field, and extracting one or more sub-field values from each source list element according to the sub-field extraction path defined in the list conversion rule to construct a target list in the first business entity data. This technical feature is mainly aimed at scenarios where the source data is a list, and part of the information needs to be extracted from each element of the list to form a new list. For example, there is a list of advertising creatives in the original request data, but the first business entity data only needs the ID and price of each advertising creative. In this case, a list conversion rule needs to be used.

[0083] List transformation rules: specify how to extract information from each element of the source list and transform it into an element of the target list. Rules usually contain:

[0084] Source list field path: The path pointing to the list field in the original request data.

[0085] Subfield extraction path: Defines which subfield values are extracted from each element in the source list. There can be one or more subfield extraction paths, corresponding to different attributes of each element in the target list.

[0086] In the specific implementation process, the following methods can be used to achieve it:

[0087] Iterate over each element in the source list.

[0088] For each source list element, extract the values of one or more subfields according to the subfield extraction path.

[0089] Construct an element of the target list using the extracted subfield value.

[0090] Add the constructed target list elements to the target list.

[0091] For example, suppose the original JSON data is as follows:

[0092]

[0093] We want to extract the ID and price of each ad creative to form a target list. The list conversion rule can be defined as follows:

[0094]

[0095] Where `targetEntity.parsedAds[*]` represents the field path of the target list.

[0096] `_sourcePath` specifies the field path of the source list as `request.ads`, `adId` and `price` specify the values of the `adid` and `price` fields to be extracted from each ad creative, respectively.

[0097] The target list construction process is similar to the map operation of the stream in Java 8, but it is implemented through configuration without writing code.

[0098] Through this technical means, this embodiment can flexibly process list data during the dynamic contract mapping process, extract and convert key information in list elements, and construct new lists, thereby meeting various complex data conversion requirements, simplifying data processing logic, and improving the scalability and applicability of the system.

[0099] In some embodiments, the response mapping rule includes response body field path mapping information, which defines a correspondence between a source field path in the second business entity data and a target field JSON path in the target response data. In step S500, a second mapping operation is performed, including copying, based on the response body field path mapping information, the field value specified by the source field path in the second business entity data to the field specified by the target field JSON path in the target response data. This embodiment focuses on mapping the response data, specifically, how to convert the second business entity data, after processing by the core business logic, into JSON response data that meets the requirements of an external interface (e.g., ADX).

[0100] Response body field path mapping information: This information defines the correspondence between the fields in the second business entity data (source fields) and the fields in the target response data JSON structure (target fields). Similar to the request mapping rules, the dotted path notation is also used here to specify the field path. For example, the source field path `rtbResponse.bid.price` represents the `price` field under the `bid` object of the second business entity `rtbResponse` object, and the target field JSON path is ``.

[0101] `response.seatbid[0].bid[0].price` represents the `price` field in the first element of the `bid` list in the first element of the `seatbid` list in the `response` object in the target response JSON data.

[0102] Mapping: Based on the response body's field path mapping information, the values of the specified fields in the second business entity data are copied to the corresponding fields in the target response data's JSON structure. This copying operation is similar to the "deserialization" process of a data structure, converting the system's internal data structure into a data format that can be recognized by the external interface.

[0103] In terms of specific implementation, you can use object mapping frameworks such as `Orika` and `BeanUtils`, or use manual parsing and assignment to achieve data replication.

[0104] Through this configuration, this embodiment achieves accurate field mapping from internal business entities of the system to external interface response data, ensuring the accuracy and compatibility of data when it is transferred between different systems.

[0105] In some embodiments, the response mapping rule further includes additional mapping information for the response body; performing the second mapping operation in step S500 further includes performing a preset conversion operation on the field value of a specific source field in the second business entity data, or setting a predefined default value for a specific target field in the target response data, based on the additional mapping information for the response body. This embodiment provides a more flexible mapping method to meet specific needs in the response mapping process.

[0106] Additional response body mapping information: Supplements the response body field path mapping information and is used to handle the following situations:

[0107] Value conversion: For example, converting the enumeration value used within the system into a specific string or integer value defined in the ADX interface document. Value conversion can include enumeration value conversion, data type format conversion, unit conversion, etc. In the specific implementation process, it can be implemented through a lookup table (Lookup Table), conditional judgment, or custom function. For example, you can configure `{"source_field":"errorCode","target_field":"code","mapping":{"0":"SUCCESS","1":"FAILED","2":"RETRY"}}` to convert the value of the `errorCode` field in the second business entity data to the value of the `code` field in the target response data.

[0108] Default Value Settings: Some ADX interfaces require that certain fields be included in the response data. Even if these fields do not exist in the secondary business entity data, they must be populated with specific default values. These default values are typically predefined by ADX. In practice, you can specify the default value of the target field directly in the configuration. For example, you can set the default value of the `currency` field in the target response data to "CNY" by configuring `{"target_field":"currency","default_value":"CNY"}`.

[0109] Through this technical means, this embodiment can flexibly perform value conversion and default value filling in the response mapping stage, further enhancing the flexibility and adaptability of interface adaptation and ensuring that the generated response data fully complies with external interface specifications.

[0110] In some embodiments, before step S300, step S210 is further included:

[0111] Dynamically instantiate one or more mapper objects according to configuration information for a target interface obtained from an external configuration source, the mapper objects including a request mapper for performing a first mapping operation and a response mapper for performing a second mapping operation;

[0112] Step S300: The instantiated request mapper performs a first mapping operation;

[0113] In step S500, the instantiated response mapper performs the second mapping operation. This embodiment aims to further decouple the execution of mapping logic from the definition of mapping rules. By introducing the concept of mapper objects, specific mapping operations are encapsulated in the mapper objects, and appropriate mapper objects are dynamically selected or generated based on external configurations.

[0114] Mapper object: A mapper object is a component responsible for performing specific mapping operations. Each mapper object usually corresponds to a specific target interface or a group of related interfaces. A mapper object can include the following functions:

[0115] Request mapper: responsible for performing the first mapping operation, converting the original request data into the first business entity data.

[0116] Response mapper: responsible for performing the second mapping operation to convert the second business entity data into target response data.

[0117] Dynamic instantiation: The instantiation of mapper objects is not completed in advance when the system starts, but is performed dynamically at runtime based on external configuration. This dynamic instantiation mechanism can select different mapper implementations according to different interface requirements, thereby improving the flexibility and scalability of the system.

[0118] In the specific implementation process, it can be achieved through the following methods:

[0119] According to the identifier of the target interface (eg, adx_name), configuration information corresponding to the interface is obtained from an external configuration source.

[0120] Based on the configuration information, select or create an appropriate mapper object.

[0121] Pass the mapping rules to the mapper object to complete the configuration of the mapper.

[0122] Mapper objects are cached for reuse in subsequent requests.

[0123] The selection and creation of mapper objects can be done in a variety of ways, for example:

[0124] Convention over configuration: automatically find the mapper class that conforms to the naming convention based on the interface identifier, such as `com.example.mappers.AdxNameRequestMapper` and

[0125] `com.example.mappers.AdxNameResponseMapper`.

[0126] Configuration specification: Explicitly specify the full class name of the mapper class in the configuration information, for example

[0127] `custom_mapper_class_name=com.example.mappers.CustomAdxMapper`.

[0128] Factory pattern: Use a mapper factory class to create a mapper object. The factory class selects the appropriate mapper implementation based on the configuration information.

[0129] After the mapper is instantiated, the first and second mapping operations are executed by the corresponding request mapper and response mapper, respectively, ensuring the modularity and maintainability of the data mapping process. This mechanism of dynamically instantiating mapper objects allows this embodiment to flexibly support a variety of different interface requirements and facilitate the expansion of new interface types, improving the efficiency of contract mapping while also enhancing the flexibility of the system.

[0130] In some embodiments, dynamically instantiating one or more mapper objects in step S210 includes:

[0131] Check whether the configuration information for the target interface obtained from the external configuration source contains the predefined custom mapper class identifier;

[0132] If a custom mapper class identifier is included, the custom mapper class specified by the custom mapper class identifier is loaded and instantiated through the reflection mechanism as a request mapper and / or response mapper;

[0133] If the custom mapper class identifier is not included, a preset universal mapper class is instantiated, and the obtained mapping rules are passed to the universal mapper class for configuration as a request mapper and / or response mapper. This embodiment provides a strategy for dynamically selecting a mapper implementation to support universality and customization requirements.

[0134] Custom mapper class identifier: This identifier is an optional configuration item in the external configuration that is used to specify the fully qualified name of the custom mapper class that needs to be used for a specific interface. The presence or absence of this identifier determines whether the system will use a generic mapper or a custom mapper. For example, `"custom_mapper_class_name":

[0135] "com.example.CustomAdxRequestMapper"`.

[0136] Loading logic:

[0137] Checking custom mapper class identity: First, the system checks if it exists in the external configuration

[0138] `custom_mapper_class_name` configuration item. If present, it indicates that a custom mapper is required for this interface.

[0139] Reflection instantiation: If `custom_mapper_class_name` exists, the system uses the Java reflection mechanism to load and instantiate the corresponding custom mapper class according to the class name. The reflection mechanism allows classes to be loaded and used dynamically at runtime without hard coding at compile time.

[0140] Generic mapper: If `custom_mapper_class_name` does not exist, the system instantiates a preset generic mapper class. The generic mapper class provides a set of general mapping logic that can handle most common mapping requirements.

[0141] Configuration transfer: Whether it is a custom mapper or a general mapper, the system will pass the mapping rules obtained from the external configuration source to the mapper object for configuration.

[0142] General mappers are usually implemented based on high-performance object mapping frameworks, such as Orika, BeanUtils, etc. These frameworks can be configured to define mapping rules and implement flexible data conversion.

[0143] Custom mappers allow developers to write completely customized mapping logic to handle complex or special mapping requirements. Developers can inherit from common mapper base classes, such as RTBRequestMapper and RTBResponseMapper, and override methods to implement custom logic.

[0144] Through this mechanism, this embodiment can not only meet the general mapping requirements of most interfaces, but also support developers to perform highly customized mapping for specific interfaces, taking into account both versatility and flexibility, effectively improving the efficiency of interface adaptation, reducing maintenance costs, and enhancing the system's adaptability to complex business scenarios.

[0145] In some embodiments, the external configuration source is a Redis database. As an external configuration source, the Redis database has the advantages of high performance, high availability, and support for rich data structures, and can effectively store and manage interface routing information and mapping rules. Redis is an open source memory data structure storage system that can be used as a database, cache, and message middleware. Advantages of Redis: High performance, Redis stores data in memory, with very fast read and write speeds, suitable for storing configuration information that needs to be accessed frequently; High availability, Redis supports multiple high availability solutions such as master-slave replication, Sentinel, and clusters to ensure the reliability and availability of configuration information; Rich data structures, Redis supports multiple data structures such as strings, hash tables, lists, sets, ordered sets, etc., and can flexibly store various types of configuration information. Data storage method: Redis's hash table (Hash) can be used to store the configuration information of each target interface. For example, using the interface identifier (adx_name) as the key, create a Hash key, and the various fields of the Hash key store configuration items such as interface routing information and mapping rules. Redis's string (String) can also be used to store mapping rules in JSON format. Configuration updates: You can use Redis's publish / subscribe (Pub / Sub) functionality to implement real-time configuration updates. When configuration changes occur, a message is published to notify all subscribers. Upon receiving the message, subscribers proactively pull the latest configuration information from Redis. You can also use Redis's watch command and transactions to ensure atomicity of configuration updates.

[0146] By using the Redis database as an external configuration source, this embodiment can achieve efficient storage, dynamic loading, and real-time updates of configuration information, effectively improving the performance, reliability, and flexibility of the system. At the same time, by utilizing the publish-subscribe feature of Redis, real-time notification of configuration changes is achieved.

[0147] In some embodiments, the original request data and target response data are formatted in JSON. JSON (JavaScript Object Notation) is a lightweight data exchange format that is easy for humans to read and write, as well as for machines to parse and generate. In this embodiment, using JSON as the format for the original request data and target response data facilitates interaction with various web services and APIs, offering excellent versatility and cross-platform compatibility. The JSON format is based on a key-value pair structure and can represent simple data types such as strings, numbers, and Booleans, as well as complex data types such as objects and arrays. The original request data is received in JSON format and, after a mapping operation, is converted into first business entity data within the system. The second business entity data is then processed and converted into target response data in JSON format and returned to the requester. While this embodiment prefers JSON as the data format, other extensible markup languages such as XML may be used in other embodiments without affecting the implementation of the present invention. By limiting the original request data and target response data to JSON format, the present invention's method can be easily integrated with various JSON-based web services and APIs, improving the system's compatibility and applicability.

[0148] In some embodiments, the method is applied to the interface data mapping between the demand-side platform (DSP) and the advertising exchange (ADX) in a real-time bidding (RTB) system. In an embodiment of the present invention, real-time bidding (RTB) is a programmatic advertising purchase method. In the RTB system, the impression of an advertisement is auctioned in real time on the advertising exchange (ADX). The demand-side platform (DSP) participates in the bidding on behalf of the advertiser and bids for each impression according to preset strategies and algorithms. The interface data mapping between the demand-side platform (DSP) and the advertising exchange (ADX) requires the DSP to interact with multiple ADXs, including: the DSP sends a bidding request to the ADX, which includes user information, device information, ad space information, etc.; the ADX returns the bidding results, including the winning ad creative, bid, etc.

[0149] Since different ADXs use different interface specifications and data formats, the DSP needs to perform interface adaptation for each ADX, that is, perform operations such as data mapping, value conversion, and format adaptation. Traditional interface adaptation methods have problems such as high development cost, low efficiency, and poor flexibility. The application of the method of the embodiment of the present invention stores the interface routing information and mapping rules of the ADX in an external configuration source (such as a Redis database). The method of the present invention is used to dynamically register the HTTP path of the ADX interface, and according to the mapping rules of the external configuration, the business data model inside the DSP is converted and adapted to the interface contract defined by the ADX. By dynamically loading and hot updating configuration information, a rapid response to the ADX interface is achieved without the need for code modification and redeployment. Applying the method of the present invention in the RTB system can significantly reduce the development and maintenance costs of the DSP docking with different ADXs, improve the system's response speed to ADX interface changes and overall flexibility and scalability, and improve the competitiveness of the DSP in the RTB environment, thereby bringing better delivery effects to advertisers.

[0150] like Figure 2 As shown, the present invention provides a dynamic interface contract mapping system based on external configuration. The system decouples the various links of interface contract mapping through modular design and drives the entire mapping process through external configuration. The steps for implementing the above-mentioned dynamic interface contract mapping method based on external configuration specifically include:

[0151] Configuration acquisition module M100 is responsible for obtaining interface routing information and mapping rules for the target interface from an external configuration source. Configuration acquisition module M100 can periodically poll the external configuration source or subscribe to configuration change notifications to achieve real-time configuration updates. The external configuration source can be a Redis database, a distributed configuration center, or a file system. The acquired mapping rules include request mapping rules and response mapping rules, which are used for converting request data and generating response data, respectively.

[0152] The routing registration module M200 dynamically registers HTTP paths based on the interface routing information obtained by the configuration acquisition module M100 to receive the original request data for the target interface. The routing registration module M200 can leverage the mechanisms provided by web frameworks (such as Spring MVC / WebFlux) to dynamically add these paths to the HTTP routing table. Dynamic registration ensures that the system can flexibly access new interfaces based on configuration without requiring code modifications or redeployment.

[0153] Request processing module M300, upon receiving raw request data via the HTTP path, maps the raw request data into first business entity data based on the request mapping rules corresponding to the target interface obtained by configuration acquisition module M100. Request processing module M300 is responsible for converting request data from the external interface into a data format that can be processed internally by the system.

[0154] The core business logic processing module M400 receives the first business entity data converted by the request processing module M300, performs core business logic processing, and obtains the second business entity data. This module is the core of the entire system and is responsible for implementing specific business functions.

[0155] Response processing module M500 maps the second business entity data output by core business logic processing module M400 into target response data based on the response mapping rules corresponding to the target interface obtained by configuration acquisition module M100, and then outputs the target response data. Response processing module M500 is responsible for converting the system's internal data format into the format required by the external interface so that the result can be returned to the requester.

[0156] In some embodiments, the configuration acquisition module M100 is further configured to:

[0157] Periodically poll interface routing information and mapping rules from external configuration sources;

[0158] When a change in the mapping rules in the external configuration source is detected, a compare-and-swap (CAS) algorithm is used to update the mapping rules cached in the application memory to the changed mapping rules.

[0159] In some embodiments, the request mapping rules include request body path mapping rules and request body additional mapping rules; the request body path mapping rules are used to define the correspondence between the field path in the original request data and the field path of the first business entity data; the request body additional mapping rules are used to define the conversion logic of specific field values in the original request data, and the conversion logic includes enumeration value mapping or data type conversion.

[0160] Through the collaborative work of the above modules, the system of the present invention realizes dynamic interface contract mapping based on external configuration, without the need to write a large amount of code for each external interface, and has high flexibility and scalability, reducing development and maintenance costs.

[0161] An embodiment of the present invention further provides a dynamic interface contract mapping program product based on external configuration. The program product includes computer instructions. When the computer instructions are executed by a processor, the steps of the above-mentioned dynamic interface contract mapping method based on external configuration are implemented.

[0162] The above content is a further detailed description of the present application in conjunction with specific preferred embodiments, and the specific implementation of the present application cannot be considered to be limited to these descriptions. For ordinary technicians in the technical field to which the present application belongs, several simple deductions or substitutions can be made without departing from the concept of the present application, and all of them should be considered to fall within the scope of protection of the present application.

Claims

1. A dynamic interface contract mapping method based on external configuration, characterized in that: The following steps are involved: Obtaining interface routing information of at least one target interface stored in a preset external configuration source and mapping rules associated with the target interface, the mapping rules including a request mapping rule for converting original request data into first business entity data and a response mapping rule for converting second business entity data into target response data; Dynamically register one or more HTTP paths based on the acquired interface routing information, where the HTTP paths are used to receive the original request data for the target interface; When the original request data is received through the dynamically registered HTTP path, performing a first mapping operation on the original request data according to the obtained request mapping rule for the target interface to generate the first business entity data; Submitting the first business entity data to a preset core business logic for processing to obtain the second business entity data; performing a second mapping operation on the second business entity data according to the acquired response mapping rule for the target interface to generate the target response data; The target response data is output.

2. The dynamic interface contract mapping method based on external configuration according to claim 1, characterized in that: The acquiring of interface routing information of at least one target interface stored in a preset external configuration source and a mapping rule associated with the target interface includes: Periodically pulling the interface routing information and the mapping rules from the external configuration source; When it is detected that the version of the mapping rule associated with the target interface in the external configuration source is inconsistent with the version of the corresponding mapping rule cached in the current application memory, the mapping rule cached in the application memory is updated to the mapping rule newly pulled from the external configuration source.

3. The dynamic interface contract mapping method based on external configuration according to claim 1, characterized in that: The request mapping rule includes request body field path mapping information, where the request body field path mapping information defines a correspondence between a source field JSON path in the original request data and a target field path in the first business entity data; The performing of the first mapping operation includes copying the field value specified by the source field JSON path in the original request data to the field specified by the target field path in the first business entity data according to the request body field path mapping information.

4. The dynamic interface contract mapping method based on external configuration according to claim 3, characterized in that: The request mapping rule further includes additional mapping information of the request body; The performing of the first mapping operation further includes performing a preset conversion operation on the field value of a specific source field in the original request data based on the additional mapping information of the request body, wherein the conversion operation is selected from at least one of: enumeration value conversion, data type format conversion, or default value filling.

5. The dynamic interface contract mapping method based on external configuration according to claim 4, characterized in that: The request body additional mapping information includes a list conversion rule for a list-type source field; The step of performing the first mapping operation also includes: when the original request data contains a list-type source field corresponding to the list conversion rule, traversing each source list element in the list-type source field, and extracting one or more sub-field values from each of the source list elements according to the sub-field extraction path defined in the list conversion rule to construct a target list in the first business entity data.

6. The dynamic interface contract mapping method based on external configuration according to claim 1, characterized in that: The response mapping rule includes response body field path mapping information, where the response body field path mapping information defines a correspondence between a source field path in the second business entity data and a target field JSON path in the target response data; The step performs a second mapping operation, including copying the field value specified by the source field path in the second business entity data to the field specified by the target field JSON path in the target response data according to the response body field path mapping information.

7. The dynamic interface contract mapping method based on external configuration according to claim 6, characterized in that: The response mapping rule further includes additional mapping information of the response body; The performing of the second mapping operation further includes performing a preset conversion operation on the field value of a specific source field in the second business entity data according to the additional mapping information of the response body, or setting a predefined default value for a specific target field in the target response data.

8. The dynamic interface contract mapping method based on external configuration according to claim 1, characterized in that: Before performing the first mapping operation, the following steps are further included: Dynamically instantiate one or more mapper objects according to the configuration information for the target interface obtained from the external configuration source, the mapper objects including a request mapper for performing the first mapping operation and a response mapper for performing the second mapping operation; performing the first mapping operation by the instantiated request mapper; The second mapping operation is performed by the instantiated response mapper.

9. A dynamic interface contract mapping system based on external configuration, characterized in that: include: A configuration acquisition module, configured to acquire interface routing information and mapping rules of at least one target interface stored in an external configuration source, wherein the mapping rules include request mapping rules and response mapping rules; A routing registration module, configured to dynamically register an HTTP path for receiving original request data for the target interface according to the interface routing information; a request processing module, configured to, upon receiving the original request data transmitted through the HTTP path, map the original request data into first business entity data according to the request mapping rule corresponding to the target interface obtained by the configuration obtaining module; a core business logic processing module, configured to receive and process the first business entity data to obtain second business entity data; The response processing module is used to convert the second business entity data into target response data according to the response mapping rule corresponding to the target interface obtained by the configuration acquisition module, and output the target response data.

10. A dynamic interface contract mapping program product based on external configuration, characterized in that: The program product includes computer instructions, which, when executed by a processor, implement the steps of the external configuration-based dynamic interface contract mapping method according to any one of claims 1 to 8.

Images