Service registration method and apparatus

Abstract

The embodiment of the present specification provides a service registration method and device, wherein the service registration method comprises receiving a service registration request of a service provider carrying a service registration parameter; in the case that the service registration parameter meets a preset service registration requirement, receiving a service providing parameter input by the service provider; obtaining service data of the service provider according to the service providing parameter, and analyzing the service data to generate a service data table; associating the service data table to a service database, and completing service registration of the service provider; the service registration method ensures that only one copy of the same data is kept in the same scene, and guarantees the consistency of the data caliber, thereby avoiding data redundancy and repetition.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a service registration method. One or more embodiments of this specification also relate to a service registration apparatus, a computing device, and a computer-readable storage medium. Background Technology

[0002] Currently, when data callers request data from data providers, the data links of the data providers are complex and the underlying interactions are messy due to different usage methods and requirements. There are also nested layers and redundant calculations, which results in long data development cycles, high communication costs, and high resource consumption for data callers. Furthermore, data callers lack a convenient and effective query platform when requesting data and do not have a good understanding of the data's source, timeliness, and definition. Different data can only be communicated with different data providers, which is not only costly and inefficient but also fails to accumulate data.

[0003] Therefore, there is an urgent need to provide a service registration method that can provide a unified data query portal, realize data accumulation, and allow multiple data users to share and use the data. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a service registration method that enables data accumulation for multiple data users to share data services. One or more embodiments of this specification also relate to service registration apparatus, computing devices, and computer-readable storage media to address technical deficiencies in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a service registration method is provided, comprising:

[0006] Receive a service registration request from the service provider, which includes service registration parameters;

[0007] If the service registration parameters meet the preset service registration requirements, the service provision parameters entered by the service provider shall be received.

[0008] The service data of the service provider is obtained according to the service provision parameters, and the service data is parsed to generate the service data table;

[0009] The service data table is associated with the service database to complete the service registration of the service provider.

[0010] According to a second aspect of the embodiments of this specification, a service registration method is provided, comprising:

[0011] Receive a service registration request from a service caller, wherein the service registration request carries a first service call parameter;

[0012] If it is determined that the first service call parameter has a corresponding database entity, the database entity selected by the service caller and the fields in the database entity are received.

[0013] Initial service data is determined based on the fields in the database entity, and the second service call parameters entered by the service caller are received according to the initial service data to complete the service registration of the service caller.

[0014] According to a third aspect of the embodiments of this specification, a service registration apparatus is provided, comprising:

[0015] The first receiving module is configured to receive service registration requests from service providers carrying service registration parameters.

[0016] The second receiving module is configured to receive the service provision parameters entered by the service provider when the service registration parameters meet the preset service registration requirements.

[0017] The data table generation module is configured to obtain the service data of the service provider based on the service provision parameters, and parse the service data to generate the service data table;

[0018] The first service registration module is configured to associate the service data table with the service database to complete the service registration of the service provider.

[0019] According to a fourth aspect of the embodiments of this specification, a service registration apparatus is provided, comprising:

[0020] The third receiving module is configured to receive a service registration request from a service caller, wherein the service registration request carries a first service call parameter.

[0021] The fourth receiving module is configured to receive the database entity selected by the service caller and the fields in the database entity when it is determined that the first service call parameters have a corresponding database entity.

[0022] The second service registration module is configured to determine initial service data based on fields in the database entity, and to receive second service call parameters entered by the service caller according to the initial service data, thereby completing the service registration of the service caller.

[0023] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0024] Memory and processor;

[0025] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein the processor executes the computer-executable instructions to implement the steps of the service registration method.

[0026] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the service registration method.

[0027] This specification implements two service registration methods and apparatuses in one embodiment. The first service registration method includes receiving a service registration request from a service provider carrying service registration parameters; if the service registration parameters meet preset service registration requirements, receiving service provision parameters entered by the service provider; obtaining service data from the service provider based on the service provision parameters, and parsing the service data to generate a service data table; associating the service data table with a service database to complete the service registration of the service provider. This service registration method ensures that only one copy of the same data is retained for the same scenario and guarantees data consistency, avoiding data redundancy and duplication. Attached Figure Description

[0028] Figure 1 This is an example diagram illustrating a specific application scenario of a service registration method provided in one embodiment of this specification;

[0029] Figure 2 This is a flowchart of a first service registration method provided in one embodiment of this specification;

[0030] Figure 3 This is a flowchart of a second service registration method provided in one embodiment of this specification;

[0031] Figure 4 This is a flowchart illustrating the processing procedure of a service registration method provided in one embodiment of this specification on the service provider side.

[0032] Figure 5 This is a flowchart illustrating the processing procedure of a service registration method provided in one embodiment of this specification on the service caller side.

[0033] Figure 6 This is a schematic diagram of the structure of a first service registration device provided in one embodiment of this specification;

[0034] Figure 7 This is a schematic diagram of the structure of a second service registration device provided in one embodiment of this specification;

[0035] Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0036] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0037] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0038] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0039] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0040] HSF: High-speed Service Framework, a distributed RPC service framework.

[0041] U2: Data Service Platform.

[0042] HTTP: Hypertext Transfer Protocol.

[0043] Dubbo is a high-performance, lightweight, open-source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

[0044] QPS (Queries per second) is a measure of how much traffic a particular query server processes within a given time period.

[0045] JSON (JavaScript Object Notation) is a lightweight data interchange format.

[0046] SQL: Structured Query Language.

[0047] This specification provides two service registration methods, and also relates to two service registration devices, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments.

[0048] See Figure 1 , Figure 1 The diagram illustrates an example application scenario of a service registration method provided in one embodiment of this specification.

[0049] Figure 1 The application scenarios include service providers 102, service data registration platforms 104, and service callers 106.

[0050] Specifically, service provider 102 registers its service data on service data registration platform 104, providing the service data to service data registration platform 104, so that service caller 106 can call the service data from service provider 102 through service data registration platform 104.

[0051] Service caller 106 registers the service data to be called on the service data registration platform 104. After successful service registration, the service data can be called from the service data registration platform 104.

[0052] In practice, service provider 104 registers its service data on service data registration platform 104, and service caller 106 registers its service data invocation on service data registration platform 104. Service data registration platform 104 is responsible for integrating service data to provide service call services to service caller 106 and providing unified query services. For service data from different service providers 102, service data registration platform 104 collects this service data from different service providers 102 for service caller 106 to share and use, reducing the data links and redundant calculations in service data invocation. Service data registration platform 104 can provide data metadata services internally, providing service caller 106 with management and query functions.

[0053] Furthermore, the service registration methods provided in the embodiments of this specification are all applied to the service data registration platform, and the specific implementation methods can be found in the following embodiments.

[0054] See Figure 2 , Figure 2 A flowchart of a first service registration method according to an embodiment of this specification is shown, including the following steps:

[0055] Step 202: Receive a service registration request from the service provider, which includes service registration parameters.

[0056] Among them, the service provider is the provider of service data, that is, the provider of service data to the service caller; for example, the provider of shopping data or order data.

[0057] Service registration parameters include, but are not limited to, service name, version, method, class (group, which can be the default), and QPS limit setting.

[0058] Specifically, receiving a service registration request from a service provider carrying service registration parameters can be understood as receiving a service registration request from a service provider on a service data registration platform. This service registration request includes the service name, version, method, class, and / or QPS limit of the service to be registered.

[0059] Step 204: If the service registration parameters meet the preset service registration requirements, receive the service provision parameters entered by the service provider.

[0060] The preset service registration requirements are the service registration parameters that the service data registration platform requires from the service provider submitting the service registration request. In other words, the service data registration platform determines the service registration parameters that the service provider needs to provide based on the type of the service provider. In actual applications, the service registration parameters required by the service data registration platform will vary depending on the type of service provider.

[0061] For example, suppose there is a service provider 1 and a service provider 2. Service provider 1 is of type 'a', and service provider 2 is of type 'b'. The service data registration platform requires service providers of type 'a' to provide the following service registration parameters for successful service registration: service name, version, method, and QPS. The service data registration platform requires service providers of type 'b' to provide the following service registration parameters for successful service registration: service name, version, method, class, and QPS. Therefore, when service provider 1 wants to register its service on the service data registration platform, it needs to provide the following service registration parameters: service name, version, method, class, and QPS. When service provider 2 wants to register its service on the service data registration platform, it needs to provide the following service registration parameters: service name, version, method, class, and QPS.

[0062] In practice, the service data registration platform receives a service registration request from a service provider carrying service registration parameters. It then verifies the service registration parameters based on the service provider's type. If the service registration parameters meet the service registration platform's requirements for that service provider, the platform receives the service provision parameters entered by the service provider. These service provision parameters can be understood as service fields, i.e., parameters that the service caller needs to provide when calling the service data from that service provider. For example, if a service provider registers an order data service on the service data registration platform, the service provision parameters are not limited to, but include, the order ID and user ID. Based on the order ID and user ID, the service data obtained from the service provider includes: the product corresponding to the order ID, the order placement time, and the order amount. In practical applications, the product corresponding to the order, the order placement time, and the order amount are generally data returned by the service provider based on the service provision parameters, and data required by the service caller.

[0063] Step 206: Obtain the service data of the service provider according to the service provision parameters, and parse the service data to generate the service data table.

[0064] Among them, service data refers to the specific service data of the service provider obtained by the service data registration platform based on the service provision parameters. For example, if the service provision parameter is an order ID, then the service data of the service provider obtained based on the service provision parameter is the specific ID value corresponding to the order ID of the service provider.

[0065] Specifically, after obtaining the service data of the service provider based on the service provision parameters, the service data registration platform parses the service data to generate a service data table that has been standardized by the service data registration platform; that is, the service data is parsed according to the data management specifications of the service data registration platform to generate a standardized service data table.

[0066] Step 208: Associate the service data table with the service database to complete the service registration of the service provider.

[0067] Specifically, after parsing and obtaining the service data table, the service data table (metadata) is stored in the service database of the service data registration platform to complete the service registration of the service provider. For example, the service provider registers the service to provide order data. In practical applications, the service data registration platform will record the service provider's service. When the service caller calls the service provider's order data, there is no need to coordinate with the service provider again to call the order data. All service callers can directly call the shared order data from the service data registration platform, reducing data links and redundant calculations, reducing the communication costs between service callers and service providers, and saving resource consumption.

[0068] In practical applications, since the service data in the service data table is obtained from the service provider, the service data provided by the service provider may contain some special service data. For example, if the service data provided by the service provider is in English, directly storing the English service data may be detrimental to the service caller's access to the service data and the service data registration platform's maintenance of the service data. To facilitate the service caller's access to the service data and the service data registration platform's maintenance of the service data, the special fields in the service data table can be parsed and easily understood text descriptions can be added. The specific implementation method is as follows:

[0069] After parsing the service data to generate the service data table, the process further includes:

[0070] If a field to be identified exists in the service data table, the field to be identified is parsed, and a field description is added to the field to be identified based on the parsing result.

[0071] The fields to be identified can be understood as fields that do not meet the storage requirements of the service data registration platform, such as English fields or fields with special characters.

[0072] Specifically, when there is a field to be identified in the service data table, the field to be identified is parsed to determine its meaning, and then an easy-to-understand field description is added to the field to be identified. For example, if the field to be identified is "Order time", parsing the field to be identified can determine that the field to be identified is "order time". Based on the parsing result, a field description of "the time when the product is selected and the sales amount of the product is paid" can be added to the field to be identified.

[0073] In practical applications, the service database includes multiple domains, such as the product domain, complaint domain, and seller domain; and each domain can include at least one entity, such as the product domain including product entities, the complaint domain including penalty entities, and the seller domain including seller entities, etc., where each entity can be understood as a data table.

[0074] In practice, the service database of the service data registration platform will have some database entities pre-existing. If a field in the obtained service data table has a corresponding database entity, the field in the service data table can be directly bound to the corresponding database entity, that is, a binding relationship can be established between the service data table and the database entity to save storage time. The specific implementation method is as follows:

[0075] If a field in the service data table has a corresponding database entity, the field is associated with the database entity in the service database.

[0076] For example, if the field in the service data table is Order ID, and the service database of the service data registration platform contains a database entity: Order Entity, then the Order ID and the corresponding service data can be stored in (data table added to) the Order Entity.

[0077] If a field in the service data table does not exist in the service database of the service data registration platform, in order to ensure that the field in the service data table is not lost, a separate query data table will be generated for the field that does not have a corresponding database entity. This is to achieve secure data storage and to facilitate use by service callers and subsequent reusability. The specific implementation method is as follows:

[0078] The step of associating the service data table with the service database includes:

[0079] If a field in the service data table does not have a corresponding database entity, a query data table is generated for that field, and the query data table is stored in the service database.

[0080] Specifically, when a field in the service data table does not have a corresponding database entity in the service database of the service data registration platform, a query data table is generated based on the field in the service data table and the service data corresponding to the field. Then, the query data table is stored in the service database of the service data registration platform to ensure the complete storage of service data.

[0081] In another embodiment of this specification, after obtaining the service data of the service provider based on the service provision parameters and before parsing the service data to generate the service data table, the method further includes:

[0082] Determine whether the service data is of a preset type.

[0083] If so, the service data is stored in the service database according to the preset storage requirements, thus completing the service registration of the service provider.

[0084] If not, the service data is parsed to generate the service data table.

[0085] Among them, the preset type is a special type confirmed by the service data registration platform, such as service data with an ISN structure, or other higher-level service data, that is, service data that is more complex to parse and wastes resources, as confirmed by the service data registration platform.

[0086] Specifically, after obtaining service data based on the service provision parameters entered by the service provider, if it is determined that there is a special type of service data confirmed by the service data registration platform, then the service data is stored in the service database according to the storage requirements of the service data registration platform for this type of service data, thereby completing the service registration of the service provider; otherwise, if the service data is not of this preset type, the above steps are continued to parse the service data to generate the service data table, and the service data table is associated with the service database to complete the service registration of the service provider.

[0087] In the embodiments described in this specification, special types of service data are specially processed before parsing the service data, in order to save the service data parsing process and improve work efficiency.

[0088] Furthermore, to ensure the consistency of service data stored on the service data registration platform and to ensure that all service data can be accessed in a unified format subsequently, the service data registration platform encapsulates special types of service data to achieve unified storage of these special types of service data. The specific implementation method is as follows:

[0089] The step of storing the service data in the service database according to preset storage requirements includes:

[0090] The service data is encapsulated according to preset storage requirements, and a data description is added to the encapsulated service data.

[0091] The encapsulated service data and its corresponding description are stored in the service database.

[0092] Among them, the preset storage requirements are the requirements for the service data registration platform to store service data of preset types.

[0093] Given service data of a predetermined type, the service data is encapsulated according to the predetermined storage requirements. Then, a data description is added to the encapsulated service data, so that subsequent service callers and service data maintainers can understand the function and role of the service data based on the data description.

[0094] Finally, the encapsulated service data and its corresponding description are stored in the service database of the service data registration platform.

[0095] The service registration method provided in the embodiments of this specification registers service data from different service providers on the service data registration platform. This allows the service data registration platform to provide a unified data access point for service data from different service providers. When a service caller needs to access multiple service data, it can directly access the service data registration platform without having to communicate and coordinate with each service provider corresponding to each service data. This saves communication time and costs and greatly improves data access efficiency.

[0096] See Figure 3 , Figure 3 A flowchart of a second service registration method according to an embodiment of this specification is shown, including the following steps:

[0097] Step 302: Receive a service registration request from the service caller, wherein the service registration request carries a first service call parameter.

[0098] In this context, the service caller is the one who calls the service data of the service provider that has registered its service on the service data registration platform. For example, if the service provider has registered its service to provide order data on the service data registration platform, then the service caller can call the order data on that service data registration platform after registering its service on the service data registration platform.

[0099] The first service call parameter is the parameter corresponding to the service data to be called by the service caller, such as the service name and field names of the service data to be called. Based on the first service call parameter, it can be determined which service data the service caller wants to call that the service provider has registered on the service data registration platform.

[0100] Step 304: If it is determined that the first service call parameter has a corresponding database entity, receive the database entity selected by the service caller and the fields in the database entity.

[0101] The explanation of the database entities can be found in the above embodiments, and will not be repeated here.

[0102] Specifically, if it is determined that there is a corresponding database entity in the first service call parameters, the system receives the database entity selected by the service caller and the fields in that database entity. For example, if the first service call parameters include the service name "order", and there is a database entity corresponding to the order in the service database of the service data registration platform, then the system can receive the database entity selected by the service caller on the service data registration platform and the fields in that database entity to be called.

[0103] In practical applications, before registering a service on the service data registration platform, the service caller inputs the call parameters (i.e., the first service call parameters) corresponding to the service data to be called into the platform. The platform then pre-displays the service data based on these parameters. The caller can then confirm the existence of a corresponding database entity for each parameter based on the pre-displayed data. If a database entity exists, the caller can select the primary key (i.e., the database entity) and attributes (fields) of the service data to be called on the platform. The primary key can be understood as a field that uniquely identifies a single order data item, thus determining the database entity containing the service data to be called, such as the database entity containing the service providing order data. Attributes, on the other hand, represent the specific service data to be called. By registering on the platform, the service caller can access the obtained service data, such as the order amount and the order placement time.

[0104] If, based on the first service call parameter, it is determined that corresponding service data exists in the service database of the service data registration platform, and the first service call parameter does not have a corresponding database entity, in order to ensure that the service data can be quickly invoked by the service caller, the service caller can invoke the service data by writing SQL statements. The specific implementation method is as follows:

[0105] After receiving the service registration request from the service caller, the process also includes:

[0106] If it is determined that the first service call parameter does not have a corresponding database entity, the data call conditions input by the service caller are received, and the initial service data is determined based on the data call conditions.

[0107] The data retrieval conditions can be understood as the SQL statements that enable service data retrieval.

[0108] Specifically, if the first service call parameter has corresponding service data in the service database of the service data registration platform, but the first service call parameter does not have a corresponding database entity, the service data to be called cannot be directly selected by the service caller. In this case, the data call conditions input by the service caller can be received, and the service caller can then call the service data based on these data call conditions.

[0109] In practice, if there is no corresponding database entity for the first service call parameter, the service data registration platform receives the data call conditions input by the service call policy for the service data to be called, and then determines the initial service data based on the data call conditions.

[0110] Step 306: Determine initial service data based on the fields in the database entity, and receive the second service call parameters entered by the service caller according to the initial service data, thereby completing the service registration of the service caller.

[0111] The initial service data is determined based on the database entity selected by the service caller and the fields in the database entity.

[0112] Specifically, after determining the initial service data, it can be determined whether the data to be called by the service caller is complete. If so, the second service call parameters entered by the service caller are received, and the service registration of the service caller is completed.

[0113] The first service call parameters and the second service call parameters may be the same or different. If the initial service data determined based on the first service call parameters are all service data to be called by the service caller, then the second service call parameters are the same as the first service call parameters. If some of the initial service data determined based on the first service call parameters are not service data to be called by the service caller, then the second service call parameters will be different from the first service call parameters. At least the second service call parameters will not include the first service call parameters corresponding to service data that is not to be called by the service caller.

[0114] In specific implementation, after determining the initial service data based on the fields in the database entity, the method further includes:

[0115] Receive operation instructions from the service caller, and preview and / or modify the initial service data based on the operation instructions.

[0116] The operation instructions can be understood as operation instructions implemented by the service caller by clicking on preview or modifying controls on the service data registration platform.

[0117] Specifically, after determining the initial service data based on the fields in the database entity, the system receives click instructions from the service caller regarding the preview control on the service data registration platform, and displays the initial service data to the service caller, enabling the service caller to preview the data. During the service caller's preview process, the system can receive modification instructions from the service caller regarding the initial service data, enabling modifications to the initial service data. For example, if the service caller finds that some fields of the service data are unnecessary during the preview process, they can deselect those fields on the service data registration platform.

[0118] Previewing and / or modifying the selected initial service data before the service caller completes service registration allows the service caller to adapt the initial service data to the actual data call requirements, avoiding the subsequent call to unnecessary service data and saving time for subsequent service data calls.

[0119] In practical applications, after previewing and / or modifying the initial service data, in order to ensure the accuracy of the service data, the initial service data can be checked in advance on the service data registration platform. The specific implementation method is as follows:

[0120] After previewing and / or modifying the initial service data based on the operation instructions, the process further includes:

[0121] The system receives a probe instruction from the service caller and performs a first data check on the initial service data based on the probe instruction.

[0122] Among them, the probe command can be understood as the probe command implemented by the service caller by clicking the verification control on the service data registration platform.

[0123] Specifically, after receiving the probe instruction from the service caller regarding the initial service data, the system performs a first data check on the initial service data based on the probe instruction. This involves sampling the initial service data to confirm that it is the service data to be invoked by the service caller, thereby avoiding problems in the actual service data invocation by the service caller and reducing the invocation rate.

[0124] In another embodiment of this specification, after receiving the service registration request from the service caller, the method further includes:

[0125] If it is determined that the first service call parameter does not have a corresponding database entity and the first service call parameter belongs to a preset type, the second service call parameter entered by the service caller is received to complete the service registration of the service caller.

[0126] For a detailed explanation of the preset types, please refer to the above embodiments, which will not be repeated here.

[0127] Specifically, if the first service call parameter does not have a corresponding database entity and belongs to a preset type, the service caller can directly receive the second service call parameter, which is the data of the service to be called, and complete the service registration of the service caller.

[0128] In other words, if the first service call parameter is of a preset type, the service caller can directly enter the second service call parameter required to call the service data on the service data registration platform to complete the service registration of the service caller. At this time, the first service call parameter and the second service call parameter are the same.

[0129] In the embodiments of this specification, the service registration method includes, when the first service call parameter belongs to a preset type, the service call parameter can be directly entered in the service data registration platform to complete the service registration of the service caller, so that the service caller can not only obtain general service data, but also obtain special service data, thereby improving the data call experience of the service caller.

[0130] In another embodiment of this specification, before completing the service registration of the service caller, the method further includes:

[0131] The target service data of the service caller is determined based on the second service call parameters, and the target service data is tested and a second data check is performed.

[0132] Specifically, after receiving the second service call parameters entered by the service caller, the target service data of the service caller is determined based on the second service call parameters, that is, the final service data to be called by the service caller is determined based on the second service call parameters, and then the target service data is tested and the second data is checked.

[0133] In practice, the target service data is tested and a second data check is performed, namely, testing whether the target service data can be called by the service caller and conducting spot checks on the target service data, in order to improve the calling rate and accuracy of the target service data.

[0134] In addition, after testing the target service data and performing the second data check, the process also includes:

[0135] Determine whether the query rate per second of the service provider that is to provide the target service data meets the needs of the service caller.

[0136] If so, then complete the service registration for the service caller.

[0137] If not, then perform exception handling.

[0138] The query rate per second of the service provider of the target service data is the QPS of the service provider of the target service data.

[0139] Specifically, after testing and exploring the target service data, the QPS of the service caller must be audited to determine whether the upper limit of the QPS requested by the service caller is less than or equal to the upper limit of the QPS of the service provider of the target service data. If so, the service registration of the service caller is completed. If not, offline communication with the service provider of the target service data is required to enable the service provider of the target service data to increase its upper limit of QPS to meet the QPS requirements of the service data to be called by the service caller.

[0140] Furthermore, in the embodiments of this specification, the service caller can only invoke the service data provided by the service provider on the service data registration platform when both the service provider and the service caller complete service registration on the service data registration platform. Therefore, in specific implementation, both the service provider and the service caller will register their services on the service data registration platform. Specifically, in this embodiment, the method for the service provider to register its services on the service data registration platform can be found in the above embodiments. Details not described in detail in the technical solution for the service provider to register its services on the service data registration platform in this service registration method can be found in the description of the technical solution for the service provider to register its services on the service data registration platform in the above service registration method.

[0141] In the embodiments of this specification, after the service caller registers the service, the following is also included:

[0142] Receive the service data call request from the service caller, wherein the service data call request carries service data call parameters;

[0143] Based on the service data call parameters, the service data to be called by the service caller is determined, and the service data to be called is returned to the service caller.

[0144] Specifically, after both the service provider and the service caller register their services on the service data registration platform, the service caller can call the service data registered by the service provider on the service data registration platform. Here, the service data call parameters are the service provision parameters when the service provider registers the service, and also the second service call parameters when the service caller calls the service data.

[0145] In the embodiments described in this specification, after the service caller completes service registration on the service data registration platform, it can call the service data registered by multiple service providers on the service data registration platform, thereby reducing the cost for the service caller to find service data and improving the efficiency of the service caller in calling service data.

[0146] The service registration method provided in the embodiments of this specification offers a universal virtualized and customized data service (i.e., a unified data portal) for both service providers and service callers. This ensures that only one copy of the same data is retained for the same scenario, and guarantees data consistency, avoiding data redundancy / duplication. Data is uniformly provided externally as a data service, defining data service standards and specifications. The underlying data is transparent to users, reducing the cost of user understanding and improving data access efficiency. A unified data query entry point is provided, allowing queries based on data domains, entities, physical tables, and other dimensions, reducing the cost of data retrieval. Furthermore, data operation and maintenance monitoring functions are provided to ensure the stability of the data service.

[0147] See Figure 4 and Figure 5 Taking the application of the service registration method described in this specification in HSF as an example, the service registration method will be further explained. Figure 4 This specification illustrates a flowchart of the service registration method provided in one embodiment on the service provider side. Figure 5 This specification illustrates a flowchart of the service registration method provided in one embodiment on the service caller side, showing the specific process. Figure 4 Includes the following steps:

[0148] Step 402: Register for HSF service.

[0149] Specifically, registering for HSF services means that the service provider begins the service registration process on the service data registration platform under the HSF framework.

[0150] Step 404: Enter service binding parameters.

[0151] Specifically, service binding parameter entry refers to the service registration platform receiving service registration parameters from the service provider based on the platform's requirements for that service provider.

[0152] Step 406: HSF input parameter configuration.

[0153] Specifically, the HSF input parameter configuration refers to the service provision parameters received from the service provider, provided that the service registration parameters meet the preset service registration requirements.

[0154] Step 408: Generalization parsing of the result.

[0155] Specifically, result generalization parsing means obtaining the service data of the service provider based on the service provider parameters, and then parsing the service data.

[0156] Step 410: Generate selectable indicator maps.

[0157] Specifically, generating selectable indicator graphs can be understood as generating service data tables after parsing the service data.

[0158] Step 412: Maintain the result return type and description.

[0159] Specifically, maintaining the result return type and description means that, given that the service provider enters service parameters of a preset type, the service data is encapsulated and a data description is added according to preset storage requirements.

[0160] Step 414: Registration complete.

[0161] Specifically, when the service provider enters service provision parameters of a preset type, the service data is encapsulated according to preset storage requirements, and a data description is added before being directly stored in the service database, thus completing the service provider's service registration.

[0162] There is no requirement for the execution order of steps 408 and 412. In practical applications, they can also be executed in parallel. In specific implementation, step 410 is executed after step 408 is completed, and step 414 is executed after step 412 is completed.

[0163] Step 416: Select an indicator and fill in the indicator description.

[0164] Specifically, selecting an indicator and filling in its description means that if there is a field to be identified in the service data table, the field to be identified is parsed, and a field description is added to the field to be identified based on the parsing results.

[0165] Step 418: Bind entity and domain.

[0166] Specifically, binding an entity and a domain means that if a field in a service data table has a corresponding database entity, then that field is stored in the service database's database entity and the corresponding domain of that database entity.

[0167] Step 420: Binding entity service registration complete.

[0168] Specifically, once the entity service registration is complete, it means that if a field in the service data table has a corresponding database entity, the field is stored in the database entity of the service database and the corresponding field of that database entity, thus completing the service registration of the service provider.

[0169] Step 422: Select service input parameters and output indicators.

[0170] Specifically, selecting service input parameters and transparent metrics means that when there is no corresponding database entity for a field in the service data table, a query data table is generated based on the selected service input parameters and transparent metrics, and the query data table is stored in the service database. Here, the service input parameters are the service provision parameters entered by the service provider, and the transparent metrics are the fields in the service data table determined according to the service provision parameters.

[0171] Step 424: Physical SQL registration is now complete.

[0172] Specifically, it supports physical SQL registration, which means that when a field in the service data table does not have a corresponding database entity, the field is used to generate a query data table, and the query data table is stored in the service database to complete the service registration of the service provider; the query data table supports physical SQL.

[0173] Steps 416 and 422 have no execution order requirement and can be executed in parallel in practical applications.

[0174] The service registration method provided in this specification has three main processing flows on the service provider side: First, it can be bound to an entity; second, it cannot be bound to an entity but can support physical SQL; and third, it only performs access without any processing, which is the preset type. The processing flow for services that can be bound to an entity includes: service binding parameter input, HSF input parameter configuration, result generalization parsing, generating selectable indicator graphs, selecting indicators and filling in indicator descriptions, binding the entity and domain, and completing the entity service registration. The processing flow for services that cannot be bound to an entity but can support physical SQL includes: service binding parameter input, HSF input parameter configuration, result generalization parsing, generating selectable indicator graphs, selecting service input parameters and exposing indicators, and completing physical SQL registration. The processing flow for services that only perform access without any processing includes: service binding parameter input, HSF input parameter configuration, result return type and description maintenance, and registration completion.

[0175] See Figure 5 , Figure 5 This specification illustrates a flowchart of the service registration method provided in one embodiment on the service caller side, specifically including the following steps:

[0176] Step 502: Create a new service.

[0177] Specifically, creating a new service involves receiving a service registration request from a service caller, where the service registration request carries the first service call parameters.

[0178] Step 504: Bind the entity service.

[0179] Specifically, the binding entity service means that the parameters of the first service call exist in the corresponding database entity.

[0180] Step 506: Primary key and attribute selection.

[0181] Specifically, regarding primary key and attribute selection, if a corresponding database entity exists in the first service call parameters, the service caller selects the database entity and the fields in the database entity on the service data registration platform, and determines the initial service data based on the fields in the database entity.

[0182] Step 508: Preview and modify.

[0183] Specifically, previewing and modifying means that upon receiving operation instructions from the service caller, the service caller can preview and / or modify the initial service data.

[0184] Step 510: Customize SQL.

[0185] Specifically, the custom SQL means that the parameters of the first service call do not have a corresponding database entity.

[0186] Step 512: Write the SQL.

[0187] Specifically, the SQL is written such that, if the first service call parameter does not have a corresponding database entity, the data call conditions input by the service caller are received, and the initial service data is determined based on the data call conditions.

[0188] There is no requirement for the execution order of steps 504 and 510. In practical applications, they can also be executed in parallel. In specific implementation, step 506 is executed after step 504 is completed, and step 512 is executed after step 510 is completed.

[0189] Step 514: Data exploration.

[0190] Specifically, after steps 508 and 512 are completed, a probe command from the service caller is received, and a first data check is performed on the initial service data based on the probe command.

[0191] Step 516: Service parameter configuration.

[0192] Specifically, after performing a first data check on the initial service data based on the probe command, and confirming that the initial service data is correct, the system receives the second service call parameters entered by the service caller, and determines the target service data based on the second service call parameters.

[0193] Step 518: Special Services.

[0194] Specifically, a special service is defined as a service whose service registration request carries a first service call parameter that does not have a corresponding database entity, and the first service call parameter belongs to a preset type. In such cases, the service data to be called by the service caller is determined to be a special service.

[0195] Step 520: Service Registration.

[0196] Specifically, if the service to be invoked by the service caller is a special service, the service caller can directly configure the service parameters on the service data registration platform to obtain the target service data.

[0197] Step 522: Testing and data exploration.

[0198] Specifically, the target service data obtained in step 516 and step 520 are used for call testing and data exploration.

[0199] Step 524: QPS review.

[0200] Specifically, after the target service data passes the test and data exploration, determine whether the QPS of the service caller is less than or equal to the QPS of the service provider. If yes, proceed to step 526; otherwise, proceed to step 528.

[0201] Step 526: Satisfied.

[0202] If the QPS of the service provider meets the QPS requirements of the service provider, the service provider can enable the service caller to call the registered service data and execute step 532.

[0203] Step 528: Not satisfied.

[0204] This means that the service provider's QPS does not meet the service provider's QPS requirements, and the service provider cannot make calls to the service data provided by the service provider.

[0205] Step 530: Offline communication and handling.

[0206] Specifically, if the QPS of the service provider does not meet the service provider's QPS requirements, the service caller can communicate with the service provider offline to enable the service provider to increase its QPS limit so that the increased QPS limit meets the service caller's needs for service data, and then execute step 532.

[0207] Step 532: Complete registration.

[0208] That is, the service caller completes the service registration.

[0209] The service registration method provided in this specification has three processing flows on the service caller side: First, binding to an entity; second, custom SQL; and third, special services, which correspond one-to-one with the processing flows on the service provider side. In the entity binding method, since the HSF service metrics are already integrated into the entity, the HSF service is a data carrier, similar to HBase, GP, and MySQL. Therefore, the service caller's service registration process is consistent with that of HSF, HBase, GP, and MySQL. Custom SQL treats the HSF as a physical table, and the HSF input parameters can be considered as rowkeys (primary keys). The third special service registration method supports complex HSFs. The platform only encapsulates the interface, excluding task logic processing. Specific application logic needs to be processed downstream; the goal is simply to achieve unified management, monitoring, and maintenance of the HSF.

[0210] The service registration method described in the embodiments of this specification can realize service registration for both service providers and service callers, providing a unified data flow platform for both service providers and service callers. The underlying data is no longer limited to querying databases, but can also include data obtained by calling various services such as HSF and HTTP (Hypertext Transfer Protocol). It also supports the mutual joining of data obtained from different sources, and can flexibly support different service types of data providers. Only corresponding service access plugins need to be developed. After the service data of each service provider is accessed, it can be integrated into the data portal (i.e., the service data registration platform) and displayed in the form of data domains, entities, and physical tables, making it convenient for users to search and use. The underlying attributes of the service are transparent to the user.

[0211] In practical applications, the service registration method provided in the embodiments of this specification can be applied to application scenarios that provide after-sales data support for shopping after-sales customer service.

[0212] If there are two service providers in this application scenario: service provider a1 and service provider a2, where service provider a1 provides user shopping data and service provider a2 provides product logistics data, there is a service caller, namely the data caller that calls the user shopping data and the product logistics data.

[0213] First, service provider A1 and service provider A2 register on the service data registration platform to provide user shopping data and product logistics data support for service callers. Service callers also register on the service data registration platform and call the user shopping data and product logistics data provided by the service providers based on the service data registration platform. The service caller can be regarded as the after-sales customer service of shopping in the embodiments of this specification. Service provider A1, service provider A2 and service caller realize the provision and call of user shopping data and product logistics data on their service data registration platform.

[0214] In practice, the after-sales customer service directly interacts with users, receiving their after-sales processing requests, such as refunds, returns, and complaints. Each after-sales processing request carries a unique user identifier. Upon receiving a request with this user identifier, the after-sales customer service representative requests the service data registration platform to send a user shopping data retrieval request. This request includes the user identifier, the user's shopping data to be retrieved, and product logistics data. The user shopping data to be retrieved includes, but is not limited to, the item name, quantity, order time, and payment amount corresponding to the user identifier. The product logistics data to be retrieved includes, but is not limited to, the product details corresponding to the user identifier. The data includes shipping time, route points, delivery time, and recipient; the service data registration platform, based on the user identifier, the user's shopping data to be retrieved, and the product logistics data, retrieves the user's shopping data corresponding to the user identifier from service provider A1, and the product logistics data corresponding to the user identifier from service provider A2, which provides the product logistics data; the service data registration platform then sends the user's shopping data and product logistics data corresponding to the user identifier to the after-sales customer service. After receiving the data, the after-sales customer service can process the user's after-sales requests based on the retrieved data, such as resolving refund issues and answering logistics information questions.

[0215] In this embodiment of the specification, the service registration method is applied to the application scenario of shopping after-sales service, so as to provide after-sales data support for shopping after-sales customer service. When shopping after-sales customer service needs to call data, it can directly call data from multiple service providers through the service data registration platform. This allows shopping after-sales customer service to quickly obtain data from multiple different service providers, thereby enabling fast and accurate handling of users' after-sales problems based on the obtained data and improving user experience.

[0216] Corresponding to the above method embodiments, this specification also provides embodiments of a service registration device. Figure 6 A schematic diagram of the structure of a first service registration apparatus provided in one embodiment of this specification is shown. Figure 6 As shown, the device includes:

[0217] The first receiving module 602 is configured to receive a service registration request from the service provider carrying service registration parameters.

[0218] The second receiving module 604 is configured to receive the service provision parameters entered by the service provider when the service registration parameters meet the preset service registration requirements.

[0219] The data table generation module 606 is configured to obtain the service data of the service provider according to the service provision parameters, and parse the service data to generate the service data table;

[0220] The first service registration module 608 is configured to associate the service data table with the service database to complete the service registration of the service provider.

[0221] Optionally, the device further includes:

[0222] The first parsing module is configured to parse the field to be identified if there is a field to be identified in the service data table, and add a field description to the field to be identified based on the parsing result.

[0223] Optionally, the first service registration module 608 is further configured as follows:

[0224] If a field in the service data table has a corresponding database entity, the field is associated with the database entity in the service database.

[0225] Optionally, the first service registration module 608 is further configured as follows:

[0226] If a field in the service data table does not have a corresponding database entity, a query data table is generated for that field, and the query data table is stored in the service database.

[0227] Optionally, the device further includes:

[0228] The first judgment module is configured to determine whether the service data is service data of a preset type.

[0229] If so, the service data is stored in the service database according to the preset storage requirements, thus completing the service registration of the service provider.

[0230] If not, the service data is parsed to generate the service data table.

[0231] Optionally, the first determination module is further configured to:

[0232] The service data is encapsulated according to preset storage requirements, and a data description is added to the encapsulated service data.

[0233] The encapsulated service data and its corresponding description are stored in the service database.

[0234] The above is an illustrative scheme of a service registration device according to this embodiment. It should be noted that the technical solution of this service registration device belongs to the same concept as the technical solution of the first service registration method described above. For details not described in detail in the technical solution of the service registration device, please refer to the description of the technical solution of the service registration method described above.

[0235] Corresponding to the above method embodiments, this specification also provides embodiments of a service registration device. Figure 7 A schematic diagram of a second service registration apparatus provided in one embodiment of this specification is shown. Figure 7 As shown, the device includes:

[0236] The third receiving module 702 is configured to receive a service registration request from a service caller, wherein the service registration request carries a first service call parameter;

[0237] The fourth receiving module 704 is configured to receive the database entity selected by the service caller and the fields in the database entity when it is determined that the first service call parameter has a corresponding database entity.

[0238] The second service registration module 706 is configured to determine initial service data based on fields in the database entity, and to receive second service call parameters entered by the service caller according to the initial service data, thereby completing the service registration of the service caller.

[0239] Optionally, the device further includes:

[0240] The fifth receiving module is configured to receive the data calling conditions input by the service caller when it is determined that the first service call parameters do not have a corresponding database entity, and to determine the initial service data based on the data calling conditions.

[0241] Optionally, the device further includes:

[0242] The sixth receiving module is configured to receive the second service call parameters entered by the service caller when it is determined that the first service call parameters do not have a corresponding database entity and the first service call parameters belong to a preset type, thereby completing the service registration of the service caller.

[0243] Optionally, the device further includes:

[0244] The seventh receiving module is configured to receive operation instructions from the service caller and to preview and / or modify the initial service data based on the operation instructions.

[0245] Optionally, the device further includes:

[0246] The eighth receiving module is configured to receive the probe instruction from the service caller and perform a first data check on the initial service data based on the probe instruction.

[0247] Optionally, the device further includes:

[0248] The testing module is configured to determine the target service data of the service caller based on the second service call parameters, and to test and perform a second data check on the target service data.

[0249] Optionally, the device further includes:

[0250] The second judgment module is configured to determine whether the query rate per second of the service provider that is to provide the target service data meets the needs of the service caller.

[0251] If so, then complete the service registration for the service caller.

[0252] If not, then perform exception handling.

[0253] Optionally, the device further includes:

[0254] The steps to implement the above service registration method.

[0255] Optionally, the device further includes:

[0256] The ninth receiving module is configured to receive the service data call request from the service caller, wherein the service data call request carries service data call parameters;

[0257] The data retrieval module is configured to determine the service data to be invoked by the service caller based on the service data retrieval parameters, and to return the service data to be invoked to the service caller.

[0258] The above is an illustrative scheme of a service registration device according to this embodiment. It should be noted that the technical solution of this service registration device and the technical solution of the second service registration method described above belong to the same concept. For details not described in detail in the technical solution of the service registration device, please refer to the description of the technical solution of the service registration method described above.

[0259] Figure 8 A structural block diagram of a computing device 800 according to one embodiment of this specification is shown. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0260] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0261] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0262] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 800 can also be a mobile or stationary server.

[0263] The processor 820 is configured to execute the following computer-executable instructions, wherein the processor executes the computer-executable instructions to implement the steps of the service registration method.

[0264] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the service registration method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the service registration method described above.

[0265] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the service registration method.

[0266] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the service registration method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the service registration method described above.

[0267] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0268] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0269] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0270] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0271] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A service registration method, comprising: receiving a service registration request of a service provider carrying service registration parameters; in a case where the service registration parameters meet preset service registration requirements, receiving service providing parameters input by the service provider, wherein the service providing parameters are parameters required to be provided by a subsequent service invoker when invoking service data of the service provider; obtaining service data of the service provider according to the service providing parameters, and parsing the service data to generate a service data table; in a case where there is a to-be-identified field in the service data table, parsing the to-be-identified field, and adding a field description to the to-be-identified field based on a parsing result, wherein the to-be-identified field is a field that does not meet storage requirements of a service data registration platform; associating the service data table to a service database, and completing service registration of the service provider. 2.The service registration method of claim 1, wherein the associating the service data table to a service database comprises: in a case where a field in the service data table has a corresponding database entity, associating the field to the database entity of the service database. 3.The service registration method of claim 1, wherein the associating the service data table to a service database comprises: in a case where a field in the service data table does not have a corresponding database entity, generating a query data table from the field, and storing the query data table to the service database. 4.The service registration method of claim 1, wherein after the obtaining service data of the service provider according to the service providing parameters, and before the parsing the service data to generate the service data table, the method further comprises: determining whether the service data is service data of a preset type, if yes, storing the service data to the service database according to preset storage requirements, and completing service registration of the service provider, if no, parsing the service data to generate the service data table. 5.The service registration method of claim 4, wherein the storing the service data to the service database according to preset storage requirements comprises: encapsulating the service data according to preset storage requirements, and adding a data description to the encapsulated service data; storing the encapsulated service data and the corresponding data description to the service database. 6.A service registration method, comprising: receiving a service registration request of a service invoker, wherein the service registration request carries first service invocation parameters, and the first service invocation parameters are parameters corresponding to service data to be invoked by the service invoker; in a case where the first service invocation parameters have corresponding database entities, receiving a database entity selected by the service invoker and fields in the database entity. determining initial service data based on fields in the database entity, and receiving second service invocation parameters entered by the service invoker according to the initial service data, and completing service registration of the service invoker, wherein in a case where a part of the initial service data determined based on the first service invocation parameters is not service data to be invoked by the service invoker, the second service invocation parameters are different from the first service invocation parameters.

7. The service registration method of claim 6, further comprising, after receiving the service registration request of the service invoker: in a case where the first service invocation parameters do not exist corresponding database entity, receiving data invocation conditions input by the service invoker, and determining the initial service data based on the data invocation conditions.

8. The service registration method of claim 6, further comprising, after receiving the service registration request of the service invoker: in a case where the first service invocation parameters do not exist corresponding database entity, and the first service invocation parameters belong to a preset type, receiving second service invocation parameters entered by the service invoker, and completing service registration of the service invoker.

9. The service registration method of claim 6, further comprising, after determining the initial service data based on fields in the database entity: receiving operation instructions of the service invoker, and previewing and / or modifying the initial service data based on the operation instructions.

10. The service registration method of claim 9, further comprising, after previewing and / or modifying the initial service data based on the operation instructions: receiving exploration instructions of the service invoker, and performing first data checking on the initial service data based on the exploration instructions.

11. The service registration method of claim 8 or 10, further comprising, before completing service registration of the service invoker: determining target service data of the service invoker based on the second service invocation parameters, and testing and performing second data checking on the target service data.

12. The service registration method of claim 11, further comprising, after testing and performing second data checking on the target service data: judging whether a query rate per second of a service provider to be provided with the target service data meets a demand of the service invoker, if yes, completing service registration of the service invoker, if no, performing exception handling.

13. The service registration method of claim 6, further comprising: implementing steps of the service registration method of any one of claims 1-5.

14. The service registration method of claim 13, further comprising, after service registration of the service invoker: receiving a service data invocation request of the service invoker, wherein the service data invocation request carries service data invocation parameters; determining service data to be invoked by the service invoker based on the service data invocation parameters, and returning the service data to be invoked to the service invoker.

15. A service registration device, comprising: The first receiving module is configured to receive a service registration request of a service provider carrying a service registration parameter; The second receiving module is configured to receive a service providing parameter input by the service provider in a case where the service registration parameter meets a preset service registration requirement, wherein the service providing parameter is a parameter required to be provided by a subsequent service invoker when invoking service data of the service provider; The data table generating module is configured to obtain service data of the service provider according to the service providing parameter, and analyze the service data to generate the service data table; The first analyzing module is configured to analyze a to-be-identified field in the service data table in a case where the to-be-identified field exists, and add a field description to the to-be-identified field based on an analysis result, wherein the to-be-identified field is a field that does not meet a storage requirement of a service data registration platform; The first service registration module is configured to associate the service data table to a service database, and complete service registration of the service provider.

16. A service registration apparatus, comprising: The third receiving module is configured to receive a service registration request of a service invoker, wherein the service registration request carries a first service invoking parameter, and the first service invoking parameter is a parameter corresponding to service data to be invoked by the service invoker; The fourth receiving module is configured to receive a database entity selected by the service invoker and a field in the database entity in a case where the first service invoking parameter corresponds to a database entity; The second service registration module is configured to determine initial service data based on the field in the database entity, and receive a second service invoking parameter input by the service invoker according to the initial service data, and complete service registration of the service invoker, wherein the second service invoking parameter is different from the first service invoking parameter in a case where a part of the initial service data determined based on the first service invoking parameter is not service data to be invoked by the service invoker.

17. A computing device, comprising: a memory and a processor; The memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions, wherein the processor executes the computer executable instructions to implement steps of the service registration method in any one of claims 1-5 or 6-14.

18. A computer readable storage medium storing computer instructions, wherein the computer instructions are executed by a processor to implement steps of the service registration method in any one of claims 1-5 or 6-14.

19. A computer program product, characterised in that, The computer readable storage medium stores computer instructions, wherein the computer instructions are executed by a processor to implement steps of the service registration method in any one of claims 1-5 or 6-14.

Images