Service invocation methods, devices, electronic devices, storage media, and program products

Abstract

This application provides a service invocation method, apparatus, electronic device, storage medium, and program product. In this method, external service providers can register services on a service gateway on their own. Internal service providers can generate processing events for the target service as needed and call back to the external service providers through the service gateway. The service gateway can complete the callback service based on the internal general parameters and registration identifier generated by the external service providers. That is, this application utilizes the service gateway to provide special service customization capabilities, eliminating the need for internal business code development, effectively reducing development costs, and enabling code decoupling between internal and external service providers, which is helpful for subsequent code maintenance and iteration.

Description

Technical Field

[0001] This application relates to the field of application development technology, and more specifically, to a service invocation method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] A platform that provides open capabilities refers to an open platform that can provide resources and services to external development organizations. External development organizations can access the platform's open services to jointly extend their business chains and expand their business scenarios.

[0003] For open platforms, when dealing with special services or external development organizations with customized needs, they typically provide internal business code development support to enable the development of custom and non-standard requirements. However, this type of service integration places high demands on development costs, and the development process is laborious and time-consuming. Summary of the Invention

[0004] The purpose of this application is to solve the technical problem of high development costs in service access.

[0005] According to one aspect of the embodiments of this application, a service invocation method is provided, applied to a service gateway, the method comprising:

[0006] Obtain the registration information of the external service provider for the target service. The registration information includes the external service provider's custom callback interface information.

[0007] Based on the registration information, generate a registration identifier and internal general parameters related to the target service;

[0008] In response to a callback request from an internal service provider to an external service provider, the system invokes the external service provider based on internal common parameters and registration identifiers to notify the external service provider of the processing events of the target service by the internal service provider.

[0009] In one alternative implementation, the method further includes:

[0010] Obtain service provider information from external service providers;

[0011] After generating the registration identifier and internal general parameters related to the target service based on the registration information, the following are also included:

[0012] Establish the primary association between the registration identifier and the service provider information;

[0013] Based on internal common parameters and registration identifiers, external service providers are invoked, including:

[0014] Based on internal common parameters, registration identifiers, and service provider information, external service providers are invoked.

[0015] In one optional implementation, after generating a registration identifier and internal generic parameters related to the target service based on the registration information, the method further includes:

[0016] Establish a second association between callback interface information and registration identifier.

[0017] In one optional implementation, the registration information also includes externally defined parameters;

[0018] Based on the registration information, generate internal general parameters related to the target service, including:

[0019] Map externally defined parameters to internally common parameters that are relevant to the target service.

[0020] In one alternative implementation, based on internal common parameters and registration identifiers, an external service provider is invoked, including:

[0021] Based on the registration identifier, determine the callback interface of the external service provider;

[0022] Map internal generic parameters to externally defined parameters;

[0023] Based on externally defined parameters and callback interfaces, call external service providers.

[0024] In one alternative implementation, the callback interface includes an HTTP interface and / or a Remote Procedure Call (RPC) interface.

[0025] If the callback interface includes a remote procedure call interface, the callback interface information includes the software development kit and RPC interface parameters.

[0026] In one optional implementation, obtaining the registration information of the external service provider for the target service includes:

[0027] In response to a service access request, display the registration interface;

[0028] Based on the input on the registration interface, obtain the registration information of the external service provider for the target service.

[0029] In one optional implementation, after generating a registration identifier and internal generic parameters related to the target service based on the registration information, the method further includes:

[0030] In response to a test request initiated by an external service provider, the test request carries relevant test data and generates a test response result;

[0031] Based on internal common parameters and registration identifiers, the system calls external service providers and notifies them of the test response results.

[0032] According to another aspect of the embodiments of this application, a service invocation method is provided, applied to an internal service provider, the method comprising:

[0033] For any external service provider, generate a processing event for the target service;

[0034] Based on the internal common parameters and registration identifier of the external service provider, a callback request is sent to the service gateway so that the service gateway can call the external service provider based on the external service provider's custom callback interface information and notify the external service provider of the processing event.

[0035] According to another aspect of the embodiments of this application, a service gateway is provided, the service gateway comprising:

[0036] The registration module is used to obtain the registration information of external service providers for the target service. The registration information includes the external service provider's custom callback interface information.

[0037] The generation module is used to generate a registration identifier and internal general parameters related to the target service based on the registration information.

[0038] The calling module is used to respond to callback requests from internal service providers to external service providers. Based on internal common parameters and registration identifiers, it calls external service providers to notify them of the processing events of the target service by the internal service providers.

[0039] In one optional implementation, the service gateway may further include: an acquisition module for acquiring service provider information of external service providers;

[0040] After generating the registration identifier and internal generic parameters related to the target service based on the registration information, the generation module is also used for:

[0041] Establish the primary association between the registration identifier and the service provider information;

[0042] When the calling module is used to call external service providers based on internal common parameters and registration identifiers, it is specifically used for:

[0043] Based on internal common parameters, registration identifiers, and service provider information, external service providers are invoked.

[0044] In one alternative implementation, after generating a registration identifier and internal general parameters related to the target service based on the registration information, the generation module is further configured to: establish a second association between the callback interface information and the registration identifier.

[0045] In one optional implementation, the registration information also includes externally defined parameters;

[0046] When the generation module is used to generate internal generic parameters related to the target service based on registration information, it is specifically used for:

[0047] Map externally defined parameters to internally common parameters that are relevant to the target service.

[0048] In one alternative implementation, when the calling module invokes an external service provider based on internal general parameters and a registration identifier, it is specifically used for:

[0049] Based on the registration identifier, determine the callback interface of the external service provider;

[0050] Map internal generic parameters to externally defined parameters;

[0051] Based on externally defined parameters and callback interfaces, call external service providers.

[0052] In one alternative implementation, the callback interface includes an HTTP interface and / or a Remote Procedure Call (RPC) interface.

[0053] If the callback interface includes a remote procedure call interface, the callback interface information includes the software development kit and RPC interface parameters.

[0054] In one optional implementation, when the registration module is used to obtain registration information from external service providers for the target service, it is specifically used for:

[0055] In response to a service access request, display the registration interface;

[0056] Based on the input on the registration interface, obtain the registration information of the external service provider for the target service.

[0057] In an optional implementation, the service gateway may further include: a testing module, which, after the generation module generates a registration identifier and internal generic parameters related to the target service based on the registration information, is used to:

[0058] In response to a test request initiated by an external service provider, the test request carries relevant test data and generates a test response result;

[0059] Based on internal common parameters and registration identifiers, the system calls external service providers and notifies them of the test response results.

[0060] According to another aspect of the embodiments of this application, an internal service provider is provided, the internal service provider comprising:

[0061] The processing module is used to generate processing events for the target service for any external service provider.

[0062] The callback module is used to send a callback request to the service gateway based on the internal common parameters and registration identifier of the external service provider. The service gateway then calls the external service provider based on the external service provider's custom callback interface information and notifies the external service provider of the processing event.

[0063] According to another aspect of the embodiments of this application, a service invocation system is provided, which includes a service gateway provided in the embodiments of this application and an internal service provider provided in the embodiments of this application.

[0064] According to another aspect of the embodiments of this application, an electronic device is provided, the electronic device including: a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of a service invocation method executed by a service gateway.

[0065] According to another aspect of the embodiments of this application, another electronic device is provided, the electronic device including: a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of a service invocation method executed by an internal service provider.

[0066] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of a service invocation method executed by a service gateway are implemented.

[0067] According to another aspect of the embodiments of this application, another computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of a service invocation method executed by an internal service provider are implemented.

[0068] According to another aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of a service invocation method executed by a service gateway.

[0069] According to another aspect of the embodiments of this application, another computer program product is provided, including a computer program that, when executed by a processor, implements the steps of a service invocation method executed by an internal service provider.

[0070] The service invocation method, apparatus, electronic device, storage medium, and program product provided in this application embodiment allow external service providers to register services on the service gateway independently. Internal service providers can generate processing events for the target service as needed and call back to the external service provider through the service gateway. The service gateway can complete the callback service based on the internal general parameters and registration identifier generated by the external service provider's registration. In other words, this application embodiment utilizes the service gateway to provide special service customization capabilities, eliminating the need for internal business code development, effectively reducing development costs, and enabling code decoupling between internal and external service providers, which is beneficial for subsequent code maintenance and iteration. Attached Figure Description

[0071] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0072] Figure 1 A schematic diagram of the architecture for the service callback implementation scenario provided in the embodiments of this application;

[0073] Figure 2 A flowchart illustrating a service invocation method provided in an embodiment of this application;

[0074] Figure 3 A schematic diagram illustrating the service gateway calling the HTTP callback interface provided in an embodiment of this application;

[0075] Figure 4 A schematic diagram illustrating the service gateway calling the RPC callback interface provided in an embodiment of this application;

[0076] Figure 5 A flowchart illustrating another service invocation method provided in an embodiment of this application;

[0077] Figure 6 This is a schematic diagram of the structure of a service gateway provided in an embodiment of this application;

[0078] Figure 7 This application provides a schematic diagram of the structure of an internal service provider.

[0079] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0080] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0081] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented information, data, steps, operations, elements, and / or components, but do not exclude implementation as other features, information, data, steps, operations, elements, components, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the element can be directly connected or coupled to the other element, or it can mean that the element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0082] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0083] When opening up capabilities, capability open platforms typically define some standard interfaces, including standard callback interfaces. External development organizations can provide callback interfaces according to these standards so that the internal business processing systems of the open platform can correctly perform callbacks.

[0084] However, some external development organizations that can provide specialized services cannot provide callback interfaces according to the above standards and can only provide custom callback interfaces. The existing solution for adapting these types of interfaces is to develop code to integrate the interface provided by the other party.

[0085] It is not difficult to understand that the existing solutions have the following technical problems:

[0086] 1. The code development is relatively complex, time-consuming, and labor-intensive, resulting in high development costs;

[0087] 2. The high coupling between special services and internal business code makes management inconvenient and affects subsequent code maintenance and iteration.

[0088] The service invocation methods, apparatus, electronic devices, storage media, and program products provided in this application are intended to solve the above-mentioned technical problems of existing solutions.

[0089] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0090] Figure 1 This is a schematic diagram of the architecture for a service callback implementation scenario provided in an embodiment of this application. Figure 1 As shown, this implementation scenario includes internal service providers, service gateways, and external service providers.

[0091] In this embodiment, the internal service provider refers to a platform that provides open capabilities, which may be called an internal business processing system, or simply an internal business system or internal system, but is not limited to these names. In practical applications, the internal service provider may include one or more business systems or business terminals. For example, taking the delivery industry as an example, the internal service provider may include a delivery resource scheduling system, an order allocation system, a delivery resource terminal, an order-related merchant terminal, a user terminal, etc., but is not limited to these. Among them, terminal devices include, but are not limited to, mobile terminals, smart terminals, such as mobile phones, smartphones, tablet computers, laptops, personal digital assistants, portable multimedia players, navigation devices, etc. Those skilled in the art will understand that, in addition to components specifically designed for mobile purposes, the construction according to the embodiments of this application can also be applied to fixed-type terminals, such as digital televisions, desktop computers, etc.

[0092] External service providers refer to platforms provided by external organizations or individuals that require access to the open services of internal service providers. These platforms may be called external service systems, external business systems, external access systems, or external developers, and can be simply referred to as external systems, but are not limited to these names. In this application's embodiments, the external service provider can refer to an external service provider that cannot provide callback interfaces according to the standards provided by the internal service provider, i.e., an external service provider that can only provide custom / non-standard callback interfaces.

[0093] A service gateway is a pre-defined platform that interfaces with external service providers. It allows external service providers to register their services and corresponding custom / non-standard callback interfaces for internal service providers to call. Internal service providers' business systems or terminals can indirectly call back to external service providers by invoking the service gateway. The service gateway only needs to focus on the callback interfaces of external service providers and does not need to be aware of their business processing flows.

[0094] This application provides a service invocation method, such as... Figure 2 As shown, applied to a service gateway, the method includes:

[0095] Step S101: Obtain the registration information of the external service provider for the target service. The registration information includes the callback interface information customized by the external service provider.

[0096] In this context, a target service refers to a service that an external service provider aims to access within the open services provided by the internal provider. In practice, there can be one or more target services.

[0097] Registration information for the target service refers to the relevant information entered by the external service provider when registering for the target service. Optionally, during the service registration process, the service gateway can provide a selection of open services, such as displaying the names, codes, and other identifiers of each open service. Alternatively, the name, code, and other identifiers of the target service can be directly entered by the external service provider, or the target service can be determined in other ways. This embodiment of the application does not limit this.

[0098] Optionally, in addition to the target service information and the external service provider's custom callback interface information, the registration information may also include other information as needed. This includes, but is not limited to, service description, execution parameters, parameter descriptions, external service provider information, relevant configuration files, and the submitter.

[0099] Step S102: Based on the registration information, generate a registration identifier and internal general parameters related to the target service.

[0100] After an external service provider completes its registration with the service gateway, the service gateway automatically generates a registration identifier (RegisterCode). This registration identifier is associated with the target service and / or registration information (such as callback interface information) for that registration. In other words, an external service provider can register multiple registration identifiers for different target services and / or registration information.

[0101] In this embodiment of the application, after this step, an association relationship (i.e., a second association relationship) can be established between the callback interface information and the registration identifier. That is, an association relationship is established between the callback interface corresponding to the callback interface information and the registration identifier, so that when calling back an external service provider, the corresponding callback interface can be quickly found through the registration identifier.

[0102] Internal common parameters (Param) are parameters common to all internal service providers. In this embodiment, by generating internal common parameters, internal service providers do not need to pay attention to the parameters defined by external service providers for the target service. When calling back to external service providers, internal service providers can provide internal common parameters, reducing the complexity of the internal service system.

[0103] In the embodiments of this application, the method of generating internal general parameters is not specifically limited. For example, it can be generated by matching the parameters defined by the external service provider, or it can be generated using models such as neural networks.

[0104] Optionally, the internal general parameters can adopt a map structure, which makes the number of parameters more flexible, easy to expand, with low coupling, and fast query and update speed.

[0105] After generating the registration identifier and internal common parameters, it can wait for processing by the internal service provider. When the internal service provider needs to call back to the external service provider for the processing event of the target service, it will send a callback request to the service gateway, that is, call back to the external service provider by invoking the service gateway.

[0106] Step S103: In response to the callback request from the internal service provider to the external service provider, based on the internal common parameters and registration identifier, the external service provider is invoked to notify the external service provider of the processing event of the target service by the internal service provider.

[0107] In this embodiment, the callback interface of the external service provider can be a custom / non-standard callback interface (i.e., not provided according to the standard callback interface defined by the internal service provider). In other embodiments, the callback interface can also be in other forms.

[0108] In this embodiment, based on internal general parameters and registration identifiers, the external service provider can be called through the pre-agreed callback interface to notify the external service provider of the current processing event of the internal service provider, thus completing the callback from the internal service provider to the external service provider.

[0109] Optionally, the service gateway provides a service gateway interface to internal service providers, allowing them to invoke the service gateway. This service gateway interface requires specifying internal common parameters and registration identifiers, as well as other parameters required by the callback interface. Upon receiving the parameters specified by the internal service provider, the service gateway invokes the corresponding callback interface to complete the callback to the external service provider corresponding to that interface.

[0110] The technical solutions provided in this application can be applied to open platforms related to the instant delivery field. In one example, the open capabilities of the internal service provider include, but are not limited to, the following two:

[0111] 1. When the transportation capacity meets its own needs, it will open up its transportation capacity to external service providers for access, that is, open up delivery resources to deliver the orders of external service providers.

[0112] 2. There is also some external transportation capacity that can be connected as a supplement to the internal transportation capacity, that is, opening up orders to allocate to external delivery resources for delivery.

[0113] In other words, the aforementioned target services include, but are not limited to, services related to at least one of the following businesses: capacity provision services, capacity utilization services, etc. The specific service processing content can be set according to actual circumstances, and this application embodiment does not limit it.

[0114] The service invocation method provided in this application embodiment, through a low-code service gateway, allows external service providers to register their services independently with the service gateway for custom / non-standard callback interfaces. Internal service providers can generate processing events for the target service as needed and call back to the external service providers through the service gateway. The service gateway can complete the callback service based on the internal general parameters and registration identifier generated by the external service provider's registration. Compared with existing solutions, this method has the following advantages:

[0115] 1. Utilize the service gateway to provide special service customization capabilities without the need for internal business code development, effectively reducing development costs.

[0116] 2. It can also decouple the code of internal service providers from that of external service providers, which is helpful for subsequent code maintenance and iteration and facilitates management.

[0117] 3. Reduce the complexity of internal systems.

[0118] 4. The interface agreement process is more self-service and standardized.

[0119] In this embodiment, the service gateway also provides external service provider identity registration. External service providers can register their identities by entering their relevant information into the service gateway, such as merchant information, but not limited to this. After identity registration is complete, the service gateway automatically generates a service provider identifier (for ease of description, it can be abbreviated as AppId) and automatically stores the service provider information of the external service provider, including but not limited to the external service provider's identity information and service provider identifier. Only the corresponding service provider information and service provider identifier are associated with and stored for each external service provider. In other words, the service provider identifier is a unique identifier for each external service provider.

[0120] In this embodiment, the timing of external service provider identity registration is not specifically limited. For example, it can be real-time registration, where the external service provider registers its identity first, and then registers for the target service (i.e., service registration). Alternatively, if the external service provider has not registered its identity after registering for the target service, it can be prompted to register. Another example is historical registration, where if the external service provider has already registered its information, it does not need to register again for different target services; it can directly register for the target service based on its existing information (e.g., after logging in).

[0121] Based on this, the service invocation method provided in this application embodiment further includes the step of: obtaining the service provider information of the external service provider.

[0122] It's understandable that service provider information is automatically stored regardless of whether it's registered in real-time or historically. This step allows retrieval of external service provider information stored by the service gateway.

[0123] Furthermore, following step S102, the method further includes the step of establishing an association between the registration identifier and the service provider information (i.e., the first association). This means establishing an association between the registration identifier and the service provider identifier (i.e., binding the registration identifier and the service provider identifier).

[0124] Furthermore, in step S103, calling an external service provider based on internal general parameters and registration identifier may include the following steps: calling an external service provider based on internal general parameters, registration identifier, and service provider information.

[0125] In this embodiment of the application, combined with the second association relationship (the association relationship between callback interface information and registration identifier), a third association relationship (the association relationship between callback interface information (the corresponding callback interface) and service provider identifier) ​​is also established. Therefore, when calling back an external service provider, the corresponding callback interface can be more reliably located using the service provider identifier and registration identifier. Then, based on internal general parameters, registration identifier, and service provider information, the external service provider can be invoked through the pre-agreed callback interface to notify the external service provider of the current processing event of the internal service provider, thus completing the callback from the internal service provider to the external service provider.

[0126] Optionally, when an internal service provider calls the service gateway's interface, it needs to specify internal general parameters, a registration identifier, a service provider identifier, and other parameters required by the callback interface. Upon receiving the parameters specified by the internal service provider, the service gateway calls the corresponding callback interface to complete the callback to the external service provider corresponding to that interface.

[0127] In this embodiment, the registration information of the external service provider for the target service may also include externally defined parameters. Therefore, in step S102, based on the registration information, generating internally common parameters related to the target service includes mapping the externally defined parameters to internally common parameters related to the target service.

[0128] Here, externally defined parameters refer to the execution parameters defined by external service providers. In this embodiment, the service gateway provides an internal / external parameter mapping mechanism, meaning that the internally common parameters used by internal service providers can be matched with the externally defined parameters required by the callback interface. For internal service providers, only the internally common parameters generated during registration are exposed; for external service providers, only the externally defined parameters registered are exposed, which can reduce the complexity of both service systems simultaneously.

[0129] In this embodiment, the specific mapping relationship of the internal and external parameter mapping mechanism is not specifically limited, and can vary depending on the business and service. Those skilled in the art can set it according to the actual situation.

[0130] Furthermore, in step S103, calling an external service provider based on internal general parameters and registration identifier may include the following steps:

[0131] Step S1031: Determine the callback interface of the external service provider based on the registration identifier;

[0132] That is, the callback interface of the external service provider is determined based on the registration identifier and the second association relationship (the association relationship between the callback interface and the registration identifier).

[0133] Optionally, the callback interface of the external service provider can be determined based on the registration identifier and the service provider identifier, thereby ensuring the accuracy of the callback interface.

[0134] That is, based on the registration identifier and the second association, as well as the service provider identifier and the third association (the association between the callback interface and the service provider identifier), the callback interface of the external service provider is determined.

[0135] Step S1032: Map internal general parameters to externally defined parameters;

[0136] Specifically, according to the internal and external parameter mapping mechanism provided in the embodiments of this application, the internal general parameters used by the internal service provider can be mapped to obtain the externally defined parameters registered by the external service provider.

[0137] Step S1033: Call the external service provider based on externally defined parameters and callback interfaces.

[0138] Based on externally defined parameters and callback interfaces, the service gateway can call external service providers to complete the callback from internal service providers to external service providers by registering the agreed-upon callback interfaces.

[0139] In this embodiment of the application, the callback interface includes an HTTP (Hyper Text Transfer Protocol) interface and / or an RPC (Remote Procedure Call) interface.

[0140] For HTTP interfaces, the callback interface information includes the special link HTTP URL (Uniform Resource Locator) information.

[0141] In the embodiments of this application, when an external service provider registers an HTTP service, it can enter a URL address and parameters (i.e., externally defined parameters) into the service gateway. After registration is completed, the service gateway will automatically generate a registerCode and map the new parameters used by the internal service provider (i.e., internal general parameters).

[0142] The internal service provider uses the registerCode (or registerCode and AppId) and internal common parameters to call the gateway service. The gateway service finds the external URL based on the registerCode (or registerCode and AppId) and maps the internal common parameters to externally defined parameters to call the external service provider, so as to notify the external service provider of the processing event and realize the callback of the internal service provider to the external service provider.

[0143] As an example, Figure 3 This illustrates a method for invoking an HTTP callback interface through a service gateway provided in this application embodiment. The gateway service finds the URL of the external service provider based on the registerCode and AppId, and maps internal generic parameters (inner) to externally defined parameters (out). Figure 3 The example illustrates the mapping relationship of three types of parameters. Parameter 1 (storeCode, store identifier) ​​of the internal general parameter maps to parameter 1 (store_code) of the externally defined parameter; parameter 2 (event, event handling) of the internal general parameter maps to parameter 2 (event) of the externally defined parameter; and parameter 3 (occurAt, occurrence time) of the internal general parameter maps to parameter 3 (occer_time) of the externally defined parameter, and so on, but is not limited to these. The service gateway can then use these externally defined parameters and URLs to call the corresponding external service providers, thus enabling callbacks from internal service providers to external service providers.

[0144] It should be noted that, Figure 3 The parameters and mapping methods shown are for illustrative purposes only. This application does not focus on the specific parameters and mapping methods; the specific parameters and mapping methods shall be subject to actual implementation. Figure 3 The parameters and their mapping examples in the document should not be construed as limiting this application.

[0145] For RPC interfaces, callback interface information includes the software development kit (SDK) and RPC interface parameters.

[0146] The software development kit (SDK) is used to encapsulate the details of communication with external service providers. Specifically, it can be a JAR (Java Archive) package, but is not limited to this. RPC interface parameters are used to establish communication with external service providers in conjunction with the JAR package. In this embodiment, the service gateway can register the callback interfaces of external service providers based on the hot-reloading capability of the JDK (Java Development Kit).

[0147] Specifically, when an external service provider registers an RPC service, it can upload a JAR package to the service gateway and enter parameters (including externally defined parameters and RPC interface parameters, which can be entered simultaneously or separately). After registration, the service gateway will automatically generate a registerCode and map the externally defined parameters to new parameters used by the internal service provider (i.e., internal general parameters).

[0148] The internal service provider uses the registerCode (or registerCode and AppId) and internal common parameters to call the gateway service. The gateway service finds the corresponding JAR package and RPC interface parameters based on the registerCode (or registerCode and AppId), loads the JAR package based on the RPC interface parameters, and maps the internal common parameters to externally defined parameters to call the external service provider. This notifies the external service provider of the processing event and enables the internal service provider to call back to the external service provider.

[0149] As an example, Figure 4 This illustrates a method for invoking an RPC callback interface through a service gateway provided in this application embodiment. The gateway service locates the external service provider's JAR package and RPC interface parameters based on the registerCode and AppId. Figure 4 The example demonstrates four types of RPC interface parameters, including resource registration class entry (address), project organization identifier (GroupId), project identifier (ArtifactId), and version number (Version), but is not limited to these. Then, internal common parameters are mapped to externally defined parameters. Figure 4The example illustrates the mapping relationship of three types of parameters. Parameter 1 (storeCode, store identifier) ​​of the internal general parameter maps to parameter 1 (store_code) of the externally defined parameter; parameter 2 (event, event handling) of the internal general parameter maps to parameter 2 (event) of the externally defined parameter; and parameter 3 (occurAt, occurrence time) of the internal general parameter maps to parameter 3 (occer_time) of the externally defined parameter, and so on, but is not limited to these. The service gateway can then load the JAR package based on these externally defined parameters and RPC interface parameters to call the corresponding external service provider, thereby implementing the callback from the internal service provider to the external service provider.

[0150] Similarly, Figure 4 The parameters and mapping methods shown are for illustrative purposes only. This application does not focus on the specific parameters and mapping methods; the specific parameters and mapping methods shall be subject to actual implementation. Figure 4 The parameters and their mapping examples in the document should not be construed as limiting this application.

[0151] Optionally, the RPC interface provided in this application embodiment can be used by external service providers that can be accessed by internal service providers.

[0152] In other embodiments, the callback interface may also include other types of interfaces. Those skilled in the art should understand that the two types of callback interfaces described above are merely examples, and appropriate changes based on these examples may also be applied to this application. Therefore, they should also be included within the scope of protection of this application and are hereby incorporated by reference.

[0153] In this embodiment of the application, an optional implementation method is provided for step S101, specifically including the steps of: displaying a registration interface in response to a service access request; and obtaining the registration information of the external service provider for the target service based on the input operation on the registration interface.

[0154] Optionally, the registration interface displays at least one input field, and the input in the input field is retrieved to obtain the registration information of the external service provider for the target service. Further optionally, corresponding input prompts are displayed for each input field. Even further optionally, each input field has corresponding input rules set, such as character type and character count.

[0155] Optionally, the type of the currently registered callback interface can be obtained first, and the corresponding registration information can be obtained based on the type of the currently registered callback interface, such as displaying different prompts or displaying different fill boxes, but not limited to this.

[0156] Optionally, the number of registration interfaces to be displayed can be one or more. If multiple registration interfaces need to be displayed, different interfaces can be used to obtain registration information for different purposes. For example, for RPC interfaces, different interfaces can be used to obtain externally defined parameters, RPC interface parameters, JAR packages, etc.

[0157] Optionally, the input operation can be performed by touch methods such as clicking, double-clicking, or gestures; or by manipulating input devices such as a mouse or keyboard, and / or input means such as Bluetooth or infrared remote control; or by using detected voice signals, shake-to-use sensor signals, etc. Those skilled in the art can set it according to the actual situation, and the embodiments of this application are not specifically limited here.

[0158] In this embodiment, the service gateway supports more self-service application and configuration by external service providers through a registration interface, thereby improving the scalability of the service.

[0159] In this embodiment, the application also provides a mock callback interface self-testing capability for external service providers. This means that after service registration, external service providers can self-test and verify whether the registered interface can correctly perform callbacks. Specifically, after step S102, the application may further include the following steps: responding to a test request initiated by an external service provider, the test request carrying relevant test data, and generating a test response result; based on internal general parameters and registration identifiers, invoking the external service provider and notifying the external service provider of the test response result.

[0160] The relevant test data can be used as the content of the callback, such as simulated processing events or other types of test data. This application embodiment does not limit the specific content of the relevant test data.

[0161] Optionally, the relevant test data can be input from an external service provider, or it can be preset or generated by the service gateway.

[0162] In this embodiment of the application, after receiving a test request initiated by an external service provider, the service gateway generates a test response result in response to the test request; based on internal general parameters and registration identifier, it calls the external service provider and notifies the external service provider of the test response result.

[0163] It's understandable that if the test response correctly notifies the external service provider, it means the registered callback interface is available and a test pass result can be generated. Otherwise, a test fail result will be generated.

[0164] Optionally, in this embodiment of the application, the above-mentioned operations such as storage and / or establishing associations can be performed after the test is passed to ensure the reliability of the data.

[0165] The service invocation method provided in this application allows external service providers to register services themselves, which means that it provides the ability to customize special callback interfaces without the need for internal business code development; and it also supports self-testing of callback interfaces on the low-code service gateway to ensure that the registered callback interfaces are available.

[0166] When an internal service provider needs to call back an external service provider, it sends a callback request to the service gateway based on the corresponding internal general parameters and registration identifier of the external service provider. The service gateway then calls the external service provider based on the external service provider's custom callback interface information and notifies the external service provider of the processing event, thus completing the callback.

[0167] The service invocation method provided in this application embodiment can effectively decouple the special callbacks of internal service providers and external service providers, reduce the complexity of the system, and make the process more standardized and self-service.

[0168] This application provides another service invocation method (also known as a service callback method), such as... Figure 5 As shown, when applied to internal service providers, the method includes:

[0169] Step S501: For any external service provider, generate a processing event for the target service;

[0170] In this context, a target service refers to a service that needs to be processed by an internal service provider within an open service that has external service providers targeting it for access. In practical applications, there can be one or more target services.

[0171] In practical applications, the external service providers and the generated processing events can be business-related. In one example, the technical solution provided in this application can be applied to open platforms related to the instant delivery field. The open capabilities of the internal service providers include, but are not limited to, the following two:

[0172] 1. When the transportation capacity meets its own needs, it will open up its transportation capacity to external service providers for access, that is, open up delivery resources to deliver the orders of external service providers.

[0173] 2. There is also some external transportation capacity that can be connected as a supplement to the internal transportation capacity, that is, opening up orders to allocate to external delivery resources for delivery.

[0174] In other words, the aforementioned target services include, but are not limited to, services related to at least one of the following businesses: capacity provision services, capacity utilization services, etc. The corresponding external service providers and specific processing events can be configured according to actual circumstances, and this application embodiment does not impose any limitations on them.

[0175] When an internal service provider needs to call back an external service provider for a processing event of a target service, it will send a callback request to the service gateway, that is, call back the external service provider by calling the service gateway, i.e., execute step S502.

[0176] Step S502: Based on the internal general parameters and registration identifier corresponding to the external service provider, initiate a callback request to the service gateway, so that the service gateway can call the external service provider based on the external service provider's custom callback interface information and notify the external service provider of the processing event.

[0177] After an external service provider registers with the service gateway (carrying custom callback interface information), the service gateway will automatically generate a registration identifier (RegisterCode) and establish an association between the callback interface information and the registration identifier (i.e., a second association). This establishes an association between the callback interface corresponding to the callback interface information and the registration identifier, so that when calling back an external service provider, the corresponding callback interface can be quickly found through the registration identifier.

[0178] Internal common parameters (Param) are parameters common to all internal service providers. In this embodiment, the service gateway generates internal common parameters, so internal service providers do not need to pay attention to the parameters defined by external service providers for the target service. When calling back to external service providers, internal service providers can provide internal common parameters, reducing the complexity of the internal service system.

[0179] Optionally, the internal general parameters can adopt a map structure, which makes the number of parameters more flexible, easy to expand, with low coupling, and fast query and update speed.

[0180] In this embodiment, the callback interface of the external service provider can be a custom / non-standard callback interface (i.e., not provided according to the standard callback interface defined by the internal service provider). In other embodiments, the callback interface can also be in other forms.

[0181] In this embodiment, the service gateway provides a service gateway interface to internal service providers for them to call the service gateway. The service gateway interface needs to specify internal general parameters and registration identifiers, as well as other parameters required by the callback interface. Internal service providers initiate callback requests to the service gateway, calling the service gateway interface and specifying the corresponding parameters. This allows the service provider to call the external service provider through the pre-agreed callback interface, based on the internal general parameters and registration identifier, to notify the external service provider of the current processing event of the internal service provider, thus completing the callback from the internal service provider to the external service provider.

[0182] External service providers can also register their identities by entering their relevant information at the service gateway. After registration, the service gateway automatically generates a service provider identifier (referred to as AppId for ease of description) for the external service provider and automatically stores the service provider's information, including but not limited to the external service provider's identity information and service provider identifier. The service gateway establishes an association between the registration identifier and the service provider information (i.e., the first association). In other words, it establishes an association between the registration identifier and the service provider identifier (i.e., binds the registration identifier and the service provider identifier).

[0183] In step S502, a callback request is initiated to the service gateway based on the internal general parameters and registration identifier corresponding to the external service provider. This may include the following steps: Initiating a callback request to the service gateway based on the internal general parameters, registration identifier, and service provider information (e.g., service provider identifier) ​​corresponding to the external service provider.

[0184] When an internal service provider calls the service gateway's interface, it needs to specify internal general parameters, a registration identifier, a service provider identifier, and other parameters required by the callback interface. Upon receiving the parameters specified by the internal service provider, the service gateway calls the corresponding callback interface to complete the callback to the external service provider corresponding to that interface.

[0185] In this embodiment of the application, combining the second association relationship (the association between callback interface information and registration identifier) ​​mentioned above, a third association relationship (the association between callback interface information (the corresponding callback interface) and service provider identifier) ​​is also established. Therefore, when calling back an external service provider, the service gateway can more reliably find the corresponding callback interface through the service provider identifier and registration identifier. Then, based on internal general parameters, registration identifier, and service provider information, the external service provider can be invoked through the pre-agreed callback interface to notify the external service provider of the current processing event of the internal service provider, thus completing the callback from the internal service provider to the external service provider.

[0186] The service invocation method provided in this application embodiment can provide the ability to customize special callback interfaces without the need for internal business code development.

[0187] The service invocation method provided in this application decouples the internal business system from the external system, reducing the complexity of the internal business code.

[0188] The service invocation method provided in this application embodiment can further standardize the service access process.

[0189] This application provides a service gateway, such as... Figure 6 As shown, the service gateway 60 may include: a registration module 601, a generation module 602, and a calling module 603, wherein,

[0190] The registration module 601 is used to obtain the registration information of the external service provider for the target service. The registration information includes the callback interface information customized by the external service provider.

[0191] The generation module 602 is used to generate a registration identifier and internal general parameters related to the target service based on the registration information;

[0192] The calling module 603 is used to respond to the callback request from the internal service provider to the external service provider. Based on the internal general parameters and registration identifier, it calls the external service provider to notify the external service provider of the processing event of the target service by the internal service provider.

[0193] In an optional implementation, the service gateway 60 may further include: an acquisition module 604, used to acquire service provider information of external service providers;

[0194] After generating a registration identifier and internal general parameters related to the target service based on the registration information, the generation module 602 is further used for:

[0195] Establish the primary association between the registration identifier and the service provider information;

[0196] When calling module 603 to invoke an external service provider based on internal general parameters and registration identifier, it is specifically used for:

[0197] Based on internal common parameters, registration identifiers, and service provider information, external service providers are invoked.

[0198] In an optional implementation, after generating a registration identifier and internal general parameters related to the target service based on the registration information, the generation module 602 is further configured to: establish a second association between the callback interface information and the registration identifier.

[0199] In one optional implementation, the registration information also includes externally defined parameters;

[0200] When generating internal general parameters related to the target service based on registration information, the generation module 602 is specifically used for:

[0201] Map externally defined parameters to internally common parameters that are relevant to the target service.

[0202] In an optional implementation, when calling an external service provider based on internal general parameters and a registration identifier, the calling module 603 is specifically used for:

[0203] Based on the registration identifier, determine the callback interface of the external service provider;

[0204] Map internal generic parameters to externally defined parameters;

[0205] Based on externally defined parameters and callback interfaces, call external service providers.

[0206] In one alternative implementation, the callback interface includes an HTTP interface and / or a Remote Procedure Call (RPC) interface.

[0207] If the callback interface includes a remote procedure call interface, the callback interface information includes the software development kit and RPC interface parameters.

[0208] In an optional implementation, when the registration module 601 obtains the registration information of the external service provider for the target service, it is specifically used for:

[0209] In response to a service access request, display the registration interface;

[0210] Based on the input on the registration interface, obtain the registration information of the external service provider for the target service.

[0211] In an optional implementation, the service gateway 60 may further include: a testing module 605, which, after the generation module 602 generates a registration identifier and internal general parameters related to the target service based on the registration information, is used to:

[0212] In response to a test request initiated by an external service provider, the test request carries relevant test data and generates a test response result;

[0213] Based on internal common parameters and registration identifiers, the system calls external service providers and notifies them of the test response results.

[0214] The apparatus in this application embodiment can execute the method executed by the service gateway in this application embodiment. The implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method executed by the service gateway in each embodiment of this application. For detailed functional descriptions of each module of the apparatus and the beneficial effects produced, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0215] This application provides an internal service provider, such as... Figure 7 As shown, the internal service provider 70 may include: a processing module 701 and a callback module 702, wherein,

[0216] Processing module 701 is used to generate processing events for the target service for any external service provider;

[0217] The callback module 702 is used to initiate a callback request to the service gateway based on the internal general parameters and registration identifier corresponding to the external service provider, so that the service gateway can call the external service provider based on the external service provider's custom callback interface information and notify the external service provider of the processing event.

[0218] The apparatus in this application embodiment can execute the method provided by the internal service provider in this application embodiment. The implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method executed by the internal service provider in each embodiment of this application. For detailed functional descriptions of each module of the apparatus and the beneficial effects produced, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0219] Based on the same inventive concept, this application provides a service invocation system 80, which includes a service gateway 60 and an internal service provider 70. The specific structure of the service gateway 60 and the internal service provider 70, the detailed functional description of each module, and the beneficial effects are detailed in the above embodiments and will not be repeated here.

[0220] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the aforementioned method embodiments. Optionally, the electronic device may be a service gateway 60; or the electronic device may be an internal service provider 70; or the electronic device may be a service invocation system 80.

[0221] In one alternative embodiment, an electronic device is provided, such as Figure 8 As shown, Figure 8 The illustrated electronic device 900 includes a processor 901 and a memory 903. The processor 901 and the memory 903 are connected, for example, via a bus 902. Optionally, the electronic device 900 may further include a transceiver 904, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 904 is not limited to one type, and the structure of the electronic device 900 does not constitute a limitation on the embodiments of this application.

[0222] Processor 901 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 901 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0223] Bus 902 may include a pathway for transmitting information between the aforementioned components. Bus 902 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 902 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0224] The memory 903 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0225] The memory 903 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 901. The processor 901 executes the computer programs stored in the memory 903 to implement the steps shown in the foregoing method embodiments.

[0226] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0227] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0228] The terms "first," "second," "1," "2," 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 data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0229] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0230] The above are only optional implementation methods for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A service invocation method, characterized by, The method applied to a service gateway comprises: In response to a service access request, a registration interface is displayed; According to an input operation on the registration interface, registration information of an external service party for a target service is obtained, the registration information including non-standard callback interface information defined by the external service party, the input operation corresponding to the type of the callback interface; Based on the registration information, a registration identifier and internal general parameters related to the target service are generated; In response to a callback request of an internal service party to the external service party, the external service party is invoked based on the internal general parameters and the registration identifier to notify the internal service party of a processing event of the target service to the external service party.

2. The service invocation method of claim 1, wherein, Further comprising: Service party information of the external service party is obtained; After the registration identifier and the internal general parameters related to the target service are generated based on the registration information, further comprising: A first association relationship between the registration identifier and the service party information is established; The external service party is invoked based on the internal general parameters, the registration identifier and the service party information. After the registration identifier and the internal general parameters related to the target service are generated based on the registration information, further comprising:

3. The service invocation method of claim 1, wherein, A second association relationship between the callback interface information and the registration identifier is established. The registration information further includes external definition parameters; 4. The service invocation method of claim 1, wherein, The internal general parameters related to the target service are generated based on the registration information, comprising: The external definition parameters are mapped to the internal general parameters related to the target service. The external service party is invoked based on the internal general parameters and the registration identifier, comprising:

5. The service invocation method of claim 4, wherein, The callback interface of the external service party is determined based on the registration identifier; The internal general parameters are mapped to the external definition parameters; The external service party is invoked based on the external definition parameters and the callback interface. The callback interface includes a hypertext transfer protocol (HTTP) interface and / or a remote procedure call (RPC) interface; 6. The service invocation method of claim 5, wherein, If the callback interface includes an RPC interface, the callback interface information includes a software development kit (SDK) and an RPC interface parameter. After the registration identifier and the internal general parameters related to the target service are generated based on the registration information, further comprising:

7. The service invocation method according to any of claims 1-6, characterized by, In response to a test request initiated by the external service party, a test response result is generated, the test request carrying relevant test data; The external service party is invoked based on the internal general parameters and the registration identifier to notify the test response result to the external service party. The method applied to an internal service party comprises:

8. A service invocation method, characterized by, A processing event of a target service is generated for any external service party; Based on internal general parameters and a registration identifier corresponding to the external service party, a callback request is initiated to a service gateway to invoke the external service party based on non-standard callback interface information defined by the external service party through the service gateway and notify the processing event to the external service party; ​ The internal general parameter and the registration identifier are generated based on registration information of the external service party for the target service, and the registration information is obtained according to input operation in a registration interface, and the input operation corresponds to the type of the callback interface.

9. A service gateway, characterized by The method comprises the following steps: The registration module is configured to, in response to a service access request, display a registration interface, and obtain registration information of the external service party for the target service according to input operation in the registration interface, wherein the registration information comprises non-standard callback interface information customized by the external service party, and the input operation corresponds to the type of the callback interface; The generation module is configured to generate a registration identifier and an internal general parameter related to the target service based on the registration information; The calling module is configured to, in response to a callback request of the internal service party to the external service party, call the external service party based on the internal general parameter and the registration identifier, so as to notify the external service party of a processing event of the internal service party to the target service.

10. An internal service provider, characterized by The method comprises the following steps: The processing module is configured to generate a processing event of a target service for any external service party; The callback module is configured to initiate a callback request to a service gateway based on an internal general parameter and a registration identifier corresponding to the external service party, so as to call the external service party based on non-standard callback interface information customized by the external service party through the service gateway, and notify the external service party of the processing event. The internal general parameter and the registration identifier are generated based on registration information of the external service party for the target service, and the registration information is obtained according to input operation in a registration interface, and the input operation corresponds to the type of the callback interface.

11. A service invocation system, characterized by The service gateway comprises the internal service party.

12. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that, when executed by the processor, cause the electronic device to perform the method of any one of claims 1-11. The processor executes the computer program to implement the steps of the method of any one of claims 1-7 or 8.

13. A computer readable storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the method of any one of claims 1-7 or 8.

14. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1-7 or 8.

Images