Disclaimer: My personal opinion 🙂
These times are very interesting when it comes to generating and utilizing data. Nowadays we are pushing the boundaries of data analytics from read-only into actionable – thanks to write-back, notifications, and many more add-ons and features.
Let’s talk about the write-back since it’s quite special and doesn’t have a long history in Qlik Sense environment. Write-back is about entering and storing data by users directly from the app somewhere. It’s a completely new stream. Without the write-back users are only consumers of the data in their apps. With it, we are changing the paradigm and switch from a one-way to a two-way road. And watching the amount of data, I would say it’s a highway in both directions now :).
Where is “somewhere”?
Write-back is about entering and storing data by users directly from the app somewhere. I used the word “somewhere” on purpose. For end-user, data storage should be irrelevant. If you use a good extension or add-on the write-back is a seamless process for your users and it doesn’t matter where the data is technically stored.
When you start discussions with developers and architects, data storage is a very important topic. There are three main categories when it comes to a data storage type for write-back:
Apache Hive, MySQL, MariaDB, MS SQL, Oracle, PostgreSQL, Snowflake…
txt, xml, html, csv…
Zoho, Jira,…
Why QVD
As I mentioned, the topic of data storage is open in discussions with developers and architects mostly. Those are people who work with Qlik or at least know the technology from their own environment. QVD is a native format developed by Qlik for storing the data. So, it’s natural, they’re asking about the possibility to write-back data into QVDs.
Why not QVD
Yes, QVD is a file format developed and optimized by Qlik in many years… BUT it’s a file format developed and optimized for:
– storing data from Qlik during the reload of the app
– loading data into Qlik during the reload of the app
So, here is the question – do you think it would be a good choice to use it for a process that’s not realized during the reload of the Qlik app? I have a clear opinion. No. And here are my reasons:
When you have QVDs on your server, they’re very often used for storing collected and transformed data from different data sources. It’s generated based on predefined and documented (at least notes in the script ;)) algorithms. If any user can change the data in the QVD “manually” from the app, would you trust the data? How would you know there are/aren’t modifications in a QVD not corresponding to the available documentation or algorithms defined by regulators? Yes, it can be managed by good architecture and permissions management… or you can avoid this risk and choose a different write-back data storage.
Based on the point above – if you manually change the QVD generated by a Qlik process… during the next reload, your changes will be rewritten. Yes, you can then correct it again… and again… and again… When using a different data storage for a write-back, developers and architects are lead to implement a process of inclusion manual inputs into current processes – based on rules, agreements, and internal policy.
If you use a DB table for storing data from your write-back, you can set the DB to generate the full changelog within the table. If you use XML file (example for Inphinity Forms), the changelog is generated automatically. You always have the information about the user, date and time of change and what’s also very important – what value/data was there before! It’s a big advantage in comparison with spreadsheets. Why not have it?
Yes, I like Qlik! 🙂 But these days one doesn’t want to be locked by a single technology. Let’s imagine the world where you can save some data from your Qlik Sense app and have it in your CRM, ERP or any other system. Don’t you want to change the data directly there because of security? No problem, there’s still an option how to import data into systems like these – at least if it’s in a readable format…
How many different tools and windows do you open each day? There are so many possibilities of integration in many different systems. One could be creative and design the process that’s optimized and both systems, Qlik and your CRM or some other tool, will use the same data storage. Thanks to it, all data there will be always up to date without any synchronization tasks… There is only one general requirement – data should be stored in a format that can be used by tools other than Qlik…
When I have a discussion about data storages supported by Inphinity Forms, my answer to the QVD question is the following: “We can do it. If it’s very important to you, just let us know. But there are some reasons why I don’t think it’s a good idea…” And the discussion starts 😉.
It’s absolutely natural to ask whether QVD is a supported format for the write-back. However, before choosing it just think about the points above.
