Service calling method, device and system based on tenant identifier and storage medium

Abstract

The invention discloses a service calling method, device and system based on tenant identification and a storage medium, and relates to the technical field of data processing. The method comprises the following steps: adding Eureka configuration in a configuration file of each service in a SaaS (Software as a Service) mode, wherein the Eureka configuration comprises a tenant identifier; integrating the Feign client to a load balancing component to obtain a load balancer based on SaaS (Software as a Service); when the calling request reaches the load balancer, all the service instances are obtained from the Eureka service registration center and traversed, whether metadata of each service instance contains a tenant identifier matched with the current calling request or not is checked, if yes, the load balancer forwards the calling request to the corresponding service instance to be processed, and if not, the calling request is sent to the corresponding service instance to be processed; and customized service calling in the SaaS mode is realized. According to the embodiment of the invention, the customization capability is enhanced, the service calling efficiency is improved, reasonable utilization of service resources is ensured, the flexibility and reliability are improved, and the operation and maintenance cost is reduced.

Description

Technical Field

[0001] This application belongs to the technical field of data processing, and particularly relates to a service call method, device, system and storage medium based on tenant identification. Background Art

[0002] In the SaaS (Software as a Service) model, software applications provide services to users over the Internet, and users do not need to manage the underlying infrastructure. In this model, multiple customers share the same software, but may require customized development for different customers.

[0003] The prior art usually routes through the gateway to the customized service by Feign. This solution uses Feign and the API gateway to implement the dynamic routing of customized services. In the Feign client of service A, a custom Feign interceptor is added. Before each request is sent, this interceptor automatically adds the tenant identification information (such as customer ID) to the HTTP request header. In the configuration file of service A, the URLs of all Feign interfaces of service B that need to be called are uniformly set to the URL of the API gateway. All call requests to service B will first be sent to the API gateway. After receiving the request from service A, the API gateway extracts the tenant identification information from the HTTP request header. According to the extracted tenant identification, the API gateway dynamically routes the request to the corresponding customer customized service B instance.

[0004] However, this method requires passing through the API gateway for each request, increasing the number of network hops and resulting in higher latency. Especially in a high-concurrency environment, this additional overhead may significantly affect system performance. The API gateway becomes the central point for all requests. If the gateway performance is insufficient or the configuration is improper, it may become the bottleneck of the system, affecting the response time and stability of the overall service. In a multi-tenant environment, maintaining and managing the routing configuration of the API gateway may become complex, and it is necessary to ensure that the routing rules for each tenant are correct, which poses higher requirements for operation and maintenance personnel. Since the request passes through multiple levels (Feign client, API gateway, actual service), problem location and debugging may become more difficult, requiring cross-component log analysis and tracing. The API gateway becomes the only way for all requests. If the gateway fails, all services will become unavailable. Summary of the Invention

[0005] The purpose of this application is to provide a service call method, device, system and storage medium based on tenant identification, which realizes the call of customized services through tenant identification in the SaaS model.

[0006] To achieve the above object, the solution of this application is:

[0007] In a first aspect, an embodiment of the present application provides a service call method based on tenant identification, including:

[0008] In the SaaS mode, add Eureka configuration to the configuration file of each service, and the Eureka configuration includes tenant identification;

[0009] Integrate the Feign client into the load balancing component to obtain a SaaS-based load balancer;

[0010] When a call request arrives at the load balancer, the load balancer obtains all service instances from the Eureka service registry and traverses them to check whether the metadata of each service instance contains a tenant identification that matches the current call request. If it contains a tenant identification that matches the current call request, the load balancer forwards the call request to the corresponding service instance for processing, realizing customized service calls in the SaaS mode.

[0011] According to the above method of the embodiment of the present application, the following additional technical features may also be included:

[0012] Further, in the Eureka configuration, configure the metadata of the service instance through eureka.instance.metadata-map.

[0013] Further, the tenant identification is passed through the metadata of the service instance.

[0014] Further, integrating the Feign client into the load balancing component includes:

[0015] In the pom.xml file, introduce the dependencies of spring-cloud-starter-openfeign and spring-cloud-starter-loadbalancer. Spring-cloud-starter-openfeign provides support for the Feign client, and spring-cloud-starter-loadbalancer provides support for the load balancing component.

[0016] Further, the Eureka service registry includes two components, Eureka Server and Eureka Client. Eureka Server is responsible for maintaining the service registration information list, and Eureka Client is used for registering, renewing, and obtaining the registration list information.

[0017] Further, when a service instance is started, the Eureka Client sends a service registration request to the Eureka Server to register the service information in the Eureka Server;

[0018] The Eureka Server records the information of the service instance in the registration information list for the invocation of other service instances.

[0019] In a second aspect, an embodiment of the present application provides a service invocation device based on a tenant identifier, including:

[0020] A service configuration module configured to add Eureka configuration to the configuration file of each service in the SaaS mode, where the Eureka configuration includes a tenant identifier;

[0021] A load balancing module configured to integrate the Feign client into the load balancing component to obtain a SaaS-based load balancer;

[0022] A service invocation module configured to, when an invocation request arrives at the load balancer, the load balancer obtains all service instances from the Eureka service registry and traverses them, checks whether the metadata of each service instance contains a tenant identifier matching the current invocation request. If it contains a tenant identifier matching the current invocation request, the load balancer forwards the invocation request to the corresponding service instance for processing, implementing customized service invocation in the SaaS mode.

[0023] In a third aspect, an embodiment of the present application provides a service invocation system based on a tenant identifier. The system includes a processor and a memory. A computer program is stored in the memory and is loaded and executed by the processor to implement the service invocation method based on a tenant identifier provided in the first aspect of the embodiments of the present application.

[0024] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium. A computer program is stored in the storage medium. When the computer program is executed by a processor, it is used to implement the service invocation method based on a tenant identifier provided in the first aspect of the embodiments of the present application.

[0025] Adopting the service invocation method based on a tenant identifier provided in the embodiments of the present application, compared with the prior art, it has the following beneficial technical effects:

[0026] By adding a tenant identifier to the Eureka configuration and transmitting the identifier in the metadata of the service instance in the embodiments of the present application, corresponding service instances can be dynamically selected and invoked according to different tenant requirements, enhancing the ability of the SaaS platform to provide customized services for different tenants.

[0027] In the embodiments of the present application, the Feign client is integrated into the load balancing component to form a SaaS-based load balancer. This load balancer can obtain all service instances from the Eureka service registry, filter out the eligible instances according to the tenant identifier for request forwarding, improve the efficiency of service invocation, ensure the reasonable utilization of service resources, avoid additional network hops, and improve communication efficiency.

[0028] In the embodiments of the present application, the Eureka service registry dynamically records and manages the information of service instances. When a new service instance joins or an existing instance exits, the registration information list can be automatically updated, enabling the SaaS platform to flexibly expand the service scale and meet the changing business requirements.

[0029] In the embodiments of the present application, through the collaborative work of the Eureka Client and the Eureka Server, the real-time and accuracy of service registration information are ensured. When a service instance fails or the network is interrupted, the Eureka Client can promptly notify the Eureka Server for update, thereby avoiding invalid request forwarding and improving reliability.

[0030] In the embodiments of the present application, by adding Eureka configurations and metadata mappings in the configuration file, and introducing the corresponding dependency libraries, the configuration and management process of service invocation in the SaaS platform are simplified, enabling system administrators to more easily maintain and update service instance information and reducing the operation and maintenance costs. Brief Description of the Drawings

[0031] Figure 1 Shows a schematic flow diagram of the service invocation method based on tenant identifier in the embodiments of the present application;

[0032] Figure 2 Shows a structural block diagram of the service invocation device based on tenant identifier in the embodiments of the present application;

[0033] Figure 3 Shows a structural block diagram of the computer device in the embodiments of the present application. Detailed Embodiments

[0034] To make the above objects, features, and advantages of the present application more obvious and understandable, the following will describe the detailed embodiments of the present application in conjunction with the accompanying drawings. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. Additionally, it should be noted that for the sake of convenience of description, only the parts related to the present application are shown in the drawings rather than all the structures. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0035] The term "including" and "having" and any variations thereof in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally further include steps or units not listed, or may optionally further include other steps or units inherent to these processes, methods, products or devices.

[0036] Referring to "embodiment" in this application means that the specific features, structures or characteristics described in connection with the embodiment can be included in at least one embodiment of this application. The occurrence of this phrase at various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described in this application can be combined with other embodiments.

[0037] Feign is a declarative and templated HTTP client provided by Spring Cloud, which makes it as simple to call a remote service as to call a local service. Developers only need to create an interface and add an annotation, and Feign will automatically generate an HTTP request and call the remote service through the HTTP protocol.

[0038] The SaaS model means that software is provided as a service. Users do not need to purchase and install the software, but only need to subscribe and use the software hosted by the SaaS provider through the network. The software applications in the SaaS model are hosted on cloud servers by the service provider, and users can access and use these software through browsers or mobile applications.

[0039] Spring Cloud is a microservices framework that provides a full set of distributed system solutions, including service registration and discovery, configuration center, message center, load balancing, data monitoring, etc. Spring Cloud encapsulates multiple open-source components of the microservices basic framework Netflix, and at the same time realizes the integration with cloud platforms and the Spring Boot framework.

[0040] Eureka is a REST-based service governance framework open-sourced by Netflix. It is mainly used to implement service registration and discovery in a distributed system. In a microservices architecture, the Eureka service registry provides a centralized platform for service registration and discovery, enabling service providers to register their service information with the registry, and service consumers to find and call the required services through the registry. Eureka configuration refers to the configuration information that a service instance needs to provide when registering with the Eureka service registry. This information usually includes basic information such as service name, service version, IP address, port, etc., as well as custom metadata that may be required (such as tenant identification information). Eureka configuration enables service instances to provide sufficient information to the Eureka service registry so that other services can correctly discover and call them.

[0041] As Figure 1 shown, an embodiment of this application provides a service call method based on tenant identification, including the following steps:

[0042] Step 101, in the SaaS mode, add Eureka configuration to the configuration file of each service, and the Eureka configuration includes tenant identification.

[0043] In the SaaS mode, each service instance needs to be able to identify and process requests from different tenants. To achieve this, in the Eureka configuration of this application embodiment, the metadata of the service instance is configured through eureka.instance.metadata-map. Metadata is a form of key-value pair information that can be used to carry various custom information, including tenant identification.

[0044] eureka.instance.metadata-map is an attribute used to configure the metadata of a service instance when using Eureka as a service registration and discovery component, especially in an environment where frameworks such as Spring Cloud integrate Eureka. This attribute allows developers to define a series of key-value pairs in the service's configuration file, and these key-value pairs will be passed as metadata to the Eureka service registry and play a role in the process of service registration and discovery.

[0045] Tenant identification is a key identifier that is used to distinguish different tenants and ensure the isolation of data and services for each tenant. By embedding the tenant identification into the metadata of the service instance in the Eureka configuration, the service instance can carry this identifier when registering with the Eureka service registry.

[0046] Step 102: Integrate the Feign client into the load balancer component to obtain a SaaS-based load balancer.

[0047] Feign is a declarative web service client that makes it easier to write web service clients. In a microservices architecture, Feign clients are typically used for calls between services. The load balancer component is responsible for distributing requests among multiple service instances to achieve load balancing and failover.

[0048] In the embodiment of this application, the process of integrating the Feign client into the load balancer component is actually to combine the Feign client with the load balancing mechanism so that service instances can be intelligently selected when calling services. This is achieved by introducing relevant dependencies and configurations in the embodiment of this application.

[0049] To integrate the Feign client and the load balancer component into the project, relevant dependencies are introduced in the pom.xml file of the project in the embodiment of this application. Specifically, the two dependencies of spring-cloud-starter-openfeign and spring-cloud-starter-loadbalancer are introduced.

[0050] spring-cloud-starter-openfeign provides support for the Feign client, including functions such as automatic configuration and dependency injection. This enables this application to use the Feign client for service calls more conveniently.

[0051] spring-cloud-starter-loadbalancer provides support for the load balancer component. In Spring Cloud, this dependency is usually used together with Ribbon or Spring Cloud LoadBalancer to achieve the load balancing function.

[0052] After introducing the necessary dependencies, the embodiment of this application also performs some configuration work to ensure that the Feign client and the load balancer component can be correctly integrated and work, including:

[0053] Configure the Feign client: Configure relevant properties of the Feign client, such as timeout and retry times, in the application.yml or application.properties file.

[0054] Enable the Feign client: Add the @EnableFeignClients annotation to the main class of the Spring Boot application to enable the Feign client function.

[0055] Configure load balancing: Configure the relevant properties of load balancing according to Spring Cloud LoadBalance. For Spring Cloud LoadBalancer, usually no additional configuration is required because it provides a default implementation. However, more complex load balancing strategies can be implemented by customizing interfaces such as LoadBalancerClient or ServiceInstanceListSupplier.

[0056] By integrating the Feign client into the load balancing component and introducing the necessary dependencies and configurations, a SaaS-based load balancer is obtained. This load balancer can support customized service calls in a multi-tenant environment, ensuring that requests from each tenant can be correctly routed to the corresponding service instance for processing.

[0057] Step 103, when the call request arrives at the load balancer, the load balancer obtains all service instances from the Eureka service registry and traverses them, checking whether the metadata of each service instance contains a tenant identifier that matches the current call request. If it contains a tenant identifier that matches the current call request, the load balancer forwards the call request to the corresponding service instance for processing, implementing customized service calls in the SaaS mode.

[0058] In the embodiment of the present application, when an external call request arrives at the load balancer, the load balancer will select a suitable service instance to process the request according to a certain strategy. The load balancer will first obtain a list of all currently available service instances from the Eureka service registry. Next, the load balancer will traverse these service instances and check whether the metadata of each service instance contains a tenant identifier that matches the current call request. If a service instance's metadata contains a tenant identifier that matches the current call request, then the load balancer will consider this service instance to be a suitable choice for processing the request. Finally, the load balancer will forward the call request to this matching service instance for processing, thereby implementing customized service calls in the SaaS mode.

[0059] The Eureka service registry is a key component for service registration and discovery in a microservices architecture. It mainly consists of two parts: Eureka Server and Eureka Client.

[0060] The Eureka Server is responsible for maintaining a list of service registration information, which contains information about all service instances that have been registered with the Eureka Server. When other service instances need to call a certain service, they can obtain the registration information of that service through the Eureka Server, so as to find a suitable service instance for the call.

[0061] The Eureka Client is used for service instance registration, renewal, and obtaining the registration list information. When a new service instance starts up, it will send a service registration request to the Eureka Server through the Eureka Client to register its own information with the Eureka Server. At the same time, the Eureka Client will also send a renewal request to the Eureka Server regularly to indicate that it is still active. In addition, when other service instances need to call this service, they can obtain the registration information list of this service from the Eureka Server through the Eureka Client.

[0062] In a microservices architecture, the registration of service instances is a very important process. It ensures that service instances can be discovered and called by other service instances. When a new service instance starts up, it will first initialize the EurekaClient. Then, the Eureka Client will send a service registration request to the Eureka Server to register its own information (such as service name, IP address, port number, etc.) with the Eureka Server. After receiving the registration request, the Eureka Server will record the information of this service instance in the registration information list and return a registration success response to the Eureka Client. To ensure the availability of service instances, the Eureka Client will also send a renewal request to the Eureka Server regularly. If the Eureka Server does not receive a renewal request from a certain service instance within a period of time, then it will consider that this service instance has failed and remove it from the registration information list.

[0063] If it does not contain a tenant identifier that matches the current call request, the processing method is as follows:

[0064] The load balancer returns an error message to the caller, indicating that no matching service instance is found, or throws an exception to let the caller know that the current request cannot be processed because no service instance for the corresponding tenant is found. If there is a default service instance or a public service in the system design, the load balancer forwards the request to this default service instance, which provides basic, non-tenant-specific services or returns an error message indicating that the tenant service they are trying to access does not exist.

[0065] In summary, the service invocation method based on tenant identification in the embodiments of this application has the advantages of strong customization service capabilities, high load balancing efficiency, strong system scalability, low operation and maintenance costs, and high system reliability in the SaaS mode. These advantages jointly promote the stable operation and continuous development of the SaaS platform.

[0066] As Figure 2 shown, the embodiments of this application provide a service invocation device based on tenant identification, including a service configuration module 201, a load balancing module 202, and a service invocation module 203, where:

[0067] The service configuration module 201 is configured to add Eureka configuration to the configuration file of each service in the SaaS mode, and the Eureka configuration includes tenant identification;

[0068] The load balancing module 202 is configured to integrate the Feign client into the load balancing component to obtain a load balancer based on SaaS;

[0069] The service invocation module 203 is configured to, when a call request arrives at the load balancer, the load balancer obtains all service instances from the Eureka service registry and traverses them to check whether the metadata of each service instance contains a tenant identification that matches the current call request. If it contains a tenant identification that matches the current call request, the load balancer forwards the call request to the corresponding service instance for processing, realizing customized service invocation in the SaaS mode.

[0070] The service call device based on tenant identification in the embodiments of the present application may be a computer device or a component in a computer device, such as an integrated circuit or a chip. The computer device may be a terminal or other devices other than terminals. Exemplarily, the computer device may be a mobile phone, a tablet computer, a laptop computer, a handheld computer, an in-vehicle computer device, a Mobile Internet Device (MID), an Ultra-Mobile Personal Computer (UMPC), a netbook, or a Personal Digital Assistant (PDA), etc., or may also be a server, a Network Attached Storage (NAS), a Personal Computer (PC), etc. The embodiments of the present application do not make specific limitations.

[0071] The service call device based on tenant identification provided in the embodiments of the present application can implement Figure 1 each process implemented by the service call method embodiment based on tenant identification. To avoid repetition, it will not be elaborated here.

[0072] The embodiments of the present application also provide a computer device, as Figure 3 shown. The computer device includes a processor 301 and a memory 302. A program or instruction that can run on the processor 301 is stored on the memory 302. When the program or instruction is executed by the processor 301, each step of the above service call method based on tenant identification is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be elaborated here.

[0073] It should be noted that the computer devices in the embodiments of the present application include the above-mentioned mobile computer devices and non-mobile computer devices.

[0074] The memory 302 can be used to store software programs and various data. The memory 302 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data. Among them, the first storage area may store an operating system, application programs or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 302 may include volatile memory or non-volatile memory, or the memory 302 may include both volatile and non-volatile memory. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDR SDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synch link dynamic random access memory (SLDRAM), and a direct rambus random access memory (DRRAM). The memory 302 in the embodiments of the present application includes, but is not limited to, these and any other suitable types of memory.

[0075] The processor 301 may include one or more processing units; optionally, the processor 301 integrates an application processor and a modem processor. Among them, the application processor mainly processes operations related to the operating system, user interface, and application programs, etc., and the modem processor mainly processes wireless communication signals, such as a baseband processor. It can be understood that the above modem processor may not be integrated into the processor 301 either.

[0076] The embodiments of the present application further provide a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, it implements each process of the above embodiments of the service call method based on a tenant identifier and can achieve the same technical effect. To avoid repetition, it will not be elaborated here.

[0077] An embodiment of the present application further provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is configured to run programs or instructions to implement each process of the above embodiment of the service call method based on tenant identification, and can achieve the same technical effects. To avoid repetition, details are not described herein again.

[0078] It should be understood that the chip mentioned in the embodiments of the present application may also be referred to as a system-on-chip, system chip, chip system, or system-on-chip, etc.

[0079] An embodiment of the present application further provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement each process of the above embodiment of the service call method based on tenant identification, and can achieve the same technical effects. To avoid repetition, details are not described herein again.

[0080] It should be noted that in the present application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in a reverse order according to the functions involved. For example, the described methods may be performed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0081] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Those of ordinary skill in the art, under the inspiration of the present application and without departing from the spirit and scope protected by the claims of the present application, can still make many forms, all of which fall within the protection scope of the present application.

Claims

1. A service calling method based on tenant identification, characterized in that: The method comprises: In SaaS mode, add Eureka configuration to the configuration file of each service, and the Eureka configuration includes the tenant identifier; Integrate the Feign client into the load balancing component to obtain a SaaS-based load balancer; When a call request arrives at the load balancer, the load balancer obtains all service instances from the Eureka service registration center and traverses them, checking whether the metadata of each service instance contains a tenant identifier that matches the current call request. If it contains a tenant identifier that matches the current call request, the load balancer forwards the call request to the corresponding service instance for processing, thereby realizing customized service calls under the SaaS model.

2. The service calling method based on tenant identification according to claim 1, characterized in that: In the Eureka configuration, the metadata of the service instance is configured through eureka.instance.metadata-map.

3. The service calling method based on tenant identification according to claim 2, characterized in that: The tenant identifier is transmitted through the metadata of the service instance.

4. The service calling method based on tenant identification according to claim 1, characterized in that: The integration of the Feign client into the load balancing component includes: In the pom.xml file, introduce the dependencies of spring-cloud-starter-openfeign and spring-cloud-starter-loadbalancer. The spring-cloud-starter-openfeign provides support for Feign clients, and the spring-cloud-starter-loadbalancer provides support for load balancing components.

5. The service calling method based on tenant identification according to claim 1, characterized in that: The Eureka service registration center includes two components: Eureka Server and Eureka Client. The Eureka Server is responsible for maintaining the service registration information list, and the Eureka Client is used to register, renew and obtain registration list information.

6. The service calling method based on tenant identification according to claim 5, characterized in that: When the service instance starts, Eureka Client sends a service registration request to Eureka Server to register the service information in Eureka Server; Eureka Server records the information of the service instance into the registration information list for calling other service instances.

7. A service invocation device based on tenant identification, characterized in that: The device comprises: A service configuration module is configured to add a Eureka configuration in a configuration file of each service in a SaaS mode, wherein the Eureka configuration includes a tenant identifier; A load balancing module is configured to integrate the Feign client into the load balancing component to obtain a SaaS-based load balancer; The service call module is configured to, when a call request arrives at the load balancer, obtain all service instances from the Eureka service registration center and traverse them, and check whether the metadata of each service instance contains a tenant identifier that matches the current call request. If it contains a tenant identifier that matches the current call request, the load balancer forwards the call request to the corresponding service instance for processing, thereby realizing customized service calls under the SaaS model.

8. A service invocation system based on tenant identification, the system comprising a processor and a memory, wherein a computer program is stored in the memory, characterized in that: The computer program is loaded and executed by the processor to implement the service invocation method based on tenant identification as described in any one of claims 1 to 6.

9. A computer-readable storage medium, wherein a computer program is stored in the storage medium, characterized in that: When the computer program is executed by a processor, it is used to implement the service calling method based on tenant identification as described in any one of claims 1 to 7.

Images