Supplier calling method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a supplier service calling method and device, equipment and a storage medium, and belongs to the technical field of Internet. The method comprises the following steps: receiving a supplier service calling request sent by a downstream system through a public interface; verifying the supplier service calling request; under the condition that the verification of the supplier service calling request is passed, service distribution is carried out according to the supplier identifier, the interface service identifier and a supplier public docking template defined by the public interface, and a supplier service calling processing strategy corresponding to the supplier service calling request is obtained; wherein the supplier service calling processing strategy is used for carrying out supplier service calling on a target supply interface of a target supplier based on the business parameters; executing the supplier service calling processing strategy to obtain a supplier service calling result corresponding to the supplier service calling request; and sending a supplier service calling result to a downstream system through the public interface. The embodiment of the invention can improve the development efficiency.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus, device and storage medium for invoking supplier services. Background Technology

[0002] In the digital age, vendor API access has become an important means of efficient data exchange across domains and organizations. This technology allows different systems to communicate through defined interfaces without needing to understand each other's internal logic.

[0003] The current common practice for integrating supplier APIs is to implement a separate interface on the caller for each different API from different suppliers. While this method enables data exchange, it requires the caller to write a separate interface for each supplier's API, resulting in a large amount of redundant code and low development efficiency. Therefore, developing a more efficient method for integrating supplier APIs has become a pressing technical problem in the field of internet technology. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, and storage medium for invoking supplier services, aiming to reduce code redundancy and improve development efficiency.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for invoking a supplier service, the method comprising:

[0006] The system receives supplier service call requests from downstream systems through the public interface; wherein, the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system;

[0007] The supplier service call request is validated;

[0008] If the supplier service call request passes verification, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters;

[0009] Execute the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request;

[0010] The supplier service call result is sent to the downstream system through the public interface.

[0011] In some embodiments, the target system further includes: an abstract interface corresponding to each supplier, and a subclass interface corresponding to the supply interface of each supplier; wherein, the abstract interface corresponding to each supplier is used to define the supplier abstract class of the supplier and inherit the supplier common interface template; the subclass interface corresponding to the supply interface of each supplier is used to define the supplier subclass of the supply interface and inherit the supplier abstract class of the supplier;

[0012] The step of distributing services based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request includes:

[0013] Based on the supplier identifier, the supplier abstract class defined in the abstract interface corresponding to the target supplier is determined as the target supplier abstract class;

[0014] Based on the interface service identifier, the supplier subclass defined in the subclass interface corresponding to the target supply interface is determined as the target supplier subclass;

[0015] Based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass, a supplier service call processing strategy corresponding to the supplier service call request is generated.

[0016] In some embodiments, generating a supplier service invocation processing strategy corresponding to the supplier service invocation request based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass includes:

[0017] Using Java reflection technology, a supplier service call processing strategy corresponding to the supplier service call request is generated based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass.

[0018] In some embodiments, the supplier service invocation processing strategy includes: a data format processing method, an HTTP request construction method, and a data parsing method corresponding to the target supplier interface;

[0019] The step of executing the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request includes:

[0020] The business parameters are processed according to the data format processing method described above to obtain the target parameters;

[0021] Construct a target HTTP request based on the target parameters according to the described HTTP request construction method;

[0022] The target HTTP request is sent to the target supply interface through the public interface;

[0023] The public interface receives the request result corresponding to the target HTTP request sent by the target supply interface.

[0024] According to the data parsing method described above, the call result of the target supply interface is parsed from the request result;

[0025] The call result is encapsulated according to the unified data encapsulation format of the target system to obtain the supplier service call result corresponding to the supplier service call request.

[0026] In some embodiments, the verification of the supplier service call request includes:

[0027] The permission verification is performed on the supplier service call request to obtain the first verification result;

[0028] Perform parameter integrity verification on the supplier service call request to obtain a second verification result;

[0029] If both the first and second verification results are successful, the supplier service call request is determined to have passed verification.

[0030] In some embodiments, the step of distributing services based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request includes:

[0031] Determine the MD5 value corresponding to the business parameter;

[0032] The target system's Redis cache is queried based on the MD5 value to obtain the query result;

[0033] If the query result indicates that the Redis does not cache the MD5 value, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request.

[0034] After executing the supplier service call processing strategy and obtaining the supplier service call result corresponding to the supplier service call request, the method further includes:

[0035] Determine the value corresponding to the result of the supplier service call;

[0036] The MD5 value is associated with the value and stored in the Redis cache.

[0037] In some embodiments, after querying the Redis cache of the target system based on the MD5 value to obtain the query result, the method further includes:

[0038] If the query result indicates that the MD5 value exists in the Redis cache, the supplier service call result corresponding to the target value in the Redis cache is sent to the downstream system; the target value is the value associated with the MD5 value in the Redis cache.

[0039] To achieve the above objectives, a second aspect of this application provides a supplier service invocation apparatus, the apparatus comprising:

[0040] The receiving module is used to receive a supplier service call request sent by a downstream system through the public interface; wherein the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system;

[0041] The verification module is used to verify the supplier service call request;

[0042] The processing strategy module is used to distribute services according to the supplier identifier, the interface service identifier, and the supplier common interface template when the supplier service call request passes the verification, and obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters;

[0043] The call result module is used to execute the supplier service call processing strategy and obtain the supplier service call result corresponding to the supplier service call request;

[0044] The sending module is used to send the supplier service call result to the downstream system through the public interface.

[0045] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0046] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0047] The supplier service invocation method, apparatus, device, and storage medium proposed in this application first receive a supplier service invocation request sent by a downstream system through a public interface. The supplier service invocation request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system. Second, the supplier service invocation request is verified. Then, if the supplier service invocation request passes verification, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier's public interface template to obtain a supplier service invocation processing strategy corresponding to the supplier service invocation request. This supplier service invocation processing strategy is used to invoke the target supplier's target supply interface based on the business parameters. Next, the supplier service invocation processing strategy is executed to obtain a supplier service invocation result corresponding to the supplier service invocation request. Finally, the supplier service invocation result is sent to the downstream system through the public interface. Thus, the method of this application receives supplier service call requests from downstream systems through a public interface, then distributes services according to the call request and the supplier's public interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request. After executing the supplier service call processing strategy, the service call result is obtained and sent to the downstream system. This allows the downstream system to call the corresponding supplier's service through the public interface without changing its own parameter format. In this way, the downstream system can meet the needs of interfacing with multiple suppliers through the public interface, without having to implement a corresponding interface for different interfaces of different suppliers. This reduces redundant code and improves development efficiency. At the same time, when making supplier service calls, there is no need to first convert the call request to obtain the target supplier interface when facing any supplier. Instead, only a unified call request format needs to be used, thus simplifying supplier service calls. Attached Figure Description

[0048] Figure 1 This is a flowchart of the supplier service invocation method provided in the embodiments of this application;

[0049] Figure 2 yes Figure 1 The flowchart of step S102 in the document;

[0050] Figure 3 yes Figure 1 The flowchart of step S103 in the process;

[0051] Figure 4 This is a diagram showing the relationship between the supplier common interface template, abstract interface, and subclass interface provided in this application embodiment;

[0052] Figure 5 yes Figure 1 The flowchart of step S104 in the process;

[0053] Figure 6 yes Figure 1 Another flowchart of step S104 in the process;

[0054] Figure 7 This is another flowchart of the supplier service invocation method provided in the embodiments of this application;

[0055] Figure 8 This is a schematic diagram of the structure of the supplier service invocation device provided in the embodiments of this application;

[0056] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0058] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0059] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0060] First, let's analyze some of the terms used in this application:

[0061] In Object-Oriented Programming (OOP), parent class (also called base class, superclass, or superclass) and child class (also called derived class or subclass) are two fundamental terms in the class inheritance relationship. A parent class is a class that is inherited by other classes in the inheritance relationship. It defines a set of attributes and methods that can be inherited by subclasses. The parent class provides a set of common characteristics that are shared across multiple subclasses. A subclass is a class that inherits from the parent class. A subclass inherits the attributes and methods of the parent class and can add or modify these attributes and methods to meet specific needs. A subclass can extend the functionality of the parent class and can also override the parent class's methods to provide specific implementations.

[0062] Characteristics of inheritance: Inheritance: Subclasses inherit public attributes and methods from their parent classes. Polymorphism: Subclasses can have different implementations, but they can interact through the parent class's interface. Encapsulation: Private members of the parent class cannot be directly accessed by the subclass; subclasses can only operate on these private members through the public methods provided by the parent class. Abstraction: Parent classes typically define some abstract methods, which subclasses need to implement according to their specific needs.

[0063] Java reflection is a powerful mechanism that allows running Java programs to access, inspect, and modify their own structures, such as classes, interfaces, fields, and methods. The core class for reflection is `java.lang.Class`, and each Java class has a corresponding `Class` object. Some key features of Java reflection include: Obtaining class information: The `Class` object can be used to obtain information such as the class name, modifiers, package, parent class, and implemented interfaces. Creating object instances: Even if the specific class name is unknown at compile time, object instances can be created at runtime using reflection. Accessing fields: Private fields of a class can be read or modified. Invoking methods: Methods of a class, including private methods, can be invoked. Manipulating arrays: Arrays can be dynamically created and manipulated. Handling exceptions: Exceptions that may be thrown during reflection operations can be caught and handled. Obtaining annotations: Class annotation information can be read.

[0064] Using reflection typically involves the following steps: Obtaining the Class object: This can be done by directly calling `.class`, `Class.forName()`, or the instance's `getClass()` method. Manipulating class members: Through the Class object, you can access the class's fields, methods, etc., and perform corresponding operations.

[0065] MD5 (Message-Digest Algorithm 5) is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value, typically represented as a 32-bit hexadecimal string.

[0066] The main characteristics of MD5 include: Determinism: Identical inputs always produce the same hash value. Randomness: It is virtually impossible to find two different inputs that produce the same hash value (i.e., a collision). Irreversibility: It is almost impossible to deduce the original input from the hash value. Fast computation: The MD5 algorithm is fast, making it suitable for applications requiring rapid response.

[0067] MD5 application scenarios: Data integrity: Used to verify whether data has been tampered with during transmission or storage. Password storage: In the early days, MD5 was used to store the hash value of user passwords to verify user identity. Digital signatures: Used to generate the hash value of data as part of a digital signature to verify the source and integrity of the data.

[0068] Service distribution is a concept in software architecture that refers to the process of allocating client requests to different service providers or service instances according to certain rules and logic. This process typically involves receiving, identifying, routing, and forwarding requests. The purpose of service distribution is to ensure that client requests are processed efficiently and accurately, while optimizing resource utilization and system performance.

[0069] Based on this, embodiments of this application provide a method, apparatus, device, and storage medium for invoking supplier services, aiming to reduce code redundancy and improve development efficiency.

[0070] The supplier service invocation method, apparatus, device, and storage medium provided in this application are specifically described through the following embodiments. First, the supplier service invocation method in this application is described.

[0071] The supplier service invocation method provided in this application relates to the field of Internet technology. The supplier service invocation method provided in this application can be applied to a target system, a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the supplier service invocation method, but is not limited to the above forms.

[0072] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0073] This application may be applied, but is not limited to, SF Express's Fengyancha system. The system includes: integration with big data personnel for risk analysis, integration with third-party intelligence data, a CAPTCHA microservice, intelligence system interface aggregation and monitoring, and intelligence system interface authorization. This application does not limit the uniqueness of its application scenarios; any scenario where the methods of this application can be implemented is included within the scope of protection of this application.

[0074] The supplier service invocation method of this application is applied to a target system, which may be a logistics system or a supply chain management system. This application does not specifically limit the target system. The target system includes a public interface, which is used to define a common interface template for suppliers.

[0075] Figure 1 This is an optional flowchart of the supplier service invocation method provided in the embodiments of this application. Figure 1The method may include, but is not limited to, steps S101 to S103.

[0076] Step S101: The public interface receives a supplier service call request sent by the downstream system; wherein, the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system.

[0077] Step S102: Verify the supplier service call request;

[0078] Step S103: If the supplier service call request passes the verification, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters;

[0079] Step S104: Execute the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request;

[0080] Step S105: Send the supplier service call result to the downstream system through the public interface.

[0081] Steps S101 to S105 as illustrated in this embodiment involve: First, receiving a supplier service call request from a downstream system via a public interface; wherein the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system; second, verifying the supplier service call request; then, if the supplier service call request passes verification, distributing services based on the supplier identifier, the interface service identifier, and the supplier's public interface template to obtain a supplier service call processing strategy corresponding to the supplier service call request; wherein the supplier service call processing strategy is used to make a supplier service call to the target supplier's target supply interface based on the business parameters; then, executing the supplier service call processing strategy to obtain a supplier service call result corresponding to the supplier service call request; finally, sending the supplier service call result to the downstream system via the public interface. Thus, the method of this application receives supplier service call requests from downstream systems through a public interface, then distributes services according to the call request and the supplier's public interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request. After executing the supplier service call processing strategy, the service call result is obtained and sent to the downstream system. This allows the downstream system to call the corresponding supplier's service through the public interface without changing its own parameter format. In this way, the downstream system can meet the needs of interfacing with multiple suppliers through the public interface, without having to implement a corresponding interface for different interfaces of different suppliers. This reduces redundant code and improves development efficiency. At the same time, when making supplier service calls, there is no need to first convert the call request to obtain the target supplier interface when facing any supplier. Instead, only a unified call request format needs to be used, thus simplifying supplier service calls.

[0082] In step S101 of some embodiments, the target system receives a service call request from a downstream system through a public interface. This request includes the identity of the downstream system, the identity of the target vendor, the interface service identifier of the target vendor's interface, and business parameters.

[0083] Downstream systems can be any system requesting supplier services. These systems can invoke supplier services through the target system. A supplier service invocation request can be a request sent by a downstream system (such as an enterprise, organization, or application) to invoke a specific service of a target supplier's target interface. To ensure the recipient of the request clearly identifies the supplier, interface, and service being invoked, the request can include: the downstream system's system identity, the target supplier's supplier identity, the target supplier's target interface's interface service identifier, and the downstream system's business parameters. The target supplier can be a selected provider of specific or particular services.

[0084] The target supplier's supplier identifier can be a code or name used to uniquely identify the supplier. Each supplier may include at least one supply interface, and a supply interface can provide one or more services. The interface service identifier of the target supplier's target supply interface can be a code or name used to uniquely identify the specific service or interface provided by the supplier. The downstream system's business parameters can be specific business data or parameters passed to the supplier by the downstream system during the service invocation process. The business parameters are used to determine the specific service being invoked.

[0085] For example, suppose an e-commerce platform (downstream system) needs to call the interface of a logistics provider (target supplier) to obtain delivery options for goods. The e-commerce platform sends a service call request to the service platform (target system). The request includes the e-commerce platform's system identity, the logistics provider's supplier identity, the interface service identity of the delivery interface to be called, and business parameters such as the weight and size of the goods.

[0086] In step S102 of some embodiments, the received service call request is verified to ensure the legitimacy of the request, thereby improving the security of the service call to the supplier.

[0087] In some implementations, verifying a supplier service call request may include: performing an authorization verification on the supplier service call request to obtain a first verification result; performing a parameter integrity verification on the supplier service call request to obtain a second verification result; and determining that the supplier service call request has passed verification if both the first verification result and the second verification result are valid.

[0088] In other embodiments, verifying a supplier service call request may include: performing an authorization verification on the supplier service call request to obtain a first verification result; and if the first verification result is a successful verification, determining that the supplier service call request has passed verification.

[0089] For example, after receiving a request, the service platform first verifies that the e-commerce platform has the right to call the service and that the information provided is complete and correct.

[0090] Please see Figure 2 In some embodiments, step S102 may include, but is not limited to, steps S201 to S203:

[0091] Step S201: Perform permission verification on the supplier service call request to obtain a first verification result;

[0092] Step S202: Perform parameter integrity verification on the supplier service call request to obtain a second verification result;

[0093] Step S203: If both the first verification result and the second verification result are verified as passed, it is determined that the supplier service call request has been verified.

[0094] In step S201 of some embodiments, firstly, the service call request from the supplier is subject to permission verification to confirm whether the requester has the right to access or call the specific service, and the permission verification result is obtained. Permission verification may involve querying a preset permission configuration table based on the downstream system's identity identifier to determine the downstream system's data access permissions; if the permission verification fails, the call request is returned as a failure to the downstream system; if the permission verification passes, parameter integrity verification continues.

[0095] In step S202 of some embodiments, the supplier service call request is then subjected to parameter integrity verification to ensure that all necessary parameters are provided and conform to the expected format and type. This helps prevent service call failures due to missing or incorrect data. Parameter integrity verification may include checking whether the downstream system's system identity identifier, the target supplier's supplier identifier, the target supplier's target supply interface's interface service identifier, and the downstream system's business parameters, and whether their types and formats meet the requirements, and whether the parameter names are correct, etc.

[0096] In step S203 of some embodiments, the entire vendor service call request is determined to have passed verification only if both the permission verification and parameter integrity verification pass, meaning the request can proceed safely and correctly.

[0097] It should be noted that permission verification can be the process of confirming whether a downstream system or requester has the necessary permissions to access the corresponding supplier's data. Parameter integrity verification can be the process of checking whether the supplier's service call request contains all the necessary parameters and whether these parameters meet the expected standards. The verification result can be the outcome of the verification process, which may be "pass" or "fail".

[0098] Steps S201 to S203, as illustrated in this embodiment, involve performing permission verification on the supplier service call request to obtain a first verification result; performing parameter integrity verification on the supplier service call request to obtain a second verification result; and determining that the supplier service call request has passed verification if both the first and second verification results are successful. In other words, verifying the supplier service call request, through permission verification, prevents unauthorized access and enhances system security. Parameter integrity verification ensures data accuracy and consistency, reducing errors and anomalies. The request is only processed when all verifications pass, reducing errors and improving the reliability of service calls.

[0099] For example, suppose an e-commerce platform (downstream system) wants to call the interface of a third-party payment service provider (target provider) to process a payment. The e-commerce platform sends a service call request to the service platform (target system). The service platform first checks whether the identity provided by the e-commerce platform is valid and whether that identity has the authority to call the payment interface. Next, it checks whether the request contains all the necessary parameters, such as order number, payment amount, currency type, etc., and whether these parameters conform to the expected format (e.g., the amount is a number, and the currency type is a valid ISO code). If the e-commerce platform's identity is valid and all the necessary payment parameters are correct, the service platform will confirm that the request has passed verification and then continue to issue the service and process the payment.

[0100] In step S103 of some embodiments, if the supplier service call request passes the verification, the service is distributed according to the supplier identifier, the interface service identifier and the supplier common interface template, so as to determine how to process the request and obtain the corresponding supplier service call processing strategy. This involves selecting the target supply interface of the corresponding target supplier to call the service according to the business parameters.

[0101] Furthermore, if the supplier service call request passes verification, the MD5 value corresponding to the business parameter is determined; the Redis cache of the target system is queried based on the MD5 value to obtain the query result; if the query result indicates that the MD5 value is not cached in Redis, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request; if the query result indicates that the MD5 value is cached in Redis, the supplier service call result corresponding to the target value in the Redis cache is sent to the downstream system; the target value is the value associated with the MD5 value in the Redis cache.

[0102] It should be noted that the supplier's common interface template can be a standardized template applicable to service calls from various suppliers. It can include data format processing, constructing HTTP requests, initiating HTTP requests, obtaining HTTP request results, parsing result data, and encapsulating result data, serving as a guide for mapping business parameters to supplier interface services. The service call processing strategy can be based on the supplier identifier, interface service identifier, and supplier's common interface template for service distribution, or it can be based on business parameters, adjusting the specific strategy for how to call supplier services.

[0103] The vendor identifier is used to determine the specific invocation strategy of the target vendor, and the interface service identifier is used to determine the specific invocation strategy of the target vendor interface.

[0104] In some implementations, these specific invocation strategies can be determined based on the vendor abstract class and vendor subclass defined by the target system's abstract interface and subclass interface.

[0105] In other implementations, these specific invocation strategies may be extracted from a file (invocation specification file) or retrieved from a mapping relationship that stores the invocation strategy corresponding to each identifier.

[0106] In some implementations, the generation of the supplier service invocation processing strategy corresponding to the supplier service invocation request may include: the target system further includes: an abstract interface corresponding to each supplier, and a subclass interface corresponding to the supply interface of each supplier; wherein, the abstract interface corresponding to each supplier is used to define the supplier abstract class of the supplier and inherit the supplier common interface template; the subclass interface corresponding to the supply interface of each supplier is used to define the supplier subclass of the supply interface and inherit the supplier abstract class of the supplier. Based on the supplier identifier, the supplier abstract class defined by the abstract interface corresponding to the target supplier is determined as the target supplier abstract class; based on the interface service identifier, the supplier subclass defined by the subclass interface corresponding to the target supply interface is determined as the target supplier subclass; based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass, the supplier service invocation processing strategy corresponding to the supplier service invocation request is generated.

[0107] In other implementations, the supplier service call processing strategy corresponding to the supplier service call request may be generated by using JAVA reflection technology, based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass.

[0108] For example, after the request is verified, the service platform (target system) finds the corresponding supplier public interface template based on the logistics supplier's identifier and interface service identifier, and determines the strategy for calling the logistics supplier's delivery interface.

[0109] Please see Figure 3 In some embodiments, step S103 may include, but is not limited to, steps S301 to S303:

[0110] The target system further includes: an abstract interface corresponding to each supplier, and a subclass interface corresponding to the supply interface of each supplier; wherein, the abstract interface corresponding to each supplier is used to define the supplier abstract class of the supplier and inherits the supplier common interface template; the subclass interface corresponding to the supply interface of each supplier is used to define the supplier subclass of the supply interface and inherits the supplier abstract class of the supplier; wherein, the relationship between the supplier common interface template, the abstract interface corresponding to each supplier, and the subclass interface corresponding to the supply interface of each supplier is as follows: Figure 4 As shown, the public interface corresponds to AbstractAPIHelper in the diagram, the abstract interface corresponds to AbstractSupplierHelper in the diagram, and the subclass interface corresponds to SupplierAPI in the diagram.

[0111] Step S301: Based on the supplier identifier, determine the supplier abstract class defined in the abstract interface corresponding to the target supplier as the target supplier abstract class;

[0112] Step S302: Based on the interface service identifier, determine the supplier subclass defined in the subclass interface corresponding to the target supplier interface as the target supplier subclass;

[0113] Step S303: Generate the supplier service call processing strategy corresponding to the supplier service call request based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass.

[0114] In step S301 of some embodiments, the target system searches for and determines an abstract class based on the supplier identifier. This class is an abstract representation of the target supplier's interface definition.

[0115] In step S302 of some embodiments, the target system then finds the corresponding subclass interface definition based on the interface service identifier. This subclass is a concrete implementation of the supplier abstract class.

[0116] In step S303 of some embodiments, finally, by combining the supplier's common interface template, the target supplier's abstract class, and its subclasses, the target system generates a service invocation processing strategy. This strategy is a specific action plan used to invoke the target supplier's service based on business parameters.

[0117] It's important to note that the supplier common interface template can be a standardized template applicable to service calls from various suppliers. It can include data format processing, constructing HTTP requests, initiating HTTP requests, obtaining HTTP request results, parsing result data, and encapsulating result data, guiding how to map business parameters to supplier interface services. The supplier abstract class can be an abstract class applied to suppliers. In object-oriented programming, an abstract class is a class that cannot be directly instantiated; it typically serves as a base class for other classes, defining a set of interfaces or public fields. Supplier subclasses can be derived from the supplier abstract class, implementing the interfaces defined in the abstract class and can be concretely instantiated.

[0118] Steps S301 to S303, as illustrated in this embodiment, involve determining the supplier abstract class defined in the abstract interface corresponding to the target supplier as the target supplier abstract class based on the supplier identifier; determining the supplier subclass defined in the subclass interface corresponding to the target supplier interface as the target supplier subclass based on the interface service identifier; and generating a supplier service call processing strategy corresponding to the supplier service call request based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass. In other words, the target supplier abstract class and target supplier subclass are determined, and then a supplier service call processing strategy is generated based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass. Using the supplier common interface template ensures the standardization of service calls and simplifies integration between different suppliers. Simultaneously, the use of abstract classes and subclasses provides high flexibility, allowing the system to easily extend to new suppliers or services. Furthermore, when it is necessary to change the supplier or modify the service implementation, only the corresponding subclass needs to be modified, without rewriting the entire call logic, improving maintainability.

[0119] In some embodiments, step S303 may include, but is not limited to, step S3031:

[0120] Step S3031: Using JAVA reflection technology, generate the supplier service call processing strategy corresponding to the supplier service call request based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass.

[0121] In step S301 of some embodiments, the target system includes a public interface. This public interface defines a common interface template for suppliers, which includes general methods for invoking supplier services. An abstract class is defined, defined by the abstract interface corresponding to each supplier. Subclasses are created for each specific supplier, implementing the methods defined in the abstract class. A reflection-based processing strategy is used to invoke the methods in the subclasses according to business parameters, completing the service invocation.

[0122] It should be noted that reflection can be a mechanism in Java that allows a program to access and modify its internal attributes and behavior at runtime. The target vendor abstract class can be an abstract class that defines the underlying interface and attributes for calling the target vendor's services. The target vendor subclass can be a concrete vendor class that implements the methods defined in the target vendor abstract class.

[0123] Step S3031, as illustrated in this embodiment, uses a reflection-based generation strategy. Reflection allows programs to dynamically create objects and invoke methods at runtime, improving system flexibility. Through the design of abstract classes and subclasses, the concrete implementation of supplier services is decoupled from the invocation logic, facilitating maintenance and expansion.

[0124] In step S104 of some embodiments, a corresponding processing strategy is executed, and the result of the service call is obtained after the supplier service call is completed.

[0125] Furthermore, after executing the supplier service call processing strategy and obtaining the supplier service call result corresponding to the supplier service call request, the value corresponding to the supplier service call result can be determined; the MD5 value and the value are associated and stored in the Redis cache.

[0126] It should be noted that the service call result can be the output returned by the supplier or service provider to the downstream system or requester after the service call request is executed. This result contains the information needed by the requester or the processing status of the request.

[0127] In some implementations, the method for obtaining the supplier service call result corresponding to the supplier service call request may be as follows: Process the business parameters according to the data format processing method to obtain target parameters; construct a target HTTP request based on the target parameters according to the HTTP request construction method; send the target HTTP request to the target supply interface through the public interface; receive the request result corresponding to the target HTTP request sent by the target supply interface through the public interface; parse the call result of the target supply interface from the request result according to the data parsing method; and encapsulate the call result according to the unified data encapsulation format of the target system to obtain the supplier service call result corresponding to the supplier service call request.

[0128] In other implementations, the supplier service call result corresponding to the supplier service call request can be obtained by searching a preset mapping table. The preset mapping table contains the mapping relationship between the business parameters of the downstream system and the supplier service call result.

[0129] For example, the service platform executes a strategy that passes the e-commerce platform's business parameters to the logistics provider's delivery interface. The logistics provider processes the request and returns information such as delivery options and costs.

[0130] The supplier service call processing strategy includes: the data format processing method corresponding to the target supplier interface, the HTTP request construction method, and the data parsing method.

[0131] Please see Figure 5 In some embodiments, step S104 may include, but is not limited to, steps S501 to S506:

[0132] Step S501: Process the business parameters according to the data format processing method to obtain the target parameters;

[0133] Step S502: Construct a target HTTP request based on the target parameters according to the HTTP request construction method (compare the target HTTP request with the call request of weight 1);

[0134] Step S503: Send the target HTTP request to the target supply interface through the public interface;

[0135] Step S504: Receive the request result corresponding to the target HTTP request sent by the target supply interface through the public interface;

[0136] Step S505: Parse the call result of the target supply interface from the request result according to the data parsing method;

[0137] Step S506: Encapsulate the call result according to the unified data encapsulation format of the target system to obtain the supplier service call result corresponding to the supplier service call request.

[0138] In step S501 of some embodiments, the service parameters are converted from one format to another to meet the format requirements of the target supply interface.

[0139] In step S502 of some embodiments, an HTTP request is constructed based on the processed business parameters (target parameters), including setting the request method, URL, header information and request body, etc., to meet the format requirements of the target supply interface.

[0140] In step S503 of some embodiments, the constructed HTTP request is sent to the target provider interface through the public interface.

[0141] In step S504 of some embodiments, a response returned by the target supply interface is received through a public interface.

[0142] In step S505 of some embodiments, the call result of the target supply interface is parsed from the received response.

[0143] In step S506 of some embodiments, the call result is encapsulated according to the unified data encapsulation format of the target system so as to be returned to the downstream system or the requester.

[0144] It should be noted that during service invocation, business parameters are the specific business data or parameters passed from the downstream system to the supplier, and their format conforms to the target system's format requirements. Target parameters can be business parameters that have undergone format processing to conform to the target supply interface's format requirements. An HTTP request can be a request sent from the target system to the supplier's target supply interface (client to server), including methods such as GET, POST, PUT, and DELETE. A supplier service invocation request can be a request issued by a downstream system (such as an enterprise, organization, or application) to the supplier to use the specific services or interfaces provided by the supplier; that is, the invocation request is used to request the invocation of the supplier's supply interface service. A public interface can be an interface for communication between systems. The request result can be the supplier's target supply interface's response to the HTTP request, typically including a status code, response headers, and a response body. Data parsing is the process of extracting useful information from the request result; parsing can include data decryption, parameter encapsulation, and format conversion. Result encapsulation is the process of organizing and packaging the parsed data according to the target system's unified data encapsulation format.

[0145] Steps S501 to S506, as illustrated in this embodiment, execute a supplier service invocation processing strategy. This strategy may include data format processing, constructing an HTTP request, initiating an HTTP request, obtaining the result of the HTTP request, parsing the result data, and encapsulating the result data to obtain the supplier service invocation result. Through data format processing, it can adapt to different interface requirements, providing flexibility. Furthermore, through a unified data encapsulation format, data readability and maintainability are improved.

[0146] Please see Figure 6 In some embodiments, step S103 may include, but is not limited to, steps S601 to S603:

[0147] In some embodiments, step S104 may include, but is not limited to, steps S604 to S605:

[0148] Step S601: Determine the MD5 value corresponding to the service parameter;

[0149] Step S602: Query the Redis cache of the target system based on the MD5 value to obtain the query result;

[0150] Step S603: If the query result indicates that the Redis does not cache the MD5 value, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request.

[0151] Step S604: Determine the value corresponding to the supplier service call result;

[0152] Step S605: Associate the MD5 value with the value and store it in the Redis cache.

[0153] In step S601 of some embodiments, the business parameters are subjected to MD5 hash operation to obtain a hash value of fixed length, which is used for subsequent cache lookup.

[0154] In step S602 of some embodiments, the obtained MD5 value is used as a key to query whether there is a corresponding cached result in the Redis cache.

[0155] In step S603 of some embodiments, if the corresponding MD5 value is not found in the cache, the service is distributed according to the supplier identifier, the interface service identifier and the supplier common interface template, and a service call processing strategy is generated.

[0156] In step S604 of some embodiments, the service call result is converted into a value in a uniform format.

[0157] In step S605 of some embodiments, the MD5 value and the corresponding value are stored in a Redis cache for future use.

[0158] It's important to note that an MD5 value is a 128-bit hash value calculated using the MD5 hash algorithm, used to verify data integrity and consistency. Redis caching can be a high-performance key-value store database used to cache data to improve access speed and efficiency.

[0159] Steps S601 to S605 of this embodiment of the application involve determining the MD5 value corresponding to the business parameter; querying the Redis cache of the target system based on the MD5 value to obtain a query result; if the query result indicates that the MD5 value is not cached in Redis, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request; after executing the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request, the method further includes: determining the value corresponding to the supplier service call result; associating the MD5 value and the value value and storing them in the Redis cache. That is, based on the MD5 value corresponding to the business parameter, the Redis cache is checked to obtain the query result, and a corresponding processing method is performed based on the result. Through the caching mechanism, duplicate service calls are avoided, returns are fast, the interface response time is reduced, and the response speed of the target system is improved. By caching frequently used data, interface rate limiting is implemented, which can alleviate server pressure in high-concurrency scenarios.

[0160] For example, suppose an e-commerce platform needs to call a logistics provider's API to query order delivery status. First, the e-commerce platform sends a call request to the target system. The target system performs an MD5 hash operation on the order information (such as order number, product information, etc.) to obtain an MD5 value. Then, it uses the MD5 value to query the Redis cache to check if the order's delivery status is already available. If the delivery status is not found in the cache, the target system generates a service call processing strategy based on the logistics provider's identifier and the interface service identifier, and executes the service call to obtain the delivery status. The target system converts the delivery status into a unified format value. The MD5 value and the delivery status value are stored in the Redis cache so that they can be retrieved directly from the cache for subsequent queries. Through this process, the target system can quickly respond to user queries for order delivery status while reducing the number of calls to the logistics provider's API, thus improving the overall system performance.

[0161] In some embodiments, step S602 may include, but is not limited to, step S6021:

[0162] Step S6021: If the query result indicates that the MD5 value is in the Redis cache, send the supplier service call result corresponding to the target value in the Redis cache to the downstream system; the target value is the value associated with the MD5 value in the Redis cache.

[0163] In step S6021 of some embodiments, the MD5 value of the business parameter is used as the key to query the Redis cache to determine whether a value associated with the MD5 value exists in the cache. If a corresponding value exists in the cache, this value is directly sent to the downstream system as the result of the provider service call.

[0164] It should be noted that the target value can be a value in the Redis cache associated with the MD5 value of the current query, representing the result of a previously calculated or queried provider service call.

[0165] In step S6021 of this embodiment, if the query result shows that the MD5 value is cached in Redis, the provider service call result corresponding to the target value in the Redis cache is sent to the downstream system; the target value is the value associated with the MD5 value in the Redis cache. That is, if the historical cached MD5 value is the same as the currently queried MD5 value, then the provider service call result corresponding to the historical cached MD5 value is used as the current call result and sent to the downstream system. By directly obtaining the result from the cache, calls to the provider service are reduced, thereby speeding up the response. The caching mechanism enables the target system to process requests more efficiently, improving the efficiency of the target system.

[0166] In step S105 of some embodiments, the target system sends the result of the service call back to the downstream system through a public interface.

[0167] For example, suppose an e-commerce platform (downstream system) needs to call the interface of a logistics provider (target supplier) to obtain delivery options for goods. The e-commerce platform sends a service call request to the service platform (target system). The request includes the e-commerce platform's system identity, the logistics provider's supplier identity, the interface service identifier of the delivery interface to be called, and business parameters such as product weight and dimensions. After receiving the request, the service platform first verifies that the e-commerce platform has the right to call the service and that the information provided is complete and correct. After successful verification, the service platform looks up the corresponding supplier public interface template based on the logistics provider's identity and interface service identifier to determine the strategy for calling the logistics provider's delivery interface. The service platform executes the strategy, passing the e-commerce platform's business parameters to the logistics provider's delivery interface. The logistics provider processes the request and returns information such as delivery options and costs. The service platform sends this information back to the e-commerce platform as the service call result. Through this process, the e-commerce platform does not need to interact directly with the logistics provider, but instead implements the service call through the service platform, simplifying the process and improving efficiency.

[0168] Please refer to Figure 7 Another optional flowchart of the supplier service invocation method provided in this application embodiment is as follows: Figure 7The method, in sequence, includes nine steps: I. A user initiates a request, i.e., a downstream system initiates a request. Parameters include: 1. The downstream system's system identity identifier; 2. The target supplier's supplier identifier; 3. The target supplier's target supply interface service identifier; 4. The downstream system's business parameters. II. 1. Permission verification (checking the permission configuration table and verifying whether the user has the corresponding data access permissions based on the system identity identifier carried in the input parameters); 2. Parameter verification (parameter integrity verification, ensuring all necessary parameters are provided and conform to the expected format and type). III. Reading the Redis cache (1. Taking the MD5 value of the user's business parameters; 2. Using this MD5 value as the key and the supplier's actual return result as the value, storing it in Redis; 3. Each time a user makes a request, first querying Redis to see if the MD5 value of the business parameter already exists. If it does, return directly, and the process ends; otherwise, continue execution). IV. Obtaining the corresponding supplier's information, mainly the downstream system's registered account and password with the corresponding supplier, for billing purposes. V. Service distribution is performed based on the supplier identifier, interface service identifier, and supplier common interface template (the abstract interface corresponding to each supplier is used to define the supplier's abstract class and inherits the supplier common interface template; the subclass interface corresponding to each supplier's supply interface is used to define the supplier subclass of the supply interface and inherits the supplier's abstract class). During code execution, Java reflection is used to achieve this; this process is service distribution. VI. The corresponding supplier subclass method is executed, and an HTTP request is sent to the supplier to obtain the return result. VII. The result is cached in Redis. VIII. Logs are recorded. IX. The result is returned to the user, and the process ends.

[0169] Please see Figure 8 This application also provides a supplier service invocation apparatus to implement the above-described supplier service invocation method. The apparatus includes:

[0170] The receiving module 801 is used to receive a supplier service call request sent by a downstream system through the public interface; wherein the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supply interface of the target supplier, and the business parameters of the downstream system.

[0171] Verification module 802 is used to verify the supplier service call request;

[0172] The processing strategy module 803 is used to distribute services according to the supplier identifier, the interface service identifier, and the supplier common interface template when the supplier service call request passes the verification, and obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters;

[0173] The call result module 804 is used to execute the supplier service call processing strategy and obtain the supplier service call result corresponding to the supplier service call request.

[0174] The sending module 805 is used to send the supplier service call result to the downstream system through the public interface.

[0175] The specific implementation of the supplier invocation device is basically the same as the specific implementation of the supplier invocation method, and will not be described again here.

[0176] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned supplier invocation method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0177] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0178] The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0179] The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is invoked by the processor 901 to execute the vendor invocation method of the embodiments of this application.

[0180] The input / output interface 903 is used to implement information input and output;

[0181] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0182] Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 604);

[0183] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0184] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described supplier invocation method.

[0185] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0186] Furthermore, this application also provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the supplier invocation method embodiment described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0187] The supplier invocation method, supplier invocation device, electronic device, and storage medium provided in this application embodiment first receive a supplier service invocation request sent by a downstream system through a public interface. The supplier service invocation request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system. Second, the supplier service invocation request is verified. Then, if the supplier service invocation request passes verification, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier's public interface template to obtain a supplier service invocation processing strategy corresponding to the supplier service invocation request. The supplier service invocation processing strategy is used to invoke the target supplier's target supply interface based on the business parameters. Then, the supplier service invocation processing strategy is executed to obtain a supplier service invocation result corresponding to the supplier service invocation request. Finally, the supplier service invocation result is sent to the downstream system through the public interface. Thus, the method of this application receives supplier service call requests from downstream systems through a public interface, then distributes services according to the call request and the supplier's public interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request. After executing the supplier service call processing strategy, the service call result is obtained and sent to the downstream system. This allows the downstream system to call the corresponding supplier's service through the public interface without changing its own parameter format. In this way, the downstream system can meet the needs of interfacing with multiple suppliers through the public interface, without having to implement a corresponding interface for different interfaces of different suppliers. This reduces redundant code and improves development efficiency. At the same time, when making supplier service calls, there is no need to first convert the call request to obtain the target supplier interface when facing any supplier. Instead, only a unified call request format needs to be used, thus simplifying supplier service calls.

[0188] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0189] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0190] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0192] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0193] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0194] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0195] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0196] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0197] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0198] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for invoking a supplier service, characterized in that, Applied to a target system, the target system including a public interface, the public interface being used to define a common interface template for suppliers; the method includes: The system receives supplier service call requests from downstream systems through the public interface; wherein, the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system; The supplier service call request is validated; If the supplier service call request passes verification, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters; Execute the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request; The supplier service call result is sent to the downstream system through the public interface.

2. The method according to claim 1, characterized in that, The target system further includes: an abstract interface corresponding to each supplier, and a subclass interface corresponding to the supply interface of each supplier; wherein, the abstract interface corresponding to each supplier is used to define the supplier abstract class of the supplier and inherit the supplier common interface template; the subclass interface corresponding to the supply interface of each supplier is used to define the supplier subclass of the supply interface and inherit the supplier abstract class of the supplier. The step of distributing services based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request includes: Based on the supplier identifier, the supplier abstract class defined in the abstract interface corresponding to the target supplier is determined as the target supplier abstract class; Based on the interface service identifier, the supplier subclass defined in the subclass interface corresponding to the target supply interface is determined as the target supplier subclass; Based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass, a supplier service call processing strategy corresponding to the supplier service call request is generated.

3. The method according to claim 2, characterized in that, The step of generating a supplier service call processing strategy corresponding to the supplier service call request based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass includes: Using Java reflection technology, a supplier service call processing strategy corresponding to the supplier service call request is generated based on the supplier common interface template, the target supplier abstract class, and the target supplier subclass.

4. The method according to claim 1, characterized in that, The supplier service call processing strategy includes: the data format processing method, the HTTP request construction method, and the data parsing method corresponding to the target supplier interface; The step of executing the supplier service call processing strategy to obtain the supplier service call result corresponding to the supplier service call request includes: The business parameters are processed according to the data format processing method described above to obtain the target parameters; Construct a target HTTP request based on the target parameters according to the described HTTP request construction method; The target HTTP request is sent to the target supply interface through the public interface; The public interface receives the request result corresponding to the target HTTP request sent by the target supply interface. According to the data parsing method described above, the call result of the target supply interface is parsed from the request result; The call result is encapsulated according to the unified data encapsulation format of the target system to obtain the supplier service call result corresponding to the supplier service call request.

5. The method according to claim 1, characterized in that, The verification of the supplier service call request includes: The permission verification is performed on the supplier service call request to obtain the first verification result; Perform parameter integrity verification on the supplier service call request to obtain a second verification result; If both the first and second verification results are successful, the supplier service call request is determined to have passed verification.

6. The method according to claim 1, characterized in that, The step of distributing services based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request includes: Determine the MD5 value corresponding to the business parameter; The target system's Redis cache is queried based on the MD5 value to obtain the query result; If the query result indicates that the Redis does not cache the MD5 value, service distribution is performed based on the supplier identifier, the interface service identifier, and the supplier common interface template to obtain the supplier service call processing strategy corresponding to the supplier service call request. After executing the supplier service call processing strategy and obtaining the supplier service call result corresponding to the supplier service call request, the method further includes: Determine the value corresponding to the result of the supplier service call; The MD5 value is associated with the value and stored in the Redis cache.

7. The method according to claim 6, characterized in that, After obtaining the query result by querying the Redis cache of the target system based on the MD5 value, the method further includes: If the query result indicates that the MD5 value exists in the Redis cache, the supplier service call result corresponding to the target value in the Redis cache is sent to the downstream system; the target value is the value associated with the MD5 value in the Redis cache.

8. A supplier service invocation device, characterized in that, Applied to a target system, the target system including a common interface for defining a common interface template for suppliers; the device includes: The receiving module is used to receive a supplier service call request sent by a downstream system through the public interface; wherein the supplier service call request includes: the system identity identifier of the downstream system, the supplier identifier of the target supplier, the interface service identifier of the target supplier's target supply interface, and the business parameters of the downstream system; The verification module is used to verify the supplier service call request; The processing strategy module is used to distribute services according to the supplier identifier, the interface service identifier, and the supplier common interface template when the supplier service call request passes the verification, and obtain the supplier service call processing strategy corresponding to the supplier service call request; wherein, the supplier service call processing strategy is used to make supplier service calls to the target supplier's target supply interface based on the business parameters; The call result module is used to execute the supplier service call processing strategy and obtain the supplier service call result corresponding to the supplier service call request; The sending module is used to send the supplier service call result to the downstream system through the public interface.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the supplier service invocation method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the supplier service invocation method as described in any one of claims 1 to 7.

Images