A method and related apparatus for invoking a service

Abstract

This application discloses a method and related apparatus for invoking a service, relating to the field of vehicle diagnostics. The method includes: inputting an OTX script into a code generator to generate target code, the OTX script specifying multiple invocation parameters; invoking multiple target functions based on the target code, passing multiple invocation parameters to the target functions, each target function pre-encapsulating at least a portion of the invocation code required to invoke its corresponding standard function; and, when the invocation parameters meet preset conditions, invoking multiple standard functions based on the target functions and the invocation parameters, passing the invocation parameters to the standard functions, and invoking a dynamic link library through the standard functions to sequentially create a target service provider and execute the target service using the target service provider. This application pre-encapsulates at least a portion of the invocation code required to invoke the standard functions into multiple target functions, thereby significantly reducing the amount of code generated by the code generator and thus lowering maintenance costs.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a service invocation method and related apparatus. Background Technology

[0002] With the increasing number of electronic control units in automobiles, the complexity of vehicle diagnostics is growing daily. To address this challenge, the International Organization for Standardization (ISO) standard ISO 13209 defines OTX (Open Test Sequence Exchange). The OTX standard, through the ExternalServiceProvider extension mechanism, allows OTX scripts to call standard functions such as CreateProvider and ExecuteService in the runtime library, and through these standard functions, call external DLLs (Dynamic Link Libraries) to implement various algorithmic functions commonly used in vehicle diagnostics, such as secure access algorithms, encryption / decryption, random number generation, and manufacturer-defined algorithms.

[0003] In practical applications, users can use an editor to convert their input into an OTX script. The OTX script is then sent to a code generator. The code generator receives the OTX script and generates the calling code required to invoke standard functions in the runtime library according to the ISO 13209 standard. However, during the generation of the calling code, the code generator needs to explicitly generate code to create multiple intermediate objects such as OtxLink and OtxName and perform type conversion operations step by step, resulting in verbose code and high maintenance costs. Summary of the Invention

[0004] In view of the above problems, this application provides a service invocation method and related apparatus to significantly reduce the amount of code generated by the code generator, thereby reducing maintenance costs. The specific solution is as follows:

[0005] The first aspect of this application provides a service invocation method, including:

[0006] An OTX script is generated based on the target input content, and the OTX script is input into the code generator to generate target code. The OTX script is used to specify multiple calling parameters, including the name of the target service provider and the name of the target service in the target service provider.

[0007] Based on the target code, multiple target functions are called, and the multiple call parameters are passed to the multiple target functions. The multiple target functions pre-encapsulate at least part of the call code required to call their respective standard functions.

[0008] When the calling parameters meet the preset conditions, multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters, and the calling parameters are passed to the standard functions. Dynamic link libraries are called through the multiple standard functions to create the target service provider and execute the target service using the target service provider.

[0009] In one possible implementation, if the calling parameters meet preset conditions, multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters, including:

[0010] Obtain a list of preset service provider names, wherein the list of preset service provider names includes the names of multiple service providers;

[0011] If the name of the target service provider is not in the preset service provider name list, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

[0012] In one possible implementation, the multiple objective functions include a first function and a second function, and the method further includes:

[0013] If the name of the target service provider belongs to the preset service provider name list, then according to the first function, a service provider object is created, and the name of the target service provider is assigned as a type identifier to the service provider object to create the target service provider;

[0014] According to the second function, the operating system API is invoked using the type identifier of the target service provider to execute the service corresponding to the target service name.

[0015] In one possible implementation, the plurality of calling parameters further includes input parameters and output parameters, the plurality of standard functions include a first standard function and a second standard function, the composition of the calling parameters required to be passed to the first standard function is fixed; the composition of the calling parameters required to be passed to the second standard function varies with the number and type of input parameters and output parameters, and the plurality of target functions include a first function corresponding to the first standard function and a second function corresponding to the second standard function;

[0016] Based on the target code, call multiple target functions, including:

[0017] Obtain the number and type of the input parameters and the number and type of the output parameters;

[0018] A second function is selected from a plurality of preset functions based on the number and type of the input parameters and the number and type of the output parameters; wherein the plurality of preset functions pre-encapsulate at least part of the calling code required to call the second standard function, and different preset functions correspond to different numbers and types of input and output parameters.

[0019] In one possible implementation, multiple standard functions are called sequentially based on the plurality of target functions and the plurality of calling parameters, including:

[0020] Obtain the function pointer of the standard function corresponding to the target function, and determine whether the function pointer is null;

[0021] If the function pointer is null, log an error and return an error code;

[0022] If the function pointer is not null, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

[0023] In one possible implementation, the objective function is an inline function.

[0024] In one possible implementation, the method further includes:

[0025] Based on the target code, a third function is invoked, which encapsulates the calling code required to invoke a third standard function;

[0026] After the target service is completed, the third standard function is called according to the third function to release the resources occupied by the target service provider through the third standard function.

[0027] A second aspect of this application provides a service invocation apparatus, comprising:

[0028] A generation module is used to generate an OTX script based on the target input content and input the OTX script into a code generator to generate target code through the code generator. The OTX script is used to specify multiple calling parameters, including the name of the target service provider and the name of the target service in the target service provider.

[0029] The first calling module is used to call multiple target functions according to the target code, and to pass the multiple calling parameters to the multiple target functions. The multiple target functions pre-encapsulate at least part of the calling code required to call their respective standard functions.

[0030] The second calling module is used to, when the calling parameters meet preset conditions, sequentially call multiple standard functions according to the multiple target functions and the multiple calling parameters, and pass the calling parameters to the standard functions, and call dynamic link libraries through the multiple standard functions to sequentially create the target service provider and execute the target service using the target service provider.

[0031] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the service invocation method described in the first aspect or any implementation thereof.

[0032] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0033] The memory is used to store computer programs;

[0034] The processor is used to execute the computer program so that the electronic device can implement the service invocation method of the first aspect or any implementation thereof.

[0035] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to invoke the service method described in the first aspect or any implementation thereof.

[0036] Using the above technical solution, this application provides a service invocation method. The user first generates an OTX script based on their self-written diagnostic process (target input content). This OTX script specifies the target service provider to be invoked (e.g., a random number service) and the specific target service within that provider (e.g., obtaining random numbers). Then, the OTX script is transmitted to a code generator, which generates target code based on the OTX script. Next, based on the generated target code, multiple target functions are invoked, passing the invocation parameters specified in the OTX script (e.g., service provider name and service name) to these target functions. These target functions pre-encapsulate at least part of the invocation code for their respective standard functions (e.g., CreateProvider, ExecuteService, etc.). When the invocation parameters meet a certain preset condition, these target functions invoke their respective standard functions, passing in the invocation parameters as well. Then, these standard functions invoke dynamic link libraries, ultimately creating the target service provider first, and then using the target service provider to execute the target service. In this embodiment, the calling code required to call the standard function is pre-encapsulated into multiple target functions. This eliminates the need for the code generator to explicitly generate lengthy code for creating intermediate objects and type conversion. Instead, it only needs to generate concise code to call the target function and pass the calling parameters to the target function during the call. This allows the standard function to be called to create the target service provider and execute the target service, thereby significantly reducing the amount of code generated by the code generator and thus lowering maintenance costs. Attached Figure Description

[0037] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0038] Figure 1 This application provides an architectural diagram of a service invocation system.

[0039] Figure 2 A flowchart illustrating a service invocation method provided in this application;

[0040] Figure 3 A functional architecture diagram of a service invocation system provided in this application;

[0041] Figure 4 This is a schematic diagram of the structure of a service invocation device provided in an embodiment of this application;

[0042] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0043] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0044] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0045] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0046] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100 and a server 200. The server 200 can provide the methods provided in the embodiments of this application to one or more terminals.

[0047] The terminal 100 may have an OTX script editing application installed. The application and webpage can provide an interface. The terminal 100 can receive relevant parameters entered by the user on the OTX script editing interface and send the parameters to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.

[0048] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters on its own, without the need for the server to cooperate. This application embodiment is not limited to this.

[0049] The following description Figure 1 The product form of the mid-terminal 100;

[0050] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0051] Terminal 100 may include a radio frequency unit, memory, input unit, display unit, camera (optional), audio circuitry (optional), speaker (optional), microphone (optional), headphone jack (optional), processor, external interface, power supply, and other components. Those skilled in the art will understand that the above-mentioned components are merely examples and do not constitute a limitation on the terminal or multifunctional device; it may include more or fewer components, or a combination of certain components, or different components.

[0052] The input unit can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit may include a touchscreen (optional) and / or other input devices. Other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0053] Among them, the input device can receive input data, etc.

[0054] The display unit can be used to display information input by the user or information provided to the user, various menus of the terminal, interactive interfaces, file display, and / or playback of any multimedia file. In the embodiments of this application, the display unit can be used to display the interface of service calls, processing results, etc.

[0055] The memory can be used to store software code related to the service call method, the processor can execute the steps of the service call method, and can also schedule other units (such as the input unit and display unit mentioned above) to achieve the corresponding functions.

[0056] This radio frequency unit (optional) can be used to receive and send signals during information transmission or calls.

[0057] In this embodiment of the application, the radio frequency unit can send data to the server 200 and receive the processing results sent by the server 200.

[0058] It should be understood that this radio frequency unit is optional and can be replaced with other communication interfaces, such as a network port.

[0059] Terminal 100 also includes a power source (such as a battery) for supplying power to the various components.

[0060] Terminal 100 also includes an external interface, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0061] Server 200 includes a bus, a processor, a communication interface, and memory. The processor, memory, and communication interface communicate with each other via the bus.

[0062] The memory can be used to store software code related to the service call method, the processor can execute the steps of the chip's service call method, and can also schedule other units to achieve the corresponding functions.

[0063] First, a definition of the terminology used in this application is provided:

[0064] OTX (Open Test Sequence eXchange): An automotive diagnostic test sequence description language defined by the ISO 13209 standard, used to write diagnostic scripts that are independent of specific vehicle platforms.

[0065] ISO 13209 standard: The OTX standard published by the International Organization for Standardization, used to standardize the description format and runtime interface of automotive diagnostic test sequences.

[0066] DLL (Dynamic Link Library): A file format used in the Windows operating system to encapsulate reusable code and data, supporting dynamic loading and calling by programs at runtime.

[0067] Secondly, to facilitate those skilled in the art to understand the technical solutions provided in the embodiments of this application, the relevant technologies are described below: In the automotive diagnostic scenario, the security access algorithms of different models (e.g., ECU unlocking algorithms of different manufacturers) are different, and it is impossible to integrate all the algorithms into the diagnostic software in advance. Therefore, it is necessary to use these security access algorithms by dynamically loading and calling external service DLLs. In order to load and call external service DLLs, the ISO 13209 standard defines a runtime library, which provides standard functions such as CreateProvider, ExecuteService, and DisposeProvider to load and call external service DLLs. On this basis, the code generator needs to explicitly generate all the intermediate step code required to call the runtime library interface according to the requirements of the ISO 13209 standard, including creating intermediate objects, performing type conversion, packaging parameters, calling standard functions, etc., and finally completing the call to the external service DLL. The existing implementation method calls the following: (1) Create a service provider: Create a first OtxLink object (i.e., create an intermediate object) and assign the service provider name to the link value field of the first OtxLink object (i.e., type conversion). Create a ServiceProvider object. The first OtxLink object and ServiceProvider object, after being assigned values, are passed as parameters to the CreateProvider function in the runtime library (i.e., calling the standard function). The CreateProvider function reads the service provider name from the link value field of the first OtxLink object and loads the corresponding external service DLL based on the name. After loading, the CreateProvider function obtains information from the external service DLL, including at least the type string of the service provider and the function pointers required to call the service in the DLL. The CreateProvider function fills this information into the ServiceProvider object. (2) Execute the service: Obtain the type string of the service provider corresponding to the ServiceProvider object from the ServiceProvider object filled above. Create a second OtxLink object (i.e., create an intermediate object) and assign the type string to the link value field of the second OtxLink object. Create an OtxName object (i.e., create an intermediate object) and assign the service name to the name field of the OtxName object. Create a parameter list and add the input and output parameters to the parameter list one by one. Pass the second OtxLink object, OtxName object, ServiceProvider object and parameter list as parameters to the ExecuteService function in the runtime library (i.e., calling the standard function).The ExecuteService function determines the service provider based on the type string in the second OtxLink object, determines the specific service based on the service name in the OtxName object, then retrieves the previously stored function pointer from the ServiceProvider object, calls the corresponding function in the external service DLL through the function pointer, reads the input parameters from the parameter list and passes them to the function to execute the service logic, and writes the output result back to the output parameter position in the parameter list. After the call is completed, the output parameters are read from the parameter list to obtain the service execution result. (3) Release resources: Pass the ServiceProvider object as a parameter and call the DisposeProvider function in the runtime library to release the resources occupied by the ServiceProvider object.

[0068] However, there are several problems with the above approach: (1) Each time an external service DLL is called, the code generator needs to generate 10 to 15 lines of code. This code involves the explicit creation of multiple intermediate objects such as OtxLink objects and OtxName objects, as well as type conversion operations, which leads to an increase in the size of the generated code. It is difficult for developers to understand and debug, and modifying a service call requires modifying multiple parts of the code, resulting in high maintenance costs. (2) The developers of the code generator need to write corresponding code generation templates for each ESP call scenario (e.g., no parameters, single output, input / output, multiple parameters, etc.). Since there are many combinations of interface parameters in the ISO standard, developers may miss the corresponding type conversion steps for some uncommon parameter combinations when writing code generation templates. This may lead to repeated type conversion code generated by the code generator, and it is also easy to miss conversion steps, which may lead to runtime errors. (3) When the ISO standard is upgraded or a new service type is added, the template of the code generator needs to be modified. During the modification process, the synchronous update of some type conversion steps may be missed. This may lead to repeated type conversion code generated by the code generator, and it is also easy to miss conversion steps, which may lead to runtime errors. (4) If the runtime library fails to load, calling a null pointer will cause the program to crash. (5) Simple services (such as random number generation) also need to call external DLLs through standard functions, increasing deployment complexity.

[0069] To address the aforementioned problems, this application provides a service invocation method. The service invocation method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0070] Reference Figure 2 , Figure 2 This is a flowchart illustrating a service invocation method provided in an embodiment of this application, such as... Figure 2As shown in the embodiment of this application, a method for invoking a service may include steps 200 to 204, which are described in detail below.

[0071] 200. Generate an OTX script based on the target input content, and input the OTX script into the code generator to generate target code. The OTX script specifies multiple calling parameters, including the name of the target service provider and the name of the target service within that provider.

[0072] Specifically, target input content can be entered into an editor (e.g., an OTX script editor) according to diagnostic needs. After receiving the target input content, the editor can automatically generate an OTX script. The OTX script can be a script file conforming to the ISO 13209 standard format, used to describe the diagnostic process. The OTX script can specify multiple calling parameters. These parameters can include the name of the target service provider (e.g., random number service) and the name of the target service within the target service provider (e.g., get random number). Other parameters may also be included, which will be described in the following embodiments and will not be repeated here. In this embodiment, by pre-encapsulating the code required to call the standard function within the target function, only a single line of concise code is needed to complete the call to the standard function, thereby simplifying the calling interface and reducing the amount of code. In some embodiments, besides generating the OTX script through an editor, it can also be generated by calling the API interface of the OTX generation service or using a predefined OTX script template.

[0073] After generating the OTX script, you can click the Generate or Export button, as follows: Figure 3 As shown, the code generator automatically reads the OTX script in the background and generates target code based on the OTX script. The target code can be a C++ source code file. In some embodiments, the target code can be saved to a specified output directory so that users can later open, view, or modify the target code using an editor or IDE (such as Visual Studio).

[0074] 202. Based on the target code, call multiple target functions and pass the multiple call parameters to the multiple target functions. The multiple target functions pre-encapsulate at least part of the call code required to call their respective standard functions.

[0075] Specifically, each of the multiple target functions pre-encapsulates at least a portion of the calling code required to invoke its corresponding standard function. Each target function corresponds to one standard function. The specific encapsulated calling code within each target function will be described in the following embodiments and will not be repeated here. The multiple target functions can be pre-existing in a code repository, which can be a local code repository or a cloud code repository. The standard function can refer to the runtime library interface function defined by the ISO 13209 standard. When invoking a target function, multiple calling parameters specified in the OTX script can be passed to the target function, enabling the target function to perform corresponding operations based on these calling parameters.

[0076] There are several ways to call multiple target functions from target code, such as direct invocation, conditional invocation, and nested invocation. Direct invocation means that the call statement in the target code specifies the name of the target function to be called, and subsequent calls are made sequentially according to the order specified in the target code. Conditional invocation means that one of multiple target functions is selected for invocation based on the call parameters. Nested invocation means that a target function calls another target function internally; for example, the target function that executes the service can call the service provider object created by the target function that creates the service provider. Exemplary schemes for calling multiple target functions are provided below.

[0077] In one possible implementation, the plurality of calling parameters may further include input parameters and output parameters. The plurality of standard functions include a first standard function and a second standard function. The composition of the calling parameters required by the first standard function is fixed. The composition of the calling parameters required by the second standard function varies with the number and type of input and output parameters. The plurality of target functions include a first function corresponding to the first standard function and a second function corresponding to the second standard function. The specific operation process of step 202 may include: obtaining the number and type of the input parameters and the number and type of the output parameters; selecting a second function from a plurality of preset functions based on the number and type of the input parameters and the number and type of the output parameters. The plurality of preset functions pre-encapsulate at least part of the calling code required to call the second standard function, and different preset functions correspond to different numbers and types of input and output parameters.

[0078] Specifically, multiple standard functions can include a first standard function and a second standard function. The first standard function is used to load the dynamic link library and create a service provider, such as `CreateProvider`. This first standard function does not call the service functions in the dynamic link library; it only loads the dynamic link library, obtains service information, and populates the service provider object. The second standard function is used to call the service functions in the dynamic link library to execute the service, such as `ExecuteService`. The composition of the call parameters refers to the number and type of parameters required when calling a function (standard function). For example, if calling a standard function requires two parameters, the first being a string and the second an integer, then the call parameters for that standard function consist of two parameters: the first is a string, and the second is an integer. In this embodiment, the call parameters required for each call to the first standard function include the service provider name. The number of parameters corresponding to the service provider name is one, and the parameter type is string. The call parameters required for each call to the second standard function include the service provider object, the service name, and a parameter list. The service provider object and service name have a fixed structure. The parameter type of the service provider object is the service provider class type, and the parameter type of the service name is a string type. Both have one parameter. The structure of the parameter list varies depending on the number and type of the input and output parameters. The parameter list can be a container for holding input and output parameters. Input parameters can be data passed to the dynamic link library when calling the service, and output parameters can be data returned from the dynamic link library after the service execution. Specifically, the number and type of parameters in the parameter list will differ depending on the number or type of input and output parameters specified in the OTX script. For example, when the OTX script specifies only one output parameter, the parameter list contains one output parameter item; when the OTX script specifies one input parameter and one output parameter, the parameter list contains one input parameter item and one output parameter item; when the OTX script specifies multiple input parameters and multiple output parameters, the parameter list contains multiple input parameter items and multiple output parameter items.

[0079] like Figure 3As shown, multiple target functions include a first function corresponding to the first standard function and a second function corresponding to the second standard function. The first function encapsulates the program code required to call the first standard function. The second function encapsulates the program code required to call the second standard function. Specifically, (1) the first function can encapsulate the program code to perform the following operations: create an OtxLink object, assign the name of the target service provider to the OtxLink object (this process is type conversion), and check whether the function pointer of the standard function for creating the target service provider is null (this process is null value checking). If the function pointer is null, the first function records the error and returns (this process is error handling); if the function pointer is not null, the first function uses the assigned OtxLink object as a call parameter to call the first standard function, which is used to load the dynamic link library and create the target service provider. (2) create an OtxName object, assign the name of the target service to the OtxName object, create a parameter list based on the input and output parameters, and pass the parameter list as a call parameter to the second standard function (this process is parameter packaging). Then, check whether the function pointer of the second standard function is null. If the function pointer is null, the second function logs the error and returns (this process is called error handling). If the function pointer is not null, the second function calls the standard function that executes the service (the second standard function), passing the target service provider, the OtxName object, and the parameter list as call parameters. The second standard function executes the specific service logic and writes the result to the output parameters. It should be noted that the target function does not contain the implementation code of the standard function itself; the implementation code of the standard function is stored in the runtime library. Of course, multiple target functions may also include other functions, which will be described in the following examples and will not be repeated here.

[0080] Because the composition of the call parameters required by the second standard function varies depending on the number and type of input and output parameters, multiple different versions of the second function (preset functions) need to be pre-defined. Each second function corresponds to a specific combination of the number and type of input and output parameters. For example, when the OTX script specifies neither input nor output parameters, the parameterless version of the second function is selected; when the OTX script specifies only output parameters, the single-output version is selected; when the OTX script specifies both input and output parameters, the input-output version is selected; and when the OTX script specifies multiple input and multiple output parameters, the multi-parameter version is selected. "Parameterless" can mean that no data needs to be passed in or returned when calling the service, such as resetting a device or enabling a function. "Single-output" can mean that no data needs to be passed in when calling the service, but a result needs to be returned, such as generating a random number or getting the current time. "Input-output" can mean that some data needs to be passed in when calling the service, and the processed result needs to be returned. For example, inputting a seed and outputting a key. Multiple parameters refer to the requirement that a service call must input multiple data types and return multiple different types of results. For example, an encryption service (inputting a key, encryption mode, and original data; returning the encrypted data and its length). Figure 3 As shown, a second function can be selected from multiple preset functions based on the number and type of input parameters and the number and type of output parameters (this process is called overload decision).

[0081] In this embodiment, by pre-encapsulating the calling code inside the target function, the code generator no longer needs to explicitly generate lengthy code for creating intermediate objects and type conversion; it only needs to generate concise code for calling the target function.

[0082] The above describes how to call multiple target functions based on the target code. The following will introduce how to call standard functions through target functions, and then call dynamic link libraries to complete the creation of the target service provider and the execution of the target service.

[0083] 204. If the calling parameters meet the preset conditions, according to the multiple target functions and the multiple calling parameters, multiple standard functions are called sequentially, and the calling parameters are passed to the standard functions. Dynamic link libraries are called through the multiple standard functions to create the target service provider and execute the target service using the target service provider.

[0084] Specifically, it can be first determined whether the calling parameters meet preset conditions. Multiple standard functions are only called if the calling parameters meet the preset conditions. Multiple standard functions can be called sequentially according to a preset order based on multiple target functions and multiple calling parameters. The preset order could be: first calling the standard function for creating the service provider (corresponding to the first standard function below), then calling the standard function for executing the service (corresponding to the second standard function below), and finally calling the standard function for releasing resources (corresponding to the third standard function below). It should be noted that the third standard function and resource release will be described in detail in the following embodiments and will not be repeated here. There are several ways to call standard functions: standard functions can be called by function name, by function pointer, or indirectly through interface functions provided by the runtime library, etc.

[0085] There are several ways to determine whether a call parameter meets preset conditions, such as based on a list of service provider names, based on flags, based on naming rules, or based on the content of the input parameters. Taking a naming rule-based approach as an example, it can determine whether the name of the target service provider conforms to a certain naming rule, such as starting with a specific prefix or ending with a specific suffix. If it conforms to the naming rule, then the call parameter is considered to meet the preset conditions.

[0086] To effectively ensure that the program does not crash if the runtime library is not loaded correctly, in one possible implementation, step 204 may include: obtaining the function pointer of the standard function corresponding to the target function, and determining whether the function pointer is null. If the function pointer is null, an error log is recorded and an error code is returned. If the function pointer is not null, multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

[0087] Specifically, a function pointer can be a pointer variable that points to the address of a function's entry point. In this embodiment, the implementation code of multiple standard functions is stored in the runtime library. When the program starts, it needs to load the entry addresses of each standard function from the runtime library and store these entry addresses in the corresponding function pointers. For example, the function pointer of the standard function for creating a service provider points to the entry address of the CreateProvider function, the function pointer of the standard function for executing a service points to the entry address of the ExecuteService function, and the function pointer of the standard function for releasing resources points to the entry address of the DisposeProvider function. If the runtime library fails to load, the function pointer may be null. A null pointer is a pointer that does not point to any valid function address. If the program directly calls a function through a null pointer, it will cause the program to crash. To effectively avoid this situation, the target function can obtain the function pointer of the corresponding standard function before calling it and check whether the function pointer is null. The specific checking process is as follows: First, the target function obtains the function pointer of the standard function corresponding to itself. For example, the first function obtains the function pointer of the standard function for creating a service provider, the second function obtains the function pointer of the standard function for executing a service, and the third function obtains the function pointer of the standard function for releasing resources. The second step is to compare these function pointers with null values, such as checking if a function pointer is equal to NULL or nullptr. The third step is that if these function pointers are null, it indicates that the runtime library has not been loaded correctly. The target function logs an error and returns the corresponding error code. The error log can contain information such as the time, location, and cause of the error. The error code is an integer value used to represent the type of error; for example, "1" indicates that the runtime library has not been loaded, and "2" indicates that the function pointer is invalid. If the function pointers are not null, it indicates that the runtime library has been loaded correctly, and the target function can directly call the corresponding standard function.

[0088] In this embodiment, it is determined whether the function pointer of the standard function corresponding to the target function is null: if it is null, an error is recorded and an error code is returned; if it is not null, the corresponding standard function is called, so that the program will not crash due to calling a null pointer when the runtime library fails to load.

[0089] In one possible implementation, step 204 may include: obtaining a list of preset service provider names, wherein the list of preset service provider names includes the names of multiple service providers; if the name of the target service provider is not in the list of preset service provider names, then calling multiple standard functions sequentially according to the multiple target functions and the multiple calling parameters.

[0090] Specifically, a list of preset service provider names can be obtained from a local configuration file or a server. This list is pre-configured and can contain the names of multiple service providers. Each name in the list corresponds to a built-in service. A built-in service can be a service that is directly implemented by the target function without needing to call a dynamic link library through standard functions. For example, a built-in service named "Random Number Service" corresponds to a random number generation function, and a built-in service named "Byte Conversion Service" corresponds to a byte conversion function. It should be noted that in existing solutions, even a simple random number generation function requires loading an external DLL (Dynamic Link Library) and calling functions within that DLL. This application's embodiments can set these general, vendor-specific algorithms as built-in services, pre-implemented in code within the target function (e.g., directly calling operating system APIs). When an OTX script requests to call these services, the target function directly executes the internal code without needing to load and call external DLLs through standard functions, thus reducing unnecessary overhead.

[0091] After obtaining the list of preset service provider names, it can be determined whether the name of the target service provider belongs to this list. Specifically, this can be done by iterating through each name in the preset service provider name list and comparing the target service provider's name with each name in the list. If a name matching the target service provider's name exists in the preset service provider name list, then the target service provider's name belongs to the list; otherwise, if no matching name is found after iterating through the list, then the target service provider's name does not belong to the list. If the target service provider's name does not belong to the preset service provider name list, the standard function for creating the service provider (first standard function) can be called first, passing the target service provider's name to the first standard function. Then, the dynamic link library is loaded and the target service provider is created using the first standard function. Next, the standard function for executing the service (second standard function) is called second, passing the target service provider, the target service's name, and a parameter list, where the parameter list may include input and / or output parameters. Finally, the service function in the dynamic link library is called using the second standard function to execute the specific service logic. For example, the target service provider is named "Encryption Service," the target service is named "AES Encryption," the input parameters include "key" and "raw data," and the output parameter includes "encryption result." In this case, the first standard function loads the dynamic link library corresponding to the encryption service and creates the target service provider. The second standard function uses this service provider to call the AES encryption function in the dynamic link library, passing in the key and raw data, executing the encryption logic, and writing the encryption result to the output parameter. If the name of the target service provider belongs to a preset list of service provider names, the processor can use an alternative processing method that does not require calling the dynamic link library through the standard function. This processing method will be described in the following embodiments.

[0092] In this embodiment, the standard function is called through the target function and then the dynamic link library is called only when the name of the target service provider is not in the preset service provider name list. This distinguishes between built-in services and external services (i.e. services that need to be loaded and called from the dynamic link library), avoids unnecessary dynamic link library loading and calling overhead, and improves service execution efficiency.

[0093] In one possible implementation, the multiple target functions include a first function and a second function. The service invocation method may further include: if the name of the target service provider belongs to the preset service provider name list, then according to the first function, creating a service provider object and assigning the name of the target service provider as a type identifier to the service provider object to create the target service provider; according to the second function, using the type identifier of the target service provider to invoke the operating system API to execute the service corresponding to the target service name.

[0094] Specifically, a service provider object can be created according to the first function, and the name of the target service provider can be assigned as the type identifier to the service provider object to complete the creation of the target service provider. The service provider object can be a data structure or a class instance. The service provider object can contain a type identifier field, a status field, etc. The type identifier is a string or an enumeration value used to identify which type of built-in service the service provider is. For example, the type identifier can be "random number service" or "byte conversion service". There are several ways to create a service provider object: (1) A new service provider object instance can be created directly through the constructor. (2) A service provider object can be obtained from a preset object pool. After creating the service provider object, the name of the target service provider can be assigned as the type identifier to the service provider object to obtain the target service provider.

[0095] After creating the target service provider, the second function can be used to invoke the operating system's application programming interface (API) using the target service provider's type identifier to execute the service corresponding to the target service name. The operating system's application programming interface is a function interface provided by the operating system to perform specific system-level functions. For example, in Windows, random number generation can be implemented by calling the CryptGenRandom interface. In Linux, random number generation can be implemented by reading the / dev / urandom device file. Byte conversion can be implemented by calling the byte order conversion functions provided by the operating system.

[0096] In this embodiment, when the target service provider name belongs to a preset list, a service provider object is created through the first function and a type identifier is assigned. Then, the second function directly calls the operating system API to execute the service based on the type identifier, without going through standard functions and dynamic link libraries, thereby simplifying the call path and improving service execution efficiency.

[0097] In one possible implementation, the objective function is an inline function.

[0098] The target function is implemented as an inline function. When compiling the target code, the compiler embeds the function body directly into the location where the function is called. During program execution, there is no need to execute function jump instructions; the code inside the target function can be executed sequentially, thereby improving program efficiency.

[0099] There are several ways to implement inline functions. For example, you can use the `inline` keyword in the function declaration or definition, and the compiler will expand the function into inline based on this marker. You can also use compiler-provided forced inline directives, such as `__attribute__((always_inline))` in the GCC compiler or `__forceinline` in the MSVC compiler, to force the compiler to expand the function into inline. Alternatively, you can write the function definition directly inside the class definition body, and the compiler will automatically treat it as an inline function. This embodiment is not limited to the specific methods listed above. Of course, the target function can also be a template function, etc. In some embodiments, a preprocessor can be used to simplify the output of the code generator.

[0100] In one possible implementation, the service invocation method may further include: invoking a third function based on the target code, the third function encapsulating the invocation code required to invoke a third standard function; and, after the target service has been executed, invoking the third standard function based on the third function to release the resources occupied by the target service provider through the third standard function.

[0101] Specifically, in addition to calling the corresponding standard functions through the first and second functions, a third function can also be called based on the target code. The third function encapsulates the calling code required to invoke the third standard function. This third standard function is a standard function used to release resources occupied by the target service provider object, such as `DisposeProvider`. Figure 3As shown, the third function can encapsulate program code that performs the following operations: It checks if the function pointer of the standard function for releasing resources is null (this process is called null checking). If the function pointer is null, the third function records an error and returns (this process is called error handling). If the function pointer is not null, the third function calls the standard function for releasing resources (the third standard function). Then, it releases the resources occupied by the target service provider through the third standard function (this process is called resource management). The resources occupied by the target service provider can include memory resources, handle resources, and dynamic link library resources. Memory resources refer to the memory space occupied by the target service provider itself. Handle resources refer to resource handles allocated to the target service provider by the operating system, such as file handles or synchronization object handles. Dynamic link library resources refer to the resources occupied by previously loaded dynamic link libraries, such as the image of the dynamic link library in memory. It should be noted that the third standard function does not need to call external DLLs. The third standard function mainly releases resources allocated internally by the runtime library for the ServiceProvider object. Although it may trigger the unloading of loaded DLLs (such as calling FreeLibrary), this is a resource cleanup operation within the runtime library, not a call to the service function in the DLL.

[0102] In this embodiment, after the target service is completed, the third standard function can be automatically called through the third function to release the resources occupied by the target service provider, thereby improving system stability and resource utilization efficiency.

[0103] The above describes a service invocation method provided by an embodiment of this application. The following describes the apparatus for executing the above service invocation method.

[0104] Please see Figure 4 , Figure 4 This is a schematic diagram of a service invocation device provided in an embodiment of this application. Figure 4 As shown, the service invocation device 400 includes:

[0105] The generation module 401 is used to generate an OTX script based on the target input content and input the OTX script into the code generator to generate target code through the code generator. The OTX script is used to specify multiple calling parameters, including the name of the target service provider and the name of the target service in the target service provider.

[0106] The first calling module 402 is used to call multiple target functions according to the target code, and to pass the multiple calling parameters to the multiple target functions. The multiple target functions pre-encapsulate at least part of the calling code required to call their respective standard functions.

[0107] The second calling module 403 is used to, when the calling parameters meet preset conditions, sequentially call multiple standard functions according to the multiple target functions and the multiple calling parameters, and pass the calling parameters to the standard functions, and call dynamic link libraries through the multiple standard functions to sequentially create the target service provider and execute the target service using the target service provider.

[0108] In one possible implementation, the second calling module 403 is specifically used for:

[0109] Obtain a list of preset service provider names, wherein the list of preset service provider names includes the names of multiple service providers;

[0110] If the name of the target service provider is not in the preset service provider name list, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

[0111] In one possible implementation, the multiple target functions include a first function and a second function, and the service invocation device 400 further includes an execution module for:

[0112] If the name of the target service provider belongs to the preset service provider name list, then according to the first function, a service provider object is created, and the name of the target service provider is assigned as a type identifier to the service provider object to create the target service provider;

[0113] According to the second function, the operating system API is invoked using the type identifier of the target service provider to execute the service corresponding to the target service name.

[0114] In one possible implementation, the plurality of calling parameters further includes input parameters and output parameters, the plurality of standard functions include a first standard function and a second standard function, the composition of the calling parameters required to be passed to the first standard function is fixed; the composition of the calling parameters required to be passed to the second standard function varies with the number and type of input parameters and output parameters, and the plurality of target functions include a first function corresponding to the first standard function and a second function corresponding to the second standard function;

[0115] The first calling module 402 is specifically used for:

[0116] Obtain the number and type of the input parameters and the number and type of the output parameters;

[0117] A second function is selected from a plurality of preset functions based on the number and type of the input parameters and the number and type of the output parameters; wherein the plurality of preset functions pre-encapsulate at least part of the calling code required to call the second standard function, and different preset functions correspond to different numbers and types of input and output parameters.

[0118] In one possible implementation, the second calling module 403 is specifically used for:

[0119] Obtain the function pointer of the standard function corresponding to the target function, and determine whether the function pointer is null;

[0120] If the function pointer is null, log an error and return an error code;

[0121] If the function pointer is not null, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

[0122] In one possible implementation, the objective function is an inline function.

[0123] In one possible implementation, the service invocation device 400 further includes a third invocation module, used for:

[0124] Based on the target code, a third function is invoked, which encapsulates the calling code required to invoke a third standard function;

[0125] After the target service is completed, the third standard function is called according to the third function to release the resources occupied by the target service provider through the third standard function.

[0126] This application also provides an electronic device in its embodiments. (See reference...) Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing the service invocation method in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0127] like Figure 5As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. When the electronic device is powered on, the RAM 503 also stores various programs and data required for the operation of the electronic device. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0128] Typically, the following devices can be connected to I / O interface 505: input devices 505 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, memory cards, hard drives, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0129] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the service invocation methods provided in this application.

[0130] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the service invocation methods provided in this application.

[0131] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0132] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0133] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0134] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A service invocation method, characterized in that, include: An OTX script is generated based on the target input content, and the OTX script is input into the code generator to generate target code. The OTX script is used to specify multiple calling parameters, including the name of the target service provider and the name of the target service in the target service provider. Based on the target code, multiple target functions are called, and the multiple call parameters are passed to the multiple target functions. The multiple target functions each pre-encapsulate at least part of the call code required to call their respective standard functions. When the calling parameters meet the preset conditions, multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters, and the calling parameters are passed to the standard functions. Dynamic link libraries are called through the multiple standard functions to create the target service provider and execute the target service using the target service provider.

2. The method according to claim 1, characterized in that, If the calling parameters meet preset conditions, multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters, including: Obtain a list of preset service provider names, wherein the list of preset service provider names includes the names of multiple service providers; If the name of the target service provider is not in the preset service provider name list, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

3. The method according to claim 2, characterized in that, The method further includes multiple objective functions, including a first function and a second function, and also includes: If the name of the target service provider belongs to the preset service provider name list, then according to the first function, a service provider object is created, and the name of the target service provider is assigned as a type identifier to the service provider object to create the target service provider; According to the second function, the operating system API is invoked using the type identifier of the target service provider to execute the service corresponding to the target service name.

4. The method according to claim 1, characterized in that, The multiple calling parameters also include input parameters and output parameters. The multiple standard functions include a first standard function and a second standard function. The composition of the calling parameters required to be passed to the first standard function is fixed. The composition of the calling parameters required to be passed to the second standard function varies with the number and type of input parameters and output parameters. The multiple target functions include a first function corresponding to the first standard function and a second function corresponding to the second standard function. Based on the target code, call multiple target functions, including: Obtain the number and type of the input parameters and the number and type of the output parameters; Based on the number and type of the input parameters and the number and type of the output parameters, a second function is selected from a plurality of preset functions; wherein, the plurality of preset functions pre-encapsulate at least part of the calling code required to call the second standard function, and different preset functions correspond to different numbers and types of input and output parameters.

5. The method according to claim 1, characterized in that, Based on the multiple target functions and the multiple calling parameters, multiple standard functions are called sequentially, including: Obtain the function pointer of the standard function corresponding to the target function, and determine whether the function pointer is null; If the function pointer is null, log an error and return an error code; If the function pointer is not null, then multiple standard functions are called sequentially according to the multiple target functions and the multiple calling parameters.

6. The method according to any one of claims 1 to 5, characterized in that, The objective function is an inline function.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Based on the target code, a third function is invoked, which encapsulates the calling code required to invoke a third standard function; After the target service is completed, the third standard function is called according to the third function to release the resources occupied by the target service provider through the third standard function.

8. A service invocation device, characterized in that, include: A generation module is used to generate an OTX script based on the target input content and input the OTX script into a code generator to generate target code through the code generator. The OTX script is used to specify multiple calling parameters, including the name of the target service provider and the name of the target service in the target service provider. The first calling module is used to call multiple target functions according to the target code, and to pass the multiple calling parameters to the multiple target functions. The multiple target functions pre-encapsulate at least part of the calling code required to call their respective standard functions. The second calling module is used to, when the calling parameters meet preset conditions, sequentially call multiple standard functions according to the multiple target functions and the multiple calling parameters, and pass the calling parameters to the standard functions, and call dynamic link libraries through the multiple standard functions to sequentially create the target service provider and execute the target service using the target service provider.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the service invocation method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the service invocation method as described in any one of claims 1 to 7.

Images