Dundas BI has built-in support for multi-tenant deployment scenarios allowing the solution provider to easily create and manage tenants (clients) which are isolated from each other under a single deployment. This is different from a standard instance which is used when the application deployment serves internal users within the organization with no need for complete isolation between users. The most common use case where a multi-tenant instance is required is for a SaaS solution provider who wants to enhance his software BI and analytics capabilities by integrating Dundas BI into it (Hosted OEM/ISV scenario). There are other cases where a multi-tenant instance may be beneficial such as a deployment of a client facing portal or a large internal deployment that requires complete isolation between different department/lines of business.
2. Multi-tenant Instance
A multi-tenant instance is used when the application deployment is done for external users who shouldn’t know about the existence of other users using the same system. It allows the solution provider to install and maintain one application of Dundas BI across all their clients (Tenants). For example, a client facing analytics portal where each client (or users from the same client) are not supposed to see data of other clients.
A simple multi-tenancy structure would be when each tenant (client) have their own database, but the solution provider hosts only one instance of Dundas BI. Assuming the database structure is the same across all tenants, Dundas BI allows you to create a single set of dashboards and reports and reuse it across all the tenants without having to maintain a copy per tenant. Reusing the same setup even when there are many database involved is possible when using the data connection override functionality. This allows the administrator to define the appropriate connection to the tenant database and leverage that when a tenant user uses the system. That way each tenant can view the application customized with their own data and the administrator has a single setup to do.
The same concept of reusing the same copy of dashboards and reports can be done even if the different tenants’ data is stored in a single database. In that case, the data of each tenant will be identified by a Tenant ID or a similar field and will be secured using custom attributes or provider security options like SSAS cubes role impersonation if the data source is an OLAP cube.
3. Advantages of a multi-tenant Instance
- Access security and isolation – Every tenant user can only see objects (i.e. dashboards) his tenant is allowed to see. Any object created by a tenant user will not be visible to users that belong to other tenants thus creating a complete separation between users from different tenants. In addition, users that belong to a certain tenant can only see users that belong to the same tenant. This is important when they share an analysis ensuring they cannot see users that belong to other tenants (regardless of the fact that those don’t even have access to that analysis to begin with).
- Commercial alignment and Licensing Control – Specific allocation of licenses count per tenant allows multi-tenant solution providers to match their different tenant’s licenses need. This is important in cases that the tenant buys licenses for their own users, hence ensuring that the licenses are not shared across all tenants but used specifically by the tenant that purchased those. This can allow SaaS provider to monetize their analytics solution by selling specific licenses (i.e. power user licenses) to their tenants.
- Data security – Multi-tenant deployments allow to use dynamic data connections by overriding them. This option should be used in the case where every tenant has its own database but the same database structure is being used across all tenants. When the tenants share the same database but should see only their own data, then custom attributes can be used for data security. Both of these data security options, allow the solution provider to create a single set of dashboards for all tenants and thus reducing the maintenance required.
4. Adding a new user account to a Tenant
Tenant administrators have the ability to add new accounts to the tenant and assign available license seats to those accounts. The membership of the Tenant Administrators group can be edited from the Groups list under Account Service.
To add a new account to the tenant, go to the Admin screen, expand Account Service and click Accounts. Add a new account and set its tenant field to an existing tenant name.
5. Content sharing between tenants
Content can be shared by different tenants only when created by a user that isn’t associated with any tenant. The content will typically by located in the global project but can also exist in other projects as long as the tenant members have at least read access to it. The benefit of using a shared project comes into play when multiple tenants have a similar dashboard structure with the same or different data. This ensures that the solution provider does not have to replicate the efforts across all tenants.
6. See Also
- Using tenant data connector overrides
- Dundas BI Licensing
- Using custom attributes to filter data by user
- Using SSAS Roles Impersonation
- Using custom attributes and custom data to filter SSAS data
- Customize branding for each Tenant