Method for invoking data heterogeneous adaptation tools based on policy optimization

Abstract

This invention relates to the field of strategy optimization technology, specifically disclosing a method for calling a data heterogeneous adaptation tool based on strategy optimization. The method includes the following steps: constructing a three-layer architecture; a unified interface layer receiving standardized requests containing target identifiers; the adaptation engine routing to the plugin, converting the protocol and declaratively mapping fields; adding authentication information based on preset authentication; the access layer sending requests and receiving results; normalizing the results and returning them to the agent; caching and reusing the token and performing timeout retries. This invention centralizes protocol conversion, data mapping, and authentication to the adaptation engine layer, allowing agents to call uniformly without needing to worry about underlying differences; the plug-in design supports hot-swappable expansion, reducing integration costs; and the introduction of local token caching avoids duplicate acquisition and rate limiting risks. Combined with timeout monitoring and automatic retry mechanisms, the counter is reset to zero after a successful call or timeout, improving cross-system call efficiency and risk resistance.

Description

Technical Field

[0001] This invention relates to the field of strategy optimization technology, and more specifically to a method for calling data heterogeneous adaptation tools based on strategy optimization. Background Technology

[0002] With the digital transformation of enterprises, multiple heterogeneous business systems such as CRM, ERP, OA, and MES often coexist and require frequent collaborative interaction. However, existing system integration faces multiple technical challenges: inconsistent interface protocols, with RESTful, SOAP, RPC, and direct database connections coexisting, preventing direct communication between systems; heterogeneous data structures, with varying field names, data types, and formatting rules, such as requiring extensive manual mapping between "customer_id" in CRM and "cust_no" in ERP; agent calling logic heavily dependent on specific systems, unable to be reused across systems, requiring repeated development of adaptation code during expansion, resulting in high maintenance costs; point-to-point integration leads to a surge in connection links when adding new systems, resulting in extremely poor scalability; and decentralized authentication methods pose significant security risks. Existing simple gateways only perform routing and forwarding, failing to address protocol conversion and data heterogeneity; while customized integration can achieve connection, its reusability is weak. Therefore, a cross-system tool calling adaptation solution is urgently needed to address the pain point of the inability of agents to make unified calls. Summary of the Invention

[0003] The purpose of this invention is to provide a method for calling data heterogeneous adaptation tools based on strategy optimization, thereby solving the above-mentioned technical problems.

[0004] The objective of this invention can be achieved through the following technical solutions: The method for invoking data heterogeneity adaptation tools based on strategy optimization includes the following steps: A three-layer abstract architecture is constructed, which includes a unified interface layer, an adaptation engine layer, and a system access layer. The unified interface layer receives standardized tool call requests sent by intelligent agents. The standardized tool call requests include target system identifier, tool identifier, and standardized call parameters. The adaptation engine layer routes to the corresponding access plugin based on the target system identifier and performs the following steps: a. Convert standardized tool call requests into native interface requests for the target business system; b. Pre-set declarative field mapping rules to convert standardized call parameters into native call parameters supported by the target business system. The declarative field mapping rules define field name mappings in the form of a configuration table. c. Perform identity authentication based on pre-set authentication information and add the authentication information to the native interface request; The system access layer sends the native interface request to the target business system and receives the returned native interface result; the adaptation engine layer processes the native interface result according to a preset unified standard format, records the processed result as a standardized return result, transmits the standardized return result to the unified interface layer, and sends it back to the intelligent agent by the unified interface layer.

[0005] As a further aspect of the present invention: the authentication information includes a Token, and when the adaptation engine layer performs Token authentication, the following steps are executed: A cache validity period is preset. If the storage time of the token is greater than the preset cache validity period, it is recorded as an expired token; if the storage time of the token is less than or equal to the preset cache validity period, it is recorded as an unexpired token. Query the local cache for the token corresponding to the target business system. If an expired token exists, reuse it directly. If an expired token exists, send an authentication request to the token acquisition address of the target business system to obtain a new token and store it in the local cache. Repeat the above operation to set the cache validity period for the new token.

[0006] As a further aspect of the present invention: the declarative field mapping rule specifically includes: The target system identifiers are categorized according to the target system. When the adaptation engine layer is called, it loads the mapping rules of the corresponding target business system and performs field renaming, data type conversion, and time format conversion of the input and output parameters.

[0007] As a further aspect of the present invention: when a new unregistered target business system appears, a corresponding access plugin is developed and registered for the new target business system, and the authentication information and declarative field mapping rules of the new target business system are configured.

[0008] As a further aspect of the present invention: when the adaptation engine layer routes to the corresponding access plugin according to the target system identifier, a timer is started, and the time from the start of the timer to the receipt of the native interface returned by the target business system is recorded as the call duration t. If the call duration t≥T, the interface call is determined to have timed out. When the interface call times out, a standard timeout exception response is generated, which includes the error type code timeout. The standard timeout exception response is returned to the intelligent agent.

[0009] As a further aspect of the present invention: when the standard timeout exception response is returned to the agent, the value of the agent's built-in counter is incremented by one, and the standardized tool call request is resent. The interface call timeout is checked again. When the current value of the counter is greater than or equal to the preset exception response threshold, the call is stopped, and the interface call timeout information is returned to the upper layer application.

[0010] As a further aspect of the present invention: when the agent receives a standard timeout exception response or a standardized return result, the value of the counter is set to zero.

[0011] As a further aspect of the present invention, the native interface request is ensured to include at least one of the following protocols: RESTful, SOAP, RPC, and database access protocols.

[0012] The beneficial effects of this invention are as follows: (1) The adaptation logic, such as protocol conversion, data mapping, and authentication, is centralized in the adaptation engine layer. The intelligent agent only needs to initiate the call according to the unified standard and does not need to care about the protocol differences and field differences of the underlying heterogeneous systems. At the same time, the plug-in design is adopted. When adding a new business system, only the corresponding plug-in needs to be developed and the mapping rules need to be configured. There is no need to modify the core code of the engine, which realizes hot-swappable expansion. Compared with the point-to-point integration or customized development method in the prior art, it reduces the amount of repetitive coding work, reduces the development and maintenance costs of enterprise multi-system integration, and improves the versatility of the intelligent agent.

[0013] (2) A local token caching mechanism is introduced to automatically determine whether to reuse or refresh the token based on its validity period, avoiding the need for the agent to repeatedly obtain the token for each call, reducing network overhead and mitigating the risk of system rate limiting. At the same time, combined with interface call timeout monitoring, built-in counters and automatic retry strategies, the agent automatically retryes when a timeout occurs, stops and reports after consecutive timeouts reach a threshold, and the counter is reset to zero after a successful call or a timeout response is received, thus improving the response efficiency of cross-system calls. Attached Figure Description

[0014] The invention will now be further described with reference to the accompanying drawings.

[0015] Figure 1 This is a schematic diagram of the data heterogeneity adaptation tool invocation method based on strategy optimization of the present invention; Figure 2 This is a flowchart illustrating the data heterogeneity adaptation tool invocation method based on strategy optimization according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Please see Figure 1 As shown, this invention is a method for invoking data heterogeneous adaptation tools based on strategy optimization, including the following steps: A three-layer abstract architecture is constructed, which includes a unified interface layer, an adaptation engine layer, and a system access layer. The unified interface layer receives standardized tool call requests sent by intelligent agents. The standardized tool call requests include target system identifier, tool identifier, and standardized call parameters. The adaptation engine layer routes to the corresponding access plugin based on the target system identifier and performs the following steps: a. Convert standardized tool call requests into native interface requests for the target business system; b. Pre-set declarative field mapping rules to convert standardized call parameters into native call parameters supported by the target business system. The declarative field mapping rules define field name mappings in the form of a configuration table. c. Perform identity authentication based on pre-set authentication information and add the authentication information to the native interface request; The system access layer sends the native interface request to the target business system and receives the returned native interface result; the adaptation engine layer processes the native interface result according to a preset unified standard format, records the processed result as a standardized return result, transmits the standardized return result to the unified interface layer, and sends it back to the intelligent agent by the unified interface layer.

[0018] It's important to note that the unified interface layer, acting as the interaction point between the intelligent agent and the adaptation system, receives standardized tool invocation requests from the intelligent agent. This request uses a unified JSON format and contains at least three core fields: the target system identifier (system_id), used to distinguish different business systems such as CRM or ERP; the tool identifier (tool_name), specifying the specific function to be invoked, such as customer query; and standardized invocation parameters (params), business data organized in key-value pairs. Upon receiving the request, the unified interface layer first performs a validity check, including verifying the existence of the target system identifier, whether the tool identifier is registered in the mapping table, and whether the invocation parameters are complete and correctly formatted. After successful verification, the request is forwarded to the adaptation engine layer.

[0019] The adaptation engine layer is the central hub of the entire solution, responsible for routing to the corresponding access plugin based on the target system identifier. Each access plugin is pre-registered and loaded through the plugin management module, encapsulating the protocol type, authentication configuration, and mapping rules for the corresponding target system. After successful routing, the adaptation engine layer executes the following three core steps in sequence: Step a: The adaptation engine layer reads the pre-configured protocol types in the access plugin and converts standardized tool call requests into native interface requests supported by the target business system. For example, for the RESTful interface, the request is converted into HTTP GET / POST format, and the parameters are appended to the URL or placed in the request body; for the SOAP interface, a SOAP envelope message conforming to the WSDL specification is generated.

[0020] Step b: Pre-configure declarative field mapping rules, defining field name mappings, data type conversions, and time format conversions in the form of a configuration table. These mapping rules are stored in the database, categorized by target system identifiers. The adaptation engine layer dynamically loads the corresponding system's mapping rules during invocation, automatically converting standardized call parameters into native call parameters supported by the target business system. For example, the standard field `customer_id` (string) can be mapped to the CRM system's `cust_id` string or the ERP system's `customer_no` value; the timestamp format is automatically converted to `yyyy-MM-ddHH:mm:ss`. The entire conversion process requires no conversion code and is entirely configuration-driven.

[0021] Step c: The adaptation engine layer performs identity authentication based on pre-set authentication information. Authentication methods include token authentication, key signature authentication, or account password authentication. Taking token authentication as an example, the system first checks if there is an expired token corresponding to the target system in the local cache. If it exists, it is reused directly; if it does not exist or has expired, an authentication request is sent to the token acquisition address of the target system to obtain a new token and store it in the local cache, while setting the cache validity period. After authentication is completed, the authentication information is added to the native interface request.

[0022] The system access layer sends the processed native interface request to the target business system and receives the returned native interface result. The adaptation engine layer normalizes the native interface result according to a preset unified standard format, including field remapping, data type conversion, and structural unification, generating a standardized return result. Finally, the standardized return result is transmitted to the unified interface layer, which sends it back to the agent, completing a cross-system tool call.

[0023] In another preferred embodiment of the present invention, the authentication information includes a token, and the following steps are performed when the adaptation engine layer performs token authentication: A cache validity period is preset. If the storage time of the token is greater than the preset cache validity period, it is recorded as an expired token; if the storage time of the token is less than or equal to the preset cache validity period, it is recorded as an unexpired token. Query the local cache for the token corresponding to the target business system. If an expired token exists, reuse it directly. If an expired token exists, send an authentication request to the token acquisition address of the target business system to obtain a new token and store it in the local cache. Repeat the above operation to set the cache validity period for the new token.

[0024] It's worth noting that, firstly, a cache expiration parameter is configured independently for each target business system. The token and its corresponding retrieval timestamp are stored in the local cache, isolated by system identifier. The adaptation engine layer compares the token's storage time with the cache expiration time. If the current time minus the retrieval timestamp is greater than the cache expiration time, it is marked as an expired token; otherwise, it is marked as a valid token.

[0025] Before each call, the adaptation engine layer queries its local cache based on the target system identifier. If an expired token exists, it is reused directly and added to the authentication header of the native interface request without additional network overhead. If an expired token exists in the cache, or if no token is available for the first call, the adaptation engine layer obtains the address, username, and password based on the pre-configured token and sends a request to the authentication interface of the target business system to obtain a new token. To prevent the same system from repeatedly obtaining tokens due to concurrent calls within a short period, when multiple requests simultaneously discover that a token has expired, only the first request performs the token acquisition operation; the remaining requests wait for the lock to be released and then reuse the newly acquired token.

[0026] In another preferred embodiment of the present invention, the declarative field mapping rule specifically includes: The target system identifiers are categorized according to the target system. When the adaptation engine layer is called, it loads the mapping rules of the corresponding target business system and performs field renaming, data type conversion, and time format conversion of the input and output parameters.

[0027] Understandably, target system identifiers are categorized according to target business systems, and independent input parameter mapping tables and output parameter mapping tables are maintained for each system category. These mapping tables are stored in JSON or database record format. The adaptation engine layer dynamically loads the mapping rules corresponding to the target business system during invocation, performing field renaming, data type conversion, and time format conversion for input and output parameters.

[0028] The input parameter mapping table defines the mapping relationship between each field in the standardized call parameters and the corresponding field in the native call parameters of the target system. For example, the standard field `customer_id` can be mapped to `cust_id` in the CRM system or `customer_no` in the ERP system. Data type conversion supports automatic conversion between strings and integers, floating-point numbers, and boolean values. Time format conversion supports bidirectional conversion between Unix timestamps and date string formats such as "yyyy-MM-ddHH:mm:ss". The output parameter mapping table defines the reverse conversion rules, mapping the native fields returned by the target system back to the standardized fields and performing the corresponding data type inverse conversion and time format normalization. The adaptation engine layer automatically generates conversion code by reading the mapping rules, eliminating the need for manual conversion logic writing and supporting field mapping for nested objects and array paths. When the interface fields of the target business system change, only the corresponding mapping configuration table needs to be modified, without modifying the intelligent agent code, reducing maintenance costs.

[0029] In another preferred embodiment of the present invention, when a new unregistered target business system appears, a corresponding access plugin is developed and registered for the new target business system, and the authentication information and declarative field mapping rules of the new target business system are configured.

[0030] It's important to note that when a new, unregistered target business system appears, there's no need to modify the core code of the adaptation engine; only extensions are needed through the plugin management module. Develop an access plugin based on the new system's interface protocol type. This plugin must include a protocol adapter, a data converter, and an exception handler. The protocol adapter is responsible for converting standardized requests into native request formats; the data converter uses declarative field mapping rules to complete parameter conversion; and the exception handler encapsulates system errors into standardized exception responses.

[0031] After plugin development is complete, upload the JAR package via the web configuration interface, fill in the system name and version number, and configure authentication information and corresponding parameters. Simultaneously configure declarative field mapping rules, defining field name mappings, data type conversions, and time format conversions. After registration, the plugin management module automatically loads and activates the plugin. Without restarting the adaptation system, the intelligent agent can call the new system interface through a unified standard, achieving hot-swappable integration.

[0032] In another preferred embodiment of the present invention, when the adaptation engine layer routes to the corresponding access plug-in according to the target system identifier, a timer is started, and the time from the start of the timer to the receipt of the native interface returned by the target business system is recorded as the call duration t. If the call duration t≥T, the interface call is determined to have timed out. When the interface call times out, a standard timeout exception response is generated, which includes the error type code timeout. The standard timeout exception response is returned to the intelligent agent.

[0033] It should be noted that once the adaptation engine layer successfully routes to the corresponding access plugin based on the target system identifier, a timer is started immediately. This timer covers the entire process from this moment until the adaptation engine layer receives the native interface result returned by the target business system, including the time consumed by all stages such as protocol conversion, data mapping, unified authentication, network transmission, and the target system's own processing. The total duration of this process is denoted as the call duration t.

[0034] For each target business system, a timeout threshold T can be pre-configured individually. During the call, the adaptation engine layer compares the thresholds in real time. If t < T, processing continues normally; if t ≥ T, the API call is deemed to have timed out. Once a timeout is determined, the adaptation engine layer immediately terminates the current request to avoid blocking system threads for an extended period.

[0035] Subsequently, the adaptation engine layer generates a standard timeout exception response, which includes at least the request ID, status code, error message, and error type code "timeout". This standardized response is returned to the agent through a unified interface layer. The agent does not need to parse the timeout error formats returned by different systems and can directly execute unified timeout handling logic based on the timeout code. At the same time, the adaptation engine layer records a timeout log, including the request ID, target system identifier, actual time elapsed (t), and configured threshold (T). This mechanism prevents the overall call chain from being blocked due to slow responses from individual systems.

[0036] In another preferred embodiment of the present invention, when the standard timeout exception response is returned to the agent, the value of the agent's built-in counter is incremented by one, and the standardized tool call request is resent. The interface call timeout is checked again. When the current value of the counter is greater than or equal to the preset exception response threshold, the call is stopped, and the interface call timeout information is returned to the upper layer application.

[0037] Understandably, when the agent receives a standard timeout exception response from the adaptation engine layer, it reads the current value of its internally maintained counter, increments it by one, and then resends a standardized tool call request that is exactly the same as the original request. After receiving the retry request, the adaptation engine layer will re-execute the complete routing, protocol conversion, data mapping, authentication, and interface call process, and re-determine the timeout.

[0038] In another preferred embodiment of the present invention, when the agent receives a standard timeout exception response or a standardized return result, the value of the counter is set to zero.

[0039] It's worth noting that when the agent receives a standard timeout exception response from the adaptation engine layer, this response indicates that the call failed due to a timeout, but the agent has already triggered a retry mechanism and the counter has been incremented. However, in a complete call lifecycle, the agent also needs to handle state reset after the call succeeds or the timeout response is finally received. Therefore, when the agent receives any standardized return result, it immediately sets the current counter value to zero, indicating that the call has been successfully completed and no retry count needs to be retained. Simultaneously, when the agent receives a standard timeout exception response, if it decides not to retry based on a preset threshold, it also sets the counter to zero after returning the final timeout information to the upper-layer application, providing an initial state for subsequent call requests to the same or different target systems. If the agent succeeds in a retry process, the counter is immediately cleared upon receiving the successful response, and any subsequent unfinished retry tasks will be ignored. Through this zeroing strategy, the agent avoids the infinite accumulation of the counter value, ensuring that each independent call request starts counting from zero, thereby controlling the number of retries and preventing new requests from being prematurely terminated due to historical residual counts.

[0040] In another preferred embodiment of the present invention, it is ensured that the native interface request includes at least one of the following protocols: RESTful, SOAP, RPC, and database access protocols.

[0041] It's worth noting that the native API requests support multiple mainstream protocols such as RESTful, SOAP, RPC, and database access, ensuring compatibility with the interface standards of various heterogeneous systems. This allows the adaptation engine to directly interface with business systems using different protocols without needing to develop additional protocol conversion logic, improving the versatility of cross-system calls.

[0042] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the present invention should still fall within the scope of the present invention.

Claims

1. A method for invoking data heterogeneous adaptation tools based on strategy optimization, characterized in that: Includes the following steps: A three-layer abstract architecture is constructed, which includes a unified interface layer, an adaptation engine layer, and a system access layer. The unified interface layer receives standardized tool call requests sent by intelligent agents. The standardized tool call requests include target system identifier, tool identifier, and standardized call parameters. The adaptation engine layer routes to the corresponding access plugin based on the target system identifier and performs the following steps: a. Convert standardized tool call requests into native interface requests for the target business system; b. Pre-set declarative field mapping rules to convert standardized call parameters into native call parameters supported by the target business system. The declarative field mapping rules define field name mappings in the form of a configuration table. c. Perform identity authentication based on pre-set authentication information and add the authentication information to the native interface request; The system access layer sends the native interface request to the target business system and receives the returned native interface result; the adaptation engine layer processes the native interface result according to a preset unified standard format, records the processed result as a standardized return result, transmits the standardized return result to the unified interface layer, and sends it back to the intelligent agent by the unified interface layer.

2. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 1, characterized in that, The authentication information includes a token. When the adaptation engine layer performs token authentication, the following steps are executed: A cache validity period is preset. If the storage time of the token is greater than the preset cache validity period, it is recorded as an expired token; if the storage time of the token is less than or equal to the preset cache validity period, it is recorded as an unexpired token. Query the local cache for the token corresponding to the target business system. If an expired token exists, reuse it directly. If an expired token exists, send an authentication request to the token acquisition address of the target business system to obtain a new token and store it in the local cache. Repeat the above operation to set the cache validity period for the new token.

3. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 1, characterized in that, The declarative field mapping rules specifically include: The target system identifiers are categorized according to the target system. When the adaptation engine layer is called, it loads the mapping rules of the corresponding target business system and performs field renaming, data type conversion, and time format conversion of the input and output parameters.

4. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 1, characterized in that, When a new unregistered target business system appears, develop and register the corresponding access plugin for the new target business system, and configure the authentication information and declarative field mapping rules for the new target business system.

5. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 1, characterized in that, When the adaptation engine layer routes to the corresponding access plugin based on the target system identifier, a timer is started. The time from the start of the timer to the receipt of the native interface returned by the target business system is recorded as the call duration t. If the call duration t≥T, the interface call is determined to have timed out. When the interface call times out, a standard timeout exception response is generated, which includes the error type code timeout. The standard timeout exception response is returned to the agent.

6. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 5, characterized in that, When a standard timeout exception response is returned to the agent, the value of the agent's built-in counter is incremented by one, and the standardized tool call request is resent. The interface call timeout is checked again. When the current value of the counter is greater than or equal to the preset exception response threshold, the call is stopped, and the interface call timeout information is returned to the upper layer application.

7. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 6, characterized in that, When the agent receives a standard timeout exception response or a standardized return result, the counter value is set to zero.

8. The method for invoking data heterogeneous adaptation tools based on strategy optimization according to claim 1, characterized in that, Ensure that the native interface requests include at least one of the following protocols: RESTful, SOAP, RPC, and database access.

Images