Troubleshooting Issues with QlikView WebParts
The first thing to understand is which deployment scenario is being used. The different deployment scenarios are described in the QlikView WebParts Manual but here is an overview.
It is essential to know if the QvAjaxZfc library is being hosted by a web server which is on the same machine as the SharePoint Server, or not. 1) or 2) below. In both cases the web server may be either QlikView Web Server or IIS.
1) QvAjaxZfc and SharePoint Server are on the same machine
2) QvAjaxZfc and SharePoint Server are on different machines
If we are dealing with scenario 1), then there is an article that describes the necessary steps to set this up: “How to configure QlikView Webparts with QlikView Web Server on the SharePoint server
If it is scenario 2), this scenario will lead to a multi hop situation. NTLM cannot be used for authentication since it does not support multiple hops. Instead it is necessary to use either Kerberos configured for delegation, or header authentication:
a) Kerberos delegation
How to set up Kerberos delegation will not be described here, it is something that needs involvement from the customers IT department.
From the QlikView side, when everything else is configured on the Windows side, not much configuration is needed but in the Web Servers (QlikView Web Server or IIS) config.xml, change protocol from NTLM to Negotiate:
<HttpAuthentication url="/QvAJAXZfc/Authenticate.aspx" scheme="Negotiate" />
The Qlik Support article Kerberos support using QlikView Webserver
describes how to configure Kerberos with QlikView Web Server.
b) Header authentication
Before implementing header authentication, the security implications will have to be thought through because the authentication is passed as a header to the QvAjaxZfc library. Anyone who has access to this server can impersonate any user so access has to be restricted.
For header authentication to work, the web server needs to be configured for header authentication, (QlikView Management Console > System > Setup > QVWS > Authentication > Type > Header) and then QlikView Web parts can be set up to do header authentication by editing the web.config of the SharePoint site. This is done by adding the following line in the <QlikViewWebParts> section:
<add key="Header" value="QVUSER" />
The value of course has to match the value set in the QlikView Management Console.
Once it is known which deployment scenario is being used, and the scenario is valid, we can look closer at the symptoms and we can roughly divide issues into issues with the installation – or issues with configuration or connectivity.
The QlikView WebPart installation is done in two steps. Step 1 is to run installer, and step 2 is to integrate the QlikView WebPart feature into SharePoint. In both steps it is necessary to not only have local administrator rights, but also permissions in SharePoint – because SharePoint administers its own security independent from Windows. The permission level necessary in SharePoint is “Farm administrator”.
Running the installation package (QlikViewWebParts_x64Setup.exe)
The installer package checks that you have access to a valid QvAjax web folder:
This step may fail if the port is not open – the standard is port 80 for http, and 443 for https. An easy way to check is to open the same URL in a browser (from the same machine as the installer is being run on) but replacing “QvAjaxZfc” with “QlikView”. In this example http://selun-mls2/QlikView
. This should open the AccessPoint, displaying a list of QlikView documents.
This step may also fail if the versions do not match – QlikView WebPart has to be the same version as the QlikView Server and AccessPoint.
The next step is where you select which of the SharePoint Web Applications that you want to install the QlikView WebPart into:
The way that the installer knows which web applications are available on the server is by issuing the command “STSADM.EXE -o enumzoneurls”.
If the list appears empty then it is most likely a case that the user running the installer does not have Farm Administrator rights in SharePoint. Running the enumzoneurls command manually can verify that the user has enough permissions:
Apart from selecting web application it is also necessary to decide if a proxy should be used. As the text says, the proxy is necessary if SharePoint and QvAjaxZfc are on separate servers. It is also necessary if they are on the same server but have different URL’s – because otherwise there will be a cross site scripting issue which will make the web browser block content which is coming from another server (or another URL).
The “Make QlikView WebParts accessible” option would run the install.cmd script (which will be discussed in the next section) automatically. Generally it is better not to do this and run the script separately.
Once all selections have been made the installer will install files into C:\Program Files\QlikView\WebParts, but nothing will have been installed into SharePoint yet (unless the “Make QlikView WebParts accessible” option was selected).
Integrating the QlikView WebPart feature into SharePoint
After running the installer, it is necessary to integrate the QlikView WebPart feature into SharePoint.
This step can be done in different ways but the easiest is to run the “Install.cmd” file which is in C:\Program Files\QlikView\WebParts\Setup”.
Running the install.cmd should always be done from a command prompt so that it is possible to notice if any of the commands in this file fails, and to catch any error messages.
The account used to run the install.cmd has to be in the Farm Administrators group in SharePoint.
Contents of the install.cmd line by line
The commands of the install.cmd are run in sequence, and if one command fails, the succeeding commands may fail as a consequence. So if there is a failure on let’s say, line 3, then it is necessary to fix what caused the issue on line 3, then rerun the commands on line 3 and onwards.
- cd "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN"
- stsadm.exe -o addsolution -filename "C:\Program Files\QlikView\WebParts\QlikViewWebPartsSolution.wsp"
- stsadm.exe -o deploysolution -name QlikViewWebPartsSolution.wsp -url http://su-mls1 -immediate -force -allowCasPolicies
- stsadm.exe -o execadmsvcjobs
- stsadm.exe -o activatefeature -name "QvWebPart" -url http://su-mls1 -force
- stsadm.exe -o copyappbincontent
This changes the directory to where the stsadmin executable is located. Notice there is a “14” in the path. This indicates the SharePoint Server is SharePoint 2010. If it was SharePoint 2007, it would instead be“12”.
This line adds the QlikView Webpart solution into SharePoint. When this is done, the solution will show up in SharePoint Central Administration in Solution Management but will not yet be deployed:
Executing line 3 of the install.cmd should result in a “Timer job successfully created” message:
Note that this means that a timer job has been created, but it doesn’t necessarily mean that the timer job will get run.
If the “SharePoint 2010 Timer” service is not running then the job will not be run. In the Solutions Management the job will then be scheduled but not yet deployed:
To solve the situation, start the “SharePoint 2010 Timer” service (and rerun the remaining commands from the install.cmd).
This line executes the “execadmsvcjobs” command which in some cases fixes the situation where the “SharePoint 2010 Timer” service is not started. But if the SharePoint Administration service is running, then this command will not help.
This line activates the QlikView WebPart feature. When it has been run successfully, you can see that the QlikView WebPart feature is activated on the Web Application:
Note that the above screenshot is taken from the SharePoint Web application where you chose to install, not from the Central Administration page. There is also a “Manage Farm Features” page in Central Administration, but it does not list the QlikView WebPart.
This line executes “copyappbincontent” which copies files and merges changes into the web.config. If there are several front end Sharepoint servers it will make the changes across all of the Front end servers.
Configuration or connectivity issues
After the installation, it should be possible to insert a QlikView Webpart:
After inserting the QlikView WebPart, it should be possible to edit the properties and select a QlikView Document and a specific object inside the QlikView Document:
Here a few issues could arise. If the Document drop down list is empty and does not even show “<select document>”, then installation may not have been successful. Check if the QlikView WebPart feature is activated.
Another reason would be if the ajaxpath URL in the web.config differs from the SharePoint URL (or even if it is the same but a different port) but you have forgotten to enable the proxy. If so, modify the web.config where the proxy line looks like this without proxy:
<add key="Proxy" value="" />
<add key="Proxy" value="/_layouts/proxy.aspx" />
If the drop down list is active then it should be possible to see the documents available on the QlikView Server. If the expected documents do not appear, then check the web.config used by the SharePoint web application and if the user has permissions to the documents from AccessPoint.
Depending on which web application QlikView WebParts was installed into, the exact location of the web.config will be different, but for most installations on port 80 the path will be:
If we open this file we will see a QlikViewWebParts sections that will look similar to this: <QlikViewWebParts> <General> <add key="QvAjaxZfcPath" value="http://QLIKVIEWSERVER1/QvAjaxZfc/" /> <add key="Proxy" value="/_layouts/proxy.aspx" /> </General> </QlikViewWebParts>
We can see here that the QvAjaxZfcPath refers to a “QLIKVIEWSERVER1” hostname. We can also see that a proxy is being used.
It is possible to add extra logging by adding the following line to the QlikViewWebParts section:
<add key="LogFile" value="/wplog.txt" />
The log will appear in the same directory as the web.config.
To verify that the server specified in QvAjaxZfcPath is available and contains the expected QlikView documents, you can open http://QLIKVIEWSERVER1/QlikView
(use the same hostname but change QvAjaxZfc into QlikView) which should open AccessPoint.
Verify that you are authenticated as the same user in AccessPoint as you are in SharePoint.
For example, here we are authenticated as Administrator in AccessPoint:
When clicking on Favorites & Profile, it can be verified that the user is in fact Domain\Administrator:
In SharePoint we are also authenticated as Domain\Administrator:
Then the document list from the QlikView WebPart should be the same as the one in AccessPoint since we are using the same user.
If AccessPoint is not available at all or is not displaying the expected documents for the user, then we have an issue with QlikView AccessPoint which needs to be fixed before we can use it for the QlikView WebPart.
List of things to ask for
The exact things to ask for depend on the issue but the four first ones are always necessary.
1) Which deployment scenario are you opting for?
- QvAjaxZfc and Sharepoint Server are on the same machine
- QvAjaxZfc and Sharepoint Server are on different machines
- Kerberos delegation
- Header authentication
2) What are the symptoms of the problem?
An exact description is necessary together with relevant screenshots or error messages.
3) Does the QlikView Server have a licence for WebParts?
The lef should have the line:
4) What are the exact versions of QlikView Server and of QlikView Webparts?
5) Are you using IIS or QlikView Web Server for hosting QvAjaxZfc?
6) The web.config for the SharePoint Web application.
There could be many web.config’s if there are are many web applications on the Sharepoint Server, so it is important to make sure we get the right one. The exact path will vary but here is the location of the web.config for the default web application on port 80:
7) Extra logging in the QlikView WebPart
Enable logging in the QlikView webpart by adding the following line into the web.config, in the <QlikViewWebParts> section:
<add key="LogFile" value="/wplog.txt" />
This section will then look like this:<QlikViewWebParts> <General> <add key="QvAjaxZfcPath" value="http://QLIKVIEWSERVER1/QvAjaxZfc/" /> <add key="Proxy" value="/_layouts/proxy.aspx" /> <add key="LogFile" value="/wplog.txt" /> </General> </QlikViewWebParts>
8) Log files from the web server hosting QvAjaxZfc
By default in C:\ProgramData\QlikTech\WebServer\Log
9) Log files from the QlikView Server
Event*, Session*, and Performance* logs from C:\ProgramData\QlikTech\QlikViewServer.
10) Msi log
For installation issues. An msi log can be found by ticking ”Show the windows Installer log” in the installer.
If the installation window has already been closed, the log file can be found directly on disk by searching the installing user’s temp folder. Example file path: