Customizable multi-tenant management system and method integrated with multiple service domains

Abstract

The invention belongs to the technical field of resource management, and particularly discloses a multi-service domain integrated customizable multi-tenant management system and method, and the system comprises a multi-tenant architecture which is configured to be used for defining different service domains as different service systems, and splitting a plurality of tenants according to different standards under each service system, different organizations are divided under each tenant, and each organization corresponds to different users; the main data management module is configured to be used for defining the dimension relation of basic data according to the relation of tenants, organizations and users under each business system within each year range, and distributing corresponding basic data to each business system; and the portal control module is configured to be used for realizing login operation and entrance authority control of the user. Tenant splitting can be performed according to different standards under different business systems, so that customized design of a multi-tenant framework is realized, and tenant splitting requirements of different business systems can be met.

Description

Technical Field

[0001] The present invention relates to the field of resource management technology, and in particular to a customizable multi-tenant management system and method for integrating multiple business domains. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] With the popularity of cloud computing and Software as a Service (SaaS), multi-tenant architecture has become a common design pattern for enterprise software applications. A multi-tenant architecture allows a single application instance to serve multiple tenants (customers), enabling efficient resource utilization and simplified maintenance.

[0004] The core advantages of a multi-tenant architecture lie in resource sharing and simplified maintenance. Traditional multi-tenant architectures are often used in SaaS models, where different tenants serve different customers. However, traditional multi-tenant architectures face new challenges in the following business scenarios: First, when splitting multiple tenants, there is often a unified splitting standard, such as by the company's organizational structure or by region. However, in some scenarios, different business domains may have different tenant splitting standards. For example, in a settlement scenario, tenants may need to be divided by geographic region, while in a budgeting scenario, tenants may need to be divided according to hierarchical organizational relationships. Secondly, a large enterprise often has multiple business lines, but only one set of basic data standards is maintained. These basic data standards need to be shared by different tenants in multiple business lines. Otherwise, basic data will be inconsistent across business lines, creating a potential risk of confusion in data standards and posing a significant risk to subsequent business analysis and statistics.

[0005] In addition, the traditional multi-tenant architecture also has certain limitations in scenarios such as cross-tenant data transmission and cross-tenant relationship transfer. When performing cross-tenant transfers, the data that needs to be transferred in the original tenant is found and then transferred to the new tenant through the database import and export tools. This method requires identifying which data needs to be transferred and how to handle the running process data, and also causes the historical traceability of the original tenant data to be lost. Summary of the Invention

[0006] To solve the above problems, the present invention proposes a customizable multi-tenant management system and method that integrates multiple business domains. It adopts centralized master data management, abstracts different business domains (such as budget, settlement, assets, contracts, etc.) into business system concepts, splits multiple tenants according to different dimensions within the business system, and incorporates an organization under each tenant to build a business system-tenant-organization-user dimension relationship, unifying the portal and permission control; at the same time, it introduces the annual dimension to support the transfer of tenant relationships across years.

[0007] In some embodiments, the following technical solutions are adopted: A customizable multi-tenant management system that integrates multiple business domains, including: The multi-tenant architecture is configured to define different business areas as different business systems. Under each business system, multiple tenants are divided according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. The master data management module is configured to define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system within each year, and distribute the corresponding basic data to each business system; The portal control module is configured to implement user login operations and entry permission control. The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

[0008] As a further solution, each business system is configured with a unique system identifier, and each business system is isolated from each other; When defining multiple tenants under each business system, a unique identifier is configured for each tenant; each tenant uses an independent database instance strategy to ensure data isolation between tenants.

[0009] As a further solution, an annual dimension is added to the multi-tenant architecture, and tenant, organization, and user relationships under different business systems are constructed in different years. The user's entrance on the portal and the specific tenant or organization that can be jumped to through the entrance are determined by the current year and the corresponding multi-tenant architecture of that year.

[0010] As a further solution, the method further includes configuring a dimension relationship time series log table, wherein the dimension relationship time series log table is configured to record all update operations of tenant, organization, user and year dimension relationships under each business system.

[0011] As a further solution, when the maintenance relationship under the business system changes, an event is triggered. The event processor queries all currently valid dimension relationships from the dimension relationship time series log table; and builds one or more Map objects in memory; the Map objects store the corresponding key-value pairs between users, years and tenants; in response to the received API request, the user and year dimension data are obtained, and the corresponding tenants are directly queried from the memory.

[0012] As a further solution, it also includes: configuring a dimension path pre-calculation table, which calculates and stores the complete dimension relationship path for each underlying data; when the dimension relationship changes or new business data is generated, the index update is triggered by asynchronous events; when an aggregate query is required, the dimension path pre-calculation table is used to perform efficient GROUP BY and LIKE operations.

[0013] As a further solution, when a process task is generated, it first enters a temporary queue. An independent proxy distributor service consumes this queue and queries the current and latest ownership of the process initiating organization from the configuration dimension relationship time series log table based on the process instance ID. If it is found that the tenant ownership has been transferred, the agent distributor redirects the process task to the corresponding user in the new tenant based on the new dimension relationship.

[0014] As a further solution, define an inheritance policy attribute for each permission, including: STRICT_TENANT: bound to a tenant and automatically invalidated after being transferred across tenants; TRANSFERABLE: Inherited when the tenant transfers; READ_ONLY_LEGACY: After a cross-tenant transfer, read-only permission is retained for the original tenant's historical data; When a user accesses the system in a new tenant, the permission engine's calculation logic is: Obtain the user's direct permissions in the new tenant, search the original tenant from the configuration dimension relationship time series log table, and load the user's permissions in the original tenant with the attributes of TRANSFERABLE or READ_ONLY_LEGACY; merge these permissions in memory to form the user's current final effective permission set.

[0015] In other embodiments, the following technical solutions are adopted: A customizable multi-tenant management method for integrating multiple business domains, comprising: Define different business areas as different business systems. Within each business system, split multiple tenants according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. Within each year, define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system, and distribute the corresponding basic data to each business system; The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

[0016] As a further solution, an annual dimension is added to the multi-tenant architecture, and tenant, organization, and user relationships under different business systems are constructed in different years. The user's entrance on the portal and the specific tenant or organization that can be jumped to through the entrance are determined by the current year and the corresponding multi-tenant architecture of that year.

[0017] Compared with the prior art, the present invention has the following beneficial effects: (1) The present invention expands the support of multi-tenant architecture in multiple business fields by abstracting the business dimensions of business system-tenant-organization-user-year, so that it can support large-scale enterprise group application scenarios with large-scale multi-business domain integration.

[0018] (2) The multi-tenant architecture of the present invention can split multiple tenants under each business system, and tenant splitting can be performed according to different standards under different business systems, thereby realizing a customized design of the multi-tenant architecture and meeting the tenant splitting requirements of different business systems.

[0019] (3) The master data management module of the present invention can define the dimensional relationship of basic data according to the annual, tenant, organization and user relationships under each business system, introduce the annual dimension, and adjust the business system relationship of each year based on actual conditions. It can solve practical application problems such as multiple business domains within large groups, frequent adjustments to organizational structures, and cross-year tenant transfers; and can support seamless connection of data before and after cross-tenant transfers.

[0020] Other features and advantages of additional aspects of the present invention will be given in part in the following description and in part will become obvious from the following description or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 Schematic diagram of a customizable multi-tenant management system integrating multiple business domains in an embodiment of the present invention; Figure 2 This is a schematic diagram of the relationship between the business system, tenant, organization, user, and year dimensions in an embodiment of the present invention; Figure 3 This is a schematic diagram of a business system identifier in an embodiment of the present invention; Figure 4 This is a schematic diagram of tenant identification in an embodiment of the present invention; Figure 5 Schematic diagram of various system entrances in the unified portal in an embodiment of the present invention. DETAILED DESCRIPTION

[0022] It should be noted that the following detailed description is illustrative and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used in the present invention have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0023] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0024] Example 1 In one or more embodiments, a customizable multi-tenant management system integrating multiple business domains is disclosed, combined with Figure 1 , specifically including: (1) Multi-tenant architecture is configured to define different business areas as different business systems. Under each business system, multiple tenants are divided according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. (2) The master data management module is configured to define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system within each year, and distribute the corresponding basic data to each business system; (3) A portal control module configured to implement user login operations and entry permission control. The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

[0025] In this embodiment, in the customizable multi-tenant management system with multi-business domain integration, "multi-business domain" means that the system architecture can be used to support multiple different business areas or business lines; "integration" emphasizes that the system architecture can integrate different business domains together, involving unified business domain management, data sharing and coordination, etc.; "customizable" means that the system architecture can be customized according to the specific needs of each business domain. Tenant splitting dimensions; "multi-tenant architecture" means that each business domain supports the multi-tenant mode.

[0026] As a specific implementation method, different business domains are abstracted into business system concepts, different business systems are isolated from each other, and HTTP (HyperText Transfer Protocol) or RPC (Remote Procedure Call) and other means are used for interaction.

[0027] Combine Figure 2Each business system can be divided into multiple tenant dimensions, and the standards for dividing dimensions are different according to different business systems. For example, different tenants can be divided according to different units in the budget business system, while different tenants can be divided according to different payment centers in the settlement business system. This allows customized tenant division to be achieved, avoiding the situation where multiple tenants are divided according to a unified standard, which results in a poor architecture applicability. Different organizations can be divided under each tenant, and each organization corresponds to different users. For example, different tenants can be divided according to different units in the budget business system, and each tenant can be divided into multiple departments, and each department corresponds to multiple users. Different tenants can be divided according to different payment centers in the settlement business system, and each tenant can be divided into multiple units, and each unit corresponds to multiple users. Therefore, different business systems in this embodiment can define their own system architecture according to different standards, achieve diversified dimensional relationship integration, and expand the support for multiple business fields based on the multi-tenant architecture, so that it can support large-scale group enterprise application scenarios with large volumes and multiple business domains.

[0028] In this embodiment, the business system is a core dimension in multi-tenant management, master data distribution, portal entry control, and permission control. For example, the unified portal displays the jump entries of multiple business domains, and whether the user can jump to each business domain entry is also determined by the relationship between the user and the business domain.

[0029] Combine Figure 3 Each business system corresponds to a unique identification code (i.e., business system ID), which is convenient for identification by the master data management module. Different business systems have different configurable parameters, which can be configured through system parameters. After the configuration is completed, the configuration parameter values ​​can be set for the objects included in the current system so that they can be used as needed in each business domain.

[0030] Similarly, combined Figure 4 When defining multiple tenants within each business system, a unique identifier (i.e., tenant ID) is assigned to each tenant. This identifier serves as the identification for subsequent master data distribution and portal access control. Each tenant uses an independent database instance strategy to ensure data isolation between tenants.

[0031] In a large enterprise, despite diverse business lines, there's often only one copy of master data. Organizational structure, user information, and other information are typically treated as foundational data (i.e., master data), shared across all business domains. The master data management system in this embodiment employs centralized foundational data management, responsible for synchronous distribution based on business system, tenant, organization, and user dimensions. The generation and maintenance of foundational data are managed by the master data management system, ensuring the uniqueness and consistency of internal foundational data.

[0032] The master data management system (MDM) is the core data hub within an enterprise. Within the architecture, it is responsible for synchronizing fundamental data with relevant systems such as business lines and portals. It also needs to be able to provide fundamental data externally. After system authorization and registration, external systems can also access relevant fundamental data from the MDM.

[0033] User data, as fundamental data, is maintained by the master data management system. This system distributes users to various systems and tenants, as well as to the portal control module. After establishing the concepts of business systems and tenants within these systems, the system-tenant-organization-user dimension is constructed. With this clear relationship, the user's portal entry point and the specific tenant they will be redirected to upon clicking on the entry point are also determined. The portal control module can then control user access permissions.

[0034] Figure 5 An example of a unified integrated portal is given, including entrances to different business systems; the portal control module not only supports access to business domain systems within the architecture, but also provides external access capabilities similar to the master data management system. It can support access by third-party systems after implementing single sign-on specifications, and supplemented by the open capabilities of the master data management system, so that the entire architecture has external access capabilities for third-party systems from the entrance to basic data.

[0035] In a multi-tenant architecture, data relationships within a tenant are typically stable and independent. However, in large-scale, complex enterprise applications, these relationships are not always static. For example, some business domains are well-suited to multi-tenancy based on organizational structure, but this structure can change and adapt. To address these changing scenarios, the "year" dimension is introduced to support the transfer of tenant relationships across years.

[0036] Combine Figure 2 In different years, tenant, organization, and user relationships are constructed for different business systems. The user's portal entry point and the specific tenant or organization they can jump to through this entry point are determined by the current year and the corresponding multi-tenant architecture. For example, in 2024, a user belongs to Organization 1 under Tenant A-1, but in 2025, the user is assigned to Organization 3 under Tenant A-2. When the user logs in to the portal in 2024 and 2025, they will jump to different tenants.

[0037] The difficulty in migrating cross-tenant relationships lies in the expansion of the underlying data dimensions, from the original business system-tenant-organization-user to the business system-tenant-organization-user-year dimension. Compared to the absence of the year dimension, the addition of the year dimension significantly impacts master data management and the unified portal. Master data distribution for the same organization's underlying data is no longer simply distributed to a single tenant; it may be distributed to multiple tenants. Furthermore, the unified portal no longer uniquely identifies the tenant when a user logs in and makes a single jump to the business domain. Therefore, the year relationship is required to identify the unique tenant.

[0038] In this embodiment, when performing a cross-tenant relationship transfer, it is first necessary to determine in which year and from which tenant the transfer needs to be made; the master data will generate different data dimension relationships in different years based on the tenant transfer relationship. For example, user 1 belongs to organization 1 in 2024 and transfers to organization 3 in 2025; the master data will distribute the organizational data of these different years to all related business systems; at the same time, the master data will also send this relationship to the portal control module. The portal control module will know which tenant the user belongs to in a certain year. When logging in and jumping to the business system, it can jump to different tenants according to this route.

[0039] The multi-business domain integrated customizable multi-tenant management system of this embodiment can provide highly customizable multi-tenant solutions for different business areas while maintaining the system's architectural consistency, efficiency, and high scalability.

[0040] As an optional implementation, this embodiment designs a dimension relationship time series log table to completely record the entire life cycle of all dimension relationships; the dimension relationship time series log table does not perform any update operations, nor does it require any dimension data migration, but only performs append operations. Traditional organizational relationships are often stored in a single table. Any "update" operation overwrites historical records, making it impossible to query the organizational status at a specific historical point in time. However, frequent changes in dimensional relationships are also a common business application requirement in enterprise business processing, such as operations such as business organization changes, reorganizations, and revocations. Therefore, the dimensional relationship time series log table of this embodiment makes all dimensional relationship changes traceable, meeting audit requirements. For example, you can query "If the organizational structure is positioned at the status on June 1st of last year, who are the people in Department A?" to provide data support for management decision-making. Table 1 shows an example of a dimensional relationship time series log table.

[0041] Table 1. Example of dimensional relationship time series log table

[0042] As a further implementation method, a dimension routing mapping cache mechanism is established based on the dimension relationship time series log table to solve the problem of fast data routing.

[0043] Specifically, as dimension relationships are adjusted, the data in the dimension relationship time series log table continues to grow. If the dimension relationship time series log table is queried every time a request arrives, it will lead to efficiency bottlenecks. To ensure millisecond-level knowledge of which database instance (for example, db_tenantA_2024) to connect to, this embodiment designs a dimension routing mapping cache mechanism. When a maintenance relationship in the business system changes, an event is triggered. The event processor queries the dimension relationship time series log table for all currently valid dimension relationships and constructs one or more Map objects in memory. These Map objects use user and year as keys and tenant ID as values, forming corresponding key-value pairs between user, year, and tenant.

[0044] In response to an API request, the system retrieves user and year dimension data, allowing it to directly query the corresponding tenant from memory. Using the dimension data as a key, the system directly queries the in-memory "dimension routing mapping cache," instantly obtaining the tenant ID corresponding to the dimension. Subsequent data access can be routed to the correct tenant based on the user and year.

[0045] This embodiment uses a dimension routing mapping cache mechanism to move complex database query operations to the cache construction stage, turning runtime routing decisions into memory queries with O(1) complexity, greatly improving routing performance.

[0046] Among them, API request refers to the data call instruction sent by the client (such as a browser, mobile application or server) to the API (Application Programming Interface) to obtain, submit or operate the resources of the remote server.

[0047] O(1) complexity means constant time complexity, that is, the time of an operation does not increase with the growth of the input size.

[0048] As a further implementation approach, as dimensional relationships continue to expand and adjust, their complexity increases, making aggregate queries more challenging. Existing techniques for answering questions like "Query all sales of tenant A in the fourth quarter of 2024" often start from the lowest level of sales records and trace back to their respective units, tenants, and business systems. This results in a large number of recursive queries and extremely poor performance.

[0049] This embodiment establishes a dimension path pre-calculation table. Table 2 shows an example of a specific data structure of the dimension path pre-calculation table.

[0050] Table 2 Example of dimension path pre-calculation table

[0051] The dimensional path generation and maintenance process is as follows: When dimensional relationships change or new business data is generated, index updates are triggered through asynchronous events. By querying the dimensional relationship time series log table, the complete dimensional path from the root (business system) to the leaf (user) is calculated and stored for each underlying data item. When aggregate queries are required, this index table can be directly used for efficient GROUP BY and LIKE operations.

[0052] GROUP BY is a grouping operation used to group query results by the values ​​of one or more columns. LIKE represents a fuzzy match and is used in the WHERE clause to search for strings that match a specific pattern.

[0053] This embodiment uses the dimension path pre-calculation table to convert complex recursive queries into simple string matching and join queries on the index table, greatly improving the performance of reporting and data analysis.

[0054] As a further implementation, based on the multi-tenant architecture of this embodiment, when a process task is generated, it first enters a temporary queue. An independent proxy dispatcher service consumes this queue and, based on the process instance ID in the workflow engine, queries the configuration dimension relationship time series log table for the current ownership of the process initiating organization. If the agent dispatcher finds that the tenant ownership has been transferred, it redirects the process task to the corresponding user in the new tenant based on the new dimension relationship. This decouples process execution from the real-time state of the organizational structure and, through an asynchronous proxy dispatch mechanism, responds to changes in the multi-tenant architecture's dimensions.

[0055] As a further implementation method, when performing cross-tenant transfer, how to effectively migrate the user's permission data under the original tenant is also a difficult problem; existing technologies often use the method of copying all or clearing all to transfer permissions. Copying all may cause data security risks (such as seeing data that the new tenant should not see); clearing all will lead to repeated permission configuration later, affecting operational efficiency. This embodiment introduces a permission attribute inheritance policy, defining an inheritance policy attribute for each permission. The inheritance policy attribute can specifically include the following forms: STRICT_TENANT: bound to a tenant and automatically invalidated after being transferred across tenants (for example, tenant A's financial report access rights); TRANSFERABLE: inherited when the tenant is transferred (for example, general OA system usage rights); READ_ONLY_LEGACY: After a cross-tenant transfer, read-only permission is retained for the original tenant's historical data (for example, viewing historical orders submitted when you were in Tenant A).

[0056] When a user accesses the system in a new tenant, the permission engine's calculation logic is: Obtain the user's direct permissions in the new tenant, search the original tenant from the configuration dimension relationship time series log table, and load the user's permissions in the original tenant with the attributes of TRANSFERABLE or READ_ONLY_LEGACY; merge these permissions in memory to form the user's current final effective permission set.

[0057] This not only ensures the data security of the new tenant, but also retains the user's necessary work permissions to the maximum extent, reducing the management cost after cross-tenant transfer.

[0058] In summary, the customizable multi-tenant management system with multi-business domain integration in this embodiment can optimize and expand the multi-tenant architecture model to support multi-business domain integration, customize tenant splitting dimensions for each business domain, integrate master data management and unified portal management, and include cross-tenant relationship transfer strategies, which can provide complete architectural method support for multi-tenant architecture in large-scale multi-business domain scenarios.

[0059] Example 2 In one or more embodiments, a customizable multi-tenant management method for integrating multiple business domains is disclosed, specifically comprising the following process: Define different business areas as different business systems. Within each business system, split multiple tenants according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. Within each year, define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system, and distribute the corresponding basic data to each business system; The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

[0060] As a further solution, an annual dimension is added to the multi-tenant architecture, and tenant, organization, and user relationships under different business systems are constructed in different years. The user's entrance on the portal and the specific tenant or organization that can be jumped to through the entrance are determined by the current year and the corresponding multi-tenant architecture of that year.

[0061] As a further solution, a dimension relationship time series log table is configured. The dimension relationship time series log table is configured to record all update operations of tenant, organization, user and year dimension relationships under each business system.

[0062] When a maintenance relationship under the business system changes, an event is triggered. The event processor queries all currently valid dimension relationships from the dimension relationship time series log table; and builds one or more Map objects in memory; the Map objects store the corresponding key-value pairs between users, years, and tenants; in response to the received API request, the user and year dimension data are obtained, and the corresponding tenants are directly queried from the memory.

[0063] As a further solution, a dimension path pre-calculation table is configured. The dimension path pre-calculation table calculates and stores the complete dimension relationship path for each underlying data. When the dimension relationship changes or new business data is generated, the index update is triggered by asynchronous events. When aggregate queries are required, the dimension path pre-calculation table is used to perform efficient GROUP BY and LIKE operations.

[0064] As a further solution, when a process task is generated, it first enters a temporary queue. An independent proxy distributor service consumes this queue and queries the current and latest ownership of the process initiating organization from the configuration dimension relationship time series log table based on the process instance ID in the workflow engine. If it is found that the tenant ownership has been transferred, the agent distributor redirects the process task to the corresponding user in the new tenant based on the new dimension relationship.

[0065] As a further solution, define an inheritance policy attribute for each permission, including: STRICT_TENANT: bound to a tenant and automatically invalidated after being transferred across tenants; TRANSFERABLE: Inherited when the tenant transfers; READ_ONLY_LEGACY: After a cross-tenant transfer, read-only permission is retained for the original tenant's historical data; When a user accesses the system in a new tenant, the permission engine's calculation logic is: Obtain the user's direct permissions in the new tenant, search the original tenant from the configuration dimension relationship time series log table, and load the user's permissions in the original tenant with the attributes of TRANSFERABLE or READ_ONLY_LEGACY; merge these permissions in memory to form the user's current final effective permission set.

[0066] It should be noted that the specific implementation of the above processes is exactly the same as that in Example 1 and will not be described in detail.

[0067] Although the above describes the specific embodiments of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without any creative work are still within the scope of protection of the present invention.

Claims

1. A customizable multi-tenant management system integrated with multiple business domains, characterized by: include: The multi-tenant architecture is configured to define different business areas as different business systems. Under each business system, multiple tenants are divided according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. The master data management module is configured to define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system within each year, and distribute the corresponding basic data to each business system; The portal control module is configured to implement user login operations and entry permission control. The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

2. A customizable multi-tenant management system integrated with multiple business domains according to claim 1, characterized in that: Each business system is configured with a unique system identifier, and each business system is isolated from each other; When defining multiple tenants under each business system, a unique identifier is configured for each tenant; each tenant uses an independent database instance strategy to ensure data isolation between tenants.

3. The multi-business domain integrated customizable multi-tenant management system according to claim 1, characterized in that: In the multi-tenant architecture, an annual dimension is added, and the tenant, organization, and user relationships under different business systems are constructed in different years. The user's entrance on the portal and the specific tenant or organization that can be jumped to through the entrance are determined by the current year and the corresponding multi-tenant architecture of that year.

4. The multi-business domain integrated customizable multi-tenant management system according to claim 1, characterized in that: Also includes: A dimension relationship time series log table is configured, where the dimension relationship time series log table is configured to record all update operations of tenant, organization, user, and year dimension relationships under each business system.

5. A customizable multi-tenant management system integrated with multiple business domains according to claim 4, characterized in that: When a maintenance relationship in the business system changes, an event is triggered. The event processor queries all currently valid dimension relationships from the dimension relationship time series log table. And build one or more Map objects in memory; The Map object stores the corresponding key-value pairs between users, years and tenants; In response to the received API request, the user and year dimension data are obtained and the corresponding tenant is directly queried from the memory.

6. The multi-business domain integrated customizable multi-tenant management system according to claim 1, characterized in that: Also includes: Configure a dimension path pre-calculation table, which calculates and stores a complete dimension relationship path for each underlying data; When dimension relationships change or new business data is generated, index updates are triggered through asynchronous events. When aggregate queries are required, dimension path pre-calculated tables are used to perform efficient GROUP BY and LIKE operations.

7. The multi-business domain integrated customizable multi-tenant management system according to claim 1, characterized in that: When a process task is generated, it first enters a temporary queue. An independent proxy dispatcher service consumes this queue and queries the latest ownership of the process initiating organization from the configuration dimension relationship time series log table based on the process instance ID. If it is found that the tenant ownership has been transferred, the agent distributor redirects the process task to the corresponding user in the new tenant based on the new dimension relationship.

8. A customizable multi-tenant management system integrated with multiple business domains according to claim 7, characterized in that: Define an inheritance policy attribute for each permission, including: STRICT_TENANT: bound to a tenant and automatically invalidated after being transferred across tenants; TRANSFERABLE: Inherited when the tenant transfers; READ_ONLY_LEGACY: After a cross-tenant transfer, read-only permission is retained for the original tenant's historical data; When a user accesses the system in a new tenant, the permission engine's calculation logic is: Obtain the user's direct permissions in the new tenant, search the original tenant from the configuration dimension relationship time series log table, and load the user's permissions in the original tenant with the attributes of TRANSFERABLE or READ_ONLY_LEGACY; merge these permissions in memory to form the user's current final effective permission set.

9. A customizable multi-tenant management method for multi-business domain integration, characterized in that: include: Define different business areas as different business systems. Within each business system, split multiple tenants according to different standards. Each tenant is divided into different organizations, and each organization corresponds to different users. Within each year, define the dimensional relationships of basic data according to the tenant, organization, and user relationships under each business system, and distribute the corresponding basic data to each business system; The user's entry on the portal and the specific tenant or organization that can be jumped to through the entry are determined by the multi-tenant architecture.

10. A customizable multi-tenant management method for multi-business domain integration according to claim 9, characterized in that: In the multi-tenant architecture, an annual dimension is added, and the tenant, organization, and user relationships under different business systems are constructed in different years. The user's entrance on the portal and the specific tenant or organization that can be jumped to through the entrance are determined by the current year and the corresponding multi-tenant architecture of that year.

Images