Middle station service dynamic access method and device based on MCP, medium and program product

Abstract

The invention belongs to the field of natural language processing, and provides an MCP-based middle station service dynamic access method and device, a medium and a program product, and the method comprises the steps: obtaining target middle station service interface configuration data through an in-mcp, generating a structured Prompt template, and obtaining a corresponding interface definition and an authentication token through a yapi-mcp according to a projectId; an MCP is called to match a user natural language demand with a Prompt template and an interface definition, a service access code is generated, the demand is analyzed, and a parameter field is injected; executing an automatic unit test, and calling a preset association rule when an error code is detected; and the code is adapted to the target middle station service after passing verification, so that dynamic access is realized. According to the method, the problems of long time consumption, difficulty in adaptation, low efficiency in error checking and the like of the traditional access are solved, the access efficiency and reliability of the middle station service are greatly improved, and the rapid iteration requirement of the service is met.

Description

Technical Field

[0001] This invention relates to the field of natural language processing technology, and more specifically, to a method, device, medium, and program product for dynamic access to a middleware service based on MCP. Background Technology

[0002] In the software development field, middleware services have become a core support for enterprise digital transformation due to their ability to integrate business capabilities and improve development efficiency. However, there are still many technical pain points in the current process of integrating middleware services, which seriously restrict development efficiency and adaptability.

[0003] First, traditional access methods rely on manual review of interface documents and writing repetitive code, which takes an average of 2-3 days per service integration, which is time-consuming and labor-intensive. Moreover, the static code template is outdated. When the platform interface (such as SMS and push service API) undergoes path modification, parameter addition or removal, the pre-built template cannot be adapted synchronously and needs to be manually readjusted, which can easily lead to integration errors.

[0004] Secondly, the problem of fragmentation between multiple systems is prominent. Developers need to frequently switch between code editors, API documentation platforms (such as YAPI), and debugging tools, and repeatedly check interface information, which is cumbersome. For personalized needs (such as quick notification functions), it is necessary to deeply modify the code logic such as the request body structure, which has a high technical threshold and is difficult for non-professional developers to complete.

[0005] Furthermore, error troubleshooting relies on manual experience and lacks an automated verification mechanism. When the platform interface returns error codes (such as frequency control errors or invalid template IDs), it is necessary to manually consult the documentation to locate the cause, resulting in low troubleshooting efficiency. At the same time, unit test cases need to be written manually, which cannot quickly verify the usability of the code, further extending the access cycle and making it difficult to meet the needs of rapid business iteration. Summary of the Invention

[0006] In response, this invention provides a method, system, electronic device, and computer program product for dynamic access to middleware services based on MCP, so as to at least partially solve the above-mentioned technical problems.

[0007] This invention provides a method for dynamic access to middleware services based on MCP, comprising the following steps: The interface configuration data of the target middleware service is obtained through the infrastructure microservice configuration platform, and a structured Prompt template is generated based on the configuration data. Through the API documentation microservice configuration platform, the corresponding interface definition and authentication token are obtained based on the projectId of the target service, where the projectId and the authentication token are in one-to-one correspondence. The microservice configuration platform MCP is invoked to match the user's input natural language requirements with the Prompt template and the interface definition, thereby generating service access code. During the code generation process, natural language requirements are parsed based on preset rules, and the parsing results are converted into corresponding parameter fields and injected into the service access code. Execute automated unit tests on the service access code, and invoke the preset association rules between error codes and solutions when an error code is detected; After the service access code passes verification, it is adapted to the target middleware service to achieve dynamic access.

[0008] In another aspect, this application also provides a dynamic access device for middleware services based on MCP, comprising: The Prompt template generation module is used to obtain the interface configuration data of the target middleware service through the infrastructure microservice configuration platform, and generate a structured Prompt template based on the configuration data. The interface definition and authentication token acquisition module is used to obtain the corresponding interface definition and authentication token based on the projectId of the target service through the API documentation microservice configuration platform, wherein the projectId and the authentication token are in one-to-one correspondence. The service access code generation module is used to call the microservice configuration platform MCP, match the natural language requirements input by the user with the Prompt template and the interface definition, and generate service access code. The parsing module is used to parse natural language requirements based on preset rules during the code generation process, and convert the parsing results into corresponding parameter fields and inject them into the service access code. The unit testing module is used to perform automated unit tests on the service access code and, when an error code is detected, invoke the preset association rules between the error code and the solution. The code access module is used to adapt the service access code to the target middleware service after the service access code has been verified, so as to achieve dynamic access.

[0009] This application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the MCP-based dynamic access method for middleware services as described above.

[0010] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the MCP-based dynamic access method for middleware services as described above.

[0011] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the MCP-based dynamic access method for middleware services as described above.

[0012] This invention addresses the pain points of traditional middleware service integration by collaborating an infrastructure microservice configuration platform (inf-mcp) and an API documentation microservice configuration platform (yapi-mcp). It can acquire interface configurations and metadata in real time, generate structured Prompt templates, and combine natural language requirement parsing to generate adaptation code, automatically injecting personalized parameters. This eliminates the need for manually writing repetitive code, significantly reducing integration time. Automated unit testing and an error code-solution association mechanism automatically verify code and quickly locate and resolve errors, reducing manual troubleshooting costs. The code adaptation process dynamically adjusts environment parameters and synchronization dependencies to ensure stable code operation in the production environment, comprehensively improving the efficiency, flexibility, and reliability of middleware service integration and meeting the needs of rapid business iteration. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0014] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of a dynamic access method for middleware services based on MCP provided in an embodiment of the present invention.

[0015] Figure 2 This is a schematic diagram illustrating the specific process of generating the Prompt template provided in an embodiment of the present invention.

[0016] Figure 3 This is a schematic diagram of the structure of a dynamic access device for middleware services based on MCP provided in an embodiment of the present invention.

[0017] Figure 4 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The technical solutions of this application will be described in detail below with reference to various embodiments.

[0020] Terminology Explanation: MCP (Microservice Configuration Platform): A microservice configuration platform used for dynamically managing service configurations and rules; inf-mcp: An infrastructure microservice configuration platform that provides access rules and Prompt templates for middleware services; yapi-mcp: An API documentation microservice configuration platform that dynamically retrieves API documentation and authentication information; Prompt template: A structured instruction template that includes a title description, document address, and interface list.

[0021] like Figure 1 As shown in the diagram, this invention discloses a method for dynamic access to a middleware service based on MCP, comprising the following steps: S101, obtain the interface configuration data of the target middleware service through the infrastructure microservice configuration platform inf-mcp, and generate a structured Prompt template based on the configuration data; S102, through the API documentation microservice configuration platform yapi-mcp, obtain the corresponding interface definition and authentication token based on the projectId of the target service, wherein the projectId and the authentication token correspond one-to-one; S103, Invoke MCP to match the user's input natural language requirements with the Prompt template and the interface definition to generate service access code; S104, During the code generation process, the natural language requirements are parsed based on preset rules, and the parsing results are converted into corresponding parameter fields and injected into the service access code; S105, Execute automated unit tests of the service access code, and call the preset association rules between error codes and solutions when an error code is detected; S106. After the service access code passes verification, the service access code is adapted to the target middleware service to achieve dynamic access.

[0022] In some embodiments, for S101, firstly, the specific type and access requirements of the target middleware service are clarified. For example, when a user needs to connect to the middleware SMS service or the middleware push service, they will initiate a target service configuration retrieval request to inf-mcp through front-end operations (such as selecting the service type in the Artificial Intelligence Integrated Development Environment (AIIDE)) or back-end instructions. This request will carry the core identification information of the target service (such as service name, business scenario tags, etc.). After receiving the request, inf-mcp will locate the interface configuration data storage path corresponding to the target service based on the built-in service-configuration mapping table, avoiding indiscriminate retrieval of irrelevant configurations and improving data retrieval efficiency. In this embodiment, inf-mcp serves as an infrastructure microservice configuration platform. One of its core functions is to maintain the interface configuration data of each middleware service in real time. This data is not statically stored but is kept synchronized with the actual interface status of the middleware services (when the middleware service interface is updated, inf-mcp will automatically synchronize the configuration through an internal linkage mechanism). During the data acquisition phase, inf-mcp calls the built-in common prompt tool, which extracts the complete interface configuration information of the target service from inf-mcp's configuration library according to the preset configuration data dimensions.

[0023] Specifically, for example, the interface configuration information includes three types of key data, such as service basic description data: used to clarify the core positioning and docking basis of the service, such as the title description of the middle platform SMS service access template (which will later be used as the title field of the Prompt template) and the official document address corresponding to the service (such as https: / / docs.example.cc / doc / xxx, which will later be used as the document address field of the Prompt template), so that developers can easily refer to the complete docking specifications later; Interface list data: This is the core of the configuration data, containing information on all interfaces that need to be connected to under the target service. Each interface includes two key elements: the interface name and the interface URL. For example, when connecting to the push service, the corresponding interface URL for sending push templates (e.g., https: / / yapi / interface / api / 864700) and the corresponding interface URL for sending SMS verification codes (e.g., https: / / yapi / interface / api / 146844) will be extracted to ensure that the generated code can point to the actual interface. Access rule data includes code generation specifications and interface call process constraints for the target service. For example, SMS services require verification of the mobile number format before calling the sending interface, and push services require a template ID to initiate a request. These rules will be integrated as hidden logic into subsequent Prompt templates to guide the AI ​​code generation engine in generating code that meets the service requirements.

[0024] In this embodiment, after obtaining complete interface configuration data, inf-mcp will convert the scattered configuration data into a unified format Prompt template according to the preset structured template standard. It can be understood that the template is not free text, but an instruction carrier containing fixed fields and having a clear logical hierarchy, to ensure that the AI ​​code generation engine can recognize and parse it.

[0025] Specifically, such as Figure 2 The process of generating the Prompt template specifically includes: S201, Field Mapping, maps the acquired configuration data to fixed fields in the Prompt template one by one. For example, the title description in the "Service Basic Description Data" is mapped to the "TitleDesc field" of the template, and the document address is mapped to the "DocUrl field". Multiple sets of "Interface Name-Interface URL" in the "Interface List Data" are mapped to the "APIs field" of the template (this field is an array structure that can store information for multiple interfaces), ensuring that each configuration data item has a clear template field to carry it.

[0026] S202, Logical Integration: Based on field mapping, INF-MCP integrates access rule data into the template in the form of comments or implicit constraints. For example, in the APIs field corresponding to the "Push Template Sending" interface, a rule description of "Requires passing template ID and user list parameters" is added. This does not destroy the structured format of the template, but provides key constraints for code generation.

[0027] S203, Format Validation: inf-mcp performs automated format validation on the completed Prompt template, checking for issues such as missing fields (e.g., missing DocUrl field), invalid interface URLs, and conflicting rule descriptions. If any anomalies are found, an error message is returned and the configuration data is retrieved again, ensuring that the final generated Prompt template has a complete structure and accurate data, and can be directly used in subsequent code generation stages.

[0028] The structured Prompt template, after format verification, is directly passed from inf-mcp to the MCP code generation engine, serving as the core instruction basis for AI-generated service access code.

[0029] In some embodiments, for S102, yapi-mcp establishes a mapping relationship between projectId and authentication token through a configuration file, and dynamically loads authentication information according to the mapping relationship during the access process, wherein the projectId is used to distinguish different middleware services.

[0030] Specifically, yapi-mcp pre-configures the mapping between projectId and authentication token. As an API documentation microservice configuration platform, yapi-mcp pre-establishes the correspondence between target service, projectId, and authentication token when initializing or adding middleware services. This relationship is stored in the form of a structured configuration file (such as YAML format), and one projectId corresponds to one authentication token. That is, the projectId serves as a unique identifier for the target service (such as the projectId of SMS service being 1664), used to distinguish different middleware services (such as SMS service, push service, notification service, etc.), while the authentication token is the security credential for calling the target service interface (such as the token "b6c" corresponding to projectId1664 of SMS service).

[0031] During configuration, yapi-mcp allows administrators or automated scripts to input basic information about the target service. For example, it first determines the service's business type (e.g., SMS service) and assigns a unique projectId. Then, it obtains the service's unique authentication token from the API management platform of the middleware service (e.g., the official YAPI platform). Finally, it writes the mapping relationship between projectId and authentication token into a designated node in the configuration file (e.g., the "yapi.token" node). It also includes auxiliary information such as the service name and the business domain to which the interface belongs, facilitating quick location and maintenance later. Furthermore, this configuration file supports real-time updates. When the authentication token of the middleware service expires or changes, the configuration file can be modified directly without adjusting the core logic of yapi-mcp, ensuring configuration flexibility.

[0032] Next, MCP automatically extracts the projectId corresponding to the target service selected by the user (e.g., the user needs to connect to the middleware SMS service) and sends a data retrieval request to yapi-mcp. This request carries a unique identifier (i.e., the projectId of the target service), and the request format matches the yapi-mcp interface specification, ensuring that yapi-mcp can identify which type of service's interface definition and authentication token needs to be obtained.

[0033] The scenarios in which requests are triggered are clearly related: they are only initiated when the user confirms the target service and starts the code generation process, avoiding meaningless data fetching; at the same time, the request will be accompanied by basic identity verification (such as internal service identifier) ​​to prevent unauthorized calls to yapi-mcp configuration data and ensure platform data security.

[0034] After receiving a request carrying a projectId, yapi-mcp first locates the target service's dedicated documentation repository in an API documentation platform (such as YAPI) based on the projectId. Then, through its built-in API scheduling module, it retrieves the complete interface definition of the target service from this repository in real time. This interface definition is not simply an interface address, but contains all the metadata information required for the interface call. For example, its content includes: Basic interface information, including interface name (such as "SMS verification code sending" or "push template sending"), interface URL (such as the push service interface URL "https: / / yapi / interface / api / 864700" in the documentation), and request method (such as GET / POST), to ensure that the generated code can accurately point to the target interface; Parameter constraint information includes the name, type (such as string, integer), whether it is required, default value, and structure of the returned parameters (such as the data field returned on success and the errno field returned on error) to prevent the code from failing due to parameter mismatch; Business rules, such as API call frequency limits and applicable scenario descriptions (e.g., "SMS verification code sending API only supports login scenarios"), will be incorporated into subsequent code generation logic as implicit constraints to ensure that the code complies with the business specifications of the middle platform service.

[0035] Throughout the retrieval process, yapi-mcp maintains real-time synchronization with the API documentation platform. If the interface of the target service changes (such as modifying the interface URL or adding required parameters), yapi-mcp can automatically detect and retrieve the latest interface definition, completely solving the problem of outdated information in traditional static documentation.

[0036] While fetching the interface definition, yapi-mcp matches the projectId in the request against the pre-defined "projectId-authentication token" mapping configuration. It iterates through the "token" node in the configuration file, finding a configuration item that perfectly matches the current projectId, and then extracts the corresponding authentication token. Since the configuration ensures a one-to-one correspondence between projectId and authentication token, there will be no situation where one projectId matches multiple tokens, nor will there be any token allocation errors. For example, if the request carries a projectId of 1664 (corresponding to the SMS service), yapi-mcp will directly locate the entry "projectId:1664" in the configuration file and extract its corresponding token "b6c". If an exception occurs where "projectId not found matching configuration" (e.g., incorrect projectId input, target service not pre-configured), yapi-mcp will return a clear error message (e.g., "projectId1665 has no corresponding configuration, please check the service identifier or supplement the configuration") and terminate subsequent data transmission to prevent invalid data from entering the code generation stage.

[0037] After yapi-mcp obtains the interface definition and authentication token, it first performs automated validation on two types of data: For the interface definition, it checks whether it contains core fields such as interface URL, request method, and required parameters. If any fields are missing, it retrieves them again. For the authentication token, it checks whether its format conforms to the authentication specifications of the middleware service (such as token length and character type). If the format is incorrect, it prompts that the token configuration is abnormal and asks you to maintain it again.

[0038] After successful verification, yapi-mcp will encapsulate the interface definition and authentication token into a unified data structure and synchronously transmit it to the MCP's "code generation engine". The interface definition provides the docking standard for AI-generated code (such as which interface the code needs to call and which parameters to pass), while the authentication token provides the calling credentials for the code (ensuring that the code can pass the authentication of the middle platform service when calling the interface).

[0039] In some embodiments, for S103-S104, the system first receives natural language requests input by the user through AIIDE. The request types cover basic functional requests (such as connecting to template push notification messages) and personalized requests (such as adding quick notifications). At this time, MCP first passes the request to the built-in semantic parsing module. This module relies on a pre-trained corpus of service request statements for the middle platform (covering common request keywords for various services such as SMS, push, and notifications) to perform structured decomposition of the natural language.

[0040] Specifically, this includes requirement type identification: determining requirement attributes through keyword matching. For example, if it contains expressions such as "connecting to XX service" or "generating XX interface call code", it is determined to be a basic functional requirement; if it contains expressions such as "adding XX feature" or "adapting to XX scenario", it is determined to be a personalized requirement, providing a basis for matching different generation logics in the future.

[0041] Core element extraction: Extract key information related to the integration with the middle platform services from the requirements. For example, in the requirement of "integrating template push notification messages", extract "service type (push service)", "functional scenario (template message)" and "interaction carrier (notification bar)"; in the requirement of "adding quick notifications", extract "target characteristics (quick notifications)" and "related services (push service)" to ensure that the requirements analysis results can be accurately associated with subsequent data.

[0042] Request validity verification: Compare the user's request with the "List of Supported Functions of Target Service" recorded in the Prompt template generated by inf-mcp (such as the functions corresponding to the interfaces included in the APIs field of the Prompt template) to verify whether the user's request is within the capabilities of the target service. For example, if the target service is SMS service and the user's request is "push message", the system will return a prompt "The request does not match the target service. Please confirm the service type" to avoid invalid matching.

[0043] After completing the requirements analysis, MCP is called to establish data interaction with the Prompt template output by inf-mcp and the interface definition obtained by yapi-mcp, respectively, to implement three-layer matching logic and ensure that the generated code has both standard basis and meets the actual requirements of the interface.

[0044] Specifically, this includes matching requirements with Prompt template rules: based on the parsed core elements of the requirements, matching the "access rules and template structure" recorded in the Prompt template. For example, for the basic functional requirement "integrating with the template to push notification messages", matching the "code generation rule document identifier" (such as "use-push-with-golib.md") corresponding to "push service" in the Prompt template. This identifier points to the preset basic code generation specifications, clarifying the overall framework of the code (such as function definition format and interface call flow). For the personalized requirement "adding quick notifications", matching the "parameter injection rules" (such as "quick notifications need to add an extra field" recorded in the Prompt template comments) corresponding to "personalized extension of push service" in the Prompt template, providing rule support for subsequent parameter injection.

[0045] Metadata matching between requirements and interface definitions: Based on the parsed requirements, the "interface metadata information" obtained by yapi-mcp in the interface definition is matched to ensure that the generated code can accurately connect to the actual interface. For example, for the requirement of "connecting to template push notification bar messages", the "request parameter requirements" (such as whether template ID and user list need to be passed) and "return value format" of the "push template sending interface" (such as the interface corresponding to the interface URL obtained by yapi-mcp) in the interface definition are matched to ensure that the generated code parameters are consistent with the interface requirements. At the same time, the "request method (such as POST)" and "interface path" in the interface definition are matched to provide accurate information for the generation of interface call statements in the code.

[0046] Cross-data dimension consistency verification: MCP's matching engine links the Prompt template and the interface definition data to verify whether there are any conflicts between them. For example, if the "push template sending interface URL" recorded in the Prompt template is inconsistent with the URL in the interface definition obtained by yapi-mcp, the real-time interface definition of yapi-mcp shall prevail, and the temporary cached data of the Prompt template shall be updated synchronously to ensure the timeliness and accuracy of the matching results. If the "required parameter" in the interface definition is not mentioned in the "code generation rules" of the Prompt template, the generation logic of the parameter shall be automatically supplemented to avoid the code missing key parameters.

[0047] After completing multi-dimensional matching, MCP's code generation engine generates service access code in layers based on the requirement type (basic / personalized) and the matching results, ensuring the integrity and adaptability of the code.

[0048] Specifically, the basic service access code generation (for basic functional requirements) is exemplified by using the basic code generation rule document (such as "use-push-with-golib.md") matched by the Prompt template as a framework, and filling in the specific content with the metadata information defined by the interface. For example, first, according to the "push service function structure" defined in the rule document, a function skeleton containing "function name (such as SendTemplate)", "input parameters (such as template ID, user list)" and "return value" is generated; then, according to the "interface URL" and "request method" defined by the interface, an interface call statement (such as "service.CallYAPI(" / sendtplpush",payload)") is generated; at the same time, according to the "parameter type requirements" defined by the interface, parameter validation logic (such as checking whether the template ID is an integer and whether the user list is not empty) is generated to ensure that the basic code can directly call the middle platform interface.

[0049] Personalized parameter injection and code optimization (for personalized needs): For example, based on the basic code generation, according to the matched "personalized parameter injection rules," the parsed personalized needs are transformed into specific code logic. For example, for the "add quick notification" requirement, the code generation engine will first identify the structure of the "request body (payload)" in the basic code and determine whether an "extra field" exists. If it does not exist, it will automatically initialize "extra" as a mapped type field. Then, according to the "quick notification parameter requirements" in the interface definition, a key-value pair "quick_notice:1" will be added to the "extra field." At the same time, the "enableQuickNotice" switch judgment logic will be added to the code (such as triggering based on configuration or user needs) to ensure that personalized functions can be flexibly enabled without affecting the normal operation of basic functions.

[0050] Preferably, after the code is generated, MCP performs preliminary adaptation and standardization on the generated service access code to prepare for subsequent automated unit testing.

[0051] Specifically, this includes automatic injection of interface authentication information. For example, the token value corresponding to the target service is extracted from the authentication token obtained from yapi-mcp, and the authentication field (such as adding "Authorization:tokenXXX" in the HTTP request header) is automatically added to the "interface call request header" or "request parameters" in the code. This avoids errors or omissions caused by manual configuration of authentication information and ensures that the code can pass authentication when calling the interface.

[0052] Code format and style verification, for example, formatting the generated code according to the "code style guidelines" (such as indentation format, variable naming rules, and comment requirements) recorded in the Prompt template, such as using 4 spaces for indentation, using "camel case" for function names, and adding comments for key logic (such as parameter injection and API calls); at the same time, calling the built-in syntax checking tool to fix syntax errors (such as mismatched brackets and undefined variables) to ensure that the code is grammatically compliant.

[0053] Service dependencies are automatically imported. For example, based on the "mid-platform service dependency libraries" involved in the generated code (such as the SDK or toolkit required to call "service.CallYAPI"), dependency import statements (such as "import "xxx / service / yapi") are automatically added to the beginning of the code to avoid the code failing to compile and run due to missing dependencies, and to ensure that the generated service access code is executable.

[0054] In some embodiments, for S105-S106, before executing automated unit tests of the service access code, test environment configuration and test case preparation are completed first to provide a stable and comprehensive verification foundation for testing and avoid inaccurate test results due to missing environment or test cases.

[0055] Specifically, for test environment configuration, for example, when calling the test environment resources of the middleware service (non-production environment), configure the network link (such as test environment interface domain name and port) and dependent services (such as the authentication service and data storage service of the test environment) that are consistent with the target middleware service. At the same time, inject the test environment authentication token obtained by yapi-mcp (distinguish it from the production token to avoid affecting the actual business) to ensure that the code can access the test interface of the target service normally during the test and will not interfere with the production data.

[0056] For test cases, for example, based on the interface definition obtained by yapi-mcp and the Prompt template rules generated by inf-mcp, unit test cases covering normal scenarios and abnormal scenarios are generated. Among them, the normal scenario test cases correspond to the standard request parameters in the interface definition (such as passing in a valid template ID, user list, and whether the test code can successfully call the interface and return the correct result); the abnormal scenario test cases correspond to common interface error scenarios (such as passing in an invalid template ID, an empty user list, or exceeding the interface frequency control limit, and whether the test code can correctly capture the error and trigger the corresponding logic).

[0057] After completing the environment and test case preparation, start the automated test execution to perform full-process testing on the service access code and ensure the stability of the code in different scenarios.

[0058] Specifically, this includes batch execution of test cases. All test cases are run in batches according to the order of normal scenarios and abnormal scenarios. That is, normal scenario test cases are executed first to verify whether the code can correctly complete the entire process of "parameter assembly → interface call → return result parsing" under standard input (such as whether the code can successfully push the message to the test user's notification bar when calling the push template sending interface, and whether there is no error mark in the return result). Then execute the test cases for abnormal scenarios to verify the code's fault tolerance under abnormal input (such as whether the code can recognize the error information returned by the interface when an invalid template ID is passed in, instead of crashing directly).

[0059] For each completed test case, the module captures two key results: first, the code execution result (such as whether the API call request was successfully generated, and whether any syntax or logic errors occurred); second, the API return result (such as the status code and data content returned by the API, and if an error occurs, the specific error code is captured, such as errno44454 or errno22000). Simultaneously, a test execution log is generated, recording the execution time, input parameters, output results, and error messages (if any) for each test case.

[0060] In this embodiment, if an error code returned by the interface is captured during automated unit testing (i.e., the execution of an abnormal scenario test case fails and the error is located to be caused by an error returned by the interface), the preset "error code-solution association rule library" is called to realize the automated processing of "error location, solution matching, and result feedback", replacing the inefficient method of manually checking documents to find errors.

[0061] Specifically, for error localization, for example, specific error codes (such as errno44454) are extracted from the test results and combined with the corresponding test case information (such as input parameters and interface call chain) to locate the specific link where the error occurred. For example, errno44454 corresponds to "invalid template ID". The module will associate the template ID passed in the test case to confirm that the error is caused by "the code using a template ID that was not created in the middle platform" rather than a code logic error.

[0062] For the association rule base matching and solution generation, for example, precise matching is performed based on error codes in a preset association rule base. This rule base is pre-maintained by the middle platform service team and stores the correspondence between "error code - error reason - solution - associated resource" (e.g., errno44454 corresponds to "Error reason: Template ID not created on the IMP platform; Solution: Contact PM to create the template on the IMP platform and update the template ID in the code; Associated resource: IMP platform address, PM contact information"); errno22000 corresponds to "Error reason: Interface call frequency exceeds limit; Solution: Add frequency control retry logic in the code, or apply to increase the interface call quota; Associated resource: Frequency control policy document address"). After a successful match, a structured solution is automatically generated, including an explanation of the error reason, specific operation steps, and links to associated resources, ensuring that developers can quickly locate and resolve the problem.

[0063] If the error code can be resolved by modifying the code (e.g., invalid template ID), the solution will be provided to the developer, and one-click retry testing will be supported (after the developer modifies the code, the test case will be re-executed without reconfiguring the environment); if the error code originates from the middle platform service configuration (e.g., insufficient interface frequency control quota), a prompt will be provided indicating that the middle platform team needs to be coordinated to handle the issue, and the test case will be paused until the configuration is adjusted before re-execution.

[0064] In this embodiment, after the service access code passes all automated unit tests (i.e. all test cases are executed successfully with no error codes or the errors have been fixed), it enters the code adaptation stage. Through environment parameter adjustment, dependency configuration synchronization, and access permission application, the code is adapted from the test environment to the production environment (or specified access environment) of the target middleware service, ensuring that the code can actually connect to the middleware service.

[0065] Specifically, for dynamic adjustment of environment parameters, for example, automatically replacing test environment parameters in the code with production environment parameters, such as replacing the "test environment interface URL" called in the code with the "production environment interface URL" of the target middleware service, and replacing the "test environment authentication token" with the "production environment token" provided by yapi-mcp (obtained by matching the projectId of the target service); at the same time, adjusting the "running parameters" in the code (such as interface call timeout time and number of retries, configured according to the performance requirements of the production environment) to ensure the running efficiency and stability of the code in the production environment.

[0066] Dependency configuration synchronization includes, for example, checking the dependencies of the middle platform services required for code execution (such as the SDK version and configuration files required to call the middle platform service) and comparing them with the production environment dependency requirements of the target middle platform service. If the SDK version required by the code is lower than the production environment requirement, it will be automatically downloaded and updated to a compatible version. If an additional whitelist of services access specific to the production environment needs to be configured (such as allowing only specified IPs or service accounts to call the middle platform service), an application will be automatically sent to the middle platform's permission management platform to add the service account to which the current code belongs to the whitelist, so as to avoid access failure due to permission issues.

[0067] Access verification and confirmation, for example, involves performing access verification after completing parameter and dependency configuration. This means calling the production environment test interface of the target middleware service (or initiating a small, business-unaffected actual call, such as sending a verification message to a specified test user) to verify whether the code can normally call the middleware service and obtain the correct results in the production environment. If the verification is successful, an access completion report is generated, recording the accessed service name, code version, access time, and verification result. At the same time, the code is synchronized to the target service's code repository (such as the middleware service's access code management repository), completing the final dynamic access. If the verification fails (e.g., a permission error still occurs), the error reason is returned, and the adaptation process is retried until the access is successful.

[0068] Figure 3 An MCP-based dynamic access device 300 for middleware services is shown. This device embodiment is similar to... Figure 1 Corresponding to the method embodiment shown, this device can be specifically applied to various electronic devices, specifically including, The Prompt template generation module 301 is used to obtain the interface configuration data of the target middleware service through the infrastructure microservice configuration platform inf-mcp, and generate a structured Prompt template based on the configuration data. The interface definition and authentication token acquisition module 302 is used to obtain the corresponding interface definition and authentication token based on the projectId of the target service through the API documentation microservice configuration platform yapi-mcp, wherein the projectId and the authentication token correspond one-to-one. The service access code generation module 303 is used to call MCP to match the natural language requirements input by the user with the Prompt template and the interface definition to generate service access code; The parsing module 304 is used to parse natural language requirements based on preset rules during the code generation process, and convert the parsing results into corresponding parameter fields and inject them into the service access code. The unit testing module 305 is used to perform automated unit tests on the service access code and to call the preset association rules between the error code and the solution when an error code is detected. The code access module 306 is used to adapt the service access code to the target middleware service after the service access code passes verification, so as to realize dynamic access.

[0069] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0070] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and smart bands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0071] Figure 4 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 400 includes a central processing unit 401, which can perform various appropriate actions and processes based on a program stored in a read-only memory 402 or a program loaded from a storage portion 408 into a random access memory 403. Various programs and data required for system operation are also stored in the RAM 403. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output interface 405 is also connected to the bus 404.

[0072] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 407 including cathode ray tubes, liquid crystal displays, LED displays, OLED displays, etc., and speakers, etc.; a storage section 408 including one or more computer-readable media such as hard disks, optical disks, magnetic disks, semiconductor memory, etc.; and a communication section 409 including network interface cards such as LAN cards, modems, etc. The communication section 409 performs communication processing via a network such as the Internet.

[0073] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 401, it performs the functions defined in the methods of this application.

[0074] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0075] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. In this document, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0076] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0077] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0078] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0079] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0083] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0084] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0086] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method for dynamic access to middleware services based on MCP, characterized in that, The methods and steps include the following: The interface configuration data of the target middleware service is obtained through the infrastructure microservice configuration platform, and a structured Prompt template is generated based on the configuration data. Through the API documentation microservice configuration platform, the corresponding interface definition and authentication token are obtained based on the projectId of the target service, where the projectId and the authentication token are in one-to-one correspondence. The microservice configuration platform MCP is invoked to match the user's input natural language requirements with the Prompt template and the interface definition, thereby generating service access code. During the code generation process, natural language requirements are parsed based on preset rules, and the parsing results are converted into corresponding parameter fields and injected into the service access code. Execute automated unit tests on the service access code, and invoke the preset association rules between error codes and solutions when an error code is detected; After the service access code passes verification, it is adapted to the target middleware service to achieve dynamic access.

2. The method for dynamic access to a middleware service based on MCP according to claim 1, characterized in that, The interface definition includes API metadata information, which includes basic interface information, parameter constraint information, and business rule information.

3. The method for dynamic access to a middleware service based on MCP according to claim 1, characterized in that, The infrastructure microservice configuration platform establishes a mapping relationship between projectId and authentication token through configuration files, and dynamically loads authentication information according to the mapping relationship during the access process, wherein the projectId is used to distinguish different middleware services.

4. The method for dynamic access to a middleware service based on MCP according to claim 1, characterized in that, The system parses natural language requirements based on preset rules and converts the parsing results into corresponding parameter fields, which are then injected into the service access code. include, The system receives user requests in natural language. If the request is for basic functionality, it calls preset rules to generate basic service access code. If the request is for personalization, it automatically parses the request and maps it to code parameter injection logic, adding personalized parameters to the basic code. Parameter injection includes mapping natural language requests to specific field key-value pairs and writing them into the request body.

5. The method for dynamic access to a middleware service based on MCP according to claim 1, characterized in that, Before executing automated unit tests on the service access code, the generated service access code undergoes preliminary adaptation and standardization processing, specifically including automatic injection of interface authentication information, code format and specification verification, and automatic introduction of service dependencies.

6. The method for dynamic access to a middleware service based on MCP according to claim 1, characterized in that, It also includes, Adapting the service access code to the target middleware service includes dynamically adjusting environment parameters, synchronizing dependency configurations, and access verification and confirmation.

7. A dynamic access device for middleware services based on MCP, characterized in that, include: The Prompt template generation module is used to obtain the interface configuration data of the target middleware service through the infrastructure microservice configuration platform, and generate a structured Prompt template based on the configuration data. The interface definition and authentication token acquisition module is used to obtain the corresponding interface definition and authentication token based on the projectId of the target service through the API documentation microservice configuration platform, wherein the projectId and the authentication token are in one-to-one correspondence. The service access code generation module is used to call the microservice configuration platform MCP, match the natural language requirements input by the user with the Prompt template and the interface definition, and generate service access code. The parsing module is used to parse natural language requirements based on preset rules during the code generation process, and convert the parsing results into corresponding parameter fields and inject them into the service access code. The unit testing module is used to perform automated unit tests on the service access code and, when an error code is detected, invoke the preset association rules between the error code and the solution. The code access module is used to adapt the service access code to the target middleware service after the service access code has been verified, so as to achieve dynamic access.

8. An electronic device, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images