(Sharepoint) integration with Qlik Sense

    This article contains the gotchas and best practices of what to think of when integrating Sense into Sharepoint - and to some extent other portals.

    Who is this article for?

    This article is for anyone who wants to integrate a Qlik Sense component into Sharepoint (or any other similar portal). The integrator should have the following knowledge:

    • Rudimentary knowledge of/experience with installing Sense on a machine.
    • Rudimentary html knowledge (putting an <iframe...> into a webpage).
    • Basic knowledge of Qlik Sense: what is the purpose of the hub, the apps and the dev-hub.
    • Basic knowledge of the QMC: how you apply a Qlik Sense license and apply a simple rule for users that is to use your integrated Sense object. Also knowledge of where to edit settings for the Proxy (only where to set reference to trusted 3rd party certificate).

     

    Prerequisites

    The following is needed for the example in this article to work (if you are a very proficient Sense user, the following doesn't differ from a normal quick setup of Qlik Sense):

    • Sharepoint installed and working of course. Note: The screenshots in the walkthrough example are from Sharepoint 2013, but there's no real reason why it shouldn't work on 2010 or any other MS-centric portal.
    • Installed Qlik Sense with quick installation.
    • Set up the license and applicable rule for the users that are to use the Sense component(s) you are going to integrate into Sharepoint. If it is only one or a few users due to access the component(s), it is easier to point out these users and use a user access license pass for each instead of setting up a rule.
    • Set up 3rd party certificate for Proxy that all in the organisation trust. See also Recommened settings on the Qlik Sense environment below for more discussion around this.

     

    Recommended settings on the Qlik Sense environment The recommended settings can be summed up as follows: don't touch the default settings (besides the 3rd party certificate if root certificate isn't trusted on every client machine; see below for comment) after installation if you want to make it easy for yourself.If you need to modify the default settings or want more than surface knowledge of settings relevant for this article, you can see the items below:

    • Only Proxy setting you actually need to consider in the default case: If you are using SSL on the "browser-facing" part of the Proxy, you should set up certificate for Proxy that all in the organisation trust - which is typically a 3rd party certificate for a public security company like VeriSign. See manual of how to install and apply 3rd part SSL certificate on the browser-facing part of the Proxy.
      recommended_settings.png
      If sys admin of an intranet makes everybody trust the Qlik Sense root certificate, there's no need to even do this since the automatically generated Sense SSL certificate (signed by said root certificate) is the default for the browser-facing part of the Proxy.
    • If you are considering to not use SSL (ie to use http://) for the Proxy, you should do the same with Sharepoint. Otherwise you would get a warning from the browser saying that there is insecure content (your http-uri to Sense in your <iframe>) on the secure webpage in Sharepoint.
    • Default authentication is NTLM-login, which fits perfectly with Sharepoint (and IE) since they are all Microsoft technologies. It also fits well together with ActiveDirectory User Directory Connector; setting up this is optional.

     

    Step by step walkthrough

    Integrating a Sense object into a Sharepoint page is very simple and with default settings of an installation (as mentioned above) you only need to do the following:

    1. Go to the Proxy node of your choice (easiest the local one via the Sense shortcuts installed on your desktop) in your web browser.
    2. Navigate to whatever object you want to integrate in Sharepoint.
    3. Copy the uri to the app component, via either...
      1. browser uri in app view (see App Integration API also)
        step_by_step_1.png
      2. supplied uri in Web Toolkit object page in dev-hub.
        step_by_step_2.png
    4. Go to Sharepoint page you want to add mentioned object to, go to "EDIT" mode and press "Embed code" under "Insert" tab.
      step_by_step_3.png
    5. Embed html code <iframe src='{your copied uri from either dev-hub or app-view}' /> and save.step_by_step_4.png
    6. Done!
      step_by_step_5.png

    Things to think of

    1. Don't complicate things. Try things out in its simplest form first. Don't try to be "clever" after reading documentation and assume you have to add tickeId to the uri in the iframe or use javascript to manipulate the session cookie or ... Start with doing these things (that shouldn't be needed) first when you run into problems - and when you do, try to understand the problem first. Best way to integrate a WTK part is to just cut-and-paste the uri to your mashup (or sheet, or single object, or...) and place that in the src-tag in the iframe on your Sharepoint page and everything should work just fine for you!
    2. Since the most common browser (for the end-user going to a Sharepoint-portal) is going to be Internet Explorer, one thing to consider is that each Web Toolkit object (ie. a mashup, a sheet, an app, a listbox etc) is going to use one websocket for itself and this limits a page to six WTK objects (due to IE limit of six concurrent websockets). If you want more than six Sense objects on a page, you can consider having a mashup where you can place the objects any way you want and still only use one websocket. Note: This limit can also be changed by the administrator of the client machine(s) (change rolled out by sys admin for several machines on an intranet): https://msdn.microsoft.com/en-us/library/ee330736(v=vs.85).aspx.
    3. Touching on the subject above, every time you open a websocket to the engine through the Proxy with a new authentication session, a license access pass is going to be used. This should usually not be any problem for you, since the objects on your page will use the same authentication session cookie.
    4. If you end up in a (perhaps strange?) situation where you need to run the Proxy without SSL but the Sharepoint site with SSL, the browser would of course complain that the some part of the content on the Sharepoint page is insecure. This should happen rarely, since if you want to use Sharepoint securely, then you should want to run the Proxy securely as well...
    5. If there is no user activity within an authenticated session, you're going to be logged out automatically for security reasons. The default value for this timeout is 30 minutes. You will get a notification in each WTK object you have on a page about this.
    6. In multinode: In the default case, all apps will be synced to every node. If you have specific needs for what app can reach what node(s) and you then have to edit the sync rules, you have to make sure that your Proxy is set up to load balance over the engine (nodes) where the sync rules will allow those apps.

     

    What about webparts?

    Note: A QlikView webpart already exists. No Sharepoint webpart exists today for Sense. We have for now decided that it isn't really needed, since it is easy enough to add an <iframe> to a Sharepoint page and referencing whatever part of Sense you want and it will work! Still, there could be a need for a webpart to make non-technical people able to add parts of Sense to Sharepoint by just making choices in drop-down menues in Sharepoint.

    Creating this webpart and making it user-friendly with contextual drop-downs would require some integration work on the Sharepoint side:

    • Generally speaking, the Sharepoint server needs to be able to communicate with Qlik Sense to get settings to present information. This means that the Sharepoint server has to be Sense node (easiest) or at least have access to client certificate (with private part), server certificate (with private part) and root certificate (only public part needed). Communication with Repository (or "Settings service" (name TBD) in G3) can either be made with System.Net.WebClient class or (recommended) BaseRESTClientFactory in Qlik.Sense.Common-dll with resulting BaseRESTClient making the rest-call. In the former case you have to implement the security requirements Sense has on incoming calls.
      In summary: the easiest way to communicate from .NET code to Repository would be to do that on a Sharepoint server that is also a Sense node and then use classBaseRestClientFactory in Qlik.Sense.Common-dll; it will handle the certificates, ssl and XRF-security (among other things) for you.
    • If it should be possible to select a virtual proxy in a drop-down for a Proxy on one node, you would need the settings of the Proxy, which are reached via endpoint "qrs/proxyservice/local" by making a GET.
    • Next step could be to get what Sense app:s are available in the system or directly choosing an app object from a list. The rest endpoints would be called in the same way as for getting settings for the local Proxy and can be found in the QRS API path documentation. I leave it to the reader to explore the documentation and find the endpoints that fit his/her intended webpart.