Hi Paul,
Like multi-tenancy, the response to this question has many layers and many different strategies one can employ in an implementation.
Let's start with the method you mentioned first:
Load all data into an app and use Section Access to manage access to the correct rows and columns.
Yes, you can load all of the data from your data warehouse into a Qlik application and then use Section Access to manage row level reduction when different tenants enter to see only the data they are supposed to. The upside is this method is relatively straightforward to implement. The downside is that when a user enters the app, their session RAM footprint remains representative of the entire dataset, and the reduction takes place after the user session is created. Consequently, more RAM is utilized per session on data the user will never see because Section Access reduces it. I am not a proponent of this method in multi-tenant deployments.
Create a template of the application. For each tenant, host a copy of the application with their specific data. Use Section Access to control data access at the user level if required.
This is the method I used when I worked for an OEM partner with QlikView. The concept is similar with Qlik Sense, and greater automation opportunities exist with Qlik Sense because of the Qlik Sense Repository Service API (QRS). In this approach, for each tenant you duplicate the app, create a stream for the app applying security rules to allow only the specific tenant entry to their stream. This capability can be accomplished with ONE security rule assigned to evaluate a user attribute representing the tenantID. In addition, create a task for reload and any other subsequent tenant/app specific requirements.
As for the data model, using variables it's possible to control where data is loaded from and what tenant data is loaded into the application.
From a deployment and performance perspective, I prefer this method because it segregates tenant data at the application level, therefore, the overall RAM footprint for each app is less and subsequent user session RAM footprint is smaller because users have a representation of the dataset for their tenant.
There are most certainly more ways to approach this topic, however, what you want to consider is balancing what the user gets relative to what the user needs against what/how you want to build the infrastructure to support it.
I hope this is helpful.
Please mark the appropriate replies as CORRECT / HELPFUL so our team and other members know that your question(s) has been answered to your satisfaction.
Cheers,
Jeff G
