Data request processing methods and electronic devices

By combining DSL configuration files and an execution engine, the problems of verbose code and high maintenance difficulty in multi-version application compatibility are solved, achieving rapid development and low maintenance.

CN115080105BActive Publication Date: 2026-06-30BEIJING SANKUAI ONLINE TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
BEIJING SANKUAI ONLINE TECH CO LTD
Filing Date
2022-05-10
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

Existing technologies, when supporting multiple versions of an application, result in lengthy and poorly readable server-side code, high maintenance difficulty, and cumbersome development of new versions.

Method used

By employing a DSL configuration file and execution engine, the target DSL configuration file is obtained based on the client version information. Data requests are executed through preset routing scripts and access interfaces, reducing the amount of code and simplifying the development process.

Benefits of technology

It improved the speed of new version development, reduced the maintenance pressure of multi-version applications, and simplified code management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115080105B_ABST
    Figure CN115080105B_ABST
Patent Text Reader

Abstract

This application proposes a data request processing method and an electronic device, relating to the field of application multi-version compatibility technology. The data request processing method includes: first, determining the application version information based on a received client data request; then, obtaining a target DSL configuration file for the application matching the version information; and finally, executing the data request using the target DSL configuration file to obtain the target data and return it to the client. This technical solution can improve the development speed of new versions and reduce the maintenance burden of multiple version applications within the server in scenarios requiring application multi-version compatibility.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] This application relates to the field of application version compatibility technology, and more particularly to a data request processing method and an electronic device. [Background Technology]

[0002] Currently, when dealing with the issue of compatibility between multiple application versions, the code logic corresponding to different versions of the application is usually stored on the server side. When a data request is received from the client, the server's processing flow for the data request is as follows: based on the version number carried in the request, the corresponding version's code logic is retrieved and executed, thereby obtaining the execution result and returning it to the client.

[0003] Based on the current approach, multi-version compatibility leads to lengthy, poorly readable, and difficult-to-maintain internal server-side code. Furthermore, even minor feature changes require rewriting code for release, making the process cumbersome and increasing the difficulty of developing new versions. [Summary of the Invention]

[0004] This application provides a data request processing method and an electronic device, which can improve the development speed of new versions and reduce the maintenance pressure of multiple versions of applications on the server side in scenarios where multiple versions of applications are compatible.

[0005] In a first aspect, embodiments of this application provide a data request processing method, comprising: determining application version information based on a received client data request; obtaining a target DSL configuration file based on the version information, wherein the target DSL configuration file is a DSL configuration file of an application that matches the version information; and executing the data request using the target DSL configuration file to obtain target data and return it to the client.

[0006] In one possible implementation, obtaining the target DSL configuration file based on the version information includes: determining the routing information of the target DSL configuration file based on the version information; and obtaining the target DSL configuration file based on the routing information.

[0007] In one possible implementation, determining the routing information of the target DSL configuration file based on the version information includes: executing a preset routing script based on the version information; and determining the routing information of the target DSL configuration file based on the execution result of the preset routing script.

[0008] In one possible implementation, obtaining the target DSL configuration file based on the routing information includes: calling a target access interface based on the routing information; and obtaining the target DSL configuration file through the target access interface.

[0009] In one possible implementation, before determining the application version information based on the received client data request, the method further includes generating the target DSL configuration file.

[0010] In one possible implementation, generating the target DSL configuration file includes: determining the application update content; and, based on the application update content, performing DSL orchestration using a DSL execution engine to generate the target DSL configuration file.

[0011] In one possible implementation, the DSL execution engine's mode type is either a Lua script mode type or a GraphQL script mode type.

[0012] In one possible implementation, after generating the target DSL configuration file, the method further includes: generating the target access interface corresponding to the target DSL configuration file.

[0013] Secondly, embodiments of this application provide a data request processing apparatus, the apparatus comprising: a determining module, configured to determine application version information based on a received client data request; an obtaining module, configured to obtain a target DSL configuration file based on the version information, the target DSL configuration file being a DSL configuration file of an application matching the version information; and an executing module, configured to execute the data request using the target DSL configuration file, obtain target data, and return it to the client.

[0014] Thirdly, embodiments of this application provide an electronic device, including: at least one processor; and at least one memory communicatively connected to the processor, wherein: the memory stores program instructions executable by the processor, and the processor can execute the method as described in the first aspect by invoking the program instructions.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions that cause the computer to perform the method described in the first aspect.

[0016] The above technical solutions can improve the development speed of new versions and reduce the maintenance pressure of multiple versions of applications on the server side in scenarios where multiple versions of applications are compatible. [Attached Image Description]

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A structural diagram of a data request processing system provided in an embodiment of this application;

[0019] Figure 2 A flowchart illustrating a data request processing method provided in an embodiment of this application;

[0020] Figure 3 A flowchart illustrating another data request processing method provided in this application embodiment;

[0021] Figure 4 This is a schematic diagram of the structure of a data request processing device provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application.

Detailed Implementation Methods

[0023] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0024] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0025] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0026] Figure 1 This is a structural diagram of a data request processing system provided in an embodiment of this application. Figure 1 As shown, the data request processing system provided in this application embodiment may include a development terminal 01, a management terminal 02, and a server terminal 03.

[0027] The development end 01 can be used to launch the Domain-Specific Language (DSL) execution engine and generate DSL configuration files for various versions of the application (APP) based on the DSL execution engine. The DSL execution engine can encapsulate various simplified configuration syntaxes and preset functions. In this embodiment, the mode type of the DSL execution engine can be either a Lua script mode type or a GraphQL script mode type.

[0028] Management terminal 02 can be used to store the DSL configuration files generated by development terminal 01 and manage and maintain the DSL configuration files for different versions of each APP. Additionally, management terminal 02 can also be used to generate access interfaces for different versions of the DSL configuration files for each APP and manage and maintain each access interface. Furthermore, management terminal 02 can also be used to send the configuration information of the corresponding access interface to server terminal 03 based on the interface call request from server terminal 03.

[0029] Server 03 can be used to receive data requests from clients and process the received data requests based on the DSL configuration file stored in management terminal 02 to obtain the target data and return it to the client.

[0030] The data request processing system provided in this application can be used to execute the data request processing method provided in this application.

[0031] Figure 2 This is a flowchart illustrating a data request processing method provided in an embodiment of this application. Figure 2 As shown, the above data request processing method may include:

[0032] Step 101: The server determines the application version information based on the received client data request.

[0033] Step 102: The server obtains the DSL configuration file of the target APP that matches the version information based on the version information.

[0034] In this embodiment of the application, in a scenario where multiple versions of the APP are compatible, the management terminal can store the DSL configuration files corresponding to each version of the APP. When the server receives a data request from the client, such as a POST request, it can call the corresponding version of the DSL configuration file from the management terminal to process the data request and obtain the target data.

[0035] Specifically, the data request may include the version information of the app currently installed on the client. Based on this, the server can determine the app's version information according to the data request.

[0036] Furthermore, the server can determine the routing information of the DSL configuration file of the APP that matches the version information based on the obtained version information. For ease of description, the DSL configuration file of the APP that matches the version information will be referred to as the target DSL configuration file below. In this embodiment, the server can be configured with a preset routing script. After obtaining the version information, the preset routing script can be executed according to the version information. Based on the execution result of the preset routing script, the routing information of the target DSL configuration file can be obtained.

[0037] Finally, the server can obtain the target DSL configuration file based on the routing information. Specifically, the management system can configure different access interfaces for different versions of the DSL configuration file. After obtaining the routing information, the server can call the target interface corresponding to the target DSL configuration file. Then, the target DSL configuration file can be obtained through the target interface.

[0038] Step 103: The server uses the target DSL configuration file to execute a data request, obtains the target data, and returns it to the client.

[0039] To improve the speed of result generation when executing data requests, such as Figure 3 As shown, the execution process, including calling the service communication framework MTransport, calling JavaService, and retrieving the configuration center Lion, can be executed in parallel. Then, the server can aggregate the execution results from each process, generate the target data, and return it to the client.

[0040] In the above technical solution, for scenarios requiring compatibility across multiple app versions, each app version provides services via a DSL configuration file. The server can call the target DSL configuration file through the target access interface and utilize the services provided by the target DSL configuration file to complete the data request processing flow. This DSL configuration file approach reduces code volume, increases the development speed of new application versions, and lowers the maintenance burden of multiple application versions.

[0041] In another embodiment of this application, the process of generating and publishing the target configuration file in the above embodiments is described.

[0042] In this embodiment, the development end 01 can start the DSL execution engine, which provides simplified configuration syntax and various preset functions. During the development phase of a new version of the APP, DSL orchestration can be performed based on the DSL execution engine according to the APP update content to generate the APP's target DSL configuration file.

[0043] Compared with the existing technology's new version development process, this application does not require a complex code writing process, which helps to simplify the development process and improve development speed; moreover, providing services in the form of DSL configuration files effectively reduces the difficulty of version maintenance.

[0044] After development end 01 completes the development of the new version of the APP, management end 02 can execute the project startup process. Specifically, in response to the project startup command, management end 02 can retrieve the target DSL configuration file corresponding to the new version of the APP from development end 01. Then, development end 01 can generate and publish the target access interface corresponding to the target DSL configuration file. This target access interface can be used by server end 03 to call the services provided by the target DSL configuration file.

[0045] In the above technical solution, each version of the APP provides services through DSL configuration files. The development of new versions can be completed using only a general service execution engine and a small amount of DSL coding, which reduces the amount of code, improves the development speed of new version APP, and reduces the maintenance pressure of multiple version APP.

[0046] Figure 4 This is a schematic diagram of the structure of a data request processing device provided in an embodiment of this application. Figure 4 As shown, the data request processing device provided in this application embodiment may include: a determination module 41, an acquisition module 42, and an execution module 43.

[0047] The determination module 41 is used to determine the version information of the application based on the received client data request.

[0048] The acquisition module 42 is used to acquire the target DSL configuration file based on the version information. The target DSL configuration file is the DSL configuration file of the application that matches the version information.

[0049] Execution module 43 is used to execute a data request using the target DSL configuration file, obtain the target data, and return it to the client.

[0050] In a specific implementation, module 42 is specifically used to determine the routing information of the target DSL configuration file based on the version information; and to obtain the target DSL configuration file based on the routing information.

[0051] In a specific implementation, module 42 is specifically used to execute a preset routing script based on version information; and to determine the routing information of the target DSL configuration file based on the execution result of the preset routing script.

[0052] In a specific implementation, module 42 is used to call the target access interface based on routing information and obtain the target DSL configuration file through the target access interface.

[0053] In a specific implementation, the above-mentioned device also includes a generation module 44 for generating a target DSL configuration file.

[0054] In a specific implementation process, the generation module 44 is specifically used to determine the application update content; based on the application update content, it performs DSL orchestration based on the DSL execution engine and generates the target DSL configuration file.

[0055] In a specific implementation, the DSL execution engine can be either a Lua script mode type or a GraphQL script mode type.

[0056] In a specific implementation, the generation module 44 is also used to generate the target access interface corresponding to the target DSL configuration file.

[0057] The above technical solutions can improve the development speed of new versions and reduce the maintenance pressure of multiple versions of applications on the server side in scenarios where multiple versions of applications are compatible.

[0058] Figure 5 A schematic diagram of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device may include at least one processor; and at least one memory communicatively connected to the processor, wherein the memory stores program instructions executable by the processor, and the processor can execute the data request processing method provided in the embodiments of this application by calling the program instructions.

[0059] The aforementioned electronic device can be a data request processing device, and this embodiment does not limit the specific form of the aforementioned electronic device.

[0060] Figure 5 A block diagram of an exemplary electronic device suitable for implementing embodiments of the present application is shown. Figure 5 The electronic device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0061] like Figure 5 As shown, the electronic device is represented in the form of a general-purpose computing device. The components of the electronic device may include, but are not limited to: one or more processors 410, memory 430, communication interface 420, and communication bus 440 connecting different system components (including memory 430 and processor 410).

[0062] Communication bus 440 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MAC) buses, Enhanced ISA buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0063] Electronic devices typically include a variety of computer-readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, and removable and non-removable media.

[0064] Memory 430 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc read-only memory (CD-ROM), a digital video disc read-only memory (DVD-ROM), or other optical media). In these cases, each drive can be connected to the communication bus 440 via one or more data media interfaces. The memory 430 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0065] A program / utility having a set (at least one) of program modules can be stored in memory 430. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0066] The electronic device can also communicate with one or more external devices (such as a keyboard, pointing device, display, etc.), and with one or more devices that enable a user to interact with the electronic device, and / or with any device that enables the electronic device to communicate with one or more other computing devices (such as a network card, modem, etc.). This communication can be performed through communication interface 420. Furthermore, the electronic device can also communicate through a network adapter ( Figure 5 (Not shown) communicates with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet). The aforementioned network adapter can communicate with other modules of the electronic device via communication bus 440. It should be understood that, although... Figure 5 Not shown, other hardware and / or software modules can be used in conjunction with electronic devices, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0067] The processor 410 executes various functional applications and data processing by running programs stored in the memory 430, such as implementing the data request processing method provided in the embodiments of this application.

[0068] This application also provides a computer-readable storage medium that stores computer instructions that cause the computer to execute the data request processing method provided in this application.

[0069] The aforementioned computer-readable storage medium may be 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. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in connection with an instruction execution system, apparatus, or device.

[0070] 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 transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0071] The 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.

[0072] 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).

[0073] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0074] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0075] 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 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0076] 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.

[0077] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data request processing method, characterized in that, include: Determine the application version information based on the received client data request; Based on the version information, obtain the target domain-specific language DSL configuration file, where the target DSL configuration file is the DSL configuration file of the application that matches the version information; The data request is executed using the target DSL configuration file to obtain the target data and return it to the client; Before determining the application version information based on the received client data request, the target DSL configuration file is generated. Generating the target DSL configuration file includes: determining the application update content; performing DSL orchestration based on the application update content using a DSL execution engine to generate the target DSL configuration file, wherein the DSL execution engine provides a simplified configuration syntax and various preset functions; and executing a data request using the target DSL configuration file to obtain the target data and return it to the client.

2. The method according to claim 1, characterized in that... Based on the version information, obtain the target DSL configuration file, including: Based on the version information, determine the routing information of the target DSL configuration file; Based on the routing information, obtain the target DSL configuration file.

3. The method according to claim 2, characterized in that, Based on the version information, determine the routing information of the target DSL configuration file, including: Execute the preset route script based on the version information; Based on the execution result of the preset routing script, the routing information of the target DSL configuration file is determined.

4. The method according to claim 2, characterized in that, Based on the routing information, the target DSL configuration file is obtained, including: The target access interface is invoked based on the routing information; The target DSL configuration file is obtained through the target access interface.

5. The method according to claim 1, characterized in that, The DSL execution engine is of either Lua script mode or GraphQL script mode type.

6. The method according to claim 1, characterized in that, After generating the target DSL configuration file, the method further includes: Generate the target access interface corresponding to the target DSL configuration file.

7. An electronic device, characterized in that, include: At least one processor; as well as At least one memory communicatively connected to the processor, wherein: The memory stores program instructions that can be executed by the processor, and the processor can execute the method as described in any one of claims 1 to 6 by calling the program instructions.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause the computer to perform the method as described in any one of claims 1 to 6.