Service processing method, apparatus and system

Abstract

Embodiments of the present application provide a service processing method, device and system, wherein the method comprises: receiving an original service request sent by a target requester; determining a to-be-converted field in the original service request and a target field corresponding to the to-be-converted field according to a routing rule; obtaining a field value of the to-be-converted field from the original service request, generating a standard service request based on the target field and the field value, and sending the standard service request to a service platform, so that the service platform performs service processing; wherein the routing rule is obtained by integrating data processing rules of each requester, so as to convert the to-be-converted field in the original service request sent by each requester into the target field according to the data processing rule corresponding to each requester, and the to-be-converted fields of each requester are different fields representing the same meaning; each field included in the standard service request is a field recognizable by the service platform; through the embodiments of the present application, rule redundancy is avoided, and the management difficulty and cost of the rules are reduced.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a service processing method, apparatus and system. Background Technology

[0002] In the field of internet finance, different asset providers typically have different data processing needs, which may lead to the use of different data formats. To ensure effective data interoperability with various asset providers, financial platforms usually maintain a set of data processing rules adapted to the data processing needs of each asset provider. However, as the number of asset providers continues to increase, financial platforms need to maintain more sets of data processing rules, and the same or similar data processing rules for different asset providers also need to be maintained multiple times. This not only increases the management difficulty and cost of data processing rules for financial platforms, but also creates rule redundancy issues, resulting in low data processing efficiency. Summary of the Invention

[0003] This application provides a service processing method, apparatus, and equipment that, while ensuring effective service delivery to all requesters, avoids rule redundancy and reduces the difficulty and cost of rule management.

[0004] In a first aspect, embodiments of this application provide a service processing method, including:

[0005] Receive the original service request sent by the target requester; the original service request is used to request service processing for the target service;

[0006] According to the routing rules, the fields to be converted in the original service request and the target fields corresponding to the fields to be converted are determined; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester, wherein the fields to be converted by each requester are different fields representing the same meaning;

[0007] The field values ​​of the fields to be transformed are obtained from the original service request, and a standard service request is generated based on the target field and the field values; the fields included in the standard service request are fields that can be recognized by the service platform.

[0008] The standard service request is sent to the service platform; the standard service request is used to request the service platform to process the target service.

[0009] As can be seen in this embodiment, when receiving an original service request from the target requester requesting service processing for the target service, the system first determines the fields to be converted and their corresponding target fields in the original service request according to the routing rules. Then, it obtains the field values ​​of the fields to be converted from the original service request and generates a standard service request recognizable by the service platform based on the target fields and their values. Finally, it sends the standard service request to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, there is no need to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplicate rules or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the management difficulty and cost of rules are reduced.

[0010] Secondly, embodiments of this application provide a service processing apparatus, including:

[0011] The receiving module is used to receive the original service request sent by the target requester; the original service request is used to request service processing for the target service;

[0012] The determination module is used to determine the fields to be converted in the original service request and the target fields corresponding to the fields to be converted, according to the routing rules. The routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into the target fields according to the data processing rules corresponding to each requester. The fields to be converted by each requester are different fields that represent the same meaning.

[0013] The generation module is used to obtain the field value of the field to be transformed from the original service request, and generate a standard service request based on the target field and the field value; the fields included in the standard service request are fields that can be identified by the service platform.

[0014] The sending module is used to send the standard service request to the service middle platform; the standard service request is used to request the service middle platform to perform service processing on the target service.

[0015] Thirdly, embodiments of this application provide a service processing system, including: a target requester, a service gateway, and a service middleware;

[0016] The target requester is used to send an original service request to the service gateway;

[0017] The service gateway is configured to receive the original service request sent by the target requester, determine the field to be converted in the original service request and the target field corresponding to the field to be converted according to the routing rules, obtain the field value of the field to be converted from the original service request, and generate a standard service request based on the target field and the field value. The routing rules are obtained by integrating the data processing rules of each requester, so as to convert the field to be converted in the original service request sent by each requester into the target field according to the data processing rules corresponding to each requester. The fields to be converted by each requester are different fields representing the same meaning.

[0018] The service platform is used to process the target service based on the received standard service request.

[0019] Fourthly, embodiments of this application provide an electronic device, including:

[0020] A processor; and a memory arranged to store computer-executable instructions configured to be executed by the processor, the executable instructions including steps for performing the service processing method provided in the first aspect above.

[0021] Fifthly, embodiments of this application provide a storage medium for storing computer-executable instructions that cause a computer to perform the steps in the service processing method provided in the first aspect. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram illustrating a first application scenario of a service processing method provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram illustrating a second application scenario of a service processing method provided in an embodiment of this application;

[0025] Figure 3 This is a first flowchart illustrating a service processing method provided in an embodiment of this application;

[0026] Figure 4 This is a second flowchart illustrating a service processing method provided in an embodiment of this application.

[0027] Figure 5 This is a data processing diagram of a service processing method provided in an embodiment of this application;

[0028] Figure 6 A schematic diagram of the module composition of a service processing device provided in an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of a first component of a service processing system provided in an embodiment of this application;

[0030] Figure 8 This is a schematic diagram illustrating a second composition of a service processing system provided in an embodiment of this application;

[0031] Figure 9 This is a schematic diagram of the structure of an electronic device provided for one or more embodiments of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this application, the technical solutions in one or more embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on one or more embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0033] This application provides a service processing method, apparatus, and system. Considering that in the prior art, financial platforms need to maintain a set of corresponding data processing rules for each asset holder, this not only increases the management difficulty and cost of data processing rules but also leads to rule redundancy. Furthermore, to ensure high service availability, existing financial platforms often employ microservice distributed systems, where each system needs to maintain a set of data processing rules. However, this approach still involves maintaining multiple sets of data processing rules, resulting in significant management difficulties; additionally, the external API interfaces are scattered, leading to complex interface management. Another existing microservice-based approach involves establishing an API lifecycle management system consisting of an API gateway, authorization and authentication center, registration center, and API monitoring center. This dynamically binds routes, products, and APIs to enable API calls. However, this approach involves a complex authorization process, which is not user-friendly for asset holders in the internet finance sector and results in high coupling. Based on this, this application improves the existing Zuul gateway to obtain a service gateway. When the service gateway receives an original service request from a target requester requesting service processing for a target service, it first determines the fields to be transformed and their corresponding target fields in the original service request according to routing rules. Then, it obtains the field values ​​of the fields to be transformed from the original service request and generates a standard service request recognizable by the service platform based on the target fields and field values. Finally, it sends the standard service request to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, there is no need to maintain multiple sets of data processing rules, but only the routing rules need to be maintained. Consequently, there is no problem of duplication of identical or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the management difficulty and cost of rules are reduced.

[0034] Specifically, Figure 1 A schematic diagram illustrating a service processing method provided in one or more embodiments of this application, such as... Figure 1 As shown, this scenario includes: the target requester, the service gateway, and the service platform. The target requester can be an individual, a company, an organization, etc. Figure 1 (Only individuals are shown in the text). A service gateway and service platform can be either a terminal device or a server. Figure 1(Only the server is shown in the image); the terminal device can be a desktop computer, a portable laptop, etc.; the server can be a standalone server or a server cluster consisting of multiple servers.

[0035] Specifically, when a requesting party wants to request service processing for a target service, it sends an original service request to the service gateway. Upon receiving the original service request, the service gateway determines the fields to be converted and their corresponding target fields in the original service request based on routing rules. It then obtains the field values ​​of the fields to be converted from the original service request, generates a standard service request based on the target fields and their values, and sends this standard service request to the service middle platform. The service middle platform processes the target service according to the received standard service request. The routing rules are obtained by integrating the data processing rules of each requester, converting the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester. The fields to be converted for each requester are different fields representing the same meaning. The fields included in the standard service request are fields that the service middle platform can recognize. The target service can be any type of service, such as credit services, account opening services, or ticketing services.

[0036] In one embodiment, such as Figure 2 As shown, this scenario can also include a rule configuration system; the rule configuration system can be a terminal device or a server; the terminal device can be a mobile phone, tablet, desktop computer, laptop, etc.; the server can be a standalone server or a server cluster composed of multiple servers. Figure 2 (Only desktop computers are shown in the image). The rule configuration system and the aforementioned service gateway and service platform can belong to the service provider. The service provider can be an individual, a company, an organization, etc.

[0037] Specifically, the service provider can pre-collect data processing rules from each requester. Service provider users can then edit and submit rule configuration information based on these collected rules using the rule configuration system. The rule configuration system responds to the user's submission, retrieves the submitted rule configuration information, and generates rule information based on this information. This rule information represents the data processing rules of each requester. The service gateway retrieves this rule information from the rule configuration system and integrates it into routing rules according to a preset integration method, saving the routing rules to the service gateway's local cache. When the service provider is an individual, the service provider user can be that individual or another user designated by that individual.

[0038] In the aforementioned service processing, the routing rules are derived by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform. Therefore, even if the data processing rules of each requester are different, the service gateway does not need to maintain multiple sets of data processing rules, but only the routing rules. Consequently, there is no problem of duplicate or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the difficulty and cost of rule management are reduced.

[0039] Based on the above application scenario architecture, one or more embodiments of this application provide a service processing method. Figure 3 This is a flowchart illustrating a service processing method provided for one or more embodiments of this application. Figure 3 The methods described can be executed by the service gateway. For example... Figure 3 As shown, the method includes the following steps:

[0040] Step S102: Receive the original service request sent by the target requester. The original service request is used to request service processing for the target service.

[0041] The original service request may include encrypted service data to be processed from the target service, signature data, etc. The signature data can be obtained by signing the encrypted service data using the private key of the requesting party, or by signing the plaintext service data; it can be set as needed in practical applications. The service type of the target service can also be set as needed in practical applications, and this application does not impose specific limitations on it. As an example, if the target service is a credit granting service, the original service request is used to request credit granting processing for the credit granting service; as another example, if the target service is a ticket purchasing service, the original service request is used to request ticket purchasing processing for the ticket purchasing service.

[0042] Step S104: According to the routing rules, determine the fields to be converted and the target fields corresponding to the fields to be converted in the original service request; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester. The fields to be converted of each requester are different fields that represent the same meaning.

[0043] The data processing rules for each requester can include the format of the original service request, the meaning of each field in the original service request, the format of the service processing result, the meaning of each field in the service processing result, encryption and decryption rules for service data and service processing results, signature rules and verification rules for signature data, and request routing methods. Correspondingly, routing rules can include transformation rules and verification rules. Transformation rules include rules for transforming the original service requests sent by each requester and rules for transforming the service processing results. Verification rules include rules for verifying the original service requests sent by each requester and rules for verifying the transformed service requests and transformed service processing results. In other words, routing rules are used to transform the original service requests sent by each requester, transform the service processing results, and verify the original service requests sent by each requester, as well as the transformed service requests and transformed service processing results.

[0044] To enable the service platform to process services without needing to parse the original service requests sent by each requester based on their respective data processing rules, this embodiment of the application, upon receiving the original service requests from each requester, converts different fields representing the same meaning in the original service requests sent by each requester into a unified target field according to the conversion rules included in the routing rules. This allows the service platform to generate a standard service request recognizable by the service platform based on the target field. For example, requester 1's data processing rules include using the field 'sk' to represent the key, and requester 2's data processing rules include using the field 'ak' to represent the key. When the service gateway receives the original service request sent by requester 1, it converts the 'sk' field in the original service request into the 'secretKey' field according to the routing rules; similarly, when the service gateway receives the original service request sent by requester 2, it converts the 'ak' field in the original service request into the 'secretKey' field according to the routing rules.

[0045] Furthermore, to facilitate understanding that the routing rules do not suffer from rule redundancy, let's take encrypting service processing results as an example. For instance, requester A's data processing rule includes encrypting the service processing result using AES encryption before sending it to requester A, and requester B's data processing rule also includes encrypting the service processing result using AES encryption before sending it to requester B. Accordingly, the routing rule only needs to include one AES encryption rule. That is, when encrypting the service processing result for requester A, encryption is performed based on this AES encryption rule; similarly, when encrypting the service processing result for requester B, encryption is also performed based on this AES encryption rule; there is no need to maintain one AES encryption rule for requester A and another for requester B. Therefore, in this embodiment, by integrating the data processing rules of each requester to obtain the routing rule, the problem of rule redundancy is avoided, while simultaneously reducing the difficulty and cost of rule management.

[0046] Step S106: Obtain the field values ​​of the fields to be converted from the original service request, and generate a standard service request based on the target field and the field values; the fields included in the standard service request are fields that can be recognized by the service platform.

[0047] Specifically, the field values ​​of the fields to be converted are obtained from the original service request, and these values ​​are identified as the field values ​​of the target fields corresponding to the fields to be converted. Based on the target fields and their values, a standard service request in a preset format is generated. In one implementation, the preset format can be JSON format; the original service request can be in JSON format, or it can be in other formats.

[0048] Step S108: Send a standard service request to the service platform. The standard service request is used to request the service platform to process the target service.

[0049] When the service platform receives a standard service request, it processes the service according to that request. For example, if the target service is a credit granting service, the service platform processes the credit granting based on the received standard service request; if the target service is a ticket purchasing service, the service platform processes the ticket purchasing based on the received standard service request.

[0050] In one or more embodiments of this application, upon receiving an original service request from a target requester requesting service processing for a target service, the process first determines the fields to be converted and their corresponding target fields in the original service request according to routing rules. Then, the field values ​​of the fields to be converted are obtained from the original service request, and a standard service request recognizable by the service platform is generated based on the target fields and their values. Finally, the standard service request is sent to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, there is no need to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplicate or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the management difficulty and cost of rules are reduced.

[0051] To enable flexible management and configuration of the various rules in the routing rules, as mentioned above, this application embodiment also provides a rule configuration system. This system can be used for requester configuration, interface configuration, and interface parameter configuration. Requester configuration may include configuring the requester identifier, requester key, requester encryption / decryption method, requester signature rules, requester callback address, and request parameters. Interface configuration may include configuring the interface unique identifier, request routing method, request path, and forwarding path. Interface parameter configuration may include configuring standard fields, custom fields, field types, field parameters, whether they are required (notNull), and field descriptions. The rule configuration system can also provide a configuration verification module to ensure the accuracy of the configuration. In one or more embodiments of this application, each interface can correspond to a service type. It is understood that each requester can correspond to multiple interfaces, meaning each requester can request services of multiple service types; each service type can have multiple parameters. Service provider users can operate the rule configuration system to configure rules based on the collected data processing rules of each requester. To enable the service gateway to quickly process and transform original service requests received from various requesters, in one or more embodiments of this application, the service gateway obtains rule information from the rule configuration system and saves the routing rules obtained by integrating the rule information to a local cache. Specifically, before step S102, the following steps S100-2 to S100-6 may also be included:

[0052] Step S100-2: Obtain rule information from the rule configuration system;

[0053] Optionally, the rule configuration system may expose an acquisition interface to the service gateway, through which the service gateway may obtain rule information from the rule configuration system; or, the service gateway may send a rule acquisition request to the rule configuration system and receive the rule information sent by the rule configuration system.

[0054] In one or more embodiments of this application, the rule information stored in the rule configuration system may be in the form of a field string.

[0055] It is understandable that since the service provider users configure the rules according to the data processing rules collected from each requester, and the rule configuration system generates rule information based on the rule configuration information submitted by the service provider users, the rule information can represent the data processing rules of each requester. In other words, the rule information is used to represent the data processing rules of each requester.

[0056] Step S100-4: According to the preset integration method, integrate the acquired rule information into routing rules;

[0057] The preset integration method includes format conversion of rule information, determination of rules corresponding to each service type, and establishment of associations between each requester and the conversion and verification rules under different service types. Specifically, in one or more embodiments of this application, after obtaining rule information in the form of field strings from the rule configuration system, the service gateway converts the field string form into an object type. For example, if the field type of a rule information stored in the rule configuration system is String, the service gateway converts it into a Java object of type String; or if the field type of a rule information stored in the rule configuration system is BigDecimal, the service gateway converts it into a Java BigDecimal class. Furthermore, considering that some requesters may have different data processing rules for different service types, for example, requester 1 uses ASE encryption for service 1 and MD5 encryption for service 2, etc., in order to provide effective services to each requester and avoid rule redundancy, during the rule information integration process, associations between each requester and the conversion and verification rules under different service types can be established. It should be noted that the specific process of integration is not specifically limited in this application, and it can be set as needed in actual application.

[0058] Step S100-6: Save the routing rules to the local cache.

[0059] In one implementation, a dictionary structure can be used to save routing rules to a local cache. The key in the dictionary structure can be the service type, and the value in the dictionary structure can be the rules corresponding to the respective service type.

[0060] Corresponding to steps S100-6, step S104, which determines the field to be converted and the target field corresponding to the field to be converted in the original service request according to the routing rules, may include: determining the field to be converted and the target field corresponding to the field to be converted in the original service request according to the routing rules in the local cache.

[0061] Therefore, the service provider's operation rule configuration system configures and manages rules, improving the flexibility and convenience of rule management; by saving routing rules to the local cache of the service gateway, the conversion rate of data such as original service requests can be improved.

[0062] Furthermore, considering that requesters often change their data processing rules, and that existing Zuul gateways require a service restart for changes to take effect, rule updates are time-consuming and inefficient. Therefore, this application embodiment improves the existing Zuul gateway, enabling the improved service gateway to dynamically and flexibly update and activate rules. Specifically, based on any of the above embodiments, the method may further include steps A2 to A10:

[0063] Step A2: Send heartbeat messages to the rule configuration system at preset time intervals;

[0064] Specifically, the service gateway adds a timer after startup and sends heartbeat messages to the rule configuration system at preset time intervals. The specific format of the heartbeat message and the preset time interval can be set as needed in actual application; for example, the preset time interval is 10 seconds.

[0065] Step A4: If a response data is received from the rule configuration system, the current rule information is obtained from the rule configuration system.

[0066] Specifically, when the rule configuration system receives a heartbeat message from the service gateway, it sends response data to the service gateway. Upon receiving this response data, the service gateway retrieves the current rule information from the rule configuration system. The method by which the service gateway retrieves the current rule information from the rule configuration system is the same as the implementation method of step S100-2 described above, and can be found in the aforementioned description; details that are repeated will not be repeated here.

[0067] Step A6: According to the preset integration method, integrate the current rule information into the routing rules to be compared;

[0068] The specific implementation method of step A6 is the same as that of step S100-4 mentioned above. Please refer to the relevant descriptions above. The repeated parts will not be repeated here.

[0069] Step A8: Compare the routing rules to be compared with the routing rules currently saved in the local cache;

[0070] In this embodiment of the application, both the routing rule to be compared and the routing rule can be in JSON format. Accordingly, the comparison process in step A8 can include: determining whether the length of the routing rule to be compared is the same as the length of the routing rule; if the lengths are different, the comparison result is determined to be inconsistent; if the lengths are the same, determining whether the version number of each service in the routing rule to be compared is the same as the version number of the corresponding service in the routing rule; if at least one version number is different, the comparison result is determined to be inconsistent; if all version numbers are the same, comparing each field in the routing rule to be compared with the corresponding field in the routing rule; if at least one field is different, the comparison result is determined to be inconsistent; if all fields are the same, the comparison result is determined to be consistent.

[0071] Step A10: If the comparison result is inconsistent, update the routing rules currently stored in the local cache according to the routing rules to be compared.

[0072] Optionally, the routing rule to be compared is determined as the current routing rule, and the routing rule currently saved in the local cache is replaced with the current routing rule; or, the rule to be updated in the routing rule currently saved in the local cache is determined according to the comparison result, and the determined rule to be updated is updated according to the routing rule to be compared.

[0073] As can be seen, the service gateway in this embodiment can update the routing rules in the local cache according to a preset time interval, realizing dynamic real-time update of the rules without having to restart when updating the rules, thus improving the update efficiency of the rules.

[0074] Furthermore, considering that existing Zuul gateways do not concern themselves with the specific format of interactive data and cannot transform it, this application improves the existing Zuul gateway to ensure data security. It rewrites the `run` method in the ZuulFilter, defines new `GwRequestFilter` and `GwResponseFilter` to achieve encrypted data transmission, and transforms the first field to be transformed in the original service request based on routing rules, performs validation according to the routing rules, and transforms the second field to be transformed in the original service request after successful validation to obtain a standard service request. Specifically, as follows... Figure 4As shown, step S104 may include steps S104-2 to S104-10:

[0075] Step S104-2: Obtain the first verification rule that matches the target service of the target requester from the routing rules;

[0076] Specifically, this application inherits and overrides the existing Zuul gateway's SimpleRouteLocator class, defining a new request route locator GwPreloadRouteLocator to determine the request routing method of the target requester based on the request path of the target requester, thereby obtaining the first verification rule that matches the target service of the target requester based on the request routing method.

[0077] More specifically, step S104-2 may include steps S104-22 to S104-26:

[0078] Step S104-22: Based on the request path of the original service request, obtain the request routing method of the target requester from the routing rules;

[0079] Specifically, when an original service request is received from the target requester, the request path of the original service request can be obtained. Based on the obtained request path, the associated request routing method is obtained from the association between request paths and request routing methods included in the routing rules, and the obtained request routing method is determined as the request routing method of the target requester. Alternatively, based on the obtained request path, the associated requester identifier is obtained from the association between request paths and requester identifiers included in the routing rules, and the obtained requester identifier is determined as the requester identifier of the target requester. Based on the requester identifier of the target requester, the associated request routing method is obtained from the association between requester identifiers and request routing methods included in the routing rules, and the obtained request routing method is determined as the request routing method of the target requester.

[0080] Step S104-24: If the request routing method is the first routing method, then obtain the associated verification rule from the routing rules according to the request path, and determine the obtained verification rule as the first verification rule that matches the target service of the target requester.

[0081] Considering the different data processing rules of different requesters, some requesters want different request paths for different service types, while others want the same request path for all service types; some requesters want different encryption / decryption methods and different signature / verification methods for different service types, while others want the same encryption / decryption method and the same signature / verification method for all service types. Based on this, this application provides two routing methods: a first routing method and a second routing method. The first routing method represents a one-to-one correspondence between request paths and service types, meaning that for the same requester, each service type uses one request path; that is, each request path is associated with a service type and the various rules under that service type. The second routing method represents a one-to-many correspondence between request paths and service types, meaning that for the same requester, all service types use the same request path; in this case, to obtain a specific rule under a certain service type, a secondary location operation is required, as shown in steps S104-26. The first routing method can also be called the path routing method, and the second routing method can also be called the method routing method.

[0082] As an example, requester A uses the first routing method, with service 1 of requester A using request path 1 and service 2 of requester A using request path 2. Requester B uses the second routing method, with service 1 of requester B using request path 3 and service 2 of requester B also using request path 3.

[0083] Furthermore, when it is determined that the request routing method of the target requester is the first routing method, the verification rule can be obtained from the routing rules, including the rules associated with the request path, based on the request path, and the obtained verification rule can be determined as the first verification rule that matches the target service of the target requester.

[0084] Step S104-26: If the request routing method is the second routing method, then obtain the preset fields and their values ​​from the request path or the original service request; obtain the associated verification rules from the routing rules based on the preset fields and their values, and determine the obtained verification rules as the first verification rules that match the target service of the target requester.

[0085] Specifically, when the request routing method is determined to be the second routing method, a secondary positioning operation is performed in the routing rules based on the field values ​​of preset fields included in the request path or the original service request to locate the service type of the target service. Then, based on the association between the target requester and the verification rules under the target service included in the routing rules, the associated verification rules are obtained from the rules corresponding to the service type of the target service, and the obtained verification rules are determined as the first verification rule matching the target service of the target requester. The preset fields can be set as needed in actual applications; in one implementation, the preset field is "method".

[0086] As an example, the original service request path is / mock / req, and the original service request is as follows:

[0087] {"method":"credit",

[0088] "sign":"RZEvPQqWA==",

[0089] "sk":"YltRh1ZDup",

[0090] "bizContent":"7Suw4n2R…3n"}

[0091] Where `sign` is the signature data, `sk` is the key, and `bizContent` is the encrypted service data to be processed for the target service. Based on the request path ` / mock / req`, the target requester's request routing method is determined to be the second routing method. Therefore, the preset field `method` and its value `credit` are obtained from the original service request. The routing rules include a request path format for service type 2 of the target requester, which is ` / mock / req ms_rk = method & ms_rv = credit`. Based on `method` and its value `credit`, the request path for service type 2 can be matched, and the first verification rule is obtained from the rules corresponding to service type 2.

[0092] Step S104-4: Determine the first field to be converted and the first target field corresponding to the first field to be converted in the original service request according to the routing rules;

[0093] As mentioned above, the service gateway in this embodiment supports encrypted data transmission. Therefore, to ensure data security, each requester typically carries encrypted service data and signature data in the original service request. Depending on the encryption method, the original service request can also carry the ciphertext of the encryption key. For example, if the AES encryption algorithm is used, the requester can use its private key to encrypt the encryption key used by the AES encryption algorithm, or use the public key of the service platform to encrypt the encryption key used by the AES encryption algorithm, and carry the ciphertext of the encrypted key in the original service request. For example, in the above example, YltRh1ZDup is the ciphertext of the encryption key.

[0094] To facilitate the service gateway's verification of the legitimacy of the original service request, in one or more embodiments of this application, when the service gateway receives the original service request, it first performs a conversion process on a first field to be converted in the original service request. This first field to be converted may include a field representing the ciphertext of the encryption key, a field representing the ciphertext of the service data, etc.

[0095] Step S104-6: Obtain the first field value of the first field to be converted from the original service request, and generate the first verification request based on the first target field and the first field value;

[0096] Continuing with the example above, based on the routing rules, the first fields to be transformed in the original service request are determined to be sk and bizContent. The first target field corresponding to the first field to be transformed, sk, is secretKey, and the first target field corresponding to the first field to be transformed, bizContent, is data. The field value of the first field to be transformed, sk, is obtained from the original service request as YltRh1ZDup, and the field value of the first field to be transformed, bizContent, is 7Suw4n2R…3n. Therefore, the generated first verification request is as follows:

[0097] {"sign":"RZEvPQqWA==",

[0098] "secretKey":"YltRh1ZDup",

[0099] "data":"7Suw4n2R…3n"}

[0100] Where `sign` is the signature data, `secretKey` is the key, and `data` is the encrypted service data to be processed by the target requester regarding the target service. It should be noted that in this example, since subsequent processing no longer uses `"method":"credit"`, the first request to be verified may not include `"method":"credit"`; the specific content of the first request to be verified can be set as needed in actual applications.

[0101] Step S104-8: Perform first verification processing on the first field value in the first request to be verified according to the first verification rule;

[0102] Specifically, the decryption rules and signature verification rules are obtained from the first verification rules; the encrypted service data included in the first request to be verified is decrypted according to the decryption rules; the signature data included in the first request to be verified is verified according to the signature verification rules; if both the decryption and signature verification are successful, the verification is determined to be successful; otherwise, the verification is determined to be unsuccessful.

[0103] It should be noted that when the original service request carries the ciphertext of the encryption key, the decryption method may include a first decryption method and a second decryption method. The service gateway decrypts the ciphertext of the encryption key according to the obtained first decryption method to obtain the plaintext of the encryption key, and decrypts the ciphertext of the service data using the plaintext of the encryption key according to the second decryption method.

[0104] Continuing with the example above, the encrypted service data 7Suw4n2R…3n included in the first request to be verified is decrypted according to the obtained decryption method, and the signature data RZEvPQqWA included in the first request to be verified is verified according to the signature verification method; if both the decryption and signature verification are successful, the verification is determined to be successful; if at least one of the processes fails, the verification is determined to be unsuccessful.

[0105] Step S104-10: If the result of the first verification process is that the verification is successful, then determine the second field to be converted and the second target field corresponding to the second field to be converted in the first request to be verified according to the routing rules.

[0106] Specifically, if the result of the first verification process is that the verification passes, then the second field to be converted in the service data plaintext corresponding to the service data ciphertext in the first request to be verified, and the second target field corresponding to the second field to be converted are determined according to the routing rules.

[0107] Corresponding to steps S104-2 to S104-10 above, such as Figure 4 As shown, step S106 may include the following step S106-2:

[0108] Step S106-2, acquiring a second field value of a second field to be converted from a first to-be-verified request, and generating a standard service request based on a second target field and the second field value.

[0109] Specifically, acquiring the field value of the second field to be converted from the plaintext of service data corresponding to the ciphertext of service data in the first to-be-verified request. Generating target conversion data of the plaintext of service data according to the second target field and the second field value, and replacing the ciphertext of service data in the first to-be-verified request with the target conversion data to obtain the standard service request.

[0110] Continuing the foregoing example, for example, the plaintext of service data corresponding to the ciphertext of service data in the first to-be-verified request is as follows:

[0111] {"userId":"userId_1234",

[0112] "name":"Zhang San",

[0113] "idNo":"342623200001111111",

[0114] "phone":"18888888888",

[0115] "bankCardNo":"1111111111111111112",

[0116] "bankCellphone":"18888888881",

[0117] "applyNo":"mock_applyNo_1234",

[0118] "applySerialNo":"1234",

[0119] "authType":"NCIIC",

[0120] "addressInfo":{"address":"Unit 1, Room 101, Building 1, XX Community, XX Street, Daxing District, Beijing,

[0121] "provinceCode":"111111",

[0122] "provinceName":"Beijing Municipality",

[0123] "cityCode":"111111",

[0124] "cityName":"Beijing Municipality"},

[0125] "authCode":"mock_authCode_1",

[0126] "contact":{"name":"Jack",

[0127] "channelPhone":"17777777777",

[0128] "relation":"R005"},

[0129] "purpose":"PL03",

[0130] "needApplyCheck":false}

[0131] The target transformed data obtained is as follows:

[0132] {"systemId":"gw",

[0133] "address":"Unit 1, Building 1, XX Community, XX Street, Daxing District, Beijing",

[0134] "authCode":"mock_authCode_1",

[0135] "bankCardNo":"11111111111111111112",

[0136] "purpose":"PL01",

[0137] "bankCellphone":"18888888881",

[0138] "provinceCode":"111111",

[0139] "cityCode":"111111",

[0140] "needApplyCheck":"false",

[0141] "certNo":"342623200001011112",

[0142] "contactList":[{"name":"Jack",

[0143] "mobile":"17777777777",

[0144] "relation":"RF02"}],

[0145] "cityName":"Beijing",

[0146] "userId":"jd_userId_1235",

[0147] "requestId":"jd_userId_1235",

[0148] "appid":"jdloan",

[0149] "applyNo":"mock_applyNo_12345",

[0150] "applySerialNo":"12345",

[0151] "name":"Tom",

[0152] "cellphone":"18888888889",

[0153] "provinceName":"Beijing",

[0154] "authType":"BANK_P2"}.

[0155] The generated standard service request is as follows:

[0156] {"sign":"RZEvPQqWA==",

[0157] "secretKey":"YltRh1ZDup",

[0158] "data":{"systemId":"gw",

[0159] "address":"Unit 1, Building 1, Other Residential Complex, Other Streets, Daxing District, Beijing","authCode":"mock_authCode_1",

[0160] "bankCardNo":"11111111111111111112",

[0161] "purpose":"PL01",

[0162] "bankCellphone":"18888888881",

[0163] "provinceCode":"111111",

[0164] "cityCode":"111111",

[0165] "needApplyCheck":"false",

[0166] "certNo":"342623200001011112",

[0167] "contactList":[{"name":"Jack",

[0168] "mobile":"17777777777",

[0169] "relation":"RF02"}],

[0170] "cityName":"Beijing",

[0171] "userId":"jd_userId_1235",

[0172] "requestId":"jd_userId_1235",

[0173] "appid":"jdloan",

[0174] "applyNo":"mock_applyNo_12345",

[0175] "applySerialNo":"12345",

[0176] "name":"Tom",

[0177] "cellphone":"18888888889",

[0178] "provinceName":"Beijing",

[0179] "authType":"BANK_P2"}

[0180] Furthermore, if the result of the first verification process is a failure, a request failure message is sent to the target requester.

[0181] It should be noted that the service data plaintext, target conversion data, and standard service request corresponding to the above-mentioned service data ciphertext are for illustrative purposes only and are not intended to limit the scope of the application. The second field to be converted and the second target field can be set as needed in actual applications.

[0182] Therefore, by improving the existing Zuul gateway, encrypted data transmission was achieved, ensuring data transmission security. Since the signature data is obtained by signing the target requester's private key, signature verification prevents others from impersonating the target requester to make service requests. At the same time, data transformation based on routing rules eliminates the need for the service gateway to maintain a set of data processing rules for each requester, avoiding data processing rule redundancy and reducing the maintenance cost and management difficulty of data processing rules.

[0183] Furthermore, to ensure the accuracy of the standard service request, in one or more embodiments of this application, generating the standard service request based on the second target field and the second field value in step S106-2 may include:

[0184] A second verification request is generated based on the second target field and the value of the second field.

[0185] According to the second verification rules included in the routing rules, the accuracy of some or all fields in the second request to be verified is verified.

[0186] If the result of the second verification process is that the verification passes, then the second request to be verified is determined as a standard service request.

[0187] Furthermore, if the result of the second verification process is that the verification fails, a prompt message is sent to the target requester.

[0188] The second validation rule may include field validation rules, such as notNull (whether a field is required) rules. The second validation process can be performed by executing the field validation engine to verify the accuracy of some or all fields in the second validation request.

[0189] Furthermore, in order to know the service processing result, in one or more embodiments of this application, step S108 may be followed by steps S110 to S118:

[0190] Step S110: Receive the standard service processing result sent by the service platform;

[0191] Step S112: Determine the recipient corresponding to the standard service processing result;

[0192] Considering that in practical applications, the requester of the target service and the recipient of the service processing result may be different, in this embodiment of the application, after receiving the standard service processing result sent by the service middleware, the service gateway determines the recipient corresponding to the standard service processing result. Optionally, the standard service processing result includes a recipient identifier, and the service gateway determines the recipient corresponding to the recipient identifier as the recipient corresponding to the standard service processing result; or, the standard service processing result includes the service serial number of the target service in this instance, and the associated recipient identifier is obtained from the recorded association relationship between service serial numbers and recipient identifiers based on the service serial number, and the recipient corresponding to the obtained recipient identifier is determined as the recipient corresponding to the standard service processing result.

[0193] Step S114: Obtain the target transformation rules of the receiver regarding the service processing result from the routing rules;

[0194] Specifically, based on the receiver's identifier and the target service's service identifier, the target transformation rules for the receiver's service processing results are obtained from the routing rules. These target transformation rules may include field transformation rules, encryption rules, and signature rules.

[0195] Step S116: Transform the standard service processing result according to the target transformation rules to obtain the target service processing result;

[0196] The conversion process for the standard service result is similar to the conversion process for the first request to be verified mentioned above. That is, after converting the standard service result, the converted result is verified. If the verification passes, the converted result is determined as the target service result. For details, please refer to the relevant description above. Repeated parts will not be repeated here.

[0197] Step S118: Send the target service processing result to the recipient.

[0198] To clearly illustrate the various data processing stages of the service gateway and the configuration content of the rule configuration system in this application, a data processing diagram is provided in the embodiments of this application, such as... Figure 5 As shown. Figure 5 The exception handling can include the handling of verification failures mentioned above. The service gateway can receive the original service requests sent by each requester through a unified entry point and send the service processing results to the corresponding requester through a unified exit point. The processing procedures of each service in the service platform can be configured as needed in actual applications. Figure 5 The specific implementation process of each step shown can be found in the relevant descriptions above.

[0199] In one or more embodiments of this application, when an original service request for service processing of a target service is received from a target requester, the fields to be converted and their corresponding target fields in the original service request are first determined according to routing rules. Then, the field values ​​of the fields to be converted are obtained from the original service request, and a standard service request recognizable by the service platform is generated based on the target fields and their values. Finally, the standard service request is sent to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, it is not necessary to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplicate rules or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the management difficulty and cost of rules are reduced.

[0200] Corresponding to the service processing method described above, based on the same technical concept, one or more embodiments of this application also provide a service processing apparatus. Figure 6 A schematic diagram of the module composition of a service processing apparatus provided for one or more embodiments of this application, such as... Figure 6 As shown, the device includes:

[0201] The receiving module 201 is used to receive the original service request sent by the target requester; the original service request is used to request service processing for the target service;

[0202] The determining module 202 is used to determine the fields to be converted in the original service request and the target fields corresponding to the fields to be converted according to the routing rules; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester, wherein the fields to be converted by each requester are different fields representing the same meaning;

[0203] The generation module 203 is used to obtain the field value of the field to be converted from the original service request, and generate a standard service request based on the target field and the field value; the fields included in the standard service request are fields that can be identified by the service platform;

[0204] The sending module 204 is used to send the standard service request to the service middle platform; the standard service request is used to request the service middle platform to perform service processing on the target service.

[0205] The service processing apparatus provided in this application, upon receiving an original service request from a target requester requesting service processing for a target service, first determines the fields to be converted and their corresponding target fields in the original service request according to routing rules. Then, it obtains the field values ​​of the fields to be converted from the original service request and generates a standard service request recognizable by the service platform based on the target fields and their values. Finally, it sends the standard service request to the service platform, enabling the service platform to process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, there is no need to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplicate or similar rules. In other words, while ensuring effective service provision to each requester, rule redundancy is avoided, reducing the difficulty and cost of rule management.

[0206] It should be noted that the embodiments of the service processing device in this application and the embodiments of the service processing method in this application are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding service processing method mentioned above, and the repeated parts will not be described again.

[0207] Corresponding to the service processing method described above, and based on the same technical concept, one or more embodiments of this application also provide a service processing system. Figure 7 This is a schematic diagram illustrating the composition of a service processing system provided in one or more embodiments of this application, such as... Figure 7 As shown, the system includes: target requester 301, service gateway 302, and service middleware 303;

[0208] The target requester 301 is used to send an original service request to the service gateway 302;

[0209] The service gateway 302 is configured to receive the original service request sent by the target requester 301, determine the field to be converted in the original service request and the target field corresponding to the field to be converted according to the routing rules; obtain the field value of the field to be converted from the original service request, and generate a standard service request based on the target field and the field value; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the field to be converted in the original service request sent by each requester into the target field according to the data processing rules corresponding to each requester, wherein the fields to be converted by each requester are different fields representing the same meaning;

[0210] The service platform 303 is used to process the target service according to the received standard service request.

[0211] Optional, such as Figure 8 As shown, the system also includes a rule configuration system 304;

[0212] The rule configuration system 304 is used to generate rule information based on the acquired rule configuration information;

[0213] The service gateway 302 is also used to obtain the rule information from the rule configuration system 304; integrate the rule information into the routing rule according to a preset integration method; and save the routing rule to a local cache.

[0214] Optionally, the service gateway 302 is further configured to send heartbeat messages to the rule configuration system 304 at preset time intervals; if it receives response data sent by the rule configuration system 304, it obtains the current rule information from the rule configuration system 304; according to the preset integration method, it integrates the current rule information into a routing rule to be compared; it compares the routing rule to be compared with the routing rule currently stored in the local cache; if the comparison result is inconsistent, it updates the routing rule currently stored in the local cache according to the routing rule to be compared.

[0215] Accordingly, the rule configuration system 304 is also used to receive the heartbeat message sent by the service gateway 302 and send the response data to the service gateway 302.

[0216] The service processing system provided in this application embodiment, when a service gateway receives an original service request from a target requester requesting service processing for a target service, first determines the fields to be converted and their corresponding target fields in the original service request according to routing rules. Then, it obtains the field values ​​of the fields to be converted from the original service request and generates a standard service request recognizable by the service platform based on the target fields and their values. Finally, it sends the standard service request to the service platform, enabling the service platform to process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, there is no need to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplicate or similar rules. In other words, while ensuring effective service provision to each requester, rule redundancy is avoided, reducing the difficulty and cost of rule management.

[0217] It should be noted that the embodiments of the service processing system in this application and the embodiments of the service processing method in this application are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding service processing method mentioned above, and the repeated parts will not be described again.

[0218] Furthermore, corresponding to the service processing method described above, based on the same technical concept, one or more embodiments of this application also provide an electronic device for executing the above-described service processing method. Figure 9 This is a schematic diagram of the structure of an electronic device provided for one or more embodiments of this application.

[0219] like Figure 9 As shown, electronic devices can vary considerably due to differences in configuration or performance. They may include one or more processors 401 and memories 402. The memories 402 may store one or more application programs or data. The memories 402 may be temporary or persistent storage. The application programs stored in the memories 402 may include one or more modules (not shown), each module including a series of computer-executable instructions within the electronic device. Furthermore, the processor 401 may be configured to communicate with the memories 402 and execute the series of computer-executable instructions stored in the memories 402 on the electronic device. The electronic device may also include one or more power supplies 403, one or more wired or wireless network interfaces 404, one or more input / output interfaces 405, one or more keyboards 406, etc.

[0220] In one specific embodiment, the electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for use in the electronic device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0221] Receive the original service request sent by the target requester; the original service request is used to request service processing for the target service;

[0222] According to the routing rules, the fields to be converted in the original service request and the target fields corresponding to the fields to be converted are determined; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester, wherein the fields to be converted by each requester are different fields representing the same meaning;

[0223] The field values ​​of the fields to be transformed are obtained from the original service request, and a standard service request is generated based on the target field and the field values; the fields included in the standard service request are fields that can be recognized by the service platform.

[0224] The standard service request is sent to the service platform; the standard service request is used to request the service platform to process the target service.

[0225] The electronic device provided in one or more embodiments of this application, when receiving an original service request from a target requester requesting service processing for a target service, first determines the field to be converted and the corresponding target field in the original service request according to routing rules. Then, it obtains the field value of the field to be converted from the original service request and generates a standard service request recognizable by the service platform based on the target field and the field value. Finally, it sends the standard service request to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, it is not necessary to maintain multiple sets of data processing rules, but only the routing rules need to be maintained. Accordingly, there is no problem of duplication of the same or similar rules. In other words, while ensuring that effective services can be provided to each requester, rule redundancy is avoided, and the management difficulty and management cost of rules are reduced.

[0226] It should be noted that the embodiments concerning electronic devices in this application and the embodiments concerning service processing methods in this application are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding service processing method described above, and the repeated parts will not be described again.

[0227] Furthermore, corresponding to the service processing method described above, based on the same technical concept, one or more embodiments of this application also provide a storage medium for storing computer-executable instructions. In a specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instructions stored in the storage medium are executed by a processor, they can realize the following process:

[0228] Receive the original service request sent by the target requester; the original service request is used to request service processing for the target service;

[0229] According to the routing rules, the fields to be converted in the original service request and the target fields corresponding to the fields to be converted are determined; the routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester, wherein the fields to be converted by each requester are different fields representing the same meaning;

[0230] The field values ​​of the fields to be transformed are obtained from the original service request, and a standard service request is generated based on the target field and the field values; the fields included in the standard service request are fields that can be recognized by the service platform.

[0231] The standard service request is sent to the service platform; the standard service request is used to request the service platform to process the target service.

[0232] When the computer-executable instructions stored in the storage medium provided in one or more embodiments of this application are executed by a processor, upon receiving an original service request from a target requester requesting service processing for a target service, the original service request is transformed into a standard service request according to routing rules applicable to each requester. First, the fields to be transformed and their corresponding target fields in the original service request are determined according to the routing rules. Then, the field values ​​of the fields to be transformed are obtained from the original service request, and a standard service request recognizable by the service platform is generated based on the target fields and field values. Finally, the standard service request is sent to the service platform so that the service platform can process the target service according to the standard service request. In this process, since the routing rules are obtained by integrating the data processing rules of each requester, and can convert different fields representing the same meaning in the original service requests sent by each requester into fields recognizable by the service platform, even if the data processing rules of each requester are different, it is not necessary to maintain multiple sets of data processing rules; only the routing rules need to be maintained. Consequently, there is no problem of duplication of identical or similar rules. In other words, while ensuring that effective services can be provided to all requesters, rule redundancy is avoided, and the difficulty and cost of rule management are reduced.

[0233] It should be noted that the embodiments concerning storage media in this application and the embodiments concerning service processing methods in this application are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding service processing method described above, and the repeated parts will not be described again.

[0234] The foregoing has described specific embodiments of this application. 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 results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0235] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0236] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0237] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0238] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing the embodiments of this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0239] Those skilled in the art will understand that one or more embodiments of this application can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0240] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0241] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0242] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0243] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0244] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0245] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0246] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0247] One or more embodiments of this application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. One or more embodiments of this application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0248] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0249] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A service processing method, characterized in that, include: Receive the original service request sent by the target requester; The original service request is used to request service processing for the target service; Based on the routing rules, determine the fields to be converted in the original service request and the target fields corresponding to the fields to be converted; The routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester. The fields to be converted by each requester are different fields representing the same meaning. The integration process includes establishing the association between each requester and the conversion rules under different service types. The routing rules are pre-stored in the local cache of the service gateway. The field values ​​of the fields to be transformed are obtained from the original service request, and a standard service request is generated based on the target field and the field values; the fields included in the standard service request are fields that can be recognized by the service platform. The standard service request is sent to the service platform; the standard service request is used to request the service platform to process the target service.

2. The method according to claim 1, characterized in that, The data processing rules include validation rules. The step of determining the field to be converted in the original service request and the target field corresponding to the field to be converted, based on the routing rules, includes: Obtain a first verification rule from the routing rules that matches the target service of the target requester; The first field to be converted and the first target field corresponding to the first field to be converted in the original service request are determined according to the routing rules. Obtain the first field value of the first field to be converted from the original service request, and generate a first verification request based on the first target field and the first field value; The first field value in the first request to be verified is subjected to a first verification process according to the first verification rule. If the result of the first verification process is that the verification passes, then the second field to be converted and the second target field corresponding to the service data ciphertext in the first request to be verified are determined according to the routing rules. The step of obtaining the field value of the field to be converted from the original service request and generating a standard service request based on the target field and the field value includes: Obtain the second field value of the second field to be converted from the service data corresponding to the encrypted service data in the first request to be verified, and generate a standard service request based on the second target field and the second field value.

3. The method according to claim 2, characterized in that, The step of obtaining a first verification rule from the routing rules that matches the target service of the target requester includes: Based on the request path of the original service request, the request routing method of the target requester is obtained from the routing rules; If the request routing method is the first routing method, then the associated verification rule is obtained from the routing rules according to the request path, and the obtained verification rule is determined as the first verification rule that matches the target service of the target requester; the first routing method indicates that the request path and the service type have a one-to-one correspondence. If the request routing method is the second routing method, then a preset field and the field value of the preset field are obtained from the request path or the original service request; based on the preset field and the field value, the associated verification rule is obtained from the routing rules, and the obtained verification rule is determined as the first verification rule that matches the target service of the target requester; the second routing method indicates that the request path and the service type have a one-to-many correspondence.

4. The method according to claim 2, characterized in that, The original service request and the first request to be verified include signature data, and the first field value includes the ciphertext of the service data to be processed for the target service. The first verification process for the value of the first field in the first request to be verified according to the first verification rule includes: Obtain the decryption rules and signature verification rules from the first verification rules; The encrypted service data included in the first request to be verified is decrypted according to the decryption rules. The signature data included in the first request to be verified is processed according to the signature verification rules. If both the decryption and signature verification processes are successful, the verification is considered successful; otherwise, the verification is considered unsuccessful.

5. The method according to claim 2, characterized in that, The routing rules include a second verification rule; the generation of a standard service request based on the second target field and the value of the second field includes: A second verification request is generated based on the second target field and the value of the second field. According to the second verification rule, the accuracy of some or all fields in the second verification request is subjected to a second verification process. If the result of the second verification process is that the verification passes, then the second request to be verified is determined as a standard service request.

6. The method according to claim 1, characterized in that, After sending the standard service request to the service middleware, the method further includes: Receive the standard service processing result sent by the service platform; Determine the recipient corresponding to the standard service processing result; Obtain the target transformation rule of the receiver regarding the service processing result from the routing rules; The standard service processing result is transformed according to the target transformation rule to obtain the target service processing result; the fields included in the target service processing result are fields that can be identified by the receiver. The result of the target service processing is sent to the recipient.

7. The method according to claim 1, characterized in that, The method further includes: Send heartbeat messages to the rule configuration system at preset time intervals; If a response data is received from the rule configuration system, the current rule information is obtained from the rule configuration system; the rule information is used to characterize the data processing rules of each requester. According to the preset integration method, the current rule information is integrated into routing rules to be compared; The routing rules to be compared are compared with the routing rules currently stored in the local cache. If the comparison results are inconsistent, the routing rules currently stored in the local cache will be updated according to the routing rules to be compared.

8. A service processing apparatus, characterized in that, include: The receiving module is used to receive the original service request sent by the target requester; The original service request is used to request service processing for the target service; The determination module is used to determine the field to be converted in the original service request and the target field corresponding to the field to be converted, based on the routing rules. The routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester. The fields to be converted by each requester are different fields representing the same meaning. The integration process includes establishing the association between each requester and the conversion rules under different service types. The routing rules are pre-stored in the local cache of the service gateway. The generation module is used to obtain the field value of the field to be transformed from the original service request, and generate a standard service request based on the target field and the field value; the fields included in the standard service request are fields that can be identified by the service platform. The sending module is used to send the standard service request to the service middle platform; the standard service request is used to request the service middle platform to perform service processing on the target service.

9. A service processing system, characterized in that, include: Target requester, service gateway, and service middleware; The target requester is used to send an original service request to the service gateway; The original service request is used to request service processing for the target service; The service gateway is configured to receive the original service request sent by the target requester, determine the fields to be converted and the corresponding target fields in the original service request according to routing rules, obtain the field values ​​of the fields to be converted from the original service request, and generate a standard service request based on the target fields and the field values. The routing rules are obtained by integrating the data processing rules of each requester, so as to convert the fields to be converted in the original service requests sent by each requester into target fields according to the data processing rules corresponding to each requester. The fields to be converted by each requester are different fields representing the same meaning. The integration process includes establishing the association between each requester and the conversion rules under different service types. The routing rules are pre-stored in the local cache of the service gateway. The service platform is used to process the target service based on the received standard service request.

10. The system according to claim 9, characterized in that, The system also includes a rule configuration system; The service gateway is also used to send heartbeat messages to the rule configuration system at preset time intervals; if it receives response data sent by the rule configuration system, it obtains the current rule information from the rule configuration system, and the rule information is used to characterize the data processing rules of each requester. According to a preset integration method, the current rule information is integrated into a routing rule to be compared; the routing rule to be compared is compared with the routing rule currently stored in the local cache; if the comparison result is inconsistent, the routing rule currently stored in the local cache is updated according to the routing rule to be compared. The rule configuration system is used to generate rule information based on the obtained rule configuration information; In addition, it receives the heartbeat message sent by the service gateway and sends the response data to the service gateway.

11. An electronic device, characterized in that, include: processor; as well as, A memory configured to store computer-executable instructions configured to be executed by the processor, the executable instructions including steps for performing the service processing method as described in any one of claims 1-7.

12. A storage medium, characterized in that, The storage medium is used to store computer-executable instructions that cause the computer to perform the service processing method as described in any one of claims 1-7.

Images