Heterogeneous service system integration method and device based on large model, terminal and medium

Abstract

The invention relates to the technical field of artificial intelligence and software engineering crossing, and particularly provides a heterogeneous business system integration method and device based on a large model, a terminal and a medium, and the method comprises the steps: constructing an interface semantic index fusing a code structure and natural language description; receiving a natural language instruction and generating a task execution graph with a dependency relationship based on the semantic index; the task graph is rehearsed in the isolation sandbox, the read operation calls a real system to obtain data, and the write operation generates simulation data through a large model; performing logic and compliance dual verification on the rehearsal logs by using the large model; and after verification is passed, real calling is executed, compensation operation is generated for each step, and automatic rollback is carried out through a rollback stack mechanism during failure so as to guarantee transaction consistency. According to the method, the tolerance of interface change is improved, the data security risk is remarkably reduced through rehearsal and verification mechanisms, and the transaction-level guarantee of cross-system operation is realized.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of artificial intelligence and software engineering, and specifically relates to a method, device, terminal and medium for integrating heterogeneous business systems based on a large model. Background Technology

[0002] As enterprises deepen their digital transformation, business systems are becoming increasingly complex and heterogeneous. How to efficiently and reliably automate the integration and orchestration of cross-system business processes has become a core challenge in software engineering and operations. Traditional integration methods heavily rely on customized code and static configuration, resulting in inherent drawbacks such as long development cycles, high maintenance costs, and poor flexibility.

[0003] In recent years, the groundbreaking development of large language models, especially their superior code generation and natural language understanding capabilities, has provided a new paradigm for automated system integration. LLM-based agents can understand users' high-level business intentions and attempt to complete tasks by calling external tools (such as application programming interfaces). Under this trend, frameworks such as LangChain and AutoGPT have emerged, aiming to connect large language models with external tools or APIs to achieve a certain degree of automation.

[0004] However, when these technologies derived from general scenarios are directly applied to the integration of complex, heterogeneous enterprise-level systems, existing solutions reveal several key shortcomings:

[0005] First, the API implementation is rigid and lacks robustness. Existing methods typically rely heavily on API description documents with standardized formats such as OpenAPI / Swagger. Once the backend system's API undergoes common iterations such as field name adjustments or parameter structure changes, the call chain based on hard-coded parsing or simple prompt word matching will fail. The lack of understanding of API semantics and adaptive capabilities makes automated processes extremely fragile.

[0006] Secondly, the execution risks are uncontrollable and pose security risks. Large language models are essentially probabilistic generative models, which may generate "illusions" that do not conform to reality or business logic. In high-risk operational scenarios involving data modification and state changes, allowing model-generated instructions to be directly executed on the production system, without strict pre-verification and in-process control, can easily lead to serious consequences such as data pollution and business chaos.

[0007] Finally, there is a lack of cross-system transaction consistency guarantees. Enterprise business processes often involve sequential calls to multiple heterogeneous systems. When such multi-step operations fail at some stage during execution, existing intelligent agent architectures typically struggle to automatically and reliably revert all related system states to their initial consistent state before the operation. In other words, they lack atomicity and consistency guarantees similar to those of database transactions, which hinders their application in critical business scenarios.

[0008] Therefore, existing technologies have failed to effectively address the core challenge of achieving adaptive, secure, reliable, and transaction-guaranteed automated orchestration of interfaces in enterprise heterogeneous system integration scenarios. A new approach that deeply integrates the intelligence of large language models with the rigor of software engineering is urgently needed to overcome these shortcomings. Summary of the Invention

[0009] In view of the above-mentioned shortcomings of the prior art, the present invention provides a method, apparatus, terminal and medium for integrating heterogeneous business systems based on a large model, so as to solve the above-mentioned technical problems.

[0010] In a first aspect, the present invention provides a method for integrating heterogeneous business systems based on a large model, comprising: Obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data; Receive natural language instructions, semantically match the interface semantic index with the natural language instructions, and generate a task execution graph corresponding to the natural language instructions, which includes interface node dependencies; The task execution graph is executed in an isolated environment. For read operation nodes in the task execution graph, the corresponding real business system is called to obtain data. For write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system. The logs generated by the task execution graph in this execution are logically and compliance-wise validated using a large language model. Once the verification is successful, a real call is initiated to the actual business system according to the task execution graph, and a corresponding compensation operation is configured for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to perform a rollback.

[0011] In one optional implementation, interface definition data from at least one heterogeneous business system is obtained. Based on the fusion semantics of the code structure features and natural language description features of the interface definition data, an interface semantic index is constructed, including: Parse the parameter structure information and functional description text information of the interface from the interface definition data; The parameter structure information is input into the code pre-training model for encoding to obtain the code structure feature vector; The functional description text information is input into a text semantic model for encoding to obtain a natural language description feature vector; The code structure feature vector and the natural language description feature vector are weighted and fused to obtain the interface semantic vector, and the interface semantic vector is stored in the vector database to construct the interface semantic index.

[0012] In one optional implementation, the code pre-training model is a neural network model trained on a large-scale code corpus for extracting semantic features of program code; the text semantic model is a neural network model trained on a large-scale text corpus for extracting semantic features of natural language.

[0013] In an optional implementation, a natural language instruction is received, and the interface semantic index is semantically matched with the natural language instruction to generate a task execution graph corresponding to the natural language instruction and containing interface node dependencies, including: In response to the natural language instruction, a set of candidate interfaces that semantically match the natural language instruction is retrieved from the interface semantic index; The candidate interface set and the interface definition data corresponding to the semantic index of each interface in the candidate interface set are input into the large language model. The large language model performs interface reordering and parameter compatibility judgment to determine the final target interface set. Based on the target interface set, the large language model analyzes the calling logic and business risks between the interfaces to generate a structured task execution graph. The task execution graph defines the dependencies between interface nodes and the risk level of each node.

[0014] In an optional implementation, the task execution graph is executed in an isolated environment, including: Maintain an isolated sandbox environment, which is used to store variable states, API response data and logs during execution; When traversing the nodes of the task execution graph, differentiated processing is performed according to the predefined operation rules of the nodes: If it is a read-only operation node, a call is initiated to the corresponding real business system, and the obtained real response data is stored in the sandbox environment after being de-identified, and the data lineage is recorded; If it is a write operation node, the call to the corresponding real business system is intercepted. Based on the interface definition data of the write operation node and the current context in the sandbox, the large language model is used to generate simulated response data and the simulated response data is stored in the sandbox environment.

[0015] In an optional implementation, a large language model is used to perform logical and compliance checks on the logs generated by the task execution graph during this execution, including: Extract key data flow records and operation sequences from the logs during the task execution process; Based on the key data flow records and operation sequences, an execution summary is constructed for analysis of large language models. The execution summary includes at least the parameter transmission link and the operation result status. The execution summary is validated by the large language model. The validation includes: verifying whether the input parameters of the downstream operation node originate from the output results of the upstream operation node; determining whether the operation sequence violates business constraints or security specifications based on preset policy rules; if the validation fails, the large language model generates a correction suggestion and triggers the rearrangement and rehearsal of the task execution graph. The logs are dynamically generated by an isolated sandbox environment. The log content includes at least: the operation type of each node, the input parameters, the returned response data, and the source identifier of the response data, wherein the source identifier is used to indicate that the response data originates from a real business system or a large language model.

[0016] In an optional implementation, a real call is initiated to the real business system according to the task execution graph, and a corresponding compensation operation is configured for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to perform a rollback, including: Before formal execution, generate corresponding, structured compensation operations for each operation to be executed in the task execution graph; The operations to be executed are executed in sequence, and after each operation is successfully executed, its corresponding compensation operation is stored in a first-in-last-out rollback stack. Monitor the execution status. If any operation fails, immediately interrupt the subsequent execution process and start from the top of the rollback stack to sequentially retrieve and perform compensation operations until the system state is restored to the initial state. The compensation operation is a reverse operation instruction used to cancel the business state change generated by the corresponding forward operation; the compensation operation is dynamically generated based on the interface semantics and parameters called by the corresponding forward operation.

[0017] Secondly, the present invention provides a heterogeneous business system integration device based on a large model, comprising: The interface parsing module is used to obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data. The task orchestration module is used to receive natural language instructions, perform semantic matching between the interface semantic index and the natural language instructions, and generate a task execution graph that corresponds to the natural language instructions and contains interface node dependencies. The task pre-simulation module is used to execute the task execution graph in an isolated environment. For read operation nodes in the task execution graph, the corresponding real business system is called to obtain data; for write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system. The pre-execution analysis module is used to perform logical and compliance verification on the logs generated by the task execution graph during this execution using a large language model; The task execution module is used to confirm that the verification is successful, initiate a real call to the real business system according to the task execution graph, and configure corresponding compensation operations for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to roll back.

[0018] Thirdly, a terminal is provided, including: Memory, used to store integration programs for heterogeneous business systems based on large models; A processor for implementing the steps of the method provided in the first aspect when executing the heterogeneous business system integration program based on the large model.

[0019] Fourthly, a computer-readable medium is provided, on which a heterogeneous business system integration program based on a large model is stored, and when the program is executed by a processor, it implements the steps of the heterogeneous business system integration method based on a large model provided in the first aspect.

[0020] The method, apparatus, terminal, and medium for integrating heterogeneous business systems based on a large model provided by this invention bring the following significant benefits: Significantly improves tolerance to interface changes and system robustness: By constructing an interface semantic index that integrates code structure features and natural language descriptions, and performing semantic matching based on this index during task orchestration, this invention achieves fuzzy matching and dynamic parameter mapping for API interfaces. This enables the system to locate and correctly call the target interface based on semantic similarity even when the backend business system's interface undergoes minor adjustments to field names or non-major changes to parameter structures. This overcomes the vulnerability caused by existing solutions' reliance on strict interface definitions, significantly enhancing the adaptability and robustness of the integration process.

[0021] Significantly reducing data security risks caused by the "illusion" of large language models: By introducing a dual security mechanism of virtual sandbox pre-performance and self-reflective verification, this invention constructs a reliable defense for operations involving data modification. All write operations are intercepted in an isolated environment, and shadow execution is performed by the large language model generating simulated responses based on interface definitions, completely avoiding direct contamination of production data by test or erroneous instructions. The logs after the pre-performance are further verified by the large language model for both logic and compliance, further eliminating contradictions and violations in business processes. This mechanism controls execution risks at the pre-performance verification stage, fundamentally reducing the incidence of production data incidents.

[0022] Effectively ensuring transaction consistency for complex operations across heterogeneous systems: By employing transaction-level execution and automatic rollback mechanisms during the execution phase, this invention provides atomicity guarantees for multi-step operations across systems. Before actual execution, the system generates corresponding compensation operations for each forward operation and monitors and maintains the rollback stack through a state machine during execution. If any step fails, the system automatically triggers a predefined sequence of compensation operations, rolling back the relevant system state to its initial state. This ensures the consistency of business states in a distributed operating environment and solves the problem of state chaos in existing Agent architectures during failure handling. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the architecture of a method according to an embodiment of the present invention.

[0026] Figure 3 This is a schematic block diagram of an apparatus according to an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0029] The method provided in this embodiment of the invention is executed by a computer terminal, and correspondingly, the heterogeneous business system integration device based on a large model runs on the computer terminal.

[0030] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1The executing entity can be a heterogeneous business system integration device based on a large model. Depending on different requirements, the order of steps in this flowchart can be changed, and some steps can be omitted.

[0031] like Figure 1 As shown, the method includes: S1. Obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data; S2. Receive natural language instructions, perform semantic matching between the interface semantic index and the natural language instructions, and generate a task execution graph corresponding to the natural language instructions, which includes interface node dependencies; S3. Execute the task execution graph in an isolated environment, wherein for read operation nodes in the task execution graph, the corresponding real business system is called to obtain data; for write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system; S4. Use a large language model to perform logical and compliance checks on the logs generated by the task execution graph in this execution; S5. Confirm that the verification is successful, initiate a real call to the real business system according to the task execution diagram, and configure the corresponding compensation operation for the real call; if a failure occurs during the execution process, execute the corresponding compensation operation to roll back.

[0032] The following is for reference. Figure 2 The steps of the present invention will be described in detail below.

[0033] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0034] S101: Interface Definition Data Parsing From registered heterogeneous business systems, the system collects interface definition data in various formats as input, including but not limited to Swagger / OpenAPI documentation (JSON / YAML format), SQL query statements, database DDL statements, and gRPCProtobuf definition files. For each collected application interface, the system performs a parsing operation to separate and extract two types of key information: Parameter structure information: This includes metadata such as the name of the interface request parameters, data type, nesting structure, and whether they are required.

[0035] Functional description text information: including interface names, comments, usage descriptions, business scenario descriptions, and other natural language text.

[0036] For example, for each API interface, extract the four-tuple feature F={Name,Description,Params,ResponseSchema}.

[0037] S102: Code Structure Feature Vectorization The parameter structure information extracted in step S101 is input into a dedicated neural network model pre-trained on a large-scale code corpus for encoding. This model is specifically designed to understand the syntax and semantics of program code, and may employ, for example, CodeBERT or its variants based on the Transformer architecture. The model transforms the unstructured parameter metadata into a high-dimensional, dense real-number vector, called the code structure feature vector. This vector can characterize the structural commonalities and semantic features of the interface at the parameter level.

[0038] For example, the CodeBERT model is used to encode code features, denoted as... .

[0039] Step S103: Natural Language Description Feature Vectorization The functional description text information extracted in step S101 is input into a text semantic model pre-trained on a large-scale general text corpus for encoding. This model is specifically designed for understanding the semantics of natural language, for example, using Sentence-BERT or a similar dual-encoder model. The model transforms the functional description text into another high-dimensional, dense real-valued vector, called the natural language description feature vector. This vector can represent the semantic information of the interface at the functional intent and business context levels.

[0040] For example, the generic Sentence-BERT model can be used to vectorize API annotations and usage descriptions, denoted as... .

[0041] Step S104: Feature fusion and index storage The code structure feature vector obtained in step S102 is fused with the natural language description feature vector obtained in step S103. In a preferred embodiment, a weighted fusion strategy is adopted, expressed by the formula:

[0042] in, Represents the feature vector of code structure. This represents the feature vector describing the natural language. α is a learnable or pre-set fusion weight coefficient (0 ≤ α ≤ 1) used to adjust the relative importance of the two types of features in the final representation. The resulting vector after fusion. This is the interface semantic vector of the interface.

[0043] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0044] S201: Semantic-driven candidate interface retrieval In response to a user-input natural language command (e.g., "Issue a 10% discount coupon to all VIP users who placed orders last week"), the system first searches the constructed interface semantic index. This process is achieved by calculating the similarity (e.g., cosine similarity) between the semantic vector of the command and the semantic vectors of all interfaces in the index. The system selects the top K interfaces with the highest similarity to form an initial candidate interface set.

[0045] In a preferred embodiment, the retrieval process may further employ a "multi-granularity semantic routing" mechanism: first, a coarse screening is performed based on domain keywords (such as "user" and "coupon") in the instruction; second, a secondary filtering is performed based on action verbs (such as "query" and "issue"); and finally, fine-tuning is performed by combining specific parameter constraints (such as "last week" and "VIP"), thereby improving the accuracy and efficiency of the retrieval. The specific process includes: First, coarse-grained routing based on business domain classification is performed. Core business entities or domain keywords (such as "user," "order," and "payment") are extracted from user natural language commands and then mapped to a pre-built business domain classification system. Each interface has been associated with a corresponding domain tag during the index building phase. Interfaces whose domain tags match the command keywords in the interface semantic index are initially filtered out, forming a broad-coverage "coarse-screened candidate set" to ensure that no potentially relevant business modules are missed.

[0046] Next, based on the coarse-screened candidate set, medium-granularity filtering is performed based on operation type. The core action verbs in the instructions (such as "query," "create," and "delete") are parsed and converted into standard operation types (such as GET and POST) using predefined mapping rules or a lightweight prediction model. Then, interfaces in the coarse-screened candidate set whose operation types, such as HTTP methods, do not match the instruction intent are filtered out. For example, for the instruction "query user," interfaces with the GET method are primarily retained. This step produces a more focused "medium-filtered candidate set" based on the operation intent.

[0047] Building upon this foundation, a fine-grained alignment based on parameter constraints is finally performed. Specific parameterized constraints (such as "last week" for time and "VIP" for status) are deeply parsed from the instructions and structured into explicit query expressions. Simultaneously, the parameter definitions of each interface in the candidate set are analyzed, including parameter names, data types, and value specifications. By determining whether the interface's parameter structure can accommodate or express the constraints in the instructions, a precise compatibility assessment and final ranking of the candidate interfaces are performed, with interfaces exhibiting higher parameter compatibility ranking higher. This results in a high-quality initial set of candidate interfaces sorted by overall matching degree.

[0048] S202: Intelligent Filtering and Determination Based on Large Language Models The initial candidate interface set obtained in step S201, along with the complete interface definition data associated with the vector index (i.e., the parameter structure and functional description parsed in step S101), is input into a large language model (such as GPT-4, Claude, etc.). The large language model acts as an "integration architect," performing the following core analyses: Interface reordering: Read through the complete documentation of each candidate interface, and re-evaluate and reorder the relevance of each interface based on a deep understanding of the user's intent.

[0049] Parameter compatibility assessment: Analyze the implicit or explicit parameter requirements in the command (such as the time range "last week" or the user level "VIP") and compare them with the request parameter structure of the candidate interfaces, automatically eliminating those interfaces whose parameters are incompatible or cannot meet the command constraints.

[0050] After completing the above analysis, the large language model outputs a refined and defined set of target interfaces. Each interface in this set is determined to both satisfy the business intent and be executable at the parameter level.

[0051] S203: Generation of Structured Task Execution Graph Based on the defined set of target interfaces, the system again invokes the large language model for in-depth analysis and structured orchestration. The large language model requires: Analyze the call logic and data dependencies: Infer and determine the execution order and data flow relationships between these interfaces. For example, the "User Order Query Interface" must be called first to obtain the user list before it can be passed as input to the "Coupon Issuance Interface".

[0052] Assess and label business risks: Based on whether the operation reads, modifies, or deletes critical business data, assign a risk level to each interface node. In a specific embodiment, the risk levels are divided into: 0 - read-only, 1 - reversible write operation (such as updating a recoverable state), and 2 - high-risk irreversible operation (such as deleting core data).

[0053] Finally, the large language model generates a structured task execution graph. This graph is a directed acyclic graph, where each node represents a target interface to be executed, and node attributes include interface identifier, parameter mapping rules, and risk level; directed edges define the execution dependencies between nodes.

[0054] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0055] Sandbox Environment Initialization and State Management: A temporary, logically isolated sandbox container is created in memory. This container acts as a lightweight virtual execution environment, its core function being to maintain a complete state snapshot during the pre-run. Internally, it maintains a structured state storage space for persisting the following key data: Global Context: A key-value pair store used to record all variables and intermediate data generated and flowing during the rehearsal process.

[0056] API Response Pool: A dedicated area for storing the return results of all API calls, whether they are obtained from a real system or generated by a model.

[0057] Execution Log: A time-series record of events, detailing the operation type, input parameters, return results, and data source for each node.

[0058] Data lineage map: used to track the derivative relationships between data, clearly identifying which output from which upstream node the data used by downstream nodes comes from.

[0059] Provide the sandbox container with a snapshot function to save the complete state at critical nodes, so as to support rollback to any checkpoint.

[0060] Risk-based intelligent request routing: When traversing each node of the task execution graph (DAG), the execution strategy is determined by an intelligent request routing module based on the preset operational risk level of that node.

[0061] Routing decision: This module reads the risk level attribute of the node. If it is level 0 (read-only), it is routed to the actual caller; if it is level 1 (reversible write operation) or level 2 (high-risk operation), it is routed to the simulation processor during the pre-rehearsal phase, regardless of whether it is reversible.

[0062] Read operation real context acquisition and security injection: For routed read-only operation nodes, the system executes a secure real call to obtain the necessary business context, as follows: Parameter preprocessing: Extract and validate parameters from the sandbox context according to the node's input mapping rules, and perform type conversion if necessary.

[0063] Protected legitimate calls: These are calls (such as HTTP GET requests) initiated to the corresponding real business system through a secure client equipped with circuit breaker, timeout, and retry mechanisms. These calls are solely for retrieving data and have absolutely no side effects.

[0064] Response processing and desensitization: After receiving a genuine response, the system processes sensitive fields according to predefined data desensitization rules (such as masking phone numbers and generalizing addresses), and writes the standardized and desensitized data into the "API response pool" in the sandbox.

[0065] Record data lineage: The system creates a record in the "Data Lineage Mapping" that indicates the output data of this node ID, and its source is "real system call".

[0066] Intelligent simulation generation of write operations: For routed write operation nodes, the system strictly intercepts any requests sent to the real system and instead activates the intelligent simulation generation engine to create highly realistic response data. The process is as follows: Constructing a simulation context: The engine integrates three aspects of information: ① the complete interface definition (request / response schema) of the current write operation node; ② the parameters that the node plans to pass in; ③ the real business data already in the sandbox obtained by the upstream read operation.

[0067] Multi-expert simulation driven by a large language model: The aforementioned context is submitted to a large language model, and a "multi-expert collaboration" mode can be selected. For example, a "data expert" model focused on data patterns is scheduled to generate numerical values ​​that conform to the schema; a "business rule expert" model that understands business processes is invoked to ensure that state changes are reasonable; and a "consistency expert" model is consulted to verify that there are no contradictions with the existing context. Finally, the outputs of multiple models are conflict-resolved and merged. This mechanism aims to simulate a review committee composed of experts from different domains, who, through division of labor, collaboration, and collective decision-making, jointly synthesize high-quality simulation data. Its core operation process is as follows: (1) Definition of expert role and division of tasks The single simulation generation task is broken down into multiple specialized sub-tasks, and each sub-task is configured with a targeted "expert" large language model instance (which can be a fine-tuned version of the same base model with different prompt words, or a different specialized model). The main expert roles include: Data schema expert: Its core responsibility is to ensure that the generated mock data strictly adheres to the response schema definition of the target interface. It focuses on understanding JSON Schema, Protobuf message structure, or database table structure, and generating fully compliant mock data in terms of data type, field format, and nesting relationships. For example, for the "Create Order" interface, it can generate a correctly formatted response body containing fields such as orderId (string) and amount (numeric).

[0068] Business rules experts are primarily responsible for ensuring that the changes in business status reflected in simulated data conform to real business logic and processes. Based on knowledge of the business domain, they determine the preconditions, postconditions, and business constraints of an operation. For example, for the "issue coupons" operation, it ensures that the coupon status, validity period, and usage rules in the generated simulated response match the user level and activity rules, preventing logical errors such as "issuing VIP-only coupons to non-VIP users."

[0069] Consistency experts are responsible for verifying that simulated operations maintain continuity and consistency with the historical state of the existing context within the sandbox. They trace data lineage to ensure that newly generated simulated data is logically consistent with the real or simulated data generated by upstream steps. For example, if step 1 finds that user A's balance is 100 yuan, and step 2 simulates a "deduction of 150 yuan," the consistency expert will be able to identify the contradiction of "insufficient balance."

[0070] (2) Parallel generation and conflict resolution process Parallel generation: The same simulation context (interface definition, input parameters, current sandbox state) is submitted to multiple expert models simultaneously. Each expert model generates a candidate simulation response independently from its own professional perspective.

[0071] Conflict Detection and Resolution: After collecting all candidate responses, a conflict resolution module is initiated. This module first compares the differences between the outputs of different experts to identify potential conflict points (e.g., a data expert generates a status code of 200, while a business rules expert believes a 400 error should be returned). Subsequently, the resolution module can employ various strategies: Weighted voting / scoring: Select the version with the highest overall score based on preset expert weights or confidence scores for each response.

[0072] Meta-negotiation: Submits each candidate response and its reasoning to a higher-level "arbitration" big language model, which analyzes the reasons for the disagreement and makes a final decision.

[0073] Rule priority: Define clear resolution rules, such as "when business rules conflict with data formats, the business rules shall be given priority, but format warnings shall be recorded".

[0074] (3) Output fusion and final generation After conflict resolution, a merged, authoritative draft response is generated. To ensure its realism, it undergoes post-processing enhancements, such as injecting simulation data patterns that conform to system conventions (e.g., specific ID generation rules, timestamp formats). Rapid boundary condition and anomaly tests are performed to verify whether the simulated response remains reasonable under extreme parameters.

[0075] Simulated data augmentation and testing: Enhance the realism of the generated simulated responses (e.g., by injecting time-series IDs that conform to business rules), and proactively inject boundary values ​​or abnormal parameters for logical testing to ensure the robustness of the simulated data.

[0076] Storage and Tagging: Store the final generated simulation data in the sandbox's "API Response Pool" and tag its source as "Model Simulation Generation" in "Data Lineage Mapping".

[0077] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0078] S401: Extraction and Preparation of Structured Logs The execution logs generated during the complete rehearsal process are extracted from the isolated sandbox environment. These logs are dynamically recorded by the sandbox environment during the rehearsal, with each record corresponding to a node in the task execution graph and structurally containing the following core fields: Operation Type: Identifies whether the node is a "read operation" or a "write operation"; Input Parameters: Records the specific parameter values ​​actually passed to the node; Returned Response Data: Records the data content returned after the node's execution; Source Identifier: A key tag clearly indicating whether this response data originates from a call to real business logic or from the simulation generation of a large language model.

[0079] Analyzing this log reveals two core clues: first, the key data flow record, i.e. how data is produced, transmitted, and consumed between nodes; and second, the operation sequence, i.e. the order in which nodes are executed.

[0080] S402: Execution Summary Construction for Large Language Models To facilitate efficient and accurate analysis by the large language model, raw logs are not directly fed into the system. Instead, a highly condensed and logical execution summary is automatically constructed based on the extracted data flow records and operation sequences. This summary aims to present the core facts of the pre-rendering in a way that is easily understood by the model, and it includes at least the following: Parameter passing chain: Show how important parameters (such as a user ID or an order number) become the input of one node from the output of another node in a clear chain form.

[0081] Operation result status: Summarize the simulated changes in the status of business objects after the execution of key operations (especially write operations) (e.g., "User A's account balance: 100 yuan -> 20 yuan after deduction").

[0082] S403: Dual verification and feedback loop driven by a large language model The constructed execution summary is submitted to the large language model, which is then instructed to perform the following dual verification: Logical consistency verification: The model focuses on analyzing the parameter transmission chain, strictly verifying whether the input parameters of downstream operation nodes truly originate from the output results of an upstream operation node. For example, it checks whether the user list used by the "issue coupons" operation comes from the query results of the upstream "query VIP users" operation, preventing logical errors such as unclear data sources or broken links.

[0083] Business compliance verification: The model scans the entire operation sequence based on the pre-injected policy rule base (such as "prohibit the issuance of coupons to deactivated users" and "transfer amount must be positive") to determine whether any operation violates the established business constraints, security specifications or compliance requirements.

[0084] Validation Result Processing: If the validation passes, an execution token is generated, allowing the process to proceed to the final actual execution stage. If the validation fails, the large language model will not only report the failure but also generate specific correction suggestions (e.g., "The transfer amount in step 2 is negative; it is recommended to correct it to the absolute value of the 'accounts receivable' from the query result in step 1"). Subsequently, based on this suggestion, the original task execution graph is automatically rearranged and a new round of virtual sandbox rehearsal is triggered, forming a self-correcting closed loop until the validation passes.

[0085] In one embodiment of the present invention, based on step S5, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0086] S501: Dynamic generation of compensation operations Before initiating a call to the actual business based on the task execution graph, a corresponding, structured compensation operation is pre-generated for each forward operation to be executed in the graph.

[0087] Definition of Compensation Operation: A compensation operation is used to precisely reverse the business status change caused by its corresponding positive operation. It is an executable reverse operation instruction. For example, if the positive operation is "create order", the compensation operation may be "cancel the order"; if the positive operation is "deduct from account", the compensation operation may be "refund the equivalent amount of funds".

[0088] Dynamically generated logic: Compensation operations are not pre-set templates, but are intelligently and dynamically generated based on the interface semantics of the forward operation and the actual call parameters. Specifically: the interface definition of the forward operation is analyzed to identify its business impact and reversibility. Combined with the specific parameters that will be used in this execution (e.g., the created order ID, the user account for deduction), a targeted and immediately executable compensation instruction is constructed.

[0089] The generation process can be driven by a rules engine or generated based on the operational context by calling a large language model, ensuring the effectiveness of the compensation operation.

[0090] S502: Forward Execution and Rollback Stack Maintenance Create a Last-In-First-Out (LIFO) rollback stack to manage compensation operations in an orderly manner during forward execution.

[0091] Execute in sequence: Strictly follow the dependencies defined in the task execution graph, and initiate calls to each real business in sequence to execute the forward operation.

[0092] Stack maintenance: Whenever a forward operation executes successfully and receives a success response, its corresponding compensation operation is immediately pushed onto the rollback stack. This ensures that the rollback order is the reverse of the execution order, which is crucial for achieving correct state rollback.

[0093] S503: Abnormal Circuit Breaker and Automatic Rollback A state machine is used to monitor the execution result of each forward operation in real time.

[0094] Anomaly detection and circuit breaking: When a forward operation fails (such as an interface returning an error code or a network timeout), the circuit breaking mechanism is immediately triggered to interrupt the execution of all subsequent forward operations.

[0095] Automatic rollback: After a circuit breaker is triggered, the rollback procedure is automatically started: Starting from the top of the rollback stack, compensation operations are popped one by one; the popped compensation operations are executed immediately, and calls are made to the corresponding real business to undo the effects of the successfully executed positive operations; this process is repeated until the rollback stack is empty. At this point, all effective business changes have been revoked, and the relevant states are restored to the initial state before the start of the entire task.

[0096] Status Report: After the rollback is completed, a clear transaction execution report is sent to the user or the operation and maintenance platform, such as: "The task failed at step k 'update inventory', and a compensatory rollback has been automatically executed. All states have been restored and are unaffected." In some embodiments, the apparatus may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the large-scale heterogeneous business system integration apparatus may be stored in the memory of a computer terminal and executed by at least one processor to perform (see details). Figure 1 (Description) Functionality for integrating heterogeneous business systems based on a large model.

[0097] In this embodiment, the heterogeneous business system integration device based on a large model can be divided into multiple functional modules according to the functions it performs, such as... Figure 3 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0098] The interface parsing module is used to obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data. The task orchestration module is used to receive natural language instructions, perform semantic matching between the interface semantic index and the natural language instructions, and generate a task execution graph that corresponds to the natural language instructions and contains interface node dependencies. The task pre-simulation module is used to execute the task execution graph in an isolated environment. For read operation nodes in the task execution graph, the corresponding real business system is called to obtain data; for write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system. The pre-execution analysis module is used to perform logical and compliance verification on the logs generated by the task execution graph during this execution using a large language model; The task execution module is used to confirm that the verification is successful, initiate a real call to the real business system according to the task execution graph, and configure corresponding compensation operations for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to roll back.

[0099] Those skilled in the art will understand that the terminal structure involved in the embodiments of the present invention does not constitute a limitation on the terminal. A terminal may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the terminal includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The terminal may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable terminals, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0100] The terminal may include a processor, a memory, and a communication unit. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0101] The present invention also provides a computer medium, wherein the computer medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0102] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer terminal (which may be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0103] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0104] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical, mechanical, or other forms.

[0105] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0107] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for integrating heterogeneous business systems based on a large model, characterized in that, include: Obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data; Receive natural language instructions, perform semantic matching between the interface semantic index and the natural language instructions, and generate a task execution graph that corresponds to the natural language instructions and contains interface node dependencies; The task execution graph is executed in an isolated environment. For read operation nodes in the task execution graph, the corresponding real business system is called to obtain data. For write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system. The logs generated by the task execution graph in this execution are logically and compliance-wise validated using a large language model. Once the verification is successful, a real call is initiated to the actual business system according to the task execution graph, and a corresponding compensation operation is configured for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to perform a rollback.

2. The method according to claim 1, characterized in that, Obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data, including: Parse the parameter structure information and functional description text information of the interface from the interface definition data; The parameter structure information is input into the code pre-training model for encoding to obtain the code structure feature vector; The functional description text information is input into a text semantic model for encoding to obtain a natural language description feature vector; The code structure feature vector and the natural language description feature vector are weighted and fused to obtain the interface semantic vector, and the interface semantic vector is stored in the vector database to construct the interface semantic index.

3. The method according to claim 2, characterized in that, The code pre-training model is a neural network model trained on a large-scale code corpus to extract semantic features of program code; the text semantic model is a neural network model trained on a large-scale text corpus to extract semantic features of natural language.

4. The method according to claim 1, characterized in that, Receiving natural language instructions, semantically matching the interface semantic index with the natural language instructions, and generating a task execution graph corresponding to the natural language instructions and containing interface node dependencies, including: In response to the natural language instruction, a set of candidate interfaces that semantically match the natural language instruction is retrieved from the interface semantic index; The candidate interface set and the interface definition data corresponding to the semantic index of each interface in the candidate interface set are input into the large language model. The large language model performs interface reordering and parameter compatibility judgment to determine the final target interface set. Based on the target interface set, the large language model analyzes the calling logic and business risks between the interfaces to generate a structured task execution graph. The task execution graph defines the dependencies between interface nodes and the risk level of each node.

5. The method according to claim 1, characterized in that, Executing the task execution graph in an isolated environment includes: Maintain an isolated sandbox environment, which is used to store variable states, API response data and logs during execution; When traversing the nodes of the task execution graph, differentiated processing is performed according to the predefined operation rules of the nodes: If it is a read-only operation node, a call is initiated to the corresponding real business system, and the obtained real response data is stored in the sandbox environment after being de-identified, and the data lineage is recorded; If it is a write operation node, the call to the corresponding real business system is intercepted. Based on the interface definition data of the write operation node and the current context in the sandbox, the large language model is used to generate simulated response data and store the simulated response data in the sandbox environment.

6. The method according to claim 5, characterized in that, The logs generated by the task execution graph in this execution are logically and compliance-wise validated using a large language model, including: Extract key data flow records and operation sequences from the logs during the task execution process; Based on the key data flow records and operation sequences, an execution summary is constructed for analysis of large language models. The execution summary includes at least the parameter transmission link and the operation result status. The execution summary is validated by the large language model. The validation includes: verifying whether the input parameters of the downstream operation node originate from the output results of the upstream operation node; determining whether the operation sequence violates business constraints or security specifications based on preset policy rules; if the validation fails, the large language model generates a correction suggestion and triggers the rearrangement and rehearsal of the task execution graph. The logs are dynamically generated by an isolated sandbox environment. The logs include at least the following: the operation type of each node, the input parameters, the returned response data, and the source identifier of the response data, wherein the source identifier is used to indicate that the response data originates from a real business system or a large language model.

7. The method according to claim 1, characterized in that, Initiate real calls to the real business system according to the task execution graph, and configure corresponding compensation operations for the real calls; If a failure occurs during execution, corresponding compensation operations will be performed to roll back the process, including: Before formal execution, generate corresponding, structured compensation operations for each operation to be executed in the task execution graph; The operations to be executed are executed in sequence, and after each operation is successfully executed, its corresponding compensation operation is stored in a first-in-last-out rollback stack. Monitor the execution status. If any operation fails, immediately interrupt the subsequent execution process and start from the top of the rollback stack to sequentially retrieve and perform compensation operations until the system state is restored to the initial state. The compensation operation is a reverse operation instruction used to cancel the business state change generated by the corresponding forward operation; the compensation operation is dynamically generated based on the interface semantics and parameters called by the corresponding forward operation.

8. A heterogeneous business system integration device based on a large model, characterized in that, include: The interface parsing module is used to obtain interface definition data from at least one heterogeneous business system, and construct an interface semantic index based on the fusion semantics of the code structure features and natural language description features of the interface definition data. The task orchestration module is used to receive natural language instructions, perform semantic matching between the interface semantic index and the natural language instructions, and generate a task execution graph corresponding to the natural language instructions, which includes interface node dependencies. The task pre-simulation module is used to execute the task execution graph in an isolated environment. For read operation nodes in the task execution graph, the corresponding real business system is called to obtain data; for write operation nodes, simulated data is generated based on the definition of the corresponding interface without calling the real business system. The pre-execution analysis module is used to perform logical and compliance verification on the logs generated by the task execution graph during this execution using a large language model; The task execution module is used to confirm that the verification is successful, initiate a real call to the real business system according to the task execution graph, and configure corresponding compensation operations for the real call; if a failure occurs during execution, the corresponding compensation operation is executed to roll back.

9. A terminal, characterized in that, include: Memory, used to store integration programs for heterogeneous business systems based on large models; A processor, configured to implement the steps of the heterogeneous business system integration method based on a large model as described in any one of claims 1-7 when executing the large model-based heterogeneous business system integration program.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a heterogeneous business system integration program based on a large model. When the heterogeneous business system integration program based on the large model is executed by a processor, it implements the steps of the heterogeneous business system integration method based on a large model as described in any one of claims 1-7.

Images