Data processing method and device and electronic equipment

Abstract

The invention discloses a data processing method and device and electronic equipment. The method comprises the following steps: receiving a request message sent by a client; the request message is arranged, the arranged request message is scheduled through a multi-language script engine, and the multi-language script engine comprises a script executor supporting multiple programming languages; sending the scheduled request message to a downstream interface for processing, and receiving a response message corresponding to the request message sent by the downstream interface; and arranging the response message, scheduling the arranged response message through a multi-language script engine, and returning the scheduled response message to the client. According to the method and the device, the technical problem that more complex business requirements, especially custom reconstruction of input and output parameters, cannot be met due to the fact that data processing in related technologies only supports simple parameter mapping and sequence recombination when API arrangement is carried out is solved.

Description

Technical Field

[0001] The present application relates to the field of data communications, and in particular, to a data processing method, device and electronic equipment. Background Art

[0002] With the increasing popularity of microservice architecture, in modern software development and IT system design, applications are decomposed into multiple independent services, each of which interacts through an API (Application Programming Interface). This architecture not only enhances the flexibility and scalability of the system, but also promotes loose coupling and reuse of business modules. However, API orchestration and management also face new challenges, especially when dealing with the collaborative work of multiple services.

[0003] Specifically, in the data processing process, API orchestration platforms in related technologies usually adopt a static configuration method, which means that in the orchestration process, once the parameter mapping and sequence reorganization of API calls are determined, it is difficult to flexibly adjust them. This static nature limits the dynamic adaptability and scalability of the orchestration service, making it necessary to frequently modify and redeploy the orchestration logic in the face of changing business needs.

[0004] At the same time, most API orchestration tools only support simple parameter mapping and sequence reorganization of APIs, and lack the ability to customize the input and output parameters. This means that for complex and deep business needs, such as data conversion, logical judgment, or third-party service integration, the orchestration tools in related technologies are often unable to cope with them, resulting in limited scalability of the overall solution.

[0005] In addition, as the number and types of APIs grow, the maintenance and update of orchestration services become increasingly complex. Especially when it is necessary to support multiple programming languages ​​and third-party libraries, the maintenance and upgrade of existing orchestration platforms is not only time-consuming but also costly. The lack of effective script and library management mechanisms makes operation and maintenance work in a multi-language environment even more difficult.

[0006] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0007] The embodiments of the present application provide a data processing method, device and electronic device to at least solve the technical problem that the data processing in the related technology only supports simple parameter mapping and sequence reorganization when performing API orchestration, and cannot meet more complex business needs, especially the technical problem of customized reconstruction of input and output parameters.

[0008] According to one aspect of an embodiment of the present application, a data processing method is provided, including: receiving a request message sent by a client; orchestrating the request message, and scheduling the orchestrated request message through a multi-language script engine, wherein the multi-language script engine includes a script executor that supports multiple programming languages; sending the scheduled request message to a downstream interface for processing, and receiving a response message corresponding to the request message sent by the downstream interface; orchestrating the response message, scheduling the orchestrated response message through the multi-language script engine, and returning the scheduled response message to the client.

[0009] Optionally, the request message is formatted, including: determining necessary parameters and non-essential parameters in the request message, wherein necessary parameters are parameters that meet the requirements of the downstream interface, and non-essential parameters are parameters that have no direct relationship with the downstream interface or contain sensitive information; deleting non-essential parameters from the request message, and formatting the necessary parameters into a request format that meets the requirements of the downstream interface.

[0010] Optionally, the method also includes: determining data structure information, wherein the data structure information includes orchestration information, lower-level node information, parameter mapping information and code script information, the data structure information is used to control the interface call process and data processing logic in the request message and the response message, the orchestration information is used to define the global process of different calling interfaces, the lower-level node information is used to describe the detailed information of each calling interface, the parameter mapping information is used to control the parameter mapping between different calling interfaces, the code script information includes a pre-script and a post-script, and the code script information is used to perform specific business logic processing on the request message and the response message.

[0011] Optionally, scheduling the arranged request message by using a multi-language script engine includes: performing pre-script processing on the arranged request message by using the multi-language script engine.

[0012] Optionally, scheduling the arranged response message by using a multi-language script engine includes: performing post-script processing on the arranged response message by using the multi-language script engine.

[0013] Optionally, the orchestrated request message is pre-scripted through a multi-language script engine, including: obtaining a third-party package uploaded by a user, and obtaining pre-defined scheduling information, wherein the third-party package is used to provide an additional function library or dependency required for the script executor in the multi-language script engine to run, and the scheduled information includes a scheduling order list and a script executor type; obtaining first data information generated by the request message during the data processing process, wherein the first data information is used to represent the context state of the request message; and pre-scripting the request message according to the third-party package, the scheduling information and the first data information.

[0014] Optionally, the orchestrated response message is post-scripted through a multi-language script engine, including: obtaining second data information generated by the response message during data processing, wherein the second data information is used to represent the context state of the response message; and performing post-script processing on the response message based on a third-party package, scheduling information and the second data information.

[0015] Optionally, the method further includes: in the case where there are multiple request messages, processing the multiple request messages and response messages corresponding to the multiple request messages in parallel through a preset network flow framework.

[0016] According to another aspect of an embodiment of the present application, a data processing device is also provided, including: a first receiving module, used to receive a request message sent by a client; a first orchestration module, used to orchestrate the request message, and schedule the orchestrated request message through a multi-language script engine, wherein the multi-language script engine includes a script executor that supports multiple programming languages; a second receiving module, used to send the scheduled request message to a downstream interface for processing, and receive a response message corresponding to the request message sent by the downstream interface; a second orchestration module, used to orchestrate the response message, schedule the orchestrated response message through the multi-language script engine, and return the scheduled response message to the client.

[0017] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including: a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute and implement the above-mentioned data processing method.

[0018] According to another aspect of the embodiments of the present application, a non-volatile storage medium is provided, the non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned data processing method by running the computer program.

[0019] According to another aspect of the embodiments of the present application, a computer program product is provided, including computer instructions, which implement the above data processing method when executed by a processor.

[0020] In an embodiment of the present application, a request message sent by a client is received; the request message is orchestrated, and the orchestrated request message is scheduled by a multilingual script engine, wherein the multilingual script engine includes a script executor that supports multiple programming languages; the scheduled request message is sent to a downstream interface for processing, and a response message corresponding to the request message sent by the downstream interface is received; the response message is orchestrated, and the orchestrated response message is scheduled by a multilingual script engine, and the scheduled response message is returned to the client, thereby achieving the technical effect of using a multilingual script engine to perform customized processing on request messages and response messages to meet ever-changing business needs, thereby achieving efficient management of API services and rapid response to complex needs, thereby solving the technical problem that the data processing in the related technology only supports simple parameter mapping and sequence reorganization when performing API orchestration, and cannot meet more complex business needs, especially the technical problem of customized reconstruction of input and output parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 is a hardware structure diagram of a computer terminal for implementing a data processing method according to an embodiment of the present application;

[0023] Figure 2 is a flow chart of a data processing method according to an embodiment of the present application;

[0024] Figure 3 is a flow chart of another data processing method according to an embodiment of the present application;

[0025] Figure 4 is a schematic diagram of a framework of data structure information according to an embodiment of the present application;

[0026] Figure 5 is a schematic diagram of a scheduling process of a multi-language script execution engine according to an embodiment of the present application;

[0027] Figure 6 It is a structural diagram of a data processing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] First, some nouns or terms that appear in the process of explaining the embodiments of the present application are subject to the following explanations:

[0031] API orchestration: refers to the process of combining and coordinating multiple API interfaces according to certain logic and processes. In a microservice architecture, an application may depend on multiple services, each with its own API. API orchestration helps developers connect these API interfaces in series to form a complete service process to meet more complex application requirements. Orchestration usually involves parameter mapping, data conversion, error handling, and transaction coordination between APIs.

[0032] Parameter mapping: refers to the process of converting the output of one interface into the input of another interface in an API call. For example, one API may return data in JSON format, while another API requires input in XML format. Parameter mapping can automatically or manually convert data formats to ensure that data between APIs can be correctly transmitted and processed.

[0033] Webflux framework: It is a sub-project of Spring framework, designed for building responsive, asynchronous and non-blocking web applications. It is based on Reactor mode and can efficiently handle a large number of concurrent requests, which is particularly suitable for building modern microservice architecture and cloud-native applications. In this application, webflux is used as the core framework of the orchestration processor to process HTTP requests asynchronously, thereby improving processing speed and system responsiveness.

[0034] Dynamic language execution engine: A software component that can interpret and execute code in a dynamic programming language (such as Python, JavaScript, or Ruby). In this application, the dynamic language execution engine can select the appropriate executor according to the scripting language type (Java, Python, JS, etc.), load the necessary third-party library dependency packages, and execute the script in sequence to process request messages and response messages.

[0035] Pre-script processing: refers to pre-processing or modifying the request message by executing a specific script or program before calling the downstream API or service. For example, it includes data format conversion, parameter encryption, adding necessary header information, etc., to ensure that the request message meets the format and requirements of the downstream API.

[0036] Post-script processing: refers to processing or modifying the response message by executing a script after the downstream API or service returns a response. For example, it includes converting the response data from one format to another, adding additional data information, error handling, etc. to meet the needs of end users or downstream services.

[0037] Strategy pattern: A behavioral design pattern that allows an algorithm or strategy to be selected at runtime. In this application, the strategy pattern is used in a dynamic language execution engine to create different script executors based on the script type. This allows the execution engine to flexibly handle scripts in different languages ​​without having to hard-code support for each language in the code.

[0038] In order to solve the problem of poor API arrangement technology in the related art, the embodiment of the present application provides a data processing method, which can be run on Figure 1 In the computer terminal shown, the computer terminal is described below.

[0039] The data processing method embodiment provided in the embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG. 1 shows a hardware structure block diagram of a computer terminal for implementing a data processing method. Figure 1As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions connected via a wired and / or wireless network. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art can understand that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0040] It should be noted that the one or more processors and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the data processing method in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizing the above-mentioned data processing method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0042] The transmission module 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0043] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0044] It should be noted that, in some optional embodiments, the above Figure 1 The computer terminal shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. It should be noted that Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the computer terminal described above.

[0045] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a data processing method. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0046] Figure 2 is a flow chart of a data processing method according to an embodiment of the present application, such as Figure 2 As shown, the method comprises the following steps:

[0047] Step S202: receiving a request message sent by the client.

[0048] In the above step S202, the client may be a variety of different applications or services, and the request message includes parameters and information required to call a specific service.

[0049] Step S204, arranging the request message, and scheduling the arranged request message through a multi-language script engine, wherein the multi-language script engine includes a script executor that supports multiple programming languages.

[0050] In the above step S204, after receiving the request message, the request message can be preliminarily arranged according to the preset arrangement rules, including parameter clipping, parameter mapping or format adjustment, etc. It should be noted that the preset arrangement rules define how to convert the request message into a format suitable for downstream API calls.

[0051] After that, the request message that has been preliminarily arranged is passed to the multi-language script engine for pre-script processing. For example, more complex processing of the request message, such as data conversion, logical judgment, or integration with third-party services, is performed to achieve more advanced business needs. Among them, the multi-language script engine contains multiple script executors that support different programming languages ​​(such as Java processors, Python processors, and JS processors). The appropriate executor can be selected according to the arrangement requirements and script language type.

[0052] Step S206: Send the scheduled request message to the downstream interface for processing, and receive a response message corresponding to the request message sent by the downstream interface.

[0053] In the above step S206, after the front script is processed, the request message is sent to the downstream API interface or service for processing, wherein the downstream API interface involves different systems or services, and each downstream API interface has specific functions and logic. Subsequently, after the downstream interface processes the request, it returns a response message to the orchestration gateway. The response message contains the response data to the request, such as JSON, XML or other data formats.

[0054] Step S208, choreographing the response message, scheduling the choreographed response message through the multi-language script engine, and returning the scheduled response message to the client.

[0055] In the above step S208, after receiving the response message, it is also necessary to perform preliminary arrangement processing on the response message, such as format conversion and parameter mapping, to ensure that it complies with the expected format and requirements of the client.

[0056] The response message is then sent to the multi-language script engine for post-script processing. For example, the format of the response message can be further adjusted, additional data can be added, or error processing can be performed according to actual needs to ensure that the response message returned to the client meets business needs. Finally, the response message that has been orchestrated and post-scripted is returned to the client, completing the entire process of API call and service orchestration.

[0057] Through the above steps S202 to S208, the multi-language script engine is used to customize the request message and the response message to meet the ever-changing business needs, thereby achieving the technical effect of efficient management of API services and rapid response to complex needs, thereby solving the technical problem that the data processing in the related technology only supports simple parameter mapping and sequence reorganization when performing API arrangement, and cannot meet more complex business needs, especially the technical problem of customized reconstruction of input and output parameters. The following is a detailed description.

[0058] Figure 3 FIG. 1 is a flow chart of another data processing method according to an embodiment of the present application. Figure 3 As shown in the figure, the core process of the dynamic multi-language capability orchestration solution is more comprehensively demonstrated. Specifically, starting from the client initiating a request, the request message first undergoes preliminary parameter orchestration (mapping) processing at the orchestration gateway, and then is sent to the multi-language script engine for pre-script processing. The multi-language script engine can dynamically load and execute scripts in different programming languages ​​(such as Java, Python, JS), as well as third-party library dependencies, to perform customized data conversion and logic processing on the request message. The processed request message is asynchronously and non-blockingly called by the downstream API interface for actual business processing. After the response message is returned, it is again processed by the parameter orchestration (mapping) of the orchestration gateway and the post-script processing of the multi-language script engine, and finally sent to the client in a format that meets the client's requirements. The entire process reflects the collaborative work between the orchestration gateway and the multi-language script engine, while supporting dynamic and flexible API service orchestration, thereby improving the overall data processing efficiency and business adaptability.

[0059] Optionally, the above method also includes: determining data structure information, wherein the data structure information includes orchestration information, lower-level node information, parameter mapping information and code script information, the data structure information is used to control the interface call process and data processing logic in the request message and the response message, the orchestration information is used to define the global process of different calling interfaces, the lower-level node information is used to describe the detailed information of each calling interface, the parameter mapping information is used to control the parameter mapping between different calling interfaces, the code script information includes a pre-script and a post-script, and the code script information is used to perform specific business logic processing on the request message and the response message.

[0060] In the embodiment of the present application, the data structure information is the core of the control request message and response message processing flow, which includes four key parts: arrangement information, lower-level node information, parameter mapping information and code script information. These information together define the architecture and logic of the service call. Figure 4As shown in the figure, these components are connected through the central node "API orchestration script", and various data structure information is intuitively displayed through branches, providing standard reference information for subsequent data processing processes. Through this structured and configurable approach, the orchestration solution can efficiently and flexibly manage the calling process of API services to meet complex and changing business needs.

[0061] In the above step S204, the request message is arranged, including: determining necessary parameters and non-essential parameters in the request message, wherein the necessary parameters are parameters that meet the requirements of the downstream interface, and the non-essential parameters are parameters that have no direct relationship with the downstream interface or contain sensitive information; deleting the non-essential parameters from the request message, and arranging the necessary parameters into a request format that meets the requirements of the downstream interface.

[0062] In an embodiment of the present application, the process of arranging the request message involves identifying and distinguishing necessary parameters from non-essential parameters in the request message. Among them, necessary parameters refer to those parameter information that are closely related to the business logic of the downstream interface and are necessary for the downstream interface to process the request; while non-essential parameters include additional data that is irrelevant to the specific service call, or fields containing user sensitive information. These parameters are not necessary for the downstream interface and may even cause security or performance issues. Therefore, a sophisticated parameter screening and arrangement mechanism can be used to automatically eliminate non-essential parameters, and at the same time, the necessary parameters are formatted and organized according to the specific requirements of the downstream interface to ensure that the downstream service can receive correct and valid requests. This parameter arrangement strategy not only optimizes the request message and reduces unnecessary data transmission, but also enhances data security and the versatility of the interface, and is a key step in achieving efficient and secure service arrangement.

[0063] Furthermore, scheduling the arranged request message through the multi-language script engine includes: performing pre-script processing on the arranged request message through the multi-language script engine.

[0064] Specifically, the arranged request message is pre-scripted through a multi-language script engine, including: obtaining a third-party package uploaded by a user, and obtaining pre-defined scheduling information, wherein the third-party package is used to provide an additional function library or dependency required for the operation of a script executor in the multi-language script engine, and the scheduled information includes a scheduling order list and a script executor type; obtaining first data information generated by the request message during the data processing process, wherein the first data information is used to represent the context state of the request message; and pre-scripting the request message according to the third-party package, the scheduling information and the first data information.

[0065] In the embodiment of the present application, the pre-script processing is a key step to deeply customize and pre-process the arranged request message through the multi-language script engine. This process involves the deep integration of the scheduling mechanism of the multi-language script engine and the script processing logic, and the specific contents are as follows:

[0066] First, obtain third-party function libraries or dependency packages uploaded by users according to the business logic that needs to be processed. These packages expand the capabilities of the script executor, enabling it to perform more complex and specific functions, such as data encryption, special data format conversion, etc.

[0067] Secondly, obtain predefined scheduling information, which includes a scheduling order list, indicating the execution order of the front-end scripts, and the type of each script executor, that is, which programming language (such as Java, Python, JS) of the script executor is used for processing.

[0068] At the same time, before the script is executed, the multi-language script engine will obtain the first data information generated by the request message during the data processing process. This is usually a record containing the context status of the request message, including but not limited to the request header, request body, parameter mapping results, etc., providing the necessary data basis for script processing.

[0069] Finally, combined with the additional functions provided by the third-party package, the execution order and script executor type defined by the scheduling information, and the context state described by the first data information, the multi-language script engine can perform in-depth pre-script processing on the request message, such as data format conversion, dynamic calculation of parameters, security checks, etc., to ensure that the request message has been pre-processed and meets the input requirements of the downstream interface when it reaches the downstream interface.

[0070] In the above process, the efficiency and flexibility of the front-end script processing greatly improves the adaptability and response speed of the entire orchestration process, and also enhances the security and business processing capabilities of the service. By allowing users to dynamically upload third-party packages and define script processing logic, the orchestration solution in this application can cope with various complex and specific business scenarios and realize highly customized service calls, which is an indispensable and important part of modern API service orchestration.

[0071] In the above step S206, the arranged response message is scheduled by the multi-language script engine, including: performing post-script processing on the arranged response message by the multi-language script engine.

[0072] Specifically, the arranged response message is post-scripted through a multi-language script engine, including: obtaining second data information generated by the response message during the data processing process, wherein the second data information is used to represent the context state of the response message; and post-scripting the response message according to a third-party package, scheduling information and the second data information.

[0073] In the embodiment of the present application, post-script processing is the core part of response message management. It uses a multi-language script engine to deeply transform the orchestrated response message to meet the needs of specific business scenarios. This process is similar to pre-script processing, but focuses on the post-processing stage of the response message. The specific content is as follows:

[0074] First, the second data information is obtained. Specifically, when the response message is returned from the downstream interface to the orchestration processor, the multi-language script engine obtains the second data information generated by the response message during the data processing process. The second data information reflects the current context state of the response message, including but not limited to the format of the response message, the response code, the response data, etc., and provides a key data environment for post-script processing.

[0075] Subsequently, similar to the pre-script processing, the post-script processing also uses the third-party package uploaded by the user, combined with the pre-defined scheduling information, i.e. the script execution order list and the script executor type, and the response message status described by the second data information, to perform in-depth processing on the response message. For example, it includes data format conversion, response data calculation and screening, error handling and response to abnormal situations, etc., to ensure that the response message has undergone necessary post-processing before being returned to the client to meet the specific needs of the client.

[0076] In the above process, post-script processing enhances the customization and flexibility of response messages by dynamically loading and executing multi-language scripts. It allows service orchestration to not only simply forward data, but also deeply intervene at the data level to support complex data operations and business logic execution.

[0077] Figure 5 FIG. 1 is a schematic diagram of a scheduling process of a multi-language script execution engine according to an embodiment of the present application. Figure 5As shown in the figure, the core scheduling mechanism in the dynamic multi-language capability orchestration solution is fully demonstrated. Specifically, the input parameters first enter the scheduling center. The scheduling center schedules multi-language script executors such as Java processors, Python processors, and JS processors according to the script type and the configured execution order, synchronously loads the third-party library dependencies uploaded by the user, and performs in-depth processing of the input parameters in the front script. During the processing, the script executor uses the strategy mode and JSONPath technology to dynamically manage context information, supports the transmission of parameters and data sharing between multiple executors, and ensures the flexible execution of scripts and the correct operation of data. After the processing is completed, the generated intermediate results are returned as output parameters. These output parameters have been customized by multiple rounds of scripts in different languages, and are finally used to build response messages or as input for subsequent service calls.

[0078] Optionally, the method further includes: in the case where there are multiple request messages, processing the multiple request messages and response messages corresponding to the multiple request messages in parallel through a preset network flow framework.

[0079] In an embodiment of the present application, the orchestration processor can use the webflux framework to implement asynchronous non-blocking processing of HTTP requests. Among them, the webflux framework, as a modern non-blocking programming framework based on the Reactor model, is particularly suitable for processing high-concurrency, data-intensive microservice architectures, and can efficiently manage non-blocking I / O operations, significantly improving system response speed and throughput.

[0080] Specifically, when there are multiple request messages, the orchestration processor can use the parallel processing capabilities of the webflux framework to process multiple request messages and their corresponding response messages at the same time, without waiting for one request to complete before processing the next request, avoiding the delays and performance bottlenecks caused by request queuing in the traditional synchronous blocking mode. When processing each request message, the orchestration processor will call the multi-language script engine for pre-script processing, then call the lower-level node in a non-blocking manner, and finally call the multi-language script engine again for post-script processing after obtaining the response message. Since the webflux framework supports responsive programming, the orchestration processor can continue to process other request messages while waiting for the response from the lower-level node, realizing true parallel processing.

[0081] In an embodiment of the present application, by dynamically loading and executing scripts in multiple programming languages, combined with flexible references to third-party libraries, the flexibility and functional extensibility of API orchestration are significantly enhanced. Among them, the pre-script processing ensures the standardization and customization of request messages, while the post-script processing realizes the deep optimization of response messages and meets complex business needs. At the same time, the non-blocking characteristics of the webflux framework are adopted to further enhance the ability to handle high-concurrency requests, realize parallel processing of multiple requests, greatly shorten the response time, optimize resource utilization, and enhance the overall performance and stability of the system. The above technical features jointly build an efficient, flexible and scalable dynamic multi-language orchestration solution, which significantly improves the management efficiency and user experience of API services, thereby improving the efficiency of data processing.

[0082] According to an embodiment of the present application, a data processing device is provided. It should be noted that the data processing device of the embodiment of the present application can be used to execute the data processing method provided by the embodiment of the present application. The data processing device provided by the embodiment of the present application is introduced below.

[0083] Figure 6 is a structural diagram of a data processing device provided according to an embodiment of the present application. Figure 6 As shown, the device comprises:

[0084] A first receiving module 60, configured to receive a request message sent by a client;

[0085] A first arrangement module 62, configured to arrange request messages and schedule the arranged request messages through a multi-language script engine, wherein the multi-language script engine includes a script executor supporting multiple programming languages;

[0086] The second receiving module 64 is used to send the scheduled request message to the downstream interface for processing, and receive a response message corresponding to the request message sent by the downstream interface;

[0087] The second orchestration module 66 is used to orchestrate the response message, schedule the orchestrated response message through the multi-language script engine, and return the scheduled response message to the client.

[0088] Through the first receiving module 60, the first orchestration module 62, the second receiving module 64 and the second orchestration module 66 in the above-mentioned data processing device, it is achieved to use a multi-language script engine to perform customized processing on request messages and response messages to meet ever-changing business needs, thereby achieving the technical effect of efficient management of API services and rapid response to complex needs, and further solving the technical problem that the data processing in the related technology only supports simple parameter mapping and sequence reorganization when performing API orchestration, and cannot meet more complex business needs, especially the technical problem of customized reconstruction of input and output parameters.

[0089] In the data processing device provided in an embodiment of the present application, the first orchestration module is also used to determine necessary parameters and non-essential parameters in the request message, wherein the necessary parameters are parameters that meet the requirements of the downstream interface, and the non-essential parameters are parameters that have no direct relationship with the downstream interface or contain sensitive information; the non-essential parameters are deleted from the request message, and the necessary parameters are orchestrated into a request format that meets the requirements of the downstream interface.

[0090] In the data processing device provided in the embodiment of the present application, the first orchestration module is further used to perform pre-script processing on the orchestrated request message through a multi-language script engine.

[0091] In the data processing device provided in the embodiment of the present application, the first orchestration module is also used to obtain a third-party package uploaded by a user, and to obtain pre-defined scheduling information, wherein the third-party package is used to provide an additional function library or dependency required for the operation of a script executor in a multi-language script engine, and the scheduling information includes a scheduling order list and a script executor type; obtain the first data information generated by the request message during the data processing process, wherein the first data information is used to represent the context state of the request message; and perform pre-script processing on the request message based on the third-party package, the scheduling information and the first data information.

[0092] In the data processing device provided in the embodiment of the present application, the second orchestration module is further used to perform post-script processing on the orchestrated response message through a multi-language script engine.

[0093] In the data processing device provided in an embodiment of the present application, the second orchestration module is also used to obtain second data information generated by the response message during the data processing process, wherein the second data information is used to represent the context state of the response message; and perform post-script processing on the response message based on the third-party package, scheduling information and the second data information.

[0094] An embodiment of the present application also provides an electronic device, including: a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute and implement the above-mentioned data processing method.

[0095] It should be noted that the above electronic equipment is used to execute Figure 2 The data processing method shown, therefore the relevant explanations and instructions in the above data processing method are also applicable to the electronic device and will not be repeated here.

[0096] An embodiment of the present application further provides a non-volatile storage medium, which includes a stored computer program, wherein a device where the non-volatile storage medium is located executes the above-mentioned data processing method by running the computer program.

[0097] It should be noted that the above non-volatile storage medium is used to execute Figure 2 The data processing method shown, therefore the relevant explanations in the above data processing method are also applicable to the non-volatile storage medium, and will not be repeated here.

[0098] An embodiment of the present application also provides a computer program product, including computer instructions, which implement the above-mentioned data processing method when executed by a processor.

[0099] It should be noted that the above-mentioned computer program product is used to execute Figure 2 The data processing method shown, therefore the relevant explanations and instructions in the above data processing method are also applicable to the computer program product and will not be repeated here.

[0100] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0101] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0102] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0103] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0104] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0105] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly or all or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc., which can store program code.

[0106] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data processing method, characterized in that: include: Receive the request message sent by the client; Arranging the request message, and scheduling the arranged request message through a multi-language script engine, wherein the multi-language script engine includes a script executor that supports multiple programming languages; Sending the scheduled request message to the downstream interface for processing, and receiving a response message corresponding to the request message sent by the downstream interface; The response message is arranged, the arranged response message is scheduled by the multi-language script engine, and the scheduled response message is returned to the client.

2. The method according to claim 1, characterized in that Arranging the request message includes: Determine necessary parameters and non-essential parameters in the request message, wherein the necessary parameters are parameters that meet the requirements of the downstream interface, and the non-essential parameters are parameters that are not directly related to the downstream interface or contain sensitive information; The non-essential parameters are deleted from the request message, and the essential parameters are arranged into a request format that complies with the downstream interface.

3. The method according to claim 1, characterized in that The method further comprises: Determine data structure information, wherein the data structure information includes orchestration information, lower-level node information, parameter mapping information and code script information, the data structure information is used to control the interface call process and data processing logic in the request message and the response message, the orchestration information is used to define the global process of different call interfaces, the lower-level node information is used to describe the detailed information of each call interface, the parameter mapping information is used to control the parameter mapping between different call interfaces, the code script information includes a pre-script and a post-script, and the code script information is used to perform specific business logic processing on the request message and the response message.

4. The method according to claim 3, characterized in that: The multi-language script engine is used to schedule the orchestrated request messages, including: The multi-language script engine performs pre-script processing on the arranged request message.

5. The method according to claim 3, characterized in that: Scheduling the arranged response message through the multi-language script engine includes: The multi-language script engine performs post-script processing on the edited response message.

6. The method according to claim 4, characterized in that The multi-language script engine performs pre-script processing on the arranged request message, including: Obtaining a third-party package uploaded by a user and obtaining predefined scheduling information, wherein the third-party package is used to provide an additional function library or dependency required for the script executor in the multi-language script engine to run, and the scheduling information includes a scheduling order list and a script executor type; Acquire first data information generated by the request message during data processing, wherein the first data information is used to indicate a context state of the request message; The request message is pre-scripted according to the third-party package, the scheduling information and the first data information.

7. The method according to claim 6, characterized in that The multi-language script engine performs post-script processing on the arranged response message, including: Acquire second data information generated by the response message during data processing, wherein the second data information is used to indicate a context state of the response message; The response message is post-script processed according to the third-party package, the scheduling information and the second data information.

8. The method according to claim 1, characterized in that The method further comprises: In the case where there are multiple request messages, the multiple request messages and the response messages corresponding to the multiple request messages are processed in parallel through a preset network flow framework.

9. A data processing device, characterized in that: include: A first receiving module, used to receive a request message sent by a client; A first orchestration module, configured to orchestrate the request message and schedule the orchestrated request message through a multi-language script engine, wherein the multi-language script engine includes a script executor that supports multiple programming languages; A second receiving module, used to send the scheduled request message to the downstream interface for processing, and receive a response message corresponding to the request message sent by the downstream interface; The second orchestration module is used to orchestrate the response message, schedule the orchestrated response message through the multi-language script engine, and return the scheduled response message to the client.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the memory is used to store program instructions; The processor is connected to the memory and is used to execute the data processing method described in any one of claims 1 to 8.

11. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the data processing method according to any one of claims 1 to 8 by running the computer program.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the data processing method according to any one of claims 1 to 8 is implemented.

Images