Did you ever see the commercial for Reese’s Peanut Butter Cups where one person is holding a chocolate bar and the other has an open peanut butter jar and they collide into each other? You know how it goes…the chocolate bar ends up in the peanut butter. Then the person with chocolate bar takes a bite of the “peanut butterized” chocolate bar and realizes that together…they make a great combination. Well, it is still early, but the initial indications are that QlikView and SharePoint also seem to work pretty well together.
Microsoft SharePoint Server is the fastest growing server product that Microsoft has ever released. Additionally, they are about to release version 4 of SharePoint in Q2 of 2010…and many of us know that by version 4, Microsoft has worked out a lot of the “kinks” and have gained a lot of market traction. That certainly seems to be to case for SharePoint 2010. So as more people look to SharePoint as a platform to power both internal portals, as well as different types of extranets, it is only natural to pontificate on how QlikView might play in the SharePoint sandbox? The answer seems to be “quite well”.
It turns out that in late 2008 QlikTech purchased the intellectual property for some server components that very neatly convert QlikView dashboard objects into SharePoint web parts. This opens a number of doors related to creating dashboard mashups to better meet the needs of your user community. Before I get too far ahead of myself, let’s understand a few of the fundamentals. First, the QlikView Web Parts for SharePoint server component works with the zero footprint deployment option within QlikView server. The great news for smaller companies is that late last year QlikTech announced that you can now run the AJAX zero footprint client with their small business edition server. This opened the door for smaller QlikView deployments as the ZFC was previously only available on the enterprise edition server. Second, the QlikView Web Parts for SharePoint component is not free. There is a cost to the component, but relatively speaking, it is pretty affordable.
The basics behind QlikView Web Parts for SharePoint are pretty straightforward. The server component is compatible with WSS 3.0 and MOSS 2007 and, presumably should work with SharePoint 2010, including the new free version dubbed SharePoint Foundation. The server component let’s you use the SharePoint designer interface to see a list of available QlikView applications. Once you connect to your preferred application, you can choose any of the QlikView objects and it creates the SharePoint web part which you can move around on the page with the designer tool. If I could change one thing about the functionality, it would be to enable QlikView objects from different QlikView applications to be added as web parts to the same SharePoint page. Right now, all your QlikView web parts on a SharePoint page need to be from a single QlikView application. Not too big of a deal, but you need to architect the underlying QlikView application to have the necessary objects available.
As for security, you have a number of options. To summarize, I would surmise that most security situations can be addressed in one way or another. The general way it works is that when the user opens the SharePoint page, their security credentials get passed to the QlikView server. If they check out, the QlikView web part is rendered with the data that the user has access to. Just to be clear, the web part object is fully functional. This means the user can interact with the object to drill down and make selections. As the objects are all rendered from the QlikView server, associated data changes in the different web part object when selections are made…just like a ZFC QlikView application.
From a business perspective, this could open some doors for distributing data that may not have been considered in the past. You could create a mashup page in SharePoint that combines a series of QlikView-powered web parts with a SQL Reporting Services web part or some other web parts. Some businesses may have made investments in SharePoint that were thought to have closed the door on leveraging QlikView. This new functionality may be just the ticket for combining the best of both worlds.
Until next time…Shawn