I’ve been wanting to use Document Attributes since I came across them when first exploring the QVSAdminDataProvider (you can see more info about that in this older post: Collaboration Metadata And More). Hurray – an opportunity finally appeared!
The Problem – too much Qlikin’ goin’ on (a good problem to have!)
I’ve been working consistently at a client and we’ve been growing the QlikView environment — more apps, more users and more revisions to apps. I was struggling to stay on top of the rapid changes: app versions; who has access to which app; which apps distribute to which groups; etc. So I started envisioning an application metadata repository. I’ve done similar things in the past using auxiliary text files that I include in scripts. These text files would hold information like the version #, an app ID, the author, the business owner, etc. This has been effective, but clunky.
But thinking a little more about these metadata, they are simply key-value pairs:
- App Name: Sales Analysis
- Author: Sven Klick
- Version: 3.1.4
- Access Group: QV – Sales
- Access Group: QV – Executives
Ah ha! What a perfect use case for Document Attributes!
As a reminder, document attributes are assigned in the Publisher task creation process on the “Document Information” tab. By using the plus sign to add rows, an unlimited (?) number of attributes await exploitation. Once the document is reloaded (i.e. the task is run), these attributes are saved with the document. Specifically, they are saved in the .meta file.
For example, I will assign four attributes to my Governance Dashboard app:
After I run the task, the attributes I assigned will be in the file:
If you want to verify the attributes are saved, you can look at the document’s details in AccessPoint, in either list or icon view:
Defining Document Attributes
Before diving in and assigning attributes to all your QVWs, I recommend you start with a short list of essential attributes. Remember, you have to maintain these attributes across all your apps, so only add what you think will be useful.
Here’s a simple list I’m working with:
- Version # – I come from a software development background, so the concept of formal versioning is critical for me.
- Owner – this is the “functional” or “business” owner of the application. This meta-datum is useful when an access request comes in for an app and I need to track down the owner to grant approval.
- Access Group – this is the NT group (or groupS, plural) to which the app is distributed. Also useful when on-boarding new users.
- Author – this is useful when you have many people contributing to the QlikView app pool.
Now comes the arduous step — go through all your applications and add these attributes.
TIP: Because the attributes are attached to published documents, the non-published documents, like QVD loaders, will not feed the AccessPoint display or the QVSAdmin data provider. But I still like to save Version # as an attribute on my QVD loader and other staging apps, so I can quickly lookup the most recently deployed version of any QVW document.
Building a meta-app — QV Admin Helper
Now that we have all these great metadata for our published documents, how can we tap into them? As shown above, we can inspect the attributes in AccessPoint. But we can also bring them into data models using the QvsAdminDataProvider.
Specifically, I recommend creating a stand-alone app, I call mine “QV Admin Helper.qvw,” to load data from the QvsAdminDataProvider and related metadata. As the name implies, this app is intended for the QlikView administrators. It is not a “business user” app.
As a reminder, the raw data model will look like this (see: Collaboration Metadata And More):
I find it useful to take the generic table (AttibuteName + AttributeValue) and blow it out into explicitly named fields:
Here’s some sample code to do that, using a FOR..NEXT loop:
Building on …
I’ve augmented my QV Admin Helper with additional metadata that describes which end-user is in which NT group. These data are maintained in an Excel worksheet outside of QlikView. Only the admins have access to it and it is saved on the production QVS server. The “glue” between the DocumentAttribute table and the NT groups & user data is the “AccessGroup” field:
Now I can make some front-end objects to do QlikView-style analysis across my metadata. For example here are the User Documents and Source Documents pivot tables (filtered to Governance Dashboard):
TIP: keeping a separate table for User Documents is helpful when you use Loop & Reduce to spawn many child apps off of one Source.
MastersSummit in Amsterdam – October 1-3, 2014
If you haven’t heard already, our traveling band of QlikView fanatics will be hitting the road (and skies) this Fall and heading to Amsterdam October 1st-3rd. I’ll touch on the QvsAdminDataProvider in my Tips & Tricks class and have some samples from the QV Admin Helper that you can integrate into your own environment. Hope to see you there!
More info at: Masters Summit for QlikView
Keep on Qlikin’