QlikView 9: Export Document Layout to XML

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!

QlikView Server 9 New Look!

I’m kicking the tires on this new version and so far it makes a really good impression. I did the default install on a vanilla Windows 2003 Server x64 SP2 installation. I’ll post notes on installation sometime soon. This is the default view of the server documents at http://localhost/qlikview/

Click to see the full-size image.

Click for a larger image.

Click for a larger image.

QlikView 9 Beta!!!

There are A TON of new features coming in version 9. Big changes in usability overall.

You can access the beta as a registered customer or partner here: http://www.qlikcommunity.com/qv9beta/

My favorite new features so far:

  • iPhone client. Zoom in. Shake to clear. Lots of fun.
  • Java client for everyone else, including Blackberry.
  • Removal of the 2 billion record limit. Now your record set is limited by RAM and CPU power.
  • Dynamic data update. Update data in the QlikView document without a reload through APIs and standard SQL statements. When used on the server, it will PUSH the data out to the clients.
  • Export QlikView documents as XML. QlikView documents (no data) can be stored in version control systems. Differentials can be generated. This also means that QlikView documents can be programmatically generated!
  • Document chaining. Open one document from another and apply selections. Great for working with segmented QlikView documents when data volumes get very large. Can also be combined with the programmatic QlikView generation in interesting ways!
  • Actions and Trigger Actions are replacing macros. Oh please, oh please be the end of macros!!
  • Set Analysis can now reference other fields, as in “Select all possible values in Customers based on a Sales last year”.
  • Sparklines. Mr. Tufte, your “tiny” contribution is everywhere. Cool.
  • Trellis charts. I’m quite proud of this since it was originally my suggestion!! Woo hoo!
  • Dynamic background charts. Swap out map backgrounds as selections are made.

QlikView’s Rapid Time-to-Implementation Improves BI Value: A TDWI Interview

“We work the way your mind works. It doesn’t matter if you get the thing perfect the first time. Let your mind go the way it wants and ask the questions that you want to ask. Your can customize [QlikView] based on the kinds of questions, the kinds of analysis, that [your users] want to do,” Deighton says.

QlikView’s Rapid Time-to-Implementation Improves BI Value

Vertica for the Cloud

While I have my head in the clouds, I should mention that Vertica has a cloud solution that they manage for you. Not new, but gives some perspective.

With competitive offerings in the $10-20k per terabyte, this is an attractive offer and a great way to try before you invest when you have that much data.

I hear Vertica is a screamer, but I can’t imagine getting sub-second results for 3 TB of data on 3 virtualized servers, for the same reasons I gave in my previous post.

Vertica for the Cloud Pricing

QlikView in the Cloud

QlikView depends entirely on processor speed, processor cache performance, memory latency and memory throughput. This makes QlikView an ideal reference for Intel, who uses QlikView to show off the latest product improvements. It also adds to the challenge of adapting QlikView to cloud platforms such as Amazon Web Services, Mosso, Joyent, etc.

The problem is virtualization. Virtualization is valuable to customers and service providers, but it’s also a thief! It adds overhead for the processor, cache and memory–everything that impacts QlikView performance!

The cloud, as in real life, is ever changing. You have no idea how many people are sharing your hardware and what their load will be from second to second. I would bet that nearly all deployed QlikView servers spend most of their time idle and the rest of their time at peak processing power. In the cloud, the goal is to spend as little time as possible idle for which we sacrifice peak processing power. QlikView depends on peak processing power and that type of application will suffer the most in the cloud.

But exactly how much will it suffer? Success in the cloud will need to be measured by the end-user experience. The cost of being in the cloud is vigilant monitoring and smart responses. What’s the right way to monitor the end-user experience in a company that uses OCX vs. AJAX, or is spread out geographically? Will bringing up more servers in the cloud improve response time? Should every QlikView server deliver the same set of apps, or should each app be served by a dynamic set of servers? Similarly, do some apps need sub-second response time while others can wait?

One thing stays the same. If you deploy large QlikView data sets you’re already sensitive to response times and what to consider when designing an app. In the cloud, smaller apps will need to think about costly chart expressions, messy data models and design choices that work fine on dedicated servers.