for licensing questions the best person to contact is your QV Sales Rep / Consultant.
Regarding Document CALs they do not limit users to open one document at a time. How it works is that for each document on your server you assign a number of document CALs to specific users. Each user accessing the document will use one of the document CALs. There is also the option to assign document CALs dynamically. However, once a user has accessed a document one document CAL is locked for 24 hours before it could be assigned to another user. That's why it's recommended to really buy 1 document CAL per user accessing the document.
Hi Lucas ,
Thanks for responding . So what I understand from your reply is say for eg. say there are two documents say document A and document B in my server . There are totally only 5 document CALS for document A . So this can be assigned only dynamically . So the first 5 users accessing the document A will consume the document CAL , the 6th person will have to wait for 24 hrs before he can access the document A is it ?
So in this scenario , it is always better to buy 6 document CAL's for document A , so that each of the 6 users can access document A simultaneously right ? I have one question here .. do we need to buy document CAL's for each of the document ? Say if there are 2 documents - document A and document B and there are 6 users who need to access these documents , so does it mean that I need to buy 2 * 6 = 12 document CAL's in total ?
Also I have asked about named user CAL .. do you mean this "1 document CAL per user accessing the document" is termed as named user CAL ??
Is it advisable to buy named user CAL instead of document CAL or is it a must to buy both ?
you can assign the document CALs dynamically OR by name. If 5 users connect they consume 5 licenses - correct. The 6th user would not have access. If you wanted to assign one of the licenses to another user then you would need to manually remove one licenses from one of the five users (you can do this only after a quarantine time of 24 hrs).
Say if there are 2 documents - document A and document B and there are 6 users who need to access these documents , so does it mean that I need to buy 2 * 6 = 12 document CAL's in total ?"
If a user needs to access Document A and Document B he will require two licenses.
It's advisable to go with named user CALs if possible - they give you more flexibility and there's less administration required. But you should determine what the most economic solution for you is. If you have a large number of users just accessing 1 document then you should go with Document CALs. If you have users accessing a lot of different documents (more than 3), then Named CALs are the better approach.
You can use a combination of both actually, so you don't need to decide for one or the other.
I refer to, a Document Cal has, for example, some delay, conflicts with other types of license, has the same toolbar that a Named Cal, It is necessary to do some special design to the information in order that it works, apart from administration, that you indicate, there are another restrictions not to use a Document Cal.
Additional, which is the definition of a document, can be a document that contains several sheets, for example 15, with three united modules: Finance (5), Sales (5) and Human Resources (5) and a user can view this with a Document Cal.
Maybe you have some document on this topic
for detailed licensing questions you should contact your QlikTech rep... we use a large number of document CALs in our environment and a small number of named CALs. Basically document CALs work the same way but need to be administrated differently as indicated.
Below the restrictions of named CALs - I'm not sure if these are still valid though, there was discussions on removing them... again you're best advised to talk to you QlikTech rep.
19.2 Types of CALs
There are four different types of CALs available:
• Named CAL (an identified user on a server) - Access is based on user identity
and valid for all documents on the server, that is any number of concurrent
sessions from one user on one machine at a time is allowed.
• Document CAL (an identified user within a given document) - Just as
above, the access is based on user identity, but the CAL is valid only for one
document. If the same user connects to two documents using this licensing
method, he will hence consume two Document CALs.
• Session CAL - Each Session CAL allows one user to access one QlikView
document, that is to have one session at a time. Anonymous users are
allowed, no identification of the client user is necessary.
• Usage CAL - Each Usage CAL gives the right to initiate one session (single
document) per running 28-day period. The session may last a maximum of
one hour. Any activity after the first hour has expired will count as a new
session (albeit without visible interruption). No identification of the client
user is necessary.
Note CALs are used for purposes of licensing only and they have nothing to do
with user authentication for data access purposes.
In order to utilize a Named CAL or a Document CAL, the client user must be
identified either via an authenticated user name (Windows Active Directory
or through a ticket exchange between the web server and the QlikView
Server) or with a unique machine ID. An IP address is not a valid form of
identification for a Named CAL. The two methods of identification cannot
be mixed on the same instance of QlikView Server. Note that the user name
identification requires Windows authentication on Java and Ajax clients,
since machine name identification is not possible from these clients.
The purpose of the Document CAL is to provide a mechanism by which
licensees can license the use of a single document. To prevent the combination
of many data models into a single document, there are restrictions in the
documents which can be used with the Document CAL. The Named CAL,
the Session CAL and the Usage CAL can however be used to open any functional
QlikView document. The Document CAL, however, can only be used
with documents which have a single contiguous data model and do not contain
any chasm traps between tables.
Most common data models used in QlikView documents can be used for
Document CALs. For instance, proper star schemas and snowflake schemas
typically have the field with the highest cardinality in the fact table and the
keys in dimensional tables have a lower cardinality. For snowflake schemas,
the cardinality decreases further as you move away from the fact table. Documents
containing such models typically fulfill the above demands and are
well suited for Document CALs.
But documents with multiple logical islands are normally not allowed. Multiple
logical islands are only allowed if the additional tables are unconnected
and contain only few records or one single column.
Further, the document may not contain any loosely coupled tables.
Finally, the cardinality (number of distinct values) of the key fields must
decrease as you move away from the fact table.
Never read this before. It seems absurd for a few reasons.
1) What if you use metadata to drive out measures? We have hundreds of measures in our document and we use a unrelated table to store the names of these measures, thresholds (for turning them green, yellow and red) and formulas for their calciulation. We also use meta data for security and these two sets of metadata are "isolated" islands i guess.
2) Another huge problem with this limitation is many to many relationships. By proper design you need to have a junction or bridge table between such dimensions. THis will break their cardinatlity descreases as you move away from fact table rule.
3) Finally, QV does not work well with proper "enterprise" DW with conformed dimensions. Take a simple example where you have two fact tables each joined to a conformed time dimension -> FactA, FactB and Time. Lets also say that only Facta is linked to a product dimension. If you choose a product it will filter out data from FactA. It will also filter out Time dimension members that have no data associated with the product you chose. Now here's the key. This will also filter out Time members associated with "real" fact that you will have in FactB. This is really a tough one for me. QV uses an inner join type of filter for this and unfortunately the really cool 'associative' model breaks down with enterprise conformed dimensional model. The solution is data island. Isolate your fact tables. THis is going back to a data mart silo approach but at least you data will be correct.
I found this document online, which explains the difference between the 4 type of CAL (Named, Document, Session and Usage). You can even find few scenario.
QlikView Licensing Overview.ppt 982.5 K