Skip to main content Skip to complementary content
Close announcements banner


The overall architecture of a QlikView installation reflects the separation of roles.

An example of QlikView server architecture. The front end consists of the QlikView Management Console, the Ajax client QlikView Mobile, and the QlikView Desktop IE plug-in. The back end consists of the QV Web Server or Microsoft IIS, the QlikView Directory Service Connector, the QlikView Management Service, the QlikView Distribution Service or Reload Engine, the QlikView Server, and the Qlik License Service.

QlikView Server architecture with one instance of each service

Front End

The front end is where end users interact with the documents and data that they are authorized to see via QlikView Server. The front end contains the QlikView user documents that typically have been created via QlikView Publisher (QlikView Distribution Service with Publisher license) at the back end. All communications between the client and server take place here and QlikView Server is fully responsible for the client authorization.

The front end relies on infrastructure resources (for example, Windows-based file share for clustering).

Information noteQlikView Server currently only conforms with Windows file sharing. This means that storage must be owned, governed, and shared by a Windows operating system instance (typically accessed using a path like \\<servername>\<share>).
Information note QlikView does not support Windows Distributed File System (DFS).

Authentication of end users is (with exception of the built-in Custom Users) handled outside QlikView.

Back End

The back end is where the QlikView source documents, created using QlikView Developer, reside. These source files contain scripts to extract data from various data sources (for example, data warehouses, Microsoft Excel® files, SAP®, and®). This extraction sometimes involves intermediate files (QVD files). The main QlikView component that performs the loading and distribution at the back end is the QlikView Distribution Service.

The back end uses the infrastructure resources for clustering (for example, Windows-based file share) and may also use resources like SMTP servers and directory catalogs.

Information noteQlikView Server currently only conforms with Windows file sharing. This means that storage must be owned, governed, and shared by a Windows operating system instance (typically accessed using a path like \\<servername>\<share>).
Information note QlikView does not support Windows Distributed File System (DFS).

QlikView Server

The number of servers (clustered or not) within an installation is only limited by the license. It is, however, not feasible to run more than one QlikView Server (QVS) process per server (physical or virtual). QlikView Server is designed to make the most of the resources available to it. Notably the QlikView Server keeps as many calculation results as possible cached in memory to keep the response times to a minimum.

QlikView Server – Client Communication

The QlikView Server – client communication architecture requires three primary processes, which must be able to communicate with each other in a consistent and secure manner. This interaction can potentially involve multiple machines and multiple network connections, as well as other subordinate processes.

A client communication setup. The Ajax client QlikView Mobile communicates with the QlikView Web Server or Microsoft IIS via an 80,443 (http) port. The QlikView Web Server or Microsoft IIS communicates with the QlikView Desktop IE plug-in via an 80 (http) port. The QlikView Desktop IE plug-in communicates with the QlikView Server via a 4747 QlikView protocol port. The QlikView Web Server or Microsoft IIS communicates with the QlikView Server via a 4747 QlikView protocol port and a 4774 QVP tunneling port.

QlikView Server – client communication

The three primary processes are described below.

Client communication processes
Process Description
QlikView Server(QVS)  Provides QlikView functionality to the client. The machine that hosts this service must be running a Microsoft Windows operating system.
Client Runs in a web browser or an application shell that provides a container for the client code. The client communicates with QVS either directly or through the web server to provide the QlikView interface and functionality to the end user.
Web server Runs an http server, which can be used to serve html web pages to the client, assists with authentication of the user, and enables communication between the client and QVS.

With the exception of Custom Users, the authentication of client users is done outside QlikView using, for example, Windows authentication.

QlikView Server Authentication Using Custom Users

The protocols defined for client communication with QlikView Server are listed below.

Client communication protocols
Protocol Description
QlikView Protocol (QVP) Encrypted, binary, and TCP-based; communicates directly with QVS on port 4747.
QVPX XML-based; communicates with the QVS using http/https through a web server.

Windows clients (.exe/.ocx) communicate directly with QlikView Server using QVP on port 4747. These clients do not require a web server to establish and maintain a connection with QlikView Server.

The AJAX client and mobile clients do not communicate directly with QlikView Server. They establish and maintain a connection using the QVPX protocol through a web server, QlikView Web Server (QVWS) or Microsoft IIS. This is normally done using port 80 (http). The web server, in turn, communicates with QVS using the QVPX2 protocol on port 4747.

The default installation settings for QVS use QVWS, not Microsoft IIS. QVWS shares port 80 with IIS on Windows 7 (and later) and Windows Server 2008 (and later).

QlikView Server access to User Document

For a user to open a document, it is required that:

  • There is a Client Access License (CAL) for the user
  • The user has access to the document

The user documents are always read by QlikView Server (QVS) and thus technically only need to be readable by the account running QVS. The access rights are either stored in the ACL list of the document (when QVS runs in NTFS mode) or in the .META file (when QVS runs in Document Metadata Service – that is, DMS – mode). These settings are part of the distribution from the back end.

Items (for example, layout, reports, bookmarks, annotations, and input field values) created by end users are stored in shared files. Shared files are not replaced by the distribution from the back end.

QlikView Web Server

QlikView Web Server (QVWS) is included as part of the QlikView Server installation. The QlikView Web Server can act as a standalone service to fulfill the need of many QlikView Server installations.

As an alternative, a Microsoft IIS solution that provides more flexibility, additional authentication schemes, and web services for applications other than QlikView Server can be deployed. When Microsoft IIS is used, a special service, QlikView Settings Service, that handles management calls is installed.

Other web servers can be used in a QVS environment, but at some point the traffic targeting QVS has to go through either QVWS or the dedicated ASPX pages on IIS.

The QlikView Web Server component (either QVWS or IIS-based) performs several tasks:

  • Handles the AccessPoint back end
  • Transforms/routes traffic between stateless http and to/from the session-based communication with QVS
  • Handles load balancing of QVS clusters
  • Serves static content (optional)
  • Handles authorization of Windows-authenticated users
  • Handles authentication of Custom Users (optional)
  • Handles group resolution through Windows or Directory Service Connector (DSC) (optional)

QlikView Server Tunnel

If the QVS communication port (4747) is blocked in the network firewall, Windows clients attempt to re-route their connection through port 80 (http). This connection path must then include the QVWS, or be installed on Microsoft IIS, so that QVS tunnel communication can be established.

QlikView Directory Service Connector

The Directory Service Connector (DSC) is responsible for retrieving user information related to end users from a variety of sources, including (but not limited to) Active Directory, LDAP, ODBC, and Custom Users.

The web server uses DSC for group resolution, the QlikView Distribution Service uses it to look up e-mail addresses or UIDs during distribution, and the Management Service uses it to help the administrator find users and groups.

QlikView Management Service

The QlikView Management Service is the entry point for all management, both through QlikView Management Console and the QlikView APIs.

The QlikView Management Service (QMS) keeps settings in a database of its own, the QVPR. The QVPR is by default stored as XML files – an alternative is storing the settings in an SQL database.

Information noteAll QlikView servers must have the same regional settings. Different regional setting may cause errors when loading QlikView XML reference files.

An installation can only have a single instance of QMS active. Active/passive failover should be used for redundancy. Note that no other service needs QMS to be running.

QlikView Distribution Service

In a QlikView installation using QlikView Distribution Service, both the back end and the front end are suitable for development, testing, and deployment.

The QlikView Distribution Service works with the source documents to produce:

  • User documents
  • .qvw files for distribution to a folder or via e-mail
  • .pdf documents for distribution to a folder or via e-mail

The chain of events up to the final distribution involves one or many of the following tasks:

  • Data is loaded from one or more data sources (including QVD) into one or more .qvw or .qvd files.
  • A document is reduced into one or more smaller documents.
  • Attributes and usage rules are added (applicable only when distributed to a QVS).

The QlikView Distribution Service performs the tasks according to defined schedules and/or as responses to events.

QlikView architecture without QlikView Distribution Service

Without QlikView Distribution Service, the QlikView architecture becomes more restrictive. All distribution and reduction facilities are removed and replaced by a reload directly on the user documents. Without QlikView Distribution Service, developers need to manually deploy the .qvw file behind the server.

Reload Engine

In the absence of a Publisher license connected to the QlikView Distribution Service, the Reload Engine provides a subset of the Publisher distribution services. The Reload Engine only reloads user documents and the settings are defined directly in the user documents.

Information noteAll QlikView services must be running on the same machine for the Reload Engine to work. If you install the services on different machines (for example, the QMC, DSC, and QDS on one machine and the QVS and QVWS on another machine), the Reload Engine will not work.

Qlik License Service

The Qlik License Service is included in QlikView April 2019 and later releases and is used when QlikView Server is activated using a signed key license. The Qlik License Service stores the information about the license, and communicates with a License Back-end Service, hosted by Qlik, for product activations and entitlement management. Port 443 is used for accessing the License Back-end Service and retrieving license information.

In a multi-node deployment, the Qlik License Service is installed on the machine running the QlikView Management Service (QMS). You can manage the status of the Qlik License Service by starting and stopping the Qlik Service Dispatcher, listed in the list of services running in the Windows machine.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!

Join the Analytics Modernization Program

Remove banner from view

Modernize without compromising your valuable QlikView apps with the Analytics Modernization Program. Click here for more information or reach out: