Method and apparatus for tenant demand processing for multi-tenant architecture services and electronic device

Abstract

This application provides a method and related apparatus for handling tenant requirements in a multi-tenant architecture service. The method includes defining a product interface for tenant front-end invocation, wherein the product interface contains logic for determining specific class partition types; defining an abstract class partition associated with the product interface; defining multiple specific class partitions associated with the abstract class partition; configuring a first abstract method corresponding to a first customized requirement specific to a first tenant in the multi-tenant architecture in the abstract class partition; and configuring implementation logic for the first customized requirement specific to the first tenant in the first specific class partition corresponding to the first tenant. The tenant requirement handling method and related apparatus provided in this application for multi-tenant architecture services have the advantage of more elegant and clear multi-tenant module code display.

Description

Technical Field

[0001] This application relates to the field of multi-tenant architecture service technology, and more specifically, to a method and apparatus for processing tenant requirements in multi-tenant architecture services, as well as related electronic devices. Background Technology

[0002] Software as a Service (SaaS) is a software delivery model. In this model, software and its associated data are centrally hosted in the cloud, and users can use the software simply by connecting to the internet, without needing to install it.

[0003] SaaS typically has two technical implementation methods: "single-tenant SaaS" and "multi-tenant SaaS".

[0004] Currently, multi-tenant SaaS is gaining wider adoption. In a multi-tenant environment, applications run on the same or a group of servers, a concept known as a "single-instance" architecture. Therefore, multi-tenant SaaS, through certain strategies, ensures that different tenants can share the same application instance while providing users with independent application experiences and data spaces. Although the main functionalities may be consistent across tenants, there may be some customized features.

[0005] To fulfill tenants' customization needs, it's often necessary to rewrite the entire code of a single instance shared by all tenants, resulting in redundant code structure. Furthermore, the code for different tenants' customization needs is mixed together, making it difficult to distinguish between tenants. This leads to complex and logically chaotic implementation methods for adding, modifying, and deleting tenant customization needs, making code review difficult and potentially rendering customization features unusable.

[0006] The background art description is provided solely for the purpose of understanding the relevant technologies in this field and is not intended as an admission of prior art. Summary of the Invention

[0007] The purpose of this application is to provide a method, related apparatus and electronic equipment for handling tenant requirements in a multi-tenant architecture service, which can realize the customized requirements of different tenants in a clear and easy-to-understand manner, and aims to simplify the configuration management of tenant customized requirements.

[0008] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:

[0009] In a first aspect, embodiments of this application provide a method for handling tenant requirements in a multi-tenant architecture service, which may include:

[0010] Define a product interface for tenant front-end calls, and the product interface contains specific partition type judgment logic;

[0011] Define an abstract class partition associated with the product interface;

[0012] Define multiple concrete class partitions associated with the abstract class partition, each concrete class partition corresponding to a tenant;

[0013] Based on the first customized requirement specific to the first tenant in the multi-tenant configuration, configure the first abstract method corresponding to the first customized requirement in the abstract class partition;

[0014] Based on the first customized requirement specific to the first tenant, the implementation logic of the first customized requirement is configured in the first specific class partition corresponding to the first tenant.

[0015] Optionally, the method may further include:

[0016] Based on the second customized requirements specific to the second tenant in the multi-tenant configuration, a second abstract method corresponding to the second customized requirements is configured in the abstract class partition;

[0017] Based on the second customized requirements specific to the second tenant, the implementation logic of the second customized requirements is configured in the second specific class partition corresponding to the second tenant.

[0018] Optionally, the first abstraction method further corresponds to a second customization requirement specific to the second tenant in the multi-tenant system. The method may further include: configuring the implementation logic of the second customization requirement in a second specific class partition corresponding to the second tenant, based on the second customization requirement specific to the second tenant; wherein the implementation logic of the first customization requirement is different from the implementation logic of the second customization requirement, and the implementation logic of the second customization requirement is not configured in the first specific class partition, nor is the implementation logic of the first customization requirement configured in the second specific class partition.

[0019] Optionally, the method may further include:

[0020] Define a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant.

[0021] Optionally, the method may further include:

[0022] Based on the common requirements of the multi-tenant community, a third method corresponding to the common requirements and its implementation logic corresponding to the common requirements are configured in the abstract class partition.

[0023] Optionally, the method may further include:

[0024] Based on the common requirements of the multi-tenant, a third abstract method corresponding to the common requirements is configured in the abstract class partition;

[0025] Based on the common requirements of the multi-tenants, implementation logic corresponding to the common requirements is configured in each specific class partition.

[0026] Optionally, the method may further include:

[0027] In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is invoked, and the judgment logic in the product interface is executed to obtain the specific class partition type;

[0028] Based on the call to the product interface, the code method in the abstract class partition is called and executed, and the code method includes the first abstract method;

[0029] Based on the obtained specific class partition type, the first specific class partition corresponding to the first tenant is determined, and based on the execution of the code method in the abstract class partition, the implementation logic of the first customized requirement in the first specific class partition is called and executed to implement the first customized requirement for the first tenant.

[0030] Optionally, the method may further include:

[0031] In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the first tenant;

[0032] Based on the first tenant's call to the product interface, the code methods in the abstract class partition are called and executed, including the first abstract method and the second abstract method;

[0033] Based on the obtained specific class partition type, determine the first specific class partition corresponding to the first tenant, and based on the execution of the first abstract method in the abstract class partition, call and execute the implementation logic of the first customized requirement in the first specific class partition to implement the first customized requirement to the first tenant.

[0034] In response to the front-end request from the second tenant to execute the second customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the second tenant;

[0035] Based on the second tenant's call to the product interface, the code method in the abstract class partition is called and executed;

[0036] Based on the obtained specific class partition type, the second specific class partition corresponding to the second tenant is determined, and based on the execution of the second abstract method in the abstract class partition, the implementation logic of the second customized requirement in the second specific class partition is called and executed to implement the second customized requirement to the second tenant.

[0037] Optionally, the method may further include:

[0038] In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the first tenant;

[0039] Based on the first tenant's call to the product interface, the code method in the abstract class partition is called and executed, and the code method includes the first abstract method;

[0040] Based on the specific class partition type of the first tenant, the first specific class partition corresponding to the first tenant is determined, and based on the execution of the first abstract method in the abstract class partition, the implementation logic of the first customized requirement in the first specific class partition is called and executed to implement the first customized requirement to the first tenant.

[0041] In response to the front-end request from the second tenant to execute the second customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the second tenant;

[0042] Based on the second tenant's call to the product interface, the code method in the abstract class partition is called and executed;

[0043] Based on the obtained specific class partition type of the second tenant, the second specific class partition corresponding to the second tenant is determined, and based on the execution of the first abstract method in the abstract class partition, the implementation logic of the second customized requirement in the second specific class partition is called and executed to implement the second customized requirement for the second tenant.

[0044] Optionally, the method may further include:

[0045] In response to the tenant's frontend request to perform common requirements, the product interface is invoked, and the judgment logic in the product interface is executed to return an empty value;

[0046] Based on the tenant's call to the product interface, the code method in the abstract class partition is called and executed. The code method includes a third method and its corresponding implementation logic for the common requirements.

[0047] Optionally, the method may further include:

[0048] Define a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant;

[0049] When a specific class partition type is not obtained, the code method in the general class partition is called and executed, thereby not executing the tenant's customized requirements.

[0050] Secondly, embodiments of this application also provide a tenant demand processing apparatus for multi-tenant architecture services, which may include:

[0051] The first definition unit is used to define the product interface for tenant front-end calls, and the product interface has specific class partition type judgment logic;

[0052] The second definition unit is used to define the abstract class partition associated with the product interface;

[0053] The third definition unit is used to define multiple concrete class partitions associated with the abstract class partition, and each concrete class partition corresponds to a tenant;

[0054] The first configuration unit is used to configure a first abstract method corresponding to the first customization requirement in the abstract class partition according to the first customization requirement specific to the first tenant in the multi-tenant;

[0055] The second configuration unit is used to configure the implementation logic of the first customization requirement in the first specific class partition corresponding to the first tenant, based on the first customization requirement specific to the first tenant.

[0056] Thirdly, embodiments of this application also provide an electronic device, which may include:

[0057] Memory, used to store one or more programs;

[0058] processor;

[0059] The above method is implemented when the one or more programs are executed by the processor.

[0060] Thirdly, embodiments of this application also provide a storage medium storing a computer program configured to implement the above-described method when run.

[0061] Compared with the prior art, this application has the following advantages:

[0062] This application provides a method and related apparatus for handling tenant requirements in a multi-tenant architecture service. It defines a product interface for tenant front-end invocation, with specific class partition type judgment logic within the product interface; defines an abstract class partition associated with the product interface; defines multiple specific class partitions associated with the abstract class partition; configures a first abstract method corresponding to the first customized requirement in the abstract class partition based on the first customized requirement specific to the first tenant in the multi-tenant architecture; and configures the implementation logic of the first customized requirement in the first specific class partition corresponding to the first tenant based on the first customized requirement specific to the first tenant. Because the technical solution of this application defines different specific class partitions and configures the tenant's customized requirement logic in each specific class partition, and achieves code separation of customized functions between different tenants / merchants through interface type judgment and abstract class method implementation, it is clear and easy to understand; it also achieves configurable and pluggable management of customized requirements; furthermore, the customized functions between different tenants / merchants do not affect each other.

[0063] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0064] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 An architectural diagram of an exemplary multi-tenant architecture service.

[0066] Figure 2 This is a schematic diagram of the architecture of code in existing technology.

[0067] Figure 3 This is a schematic structural block diagram of a server provided in an embodiment of this application.

[0068] Figure 4 An exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0069] Figure 5 Another exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0070] Figure 6Another exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0071] Figure 7 Another exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0072] Figure 8 Another exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0073] Figure 9 Another exemplary flowchart of a tenant demand processing method for multi-tenant architecture services provided in this application embodiment.

[0074] Figure 10 This is an application example class diagram of a tenant requirement processing method for multi-tenant architecture services provided in the embodiments of this application.

[0075] Figure 11 A flowchart illustrating the implementation of an application example of the tenant requirement processing method for multi-tenant architecture services provided in this application embodiment.

[0076] Figure 12 This is a schematic diagram of the structure of a tenant demand processing device for multi-tenant architecture services provided in an embodiment of this application. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0078] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0079] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance. It should be noted that, in this document, the terms "first," "second," etc., do not require or imply any relationship or order between these entities or operations.

[0080] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0081] SaaS is an abbreviation for Software-as-a-Service, meaning software as a service, which is the delivery of software services over the internet. SaaS platform providers deploy application software on their own servers, and customers can order the application software services they need from the vendor via the internet based on their actual work requirements. They pay the vendor according to the amount and duration of the service ordered and receive the services provided by the SaaS platform provider through the internet.

[0082] SaaS typically has two technical implementations: "single-tenant SaaS" and "multi-tenant SaaS". In this article, a tenant refers to a user of the SaaS platform, and can also be called a merchant. One tenant usually corresponds to one organization.

[0083] The solution in this application is applied to a multi-tenant architecture service.

[0084] like Figure 1 The diagram illustrates an exemplary multi-tenant architecture for a service (SaaS). Tenant A and Tenant B are shown in the diagram. Of course, there may be more tenants, which are not limited here.

[0085] like Figure 1 As shown, multiple tenants, such as tenant A and tenant B, run their applications on the same or the same group of servers, i.e., in a single-instance manner; while the data of these multiple tenants, such as data A and B, can be stored separately in the database. Although Figure 1 This demonstrates that data from multiple tenants can be stored in the same database, but it can also be stored in a distributed manner.

[0086] Based on this, the server-side, or service provider, can use a single set of basic code to support all tenants, thus providing the same services to tenant A and tenant B for common needs. However, tenant A and tenant B may customize different requirements based on individual needs. In this article, different customization requirements include different categories of customization requirements, as well as similar customization requirements with different details or sub-functions. For example, tenant A needs customized intelligent customer service, while tenant B needs customized intelligent decision-making. Or, both tenant A and tenant B need customized intelligent customer service, but the specific details or processes differ. Figure 2 As exemplified, tenant A has two custom requirements a and c and a common requirement b; while tenant b has two custom requirements d and f and a common requirement b.

[0087] However, for the server-side, i.e., the service provider, in order to meet the different customization needs of different tenants in this multi-tenant architecture, the aforementioned basic code management suffers from code merging across all tenants. Different customization needs of different tenants must be implemented separately in the basic code based on conditional logic structures. This results in code redundancy, numerous logical judgments, and unclear distinctions between each tenant and each tenant's customization needs, making it highly error-prone and rendering customization features unusable. Furthermore, the class diagram architecture of the code is extremely chaotic and inelegant. Such a structure also hinders the rapid configuration and plug-and-play use of tenant customization needs.

[0088] In view of this, in order to solve the above problems, embodiments of this application provide a tenant demand processing method and apparatus for multi-tenant architecture services, as well as related electronic devices and storage media.

[0089] It should be noted that the method and apparatus provided in this application can be applied to, for example... Figure 1 The multi-tenant architecture service (SaaS service) shown is particularly applicable to electronic devices, such as computers, which can be one or more servers, and can be centralized or distributed.

[0090] Figure 3 This illustration shows a schematic block diagram of an electronic device, such as a computer 300, provided in an embodiment of this application. The electronic device 300 includes a memory 302, a processor 301, and a communication interface 303. The memory 302, processor 301, and communication interface 303 are electrically connected to each other directly or indirectly to realize data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0091] The memory 302 can be used to store software programs and modules, such as the program instructions or modules corresponding to the tenant demand processing device for multi-tenant architecture services provided in the embodiments of this application. The processor 301 executes the software programs and modules stored in the memory 302 to perform various functional applications and data processing, thereby executing the steps of the tenant demand processing method for multi-tenant architecture services provided in the embodiments of this application. The communication interface 303 can be used to communicate with other node devices for signaling or data.

[0092] The memory 302 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0093] Processor 301 can be an integrated circuit chip with signal processing capabilities. Processor 101 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0094] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device 300 may also include components that are more advanced than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof.

[0095] The following uses a server as an illustrative execution subject to illustrate the tenant requirement processing method for multi-tenant architecture services provided in this application embodiment.

[0096] As an optional implementation, please refer to Figure 4 The method for handling tenant requirements in a multi-tenant architecture service may include:

[0097] S402: Defines the product interface used for front-end calls by tenants.

[0098] S404: Defines an abstract class partition associated with the product interface.

[0099] S406: Define multiple concrete class partitions associated with the abstract class partition, each concrete class partition corresponding to a tenant.

[0100] S408: Configure a first abstract method in the abstract class partition based on the first customization requirement specific to the first tenant in the multi-tenant system.

[0101] S410: Based on the first customized requirement specific to the first tenant, configure the implementation logic of the first customized requirement in the first specific class partition corresponding to the first tenant.

[0102] In step S402, the method further includes: determining logic for a specific class partition type in the product interface. In some embodiments, the determining logic for a specific class partition type in the product interface may include defining or configuring a corresponding modified pattern, such as the factory pattern, in the product interface, which will be further explained below.

[0103] In this embodiment of the application, the abstract method may include an empty method.

[0104] exist Figure 4 In the illustrated embodiment, the first abstract method corresponds to a first customization requirement. For example, for Figure 1 The first abstract method of tenant A, such as call(), can correspond to tenant A's first customized requirement a, such as intelligent customer service.

[0105] In a further embodiment, the second tenant can also be configured and its customized requirements can be implemented.

[0106] like Figure 5 As shown, in Figure 4 Based on the illustrated embodiment, the tenant demand processing method may further include:

[0107] S412: Configure a second abstract method in the abstract class partition according to the second customized requirements specific to the second tenant in the multi-tenant configuration;

[0108] S414: Based on the second customized requirements specific to the second tenant, configure the implementation logic of the second customized requirements in the second specific class partition corresponding to the second tenant.

[0109] exist Figure 5 In the illustrated embodiment, the second abstract method corresponds to the second customization requirement. Therefore, combined with... Figure 4 and Figure 5 To address the different customization needs of different tenants / merchants, separate abstract methods can be defined within the abstract class section. For example, for Figure 1 For tenant A shown, the first abstract method, such as call(), can correspond to tenant A's first customized requirement a, such as intelligent customer service; for Figure 1 The second abstract method, such as `consult()`, can correspond to the second customized requirement d of tenant A, such as intelligent decision-making, for tenant B.

[0110] In this embodiment, different abstraction methods are defined for different customization needs. These methods can be applied to different categories of customization needs, or to customization needs of the same type with different details or sub-functions.

[0111] Based on defining different abstract methods in an abstract class and configuring different implementation logic in their respective concrete classes, in Figure 5 In this embodiment, the configurable and pluggable effect of each tenant's customized needs can be achieved.

[0112] In an alternative embodiment that configures and implements the customization requirements for the second tenant, such as Figure 6 As shown, the same abstract methods can be defined in the abstract class partition for different customization needs, but different implementation logic can be defined in the specific class partition of each tenant.

[0113] like Figure 6 As shown, in Figure 4 Based on the illustrated embodiment, the tenant demand processing method may further include:

[0114] S414': Based on the second customized requirements specific to the second tenant, configure the implementation logic of the second customized requirements in the second specific class partition corresponding to the second tenant.

[0115] exist Figure 6 In the illustrated embodiment, the first abstraction method also corresponds to the second tenant's proprietary second customization requirement.

[0116] Moreover, in Figure 6 In the illustrated embodiment, the implementation logic of the first customization requirement is different from the implementation logic of the second customization requirement, and the implementation logic of the second customization requirement is not configured in the first specific class partition, nor is the implementation logic of the first customization requirement configured in the second specific class partition.

[0117] Therefore, combined Figure 4 and Figure 6 To address the diverse customization needs of different tenants / merchants, especially when similar customization needs from different tenants / merchants have different details or sub-functions, the same abstract methods can be defined in the abstract class section, but different implementation logic can be configured in their respective concrete classes. For example, for Figure 1 For tenant A shown, the first abstract method, such as `loan()`, can correspond to tenant A's first customized requirement c, such as tenant A's intelligent loan approval; for Figure 1 The same first abstract method in the abstract class of tenant B, such as loan(), can correspond to tenant B's second customized requirement f, such as tenant B's smart loan approval. Although tenant A's first customized requirement c, such as smart loan approval, is of the same type as tenant B's second customized requirement f, such as smart loan approval, the implementation or process details may be different, that is, they are still different customized requirements.

[0118] Based on defining the same abstract method in an abstract class, but configuring different implementation logic in their respective concrete classes, and not configuring implementation logic for other tenants' customized needs in their respective concrete classes, in Figure 6 In the embodiments, the configurable and pluggable effect of each tenant's customized needs can still be achieved.

[0119] In a further embodiment, the method may also provide an interruption mechanism for customized needs. For example, the method may further include: A1 defining a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant.

[0120] In a further embodiment, the method also provides a simple and readily available configuration scheme for the needs shared by all tenants.

[0121] For example, in one of the schemes, the method may further include: B1 configuring a third method corresponding to the common requirements and its implementation logic corresponding to the common requirements in the abstract class partition according to the common requirements of the multi-tenant.

[0122] As an alternative to the above solution, the method may include: C1 configuring a third abstract method corresponding to the common requirements in the abstract class partition according to the common requirements of the multi-tenants; C2 configuring the implementation logic corresponding to the common requirements in each specific class partition according to the common requirements of the multi-tenants.

[0123] In the first approach, the implementation logic for common requirements is configured in the abstract class section. In the second approach, the implementation logic for common requirements is configured in the concrete class section. This may increase the configuration complexity to some extent, but it is beneficial for customizing common requirements.

[0124] Based on the above embodiments of this application, when a tenant initiates a front-end request to execute its required needs, the execution of the needs can be achieved through a variety of different embodiments.

[0125] like Figure 7 In the illustrated embodiment, for the first customized requirement (such as intelligent customer service or intelligent loan approval) of the first tenant (tenant A), the method may further include the following steps:

[0126] S702: In response to the front-end request from the first tenant to execute the first customized requirement, call the product interface and execute the judgment logic in the product interface to obtain the specific class partition type;

[0127] S704: Based on the call to the product interface, call and execute the code method in the abstract class partition, the code method including the first abstract method;

[0128] S706: Based on the obtained specific class partition type, determine the first specific class partition corresponding to the first tenant, and based on the execution of the code method in the abstract class partition, call and execute the implementation logic of the first customized requirement in the first specific class partition to implement the first customized requirement for the first tenant.

[0129] like Figure 7 The illustrated embodiments are particularly applicable to Figures 4 to 6 This implementation is based on the example shown.

[0130] Accordingly, in Figure 5 Based on the embodiments shown, and in accordance with... Figure 8 In the illustrated embodiment, the method may include, for the different customization needs of the first and second tenants, the following:

[0131] S802: In response to the front-end request from the first tenant to execute the first customized requirement, call the product interface and execute the judgment logic in the product interface to obtain the specific class partition type of the first tenant;

[0132] S804: Based on the first tenant's call to the product interface, call and execute the code methods in the abstract class partition, the code methods including the first abstract method and the second abstract method;

[0133] S806: Based on the obtained specific class partition type, determine the first specific class partition corresponding to the first tenant, and based on the execution of the first abstract method in the abstract class partition, call and execute the implementation logic of the first customized requirement in the first specific class partition to implement the first customized requirement for the first tenant.

[0134] S808: In response to the front-end request from the second tenant to execute the second customized requirement, call the product interface and execute the judgment logic in the product interface to obtain the specific class partition type of the second tenant;

[0135] S810: Based on the second tenant's call to the product interface, call and execute the code method in the abstract class partition;

[0136] S812: Based on the obtained specific class partition type, determine the second specific class partition corresponding to the second tenant, and based on the execution of the second abstract method in the abstract class partition, call and execute the implementation logic of the second customized requirement in the second specific class partition to implement the first customized requirement to the first tenant.

[0137] As an alternative embodiment, in Figure 6 Based on the embodiments shown, and in accordance with... Figure 9 In the illustrated embodiment, the method may include, for the different customization needs of the first and second tenants, the following:

[0138] S902: In response to the front-end request from the first tenant to execute the first customized requirement, call the product interface and execute the judgment logic in the product interface to obtain the specific class partition type of the first tenant;

[0139] S904: Based on the first tenant's call to the product interface, call and execute the code method in the abstract class partition, the code method including the first abstract method;

[0140] S906: Based on the obtained specific class partition type of the first tenant, determine the first specific class partition corresponding to the first tenant, and based on the execution of the first abstract method in the abstract class partition, call and execute the implementation logic of the first customized requirement in the first specific class partition to implement the first customized requirement for the first tenant.

[0141] S908: In response to the front-end request from the second tenant to execute the second customized requirement, call the product interface and execute the judgment logic in the product interface to obtain the specific class partition type of the second tenant;

[0142] S910: Based on the second tenant's call to the product interface, call and execute the code method in the abstract class partition;

[0143] S912: Based on the obtained specific class partition type of the second tenant, determine the second specific class partition corresponding to the second tenant, and based on the execution of the first abstract method in the abstract class partition, call and execute the implementation logic of the second customized requirement in the second specific class partition to implement the second customized requirement for the second tenant.

[0144] As Figures 7 to 9 As a further possibility of the illustrated embodiment, the method can also provide an interruption mechanism for customized requirements. For example, the method may further include: D1 calling and executing a code method in the generic class partition when a specific class partition type is not obtained, thereby preventing the execution of the tenant's customized requirements.

[0145] As Figures 7 to 9 Further possibilities or alternatives to the illustrated embodiment, for the execution of common requirements of multiple tenants including first and second tenants, the method may include: E1 responding to a front-end request from a tenant to execute a common requirement, calling the product interface, and executing the judgment logic in the product interface to return a null value; E2, based on the tenant's call to the product interface, calling and executing a code method in the abstract class partition, the code method including a third method and its corresponding implementation logic for the common requirement.

[0146] As one implementation method, the tenant demand handling method for multi-tenant architecture services provided in this application can be implemented based on the Java language, which will be discussed below. Figure 10 and Figure 11 This paper describes an exemplary implementation based on the Java language. However, it is conceivable that other embodiments according to this application can be implemented in other languages, and the implementation using Java as an example below can be implemented in other languages, which falls within the scope of this application.

[0147] like Figure 10 As shown, we can first define the product interface, which is used by the tenant's front end to call the product interface, such as the Merchant interface shown in the figure.

[0148] Continue as Figure 10 As shown, abstract class partitions can also be defined, such as... Figure 10 The abstract class partition AbstractMerchant shown implements the Product interface and the Merchant interface. To implement the Product interface, the abstract class partition AbstractMerchant is associated with both the Product interface and the Merchant interface.

[0149] although Figure 10 Not specifically shown, multiple code methods can be used within the abstract class partition. These code methods can include abstract methods corresponding to the various customization requirements (all customization requirements) of each tenant (all tenants). The configuration of these abstract methods can be as follows: Figure 6 The one-to-one configuration shown in the embodiment can also be as follows: Figure 7 The embodiment shown can be configured as a one-to-many configuration, or a combination of both.

[0150] Continue as Figure 10As shown, multiple concrete class partitions, such as AMinchant and BMinchant, can be used to implement abstract class partitions, with each concrete class partition corresponding to one tenant. For example... Figure 10 The diagram illustrates the concrete class partition Amerchant corresponding to the first tenant (tenant A) and the concrete class partition Bmerchant corresponding to the second tenant (tenant B). To implement an abstract class partition, each concrete class can be associated with an abstract class. For example, each concrete class partition is a subclass of the abstract class partition, and the two can have an inheritance relationship.

[0151] although Figure 10 Not specifically shown, within each specific class partition, the implementation logic for these requirements can be configured according to the corresponding tenant-specific customization needs. Those skilled in the art will understand that the implementation logic for each tenant-specific customization requirement is configured only within the corresponding specific class partition, and not in other specific class partitions.

[0152] Specifically, you can define empty methods in the abstract class to implement all customization requirements, and define the language logic to implement customization requirements in the concrete class.

[0153] Since each specific class partition is used to implement the customized requirements logic of a tenant, and the customized requirements in each specific class partition are displayed in parallel, the code compiler can intuitively see all the customized requirements of the corresponding specific class partition, making the code display more convenient. At the same time, it facilitates the configurable and pluggable management of the customized requirements of each tenant.

[0154] like Figure 10 The text further illustrates that a general class partition, GeneralMerchant, can also be defined, which can be associated with an abstract class partition and can also be a subclass of the abstract class partition, thus establishing an inheritance relationship.

[0155] This generic partition can be configured without any implementation logic and can be shared by all tenants. Therefore, when this generic partition is invoked, it can return a null value.

[0156] although Figure 10 Not specifically shown, in one embodiment, a third method corresponding to a common requirement and its corresponding implementation logic can also be configured in the abstract class. That is, the code methods of the abstract class partition may include a third method, which is not an abstract method or an empty method, and has implementation logic for implementing the common requirement.

[0157] It should be noted that Java includes various patterns, such as the factory pattern, adapter pattern, and decision pattern. When defining product interfaces, abstract class partitions, and concrete class partitions, the adapter pattern or the factory pattern can be used, and no restriction is made here.

[0158] In one specific embodiment, combined with Figure 10 and Figure 11 As shown, the factory pattern can be used to configure the logic for determining the specific class partition type in the product interface, such as... Figure 10 The example shown is `getMerchantType()`. Correspondingly, the logic for determining the partition type of a specific class can also be configured in each concrete class as a condition for calling the concrete class, such as... Figure 10 The getMerchantType() function is shown.

[0159] Furthermore, when defining specific class partitions, the sub-abstracts can be initialized. For example... Figure 10 and Figure 11 In the illustrated embodiment, the above judgment logic can be implemented by defining a MerchantFactory to initialize specific concrete class partitions in the factory pattern. Thus, based on the tenant's configuration, the specific concrete class partitions are called and executed. Each concrete class partition includes the implementation logic for the tenant's customized requirements.

[0160] In one exemplary embodiment, the pseudocode for defining MerchantFactory is shown below:

[0161] public class MerchantFactory {

[0162] private static Map<Integer, Merchant> merchantTypeMap = newHashMap<>();

[0163] @Autowired

[0164] private Map<String, Merchant> merchantMap;

[0165] public static Merchant get(MerchantTypeEnum merchantType) {

[0166] if(merchantType == null){

[0167] log.info("MerchantFactory -> get -> merchantType is null,set MerchantTypeEnum.General !");

[0168] return merchantTypeMap.get(MerchantTypeEnum.General.getCode());

[0169] }

[0170] return merchantTypeMap.get(merchantType.getCode());

[0171] }

[0172] @PostConstruct

[0173] public void init() {

[0174] for (Map.Entry<String, Merchant> en : merchantMap.entrySet()){

[0175] merchantTypeMap.put(en.getValue().getMerchantType().getCode(), en.getValue());

[0176] }

[0177] }

[0178] }

[0179] As mentioned earlier, the product interface, abstract class partition, and concrete class partition are sequentially related, especially in terms of inheritance.

[0180] like Figure 11 Combination Figure 10 As shown, when a tenant requests to execute customized requirements, the tenant type MerchantType (e.g., tenant A) configured in the product interface Merchant can be obtained. Based on this determined tenant type MerchantType, the specific class partition, i.e., the specific tenant Merchant partition, can be obtained through MerchantFactory. Meanwhile, although... Figure 11 Not shown, based on the above-mentioned relationships, other code methods of the product interface will also be executed, and subsequently, code methods in the abstract class partition will be executed, including abstract methods or empty methods corresponding to different customized needs of different tenants, such as tenant A's needs a and c, and tenant B's needs d and e. Furthermore, the execution of code methods in the abstract class partition may optionally also include a third method and its implementation logic for executing common needs, such as tenant A and tenant B's needs b.

[0181] like Figure 11 Combination Figure 10 As shown, if MerchantType is successfully obtained, the corresponding concrete class partition is invoked, and the implementation logic for customized requirements in that concrete partition is executed based on the association between that concrete class partition and the abstract class partition. If MerchantType fails to be obtained, the general class partition is invoked, but the processing of the tenant's customized requirements is not executed.

[0182] It should be noted that the customization requirements of different specific categories are independent of each other and do not affect each other.

[0183] As mentioned earlier, all empty methods for customized requirements are defined in a common abstract class, and the logic for each customized requirement is defined in a specific concrete class. The logic for customized requirements differs in different concrete class partitions, so that the corresponding customized requirements can be executed in the specific implementation.

[0184] For example, the first tenant only has the first customization requirement and no second customization requirement. Based on this, when the program is executed, the empty methods of the first customization requirement and the second customization requirement in the abstract class partition are both called and executed. However, since the first concrete class partition only defines the logic of the first customization requirement, it will only execute the first customization requirement and not the second customization requirement.

[0185] Furthermore, for any tenant, upon responding to the tenant's first customized requirement request instruction, the product interface is invoked according to the request instruction, and the first abstract method is implemented by the abstract class partition. Then, it is determined whether the call was successful. If the call is successful, the first customized requirement logic is executed, and other customized requirement logic and the general requirement logic are not executed. If the call fails, the third abstract method is implemented by the abstract class partition to execute the general requirement logic.

[0186] It should be noted that in the specific implementation process, the tenant configuration can be achieved through a configurable page, such as the configuration page of the management account. Thus, the configuration and display of specific class partitions can be achieved according to the preset configuration information.

[0187] As a preferred example, the solution according to embodiments of the present invention also provides a highly separable and highly customizable implementation effect. For example, when a specific class partition includes specific class partition a, specific class partition b, and specific class partition c, the platform's management account can display and operate specific class partition a, specific class partition b, and specific class partition c, while specific class partition a can be opened to tenant A, and specific class partition b can be opened to tenant B, so as to run tenants' customized needs in a separable manner. In some optional examples, the platform provider can provide conventional implementation logic for the requirements, such as providing the implementation logic of intelligent customer service call() in each specific class partition. Tenants can change or delete the implementation logic of intelligent customer service in their respective partitions, thereby achieving configurable and pluggable management without affecting other tenants.

[0188] The tenant requirement handling method for multi-tenant architecture services provided in this application offers several advantages. First, when customized requirements exist, the interface displays the information according to those requirements; otherwise, it returns to the general interface, enabling plug-and-play management and making management more convenient. Second, each tenant's customized requirements correspond to an independent specific class partition, ensuring that the customized functions of each tenant do not affect each other. Furthermore, the separation of customized requirement code across tenants makes the code more concise and easier to view.

[0189] Based on the above implementation method, please refer to Figure 12 This application also provides a tenant demand processing apparatus 1200 for multi-tenant architecture services, the tenant demand processing apparatus 1200 for multi-tenant architecture services comprising:

[0190] The first definition unit 1210 is used to define the product interface for tenant front-end calls, and the product interface has specific class partition type judgment logic.

[0191] The second definition unit 1220 is used to define the abstract class partition associated with the product interface.

[0192] The third defining unit 1230 is used to define multiple concrete class partitions associated with the abstract class partition, each of the concrete class partitions corresponding to a tenant.

[0193] The first configuration unit 1240 is used to configure a first abstract method corresponding to the first customization requirement in the abstract class partition according to the first customization requirement specific to the first tenant in the multi-tenant system.

[0194] The second configuration unit 1250 is used to configure the implementation logic of the first customization requirement in the first specific class partition corresponding to the first tenant, according to the first customization requirement dedicated to the first tenant.

[0195] In summary, this application provides a method and related apparatus for handling tenant requirements in a multi-tenant architecture service. It defines a product interface for tenant front-end invocation, with specific class partition type judgment logic within the product interface; defines an abstract class partition associated with the product interface; defines multiple specific class partitions associated with the abstract class partition; configures a first abstract method corresponding to the first customized requirement in the abstract class partition based on the first customized requirement specific to the first tenant in the multi-tenant architecture; and configures the implementation logic of the first customized requirement in the first specific class partition corresponding to the first tenant based on the first customized requirement specific to the first tenant. Since the technical solution of this application can define different specific class partitions, and each specific class partition can define a tenant's customized requirement, when viewing a tenant's customized requirement, it can be viewed directly through the specific class partitions without needing to display them one by one. Therefore, the code is simpler and more convenient for users to view the code.

[0196] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the apparatus, methods, and computer program products according to embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function.

[0197] It should also be noted that in some alternative implementations, the functions marked in the boxes may occur in a different order than those shown in the accompanying drawings. For example, two consecutive boxes may actually be executed in essentially parallel order, or they may sometimes be executed in reverse order, depending on the functions involved.

[0198] It should also be noted that each box in a block diagram and / or flowchart, as well as combinations of boxes in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0199] In addition, the functional modules in the embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0200] If the aforementioned function is implemented as a software functional module 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 a portion 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 several 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 method described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0201] While the present invention has been disclosed above, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of the invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A method for handling tenant requirements in a multi-tenant architecture service, characterized in that, The method includes: Define a product interface for tenant front-end calls, and the product interface contains specific partition type judgment logic; Define an abstract class partition associated with the product interface; Define multiple concrete class partitions associated with the abstract class partition, each concrete class partition corresponding to a tenant, wherein the implementation logic for the customization requirements of other tenants other than the tenant corresponding to its own category is not configured in its respective concrete class; Based on the first customized requirement specific to the first tenant in the multi-tenant configuration, configure the first abstract method corresponding to the first customized requirement in the abstract class partition; Based on the first customized requirement specific to the first tenant, the implementation logic of the first customized requirement is configured in the first specific class partition corresponding to the first tenant.

2. The tenant demand processing method as described in claim 1, characterized in that, The method further includes: Based on the second customized requirements specific to the second tenant in the multi-tenant configuration, a second abstract method corresponding to the second customized requirements is configured in the abstract class partition; Based on the second customized requirements specific to the second tenant, the implementation logic of the second customized requirements is configured in the second specific class partition corresponding to the second tenant.

3. The tenant demand processing method of claim 1, wherein, The first abstraction method also corresponds to the second customization requirement specific to the second tenant in a multi-tenant environment. The method further includes: configuring the implementation logic of the second customization requirement in the second specific class partition corresponding to the second tenant, based on the second customization requirement specific to the second tenant; The implementation logic of the first customization requirement is different from that of the second customization requirement. The implementation logic of the second customization requirement is not configured in the first specific class partition, and the implementation logic of the first customization requirement is not configured in the second specific class partition.

4. The tenant demand processing method according to any one of claims 1 to 3, wherein, The method further includes: Define a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant.

5. The tenant demand processing method according to any one of claims 1 to 3, wherein, The method further includes: Based on the common requirements of the multi-tenant community, a third method corresponding to the common requirements and its implementation logic corresponding to the common requirements are configured in the abstract class partition.

6. The tenant demand processing method according to any one of claims 1 to 3, wherein, The method further includes: Based on the common requirements of the multi-tenant, a third abstract method corresponding to the common requirements is configured in the abstract class partition; Based on the common requirements of the multi-tenants, implementation logic corresponding to the common requirements is configured in each specific class partition.

7. The tenant demand processing method according to any one of claims 1 to 3, wherein, The method includes: In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is invoked, and the judgment logic in the product interface is executed to obtain the specific class partition type; Based on the call to the product interface, the code method in the abstract class partition is called and executed, and the code method includes the first abstract method; Based on the obtained specific class partition type, the first specific class partition corresponding to the first tenant is determined, and based on the execution of the code method in the abstract class partition, the implementation logic of the first customized requirement in the first specific class partition is called and executed to implement the first customized requirement for the first tenant.

8. The tenant demand processing method of claim 2, wherein, The method includes: In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the first tenant; Based on the first tenant's call to the product interface, the code methods in the abstract class partition are called and executed, including the first abstract method and the second abstract method; Based on the obtained specific class partition type, determine the first specific class partition corresponding to the first tenant, and based on the execution of the first abstract method in the abstract class partition, call and execute the implementation logic of the first customized requirement in the first specific class partition to implement the first customized requirement to the first tenant. In response to the front-end request from the second tenant to execute the second customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the second tenant; Based on the second tenant's call to the product interface, the code method in the abstract class partition is called and executed; Based on the obtained specific class partition type, the second specific class partition corresponding to the second tenant is determined, and based on the execution of the second abstract method in the abstract class partition, the implementation logic of the second customized requirement in the second specific class partition is called and executed to implement the second customized requirement to the second tenant.

9. The tenant demand processing method of claim 3, wherein, The method includes: In response to the front-end request from the first tenant to execute the first customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the first tenant; Based on the first tenant's call to the product interface, the code method in the abstract class partition is called and executed, and the code method includes the first abstract method; Based on the specific class partition type of the first tenant, the first specific class partition corresponding to the first tenant is determined, and based on the execution of the first abstract method in the abstract class partition, the implementation logic of the first customized requirement in the first specific class partition is called and executed to implement the first customized requirement to the first tenant. In response to the front-end request from the second tenant to execute the second customized requirement, the product interface is called, and the judgment logic in the product interface is executed to obtain the specific class partition type of the second tenant; Based on the second tenant's call to the product interface, the code method in the abstract class partition is called and executed; Based on the obtained specific class partition type of the second tenant, the second specific class partition corresponding to the second tenant is determined, and based on the execution of the first abstract method in the abstract class partition, the implementation logic of the second customized requirement in the second specific class partition is called and executed to implement the second customized requirement for the second tenant.

10. The tenant demand processing method of claim 5, wherein, The method includes: In response to the tenant's frontend request to perform common requirements, the product interface is invoked, and the judgment logic in the product interface is executed to return an empty value; Based on the tenant's call to the product interface, the code method in the abstract class partition is called and executed. The code method includes a third method and its corresponding implementation logic for the common requirements.

11. The tenant demand processing method of claim 7, wherein, The method further includes: Define a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant; When a specific class partition type is not obtained, the code method in the general class partition is called and executed, thereby not executing the tenant's customized requirements.

12. The tenant demand processing method as described in any one of claims 8 to 10, characterized in that, The method further includes: Define a generic class partition associated with the abstract class partition, wherein the generic class partition is configured to return a null value when invoked and is shared by the multi-tenant; When a specific class partition type is not obtained, the code method in the general class partition is called and executed, thereby not executing the tenant's customized requirements.

13. A tenant demand processing apparatus for multi-tenant architecture services, characterized in that, The device includes: The first definition unit is used to define the product interface for tenant front-end calls, and the product interface has specific class partition type judgment logic; The second definition unit is used to define the abstract class partition associated with the product interface; The third definition unit is used to define multiple concrete class partitions associated with the abstract class partition. Each concrete class partition corresponds to a tenant. In its respective concrete class, no implementation logic for the customized requirements of other tenants other than the tenant corresponding to its own category is configured. The first configuration unit is used to configure a first abstract method corresponding to the first customization requirement in the abstract class partition according to the first customization requirement specific to the first tenant in the multi-tenant; The second configuration unit is used to configure the implementation logic of the first customization requirement in the first specific class partition corresponding to the first tenant, based on the first customization requirement specific to the first tenant.

14. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-12 is implemented.

Images