A key desirable system characteristic of SaaS systems is multi-tenancy, which refers to hosting multiple virtually independent customers in a single shared infrastructure in a cost effective manner.
Multi-tenant deployments can be created since BOE XI 3.1, but the effort to operate such systems had a very high total cost of ownership. In many multi-tenant SaaS systems, each tenant is set up in the same way, or using a common base with slight customization. Hence the operation cost can be minimized by standardization and sharing of technical objects.
In BI4.0 SP4 a command line tenant onboarding was introduced to streamline and automate common operations pertaining to multi-tenant BI System. The tool focuses on tenant onboarding and BI contents management. Its goal is to reduce manual work by enabling automation without lot of low level programming, hence saving time and making the onboarding process less prone to human mistake.
As mentioned above tenants in a multi-tenants system have structural similarity. A tenant template can serve as model to manage tenants in a well defined and repeatable manner. The following objects and structural elements make up a tenant template
- User Groups
- BI Documents
- Security Setting
In order to use the onboarding tool you need to set up a tenant template using standard tools such as the Central Management Console (CMC), Report designers, Universe designer, ect. Once the template has been set up you run the command line tool to add a new tenant.
The operations that can be automated by the tenant provisioning tool are:
- Creating user groups
- Creating folders
- Setting ACL (Access Control List) on folders
- Copying documents and universes from template folder to individual tenant folder
- Adding universe restrictions for UNV (as of BI 4.0 SP4) and single source UNX (as of BI4.1)
- Creating connections
As mentioned above one has to create a tenant template first. The template consists of user groups, folders, ACLs, reports, universes, connections and so on. A tenant template token (e.g. $Tenant_Template$) should be used as prefix for at least tenant root folders and root user groups. The token can be any string, but it has to be consistent for the entire template. At onboarding time when creating tenant specific objects, this tenant template token will be replaced with the tenant name. Each template folder may contains a number of documents. Note the template token is only required for the root folders. Your tenant template should contain template user groups. Best practice is to have one root tenant template user group which includes the tenant template token as prefix. Do not include users in your tenant template as otherwise these will automatically become tenant users as well!
Before running the onboarding tool, you need to write a tenant template definition file. The tenant template definition file describes the location of tenant template, and specifies run time options such as tenant name, which folders belong to the tenant, what are the new database connections that the tenant is using and so on. The <EnterpriseDir>\java\apps\multitenancyManager\jars folder contains a sample definition file, that explains the different options. It is recommended to have one definition file per tenant.
Next you run the tenant provisioning tool in the command prompt; -jar multitenancymanager.jar –configFile tenant_template_def.properties
When running the tool it will create all the content that you set up in the definition file.
After running the tool you can view the tenant’s content in the CMC. In the image below you see that CompanyABC content was created. Note that the tenant template token $Tenant_Template$ was used to identify the template and for the new tenant’s content the token was replaced with the tenant’s name CompanyABC
After a tenant is created, the template content (documents, universe, connection) can still undergo changes. For example, if new stock BI documents are made available to tenants, or changes are made to stock BI documents or universe. Rerunning the command line tool with the same tenant definition file will provision the tenant and make the changes available to the tenant. The tool, however, does not handle the situation where a content copied to the tenant is modified by the tenant itself as well as by the central provider. In this case the tool would not attempt any merging of changes from two paths.
An additional feature in the BI4.1 release is that Tenants which were onboarded via the tenant onboarding command line tool are now visible in a new Multitenancy tab in the CMC. If you onboarded the tenant with BI4.0 SP4 then you need to rerun the tool on the BI4.1 again before you can see the tenant in the Multitenancy tab.
In 4.1. you also have the ability to change tenant properties such as tenant name, concurrent user limit and associated user groups.
From the Multitenancy tab you also have the option to delete a tenant and its entire associate objects with the option to excuse certain objects.
The last feature added in BI 4.1 is that in the user/user group tab you will also be able to see which user or user group belongs to which tenant.
More infromation can be found in the Business Intelligence Platform Multitenancy Guide
General best practices for multitenancy and shared services can be found in my Best Practices for BI 4.x Shared Service Deployments blog post.