& Lt; ABP documentation

<ABP document, abp document

Document directory

 

Content of this section:

• What is multi-tenant
  • Multi-deployment-multi-database
  • Single deployment-multiple databases
  • Single deployment-single database
  • Single deployment-hybrid Database
  • Multi-deployment-single/Multi-mixed Database
• Multi-tenant
  • Enable multi-tenant
  • Host and tenant
  • Session
  • Data Filtering
    • IMustHaveTenant Interface
    • IMayHaveTenant Interface
    • Supplemental reminder
  • Switch between the host and tenant

 

What is multi-tenant

Wikipedia: "software multi-tenant is a software architecture. Only one instance of the software runs on the server and serves multiple tenants. A tenant contains a group of users who have the specified permissions to access a software instance. In a multi-tenant architecture, applications provide each tenant with a unique data, configuration, user management, and tenant-specific function and attribute. The multi-tenant architecture is abstracted from the Multi-instance framework. The multi-instance architecture regards each instance as a tenant. "

Multiple tenants are usually used to create Saas (software as a service) Applications (cloud computing ). Multi-tenant architecture:

 

Multi-deployment-multi-database

This is not actually multi-tenant. However, if we run an instance of an application for each customer (Tenant) and use an independent database, then we can serve multiple tenants on one server. We only need to ensure that multiple instances of the application do not conflict with each other in one server environment.

It is designed for an application that is not designed for multiple tenants but is already running, providing the possibility. This method makes it easier to create an application without considering multiple tenants, but it has some problems in installation, use and maintenance.

 

Single deployment-multiple databases

In this way, we run a single instance of an application on a server. We have a master (host) database to store tenant metadata (such as tenant names and subdomains ), maintain an isolated database for each tenant. Once we identify the current tenant (for example, from a subdomain or from a user login form), we will switch to the tenant's database for operations.

In this way, we should design an application as a multi-tenant at some level, but most of the applications do not depend on the Multi-tenant.

We should create and maintain an isolated database for each tenant, including data migration. If we have multiple tenants, we need to maintain their proprietary databases. When the application is updated, it may take a long time to migrate the database structure. Because we have isolated databases from tenants, we can back up our own databases separately. At the same tenant requirement, we can also move the tenant database to a more powerful server.

 

Single deployment-single database

This is the most pure multi-tenant architecture: We only deploy a single instance and a single database of the application on one server. We use a TenantId (Tenant Id or similar) Field in each table (Relational Database) to differentiate and isolate each tenant's data.

This method is easy to install and maintain, but it is difficult to create such an application, because we must prevent one tenant from reading or writing data from other tenants. We have to add TenantId for each database read (select) operation to filter. Similarly, we also check whether the current entity is related to the current tenant every time we write data to the database, which is tedious and error-prone. However, TTL automatically uses data filtering technology to solve these problems.

This method may cause performance problems when there are many tenants and large data volumes. We can use table partitions or other database features to solve this problem.

 

Single deployment-hybrid Database

We may want to store tenant data to a database, but we want to create a separate database for tenants who need it. For example, we can store tenant big data to their respective databases, but all others are saved to another database.

 

Multi-deployment-single/Multi-mixed Database

Finally, we may want to deploy our applications to multiple servers (such as distributed server clusters) for better performance, practicality, and scalability. This is a database-dependent approach.

 

Multi-tenant

This can be used in the scenario described above.

 

Enable multi-tenant

Multi-tenant is disabled by default. We can enable it in PreInitialize of our module, as shown below:

Configuration.MultiTenancy.IsEnabled = true; 

 

Host and tenant

First, we need to define two terms in a multi-tenant system:

• Tenant (Tenant): a customer who has multiple users, roles, licenses, and settings must use this application independently. A multi-tenant application may have multiple tenants. Each tenant has its own account, contacts, products, and others. So when we say "Tenant user", it indicates a user under a Tenant.
• Host: the Host is a singleton (just a Host). This Host is responsible for creating and managing tenants, so "Host user" has a higher level, independent from tenants and able to control tenants.

 

Session)

The ABP defines the IAbpSession interface, which is used to obtain the user and tenant ids (tenant Id ). This interface obtains the current tenant Id by default in a multi-tenant system, so it can filter data based on the tenant Id. There are the following rules:

• If the user Id and tenant Id are both null, the current user has not logged on to the system, so we do not know whether it is a host user or a tenant user. In this case, the user cannot access the content to be authorized.
• If the user Id is not null and the tenant Id is null, we can know that the current user is the host user.
• If the user Id is not null and the tenant Id is not null, we can know that the current user is a tenant user.

View the session document for more information.

 

Data Filtering

In the multi-tenant single database mode, we must add a TenantId (Tenant Id) filter to obtain only the entity of the current tenant from the database. When your entity implements one of the IMustHaveTenant and ImayHaveTenant interfaces, abcwill automatically do this.

 

IMustHaveTenant Interface

This interface identifies entities for different tenants by defining the TenantId attribute. As shown below, an entity implements IMustHaveTenant:

public class Product : Entity, IMustHaveTenant{    public int TenantId { get; set; }    public string Name { get; set; }    //...other properties}

Therefore, the ABP knows that this is the entity of a specific tenant and is automatically separated from the entity of other tenants.

 

IMayHaveTenant Interface

We sometimes need to share an entity between the host and the tenant, so an entity may be the host or tenant. The IMayHaveTenant interface also defines the TenantId attribute (similar to IMustHaveTenant), but it is nullable (can be empty ). As shown below, an entity implements IMayHaveTenant:

public class Role : Entity, IMayHaveTenant{    public int? TenantId { get; set; }    public string RoleName { get; set; }    //...other properties}

We can use two role classes to store the host and tenant roles. In this case, the TenantId attribute is used to distinguish whether the host or tenant entity is the same. If it is null, This is a host entity. Otherwise, it is a tenant entity and its value is the tenant Id.

 

Note:

IMayHaveTenant is not as common as IMustHaveTenant. For example, a Product class cannot be IMayHaveTenant, because it is related to application functions rather than tenant management. Therefore, you must be especially careful when using the IMayHaveTenant interface. After all, it is difficult to maintain the code shared with the host and the tenant.

When you define an object type as IMustHaveTenant or IMayHaveTenant, you should specify TenantId when creating a new object (although the ABP will try to assign the current TenantId to it, but in some cases it will not succeed, especially when IMayHaveTenant is used ). In most cases, this TenantId attribute is the only point that needs to be processed. When you write a code in LINQ, you do not need to explicitly write the TenantId filter in the where condition because it will be automatically filtered.

 

Switch between the host and tenant

On the multi-tenant application database, we should know the current tenant. By default, it can be obtained from IAbpSession (as described earlier ). However, we can change this behavior to another tenant's database, for example:

public class ProductService : ITransientDependency{    private readonly IRepository<Product> _productRepository;    private readonly IUnitOfWorkManager _unitOfWorkManager;    public ProductService(IRepository<Product> productRepository, IUnitOfWorkManager unitOfWorkManager)    {        _productRepository = productRepository;        _unitOfWorkManager = unitOfWorkManager;    }    [UnitOfWork]    public virtual List<Product> GetProducts(int tenantId)    {        using (_unitOfWorkManager.Current.SetTenantId(tenantId))        {            return _productRepository.GetAllList();        }    }}

SetTenantId: Make sure that we work on the data of a given tenant. The acquisition method depends on the database:

• If a given tenant has a specific database, it switches to the database to obtain the product.
• If the given Tenant does not have a specific database (for example, the single database mode), it automatically adds TenantId to the query and obtains only the products of the given tenant.

If SetTenantId is not used, as mentioned above, TenantId will be obtained from the session. Here are some reminders and best practices:

• Use SetTenantId (null) to switch to the host.
• If there are no special cases, use SetTenantId in the using block as in the example, because it will automatically restore the value of TenantId after the block, the code that calls the GetProducts method also works as before the call.
• If necessary, you can use SetTenantId nested in the block.
• Since _ unitOfWorkManger. Current is only available in the same unit of work, make sure that your code runs in the same unit of work.