The multi layer qvd architecture is the good approach to empower the end-user with an accurate, trustable and reliable Single Source of Truth.
This this context binary loads are a critical part of the approach. They allow the power user to easily access to the proper Data Model while the Data Team can maintain the whole architecture and provide high data quality.
In Sense it is possible to use binary load with qvf and qvw
For example, with the desktop version:
This will binary load “My Data Model.qvf” located on the C drive under “Qlik Apps”.
With Qlik Sense Enterprise, this approach will not work. For security reason it is required in Qlik Sense Enterprise to access files using a “Folder Data Connection”
Using the previous example and assuming that we have defined a Folder Data Connection “Qlik Apps” which point to “C:\Qlik Apps” then the proper binary load script would be:
Binary [lib://Qlik Apps/My Data Model.qvf];
Therefore the question would be, “how can I export into qvf the apps of my Data Model layer when the scheduled reload is finished?”.
Actually, nothing in Sense allows you to do that but you actually not need it.
However in Sense Enterprise you can use the app uuid to reference an app. In fact the app is stored in the working directory of the sense server using a qvf named with the app's uuid (without extension).
In this example, the app “Data Model – Example” has the uuid 193dc96e-0f97-4184-aa76-1a2c08853f4f and is stored in the Sense working directory in a file named 193dc96e-0f97-4184-aa76-1a2c08853f4f
Assuming that an administrator creates a Folder Data Connection named “Apps” which points to the Working Directory of the Qlik Sense server, then the following binary load work:
That works but is an unsecured solution as it gives access to all the apps for every user who have access to that particular Data Connection. This should not be used in a production environment.
Simply by using a Folder Data Connection which point directly to the app itself.
Creating one Data Connection per Data Model, provides a granularity fine enough to easily manage who have access to which Data Model. The Data Model app can then be published in a stream which is only available to the Data Team and refreshed using the standard task management, and the Data Connection gives access to the Data Model app, whiout having to give access to the app it self.
Moreover, thanks to Qlik Sense Enterprise architecture, the app will be sync automatically to all nodes of the cluster.
*Notes: My Working Directory is “D:\Apps”. As this is a “global” connection I usually remove the name of the owner from the connection name.
Binary [lib://Data Model - Example];
I saw an article recommending an App generating a set of QVDs rather because of risks with BINARY load of a QVF. I can't find the doc but my recall is that it is because Qlik Sense Enterprise might spread one single App over multiple physical QVF files... if this is true, this BINARY load method would fail?
There is a difference between using QVDs and Binary load. Qvd only store one table, while binary load allows you to load directly a full Data Model (and the Data).
In fact in a multi-layer architecture you do both: You start by building QVDs (Extraction and transformation) and then you combine them in to a Data Model, which is use as source for the binary load.
As a warning, this isn't supported due to the risk for file corruption and/or other weirdness by the Engine if it is trying to simultaneously read from and write to an app.
Agree with Levi, And a side note using the Index functionality in the framework you can with ease load in a data model based on qvd's with a single command.
The documentation state that the binary load of Qlik Sense application are supported and you can read them directly from the "Working Directory" (ie the "Apps" directory).
Here I'm only suggesting to alias the application itself instead of sharing the whole working directory, giving the administrator a full control of the access rights
The basics of the index functionality is described in the Qlik Deployment Framework Development Guide page 27.