The overall architecture of a QlikView installation reflects the separation of roles.
QlikView with Publisher
The figure below shows a QlikView deployment with Publisher containing the location of the QlikView components.
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 at the back end. All communication between the client and server takes 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).
Authentication of end users is (with exception of the built-in Custom Users) handled outside QlikView.
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 Salesforce.com®). This extraction sometimes involves intermediate files (QVD files). The main QlikView component that performs the loading and distribution at the back end is the Distribution Service. Within the back end, the Windows file system is always in charge of authorization (that is, QlikView is not responsible for any access privileges).
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.
As depicted here, both the back end and front end are suitable for development, testing, and deployment.
QlikView without Publisher
Without Publisher, the QlikView architecture becomes more restrictive. All distribution and reduction facilities are removed and replaced by a reload directly on the user documents. Without the distribution abilities of Publisher, developers need to manually deploy the .qvw file behind the 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 QVS process per server (physical or virtual). QVS is designed to make the most of the resources available to it. Notably the QVS keeps as many calculation results as possible cached in memory to keep the response times to a minimum.
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.
The three primary processes are described below.
|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.
The protocols defined for client communication with QVS are listed below.
|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 QVS using QVP on port 4747. These clients do not require a web server to establish and maintain a connection with QVS.
The AJAX client and mobile clients do not communicate directly with QVS. 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 IIS. QVWS shares port 80 with IIS on Windows 7(and later) and Windows Server 2008 (and later).
QlikView Server – 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 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 (QVWS) is included as part of the QlikView Server installation. The 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 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)
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.
Directory Service Connector
The figure below shows the information flow. 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 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.
The 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.
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.
The 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 Distribution Service performs the tasks according to defined schedules and/or as responses to events.
In the absence of a Publisher license, 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.