How to implement multi-tenancy
It is often required that the same application is hosted for different “tenants”. A tenant logs into the system and only sees data that belongs to him, but not other tenants.
There are two approaches in Aware IM on how this can be implemented:
- Each tenant has a separate business space allocated to the tenant and the same application is loaded into each business space
- All tenants are managed by the same business space and the application itself is defined in such a way that each tenant’s data is protected from another tenant
There are pros and cons in both approaches, so the approach you should take depends on your specific requirements.
The advantage of the first approach is that each tenant is completely independent from each other because each business space is totally separate from another one. Moreover, you can allocate a separate database to each business space, so that the data of each tenant is stored in its own database. The application is simpler because there is nothing in it that refers to tenants. Data backup can be done on a tenant-by-tenant basis and a data problem in one tenant doesn’t affect another tenants.
The disadvantage of the first approach is that if there are thousands of tenants, existence of thousands of business spaces can significantly impact the performance of the server (however, you can add more servers to alleviate the problem). Another disadvantage is that if your applications needs functionality that works across different tenants – for example, if you want to collect statistics about your tenants, look at all registered tenants etc, it may be hard to do if all your tenants are independent applications.
Advantages and disadvantages of the second approach are reverse of that of the first one. The second approach may not depend as much on the larger number of tenants as the first approach and it’s also quite easy to provide functionality that looks across different tenants. But the application itself becomes more complicated and it is a lot more difficult to provide backup/restore on a tenant-by-tenant basis (but not impossible).
The following paragraph describes what needs to be done in the application to implement the second approach. This is what you need to do:
- Define an object representing a Tenant
- For all objects that belong to the tenant add a reference to the Tenant that it belongs to, for example
Account.Tenant - The user object must have a reference to Tenant that it operates on behalf of -
LoggedInSystemUser.Tenant - For each object that belongs to some tenant add rules to initialise tenant from the tenant of the logged in user that created the object, for example:
IF Account.Tenant IS UNDEFINED THEN Account.Tenant = LoggedInSystemUser.Tenant
- Finally add protection rules to the object that belong to the tenant so that other tenants do not see it, for example:
IF Account.Tenant <> LoggedInSystemUser.Tenant THEN READ PROTECT Account FROM ALL EXCEPT System