One of the new features in QlikView 9 is “Export Document Layout”. Despite the name, the entire application without data is exported to XML: script, layout, embedded images, everything!
I exported the blank “New” document to XML. Click here to see what it looks like in XML.
Why add XML export? One of the big-picture features that was missing from QlikView is support for version control. By using XML as the storage format you can use standard version control products and produce accurate differentials.
But now that QlikView has embraced an open file format, there are so many more things we can do…
Track Metadata in Large Deployments
Some QlikView deployments have many HUNDREDS of QVW files. Someone is probably over 1000 by now. These are unique apps; not the result of Publisher distribution loops. It’s a tedious task to manage metadata when it’s locked inside a proprietary file format.
Which apps use the [Salesman] field? Which apps have expressions that fail to multiply [Revenue] by the [Exchange Rate]? Use a tool like Rob Wunderlich’s on the XML versions of all these QVW files and we can track, compare and search hundreds of thousands of expressions, tens of thousands of layout objects, and thousands of scripts as quickly as we would explore any other data in QlikView.
Generate New Applications
Kalido is exporting basic QVWs and QVDs, That feature required custom code integration. Soon any one of us can achieve the same end result: export a complete XML specification, import the XML into QlikView, and hit reload to execute the script. If QlikTech can make this happen from the command-line then the entire process can be hidden and the end user receives a freshly baked QVW (or QVD!).
Dynamically Update Applications
You could generate a full application, but it’s more likely that you will want to make small changes to one that’s already developed.
What do you do when you cannot predict the format of a data update. What if there are new columns added each day? Or what if the headers change? One of the simple things that QlikView can’t handle on its own is the addition or removal of fields from Excel sheets. I don’t know any business intelligence tool that gracefully adapts when a data field is missing.
What if you would like to change the layout every day. Maybe a new field in the Excel sheet needs to be added to a table, or to an expression, or to a drill-down. Maybe you would like to add a chart. Every part of the application is exposed in XML, so you can do anything you want.
Go With The Flow
Speaking more generally about adapting to data… One of the mantras of business intelligence and the database world is “Will the data have this format every time?” If it won’t, no deal. Well, now we can adapt to changing data. We can also deliver dynamic applications that are driven by that data.
And more…
It’s hard to say where this goes but I think it has big potential. Are there any other BI tools that we can look to for inspiration? Do you see yourself using this feature? I’d love to read your ideas!
Pingback: Qlikview - Nice Reads (Analyse field usage; applymap instead of join; XML export; Wolters Kluwers health) | Quick - Qlear - Qool
Hi Jay,
we definitely will use this for versioning and metadata tracking. But a diff of two of these XML files will be very difficult. Could it be a good idea to use a XML database instead of versionig tool (or additional)?
Ralf
I agree, Ralf. I combined two thoughts into one idea that isn’t clear. There are tools and scripts available to create differentials of XML. And it’s easy to push the XML into a standard version control system.
Pingback: Posts about xml as of April 29, 2009 | Shirasmane
Pingback: QlikCommunity | The Year in QlikView - The QlikView Blogroll
Pingback: QlikCommunity | A Brief Look at QlikView Storage - The QlikView Blogroll