Key Differences Between Planning for Qlik Sense and QlikView
What are the key differences between planning the data-flow and app (qvw/qvf) architecture for Qlik Sense vs Qlik Sense? This is an important question that clients with large QlikView implementations with many apps and many users are asking as they investigate a migration from QlikView to Qlik Sense.
To start, there are three high level areas to consider; file and folder structures, data load capabilities and data-flow, and finally application security.
File and Folder Structures: n-Tier architectures are very common in QlikView with developers separating their QlikView QVW's and their QVD's into multiple tiers, breaking out extracts, transforms, data-models, and front-end applications (QVW files) into separate folders. However, in Qlik Sense all of the QVF files (the Qlik Sense equivalent to a QVW) are stored in one central location and the files on disk are not named by the user. Instead, the Qlik Sense server gives each QVF a unique ID(GUID) as its name and application title is nothing more than another attribute of the file. Because of this, you no longer have the capability to organize Qlik apps into different folders and only create folder structures for your flat file inputs and flat file outputs, most of which are QVD files. To organize your Qlik apps you will have to utilize Streams and secure them by managing Sense security rules and Sense user roles. One key thing to keep in mind here is that Streams do not have sub-streams or sub-folders, so all of the apps you place into a Stream in Qlik Sense are essentially in the same organizational unit. To differentiate them further you will need to use tags or custom properties.
Data Load Capabilities and Data-Flow: Building upon the n-tier architecture topic mentioned above one common tier is to create "data-model" applications that simply load in multiple raw and transformed data tables to create a model for analysis. That application can then be loaded into one or more "data-model" applications, or into one or more "front-end" applications. This is done to reduce the overall load time of applications that have very similar schema's and share common data elements. While binary loads are still possible in Qlik Sense, this becomes less desirable as the file names referenced in the load statements are cryptic ID's, and not meaningful to those reading and writing them. This also creates challenges in coding and troubleshooting these load statements. Instead, we recommend taking common segments of the load script and converting them to external includes. This facilitates ease of maintenance and time-to-value during development. The second concern when it comes to data-load capabilities and data-flow is the fact that Qlik Sense does not have a Publisher like equivalent for advanced task scheduling. This means that while Qlik Sense does support the creation and automation of reload tasks, it does not have the same "Loop and Reduce" or "Loop and Distribute" capabilities. Without Publisher, Qlik Sense also lacks the concept of supporting tasks out of the box, which could be used to call external files and do many useful things such as deleting "done files" or removing temp QVD file outputs.
Application Security: When it comes to Section Access for application, row, or column level application security, Qlik Sense has a few key differences in its approach. In QlikView, administrators often control app security by managing the file permissions on the QVW file itself, using Active Directory (AD) groups. If a windows user has read permissions for the QVW on disk, then the windows user can see and open the Qlik dashboard in the Access Point. This is very different in Qlik Sense. To start, a windows user's individual account privileges to the application file itself no longer matter. Instead, the Qlik Sense server determines based on its rules engine if a user has access to a Stream and all of the applications contained within. The rules engine is fortunately very robust and allows for the use of either custom roles defined in the Qlik Management Console (QMC) or AD (or other Directory Service providers) groups to control security. The most challenging aspects of managing security in Qlik Sense is the lack of denial based permissions. Instead, everything is permit based only. Meaning that once an action is permitted against an object based on one rule, it can not be removed by another rule. It can also be difficult to override Qlik Sense's default security behavior and do things like remove access to one particular application in a stream where the user has already been granted access to the stream containing the application. On a final note when planning your Qlik Sense security think about the following items and how they relate to one another; users, AD groups, roles, rules, Streams, applications, and custom properties (note: custom properties can be referenced in rule definitions but tags cannot).
There are other considerations when planning the technical architecture such as multi-node considerations. Please contact us
if you have any questions regarding your QlikView or Qlik Sense architecture.