Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi Guys,
I have recently joined QDF and have extracted Admin & Shared container on my local machine.
I have some simple questions regarding best practices
About the current Architecture :
How do we best manage the process ?
Your ideas and feedback will be highly appreciated.
Thanks
Hi Lokesh, good questions. Here is a thread that might fit your environment well How to set up DTAP in small environments
Hope that this helps.
Regards
Magnus
Read more in the:
Connection strings are a security credential and should always reside in the architecture Back end, in the data tier. Well protected from unauthorized access. Remember that architecture front-end (QlikView Server and QlikView Web Server) does not have any open ports the back-end, these servers could be in different network zones and security boundaries. When distributing QlikView applications via the Publisher in Back end to the application tier, scripts and connection strings will automatically be removed.
By separating the connection string from the script reusability and higher security will be achieved.
There are two ways to separate and reuse the connection strings:
Best practice is to keep the connection strings in a separate Include file. This behavior is supported by Deployment Framework. Use the Global Variable vG.ConnStringPath to connect inside your container, example:
// Connection string to Northwind Access data source
$(Must_Include=$(vG.ConnStringPath)\0.example_access_northwind.qvs);
If the connection string is in another container, for example the Shared folders use the Global Variable vG.SharedConnStringPath to connect, example:
// Connection string to Northwind Access data source
$(Must_Include Include=$(vG.SharedConnStringPath)\0.example_access_northwind.qvs);
Recommendation is to use Must_Include so that the Qlik script fails if include script is missing.
QlikView infrastructure without a Publisher license does not have a Back End. The Source documents are loaded with a simple reload engine that is bundled with QlikView Server. This solution works fine with smaller installations, and in development and test environments. In a production environment QlikTech recommends the Publisher and Back End/ Front End separation.
Without a Publisher there is no Source Document structure in QlikView. Instead the Containers need to be mounted directly in the QlikView Servers User Document structure.
When not using a Publisher file system security on the containers will reflect into AccessPoint and QlikView Server, this is not a good behavior. Therefore it’s important to add two mounted folders for every container:
Example: Name 0.Administration_1.Application Path c:\QV-Docs\userdocs_test\0.Administration\1.Application Browsable enable.
A container that only is used for reloading and not for end user presentation do not need the second mount (to the 1.Application folder) it’s very important that Browsable is disabled.
Do not uncheck the setting Respect browsable flag on mount in QlikView Web Servers settings. This will disable the Browsable functionality in QlikView Server Mount Settings.
Creating a reload task with no publisher is quite straight forward. Remember that without a Publisher license only scheduled reloads is possible.
Start QlikView Management Console (QMC) and click on the Documents Tab. Select the (User Document) container and QlikView Document that needs to be reloaded and add schedule in the right pane.
Thank you Magnus,
Pleas forgive my ignorance but I found QDF little confusing (may be lack of my experience) but anyways, I have created my own custom QDF inspired by the original QDF.
I have simplified my version to be very straight forward and useful for small teams without publishers.
I have also incorporated source control for the entire QDF which helps a lot to version control each and every aspect of the QDF (Include scripts, expressions, variables, load scripts and QVWs)
I have also created custom Octopus Deployment too which will automatically deploy everything from dev to test to UAT to production.
I will be sharing my solution here this weekend and would love to get feedback.
That sounds great Lokesh, the idea with a framework is that you can take the pieces needed for you and leave the rest. Especially as the framework is designed with the Publisher in mind from the beginning.
Regards
Magnus
I agree and I think its great when you are big organisation and have multiple data sources. But i also think its bit too much when you have single data source like in my instance. I will update you when post my version. Thank you for taking time in replying my question.
Hi Lokesh,
Would you be able to share your solution on version control on each aspect of QDF and how the DTAP work for all these?
Thanks!