Setting up user authorization under QlikView is generally referred to as section access, named after the statement that initiates the authorization section of the script. In section access, fields are loaded with details on which user is allowed which access rights. These fields are loaded in the same way as any other field in QlikView and can be sourced from an inline table, database, or external file.
Better Save than sorry (2)
It is strongly recommended to make a backup copy of your QlikView document before setting up section access. If anything goes wrong during the setup of section access, you will not be able to open your document anymore. Be very careful!
Besides using an inline table, database, or external file, there is also the option of storing and maintaining section access information under QlikView Publisher. Logically, this is no different than storing a table file with section access information in a (semi-)shared folder or, for example, on SharePoint. The data is loaded into the QlikView document as a web file.
As this book is focused on development within QlikView Desktop, storing section access information in QlikView
Publisher is out of scope, but it is a good idea to take note of.
Let's start with a simple exercise that protects our QlikView document with a username and password:
The following script should have now been generated:
As we can see, the script is started with the Section Access statement, which indicates to QlikView that we will be loading user authorization data. This data, access, userid, and password, is loaded in the next step using an inline table. The script is ended with the Section Application statement, indicating that QlikView should return to the regular application script.
We used a hidden script tab to create our section access. When using regular script, any user with privileges to view the script has full access to either the user credentials in plain text (when using an inline table), or to the location of the access files (when using an external table file). By using a hidden script, we can limit who will be able to see the section access script, adding an extra layer of security.
Another thing that you may have noticed is that all field names and field data are written in uppercase. While technically this is not necessary for data loaded from an inline table, any data loaded in section access from an external source must always be in uppercase. For the sake of consistency, it is a good idea to always load all data in uppercase in the section access area.
Now that we've seen how a basic section access example is set up, let's see if it works by following these steps:
If everything was set up ok, you should now be back in the document. Feel free to repeat these steps and enter wrong usernames and passwords to verify that QlikView will deny access to the document.
QlikView will only verify your user credentials once during each session. You can verify this by closing the document and reopening it, without exiting QlikView Desktop. QlikView will not ask for your username and password the second time. Only when you completely close and reopen QlikView Desktop will you be asked for your credentials again. This is important to remember when changing and testing section access.
Section access fields
Access rights can be defined based on (a combination of) various criteria. In the previous example we used the access, userid, and password fields, but as we saw in the Access Restriction Table Wizard dialog, there are more options, as seen here:
These options, and their description, are listed in the following table:
Note that just about any combination of fields is allowable. For instance, if just NTNAME and PASSWORD is defined, the domain user will need to be logged on correctly and provide the password associated with their domain account in section access. Also, it is valid to just have USERID, so only a name needs to be given to get access, regardless of domain user, and there will be no prompt for a password.
In the next section, we'll look at how we can use section access to restrict the data that users can see.
Besides the fields listed in the previous section, we can associate additional fields with the security fields to reduce the set of data that individual users have access to. Let's follow this example and see how we can limit the flight type (and associated flights) that are available to different users:
The resulting script should look like this:
In this script, we've created the % FLIGHT TYPE field. This field exists in both the section access part of the script as well as in the actual data model, thereby acting as a bridge field between these two sections. Through association, we can now limit what a particular user can access with in the data model.
Basing an inline table on existing data
One nice feature in the Inline Data Wizard dialog is the C) ability to load the contents of an already loaded field by using Tools | Document Data. This can be very useful when we want to group the values of an existing field.
You may notice that for the ADMIN user, we used an asterisk (*) instead of a % FLIGHT TYPE value. When we use an asterisk, it means that the user gets access to all values listed in the reduction field. In this case, that means that admin gets access to the domestic_foreign, domestic_us, and international_us flight types, but not to the INTERNATIONAL_FOREIGN flight type, since that is not listed in the section access table.
If we want the ADMIN user to be able to access the INTERNATIONAL_FOREIGN flight type as well, we will need to add an additional line referencing the INTERNATIONAL_ foreign flight type to the section access inline table. Let's do that now:
In this exercise, we reduce the data model based on a single field. To reduce the data model on multiple fields, we can simply add another reduction column to the section access table and add a bridge field to the data model.
One important caveat to be aware of in this scenario is that the reduction will be performed over the intersection of all fields.
If, for example, we give a user access to the Domestic, US Carriers Only flight type and to the Jet engine type, the user will only be able to see domestic flights carried out by US carriers using a jet-powered aircraft. Any flights that were made using another engine type will be excluded.
Although we have now finished the script part of setting up section access with reduction fields, we will need to make a few more changes before we can see the results. Let's head over to the frontend.
Initial data reduction
We will need to tell QlikView to perform an Initial Data Reduction when opening the document. When using initial data reduction, QlikView removes all of the data the user does not have access to, based on the authorizations in section access.
Using initial data reduction is very important. Not using it means that everyone with access to the document has access to all of the data. This means he entire point of using section access is all but lost.
Let's follow these steps to set up initial data reduction for our document:
We have now set up the document to, upon opening, exclude all of the data that the user does not have access to. Let's have a closer look at the options that we set in the Document Properties:
When a document containing section access is loaded into another document using binary load, the new document will inherit the section access of the original application. Take a minute to try logging in as the DUDF and IF users and see how the data is reduced to show only the authorized flight types. After that, reopen the document and log in as the ADMIN user, we'll need the privileges to make our next changes.
While looking at the fields in the Access Restriction Table Wizard, you may have noticed that there is one field that is a little different from the others: the omit field. While all of the other fields are used to identify a user, the OMIT field is used to remove fields from the data model for the specified user.
In the next exercise, we will create a new user, NOCARRIER, and will remove the Carrier Name field for this user. Let's follow these steps:
The resulting script should look like this:
We've created a new user, nocarrier, whose password is nocarrier123. This user has access to all flight types, but cannot see the Carrier Name field.
We'll test if this works according to plan, but this time we will use another method. Let's follow these steps:
If everything went well, we should see that the Carrier Name listbox is empty, and that the field is marked as (unavailable).(unavaMable)[Camer Name]
By opening a second copy of the QlikView software and testing our file in that, we've significantly reduced the risk of getting locked out of our document. If anything is wrong, we can just revert back to the document that we did not close after saving and make the required changes to section access before repeating the process to try again. Using this approach is highly recommended.
Association works in section access too
So far we have been using a single table to store our section access data. However, we can use multiple, associated tables as well.
For example, when we want to OMIT multiple fields for a single user, we need to add each field on a separate line. We can do this within the single table that we've been using so far. However, a better alternative is to remove the OMIT field from the first table and create a second, associated table that contains the USERID and OMIT fields.
Now that we've seen how we can limit who has access to our document, and what they can see, we will now look at how we can restrict what users can do within the document in the next section.
Qlik View Related Interview Questions
|Microstrategy Interview Questions||IBM Cognos Interview Questions|
|PL/SQL Interview Questions||MSBI Interview Questions|
|VBA For Excel Interview Questions||SAP BO Interview Questions|
|SQL Database Interview Questions||Qlik View Interview Questions|
|R Programming language Interview Questions||Pentaho Interview Questions|
|Advanced SAS Interview Questions|
Qlik View Tutorial
Seeing Is Believing
Data Modeling Best Practices
Basic Data Transformation
Set Analysis And Point In Time Reporting
Advanced Data Transformation
More On Visual Design And User Experience
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.