Section Access in QlikView

Met QlikView is het eenvoudig mogelijk om op basis van inlog informatie wel of niet te laten zien. Erg handig als je na inloggen precies die data te zien krijgt, die voor jou van toepassing is, zoals bijvoorbeeld de marktaandelen in jouw werkgebied of de verkoopcijfers van jouw medewerkers,  zonder dat je inzicht krijgt in informatie die enkel je collega’s aangaat.

Deze methodiek wordt Section Access genoemd, ofwel ‘toegang op maat’.  Je regelt Section Access in het QlikView script. Omdat Section Access ook gebruikt kan worden voor extra beveiliging, kun je dit stukje script ook verbergen (‘hidden script’) achter een wachtwoord.

Stel je bent een salesmanager voor een organisatie in outdoor producten. En je wilt graag inzicht in de verkoopcijfers. In QlikView zou je klikken op je eigen naam bij de salesmanagers. Echter de organisatie wil, uit privacy en concurrentie overwegingen, niet dat salesmanagers gegevens opvragen van hun collega’s en al helemaal niet dat niet-salesmanagers verkoopcijfers opvragen.

Met  Section Access geef je op basis van jouw gebruikersnaam en het wachtwoord eenvoudig toegang tot je verkoopcijfers. En dan is dit het resultaat:

Datamodel script

Datamodel script

 

 

cijfers salesmanager

Dit is precies zoals het resultaat zou zijn als je deze selectie in de applicatie zou zijn gemaakt, nu zonder de mogelijkheid om de verkoopcijfers van jouw collega op te vragen. De informatie van je collega’s is simpelweg uit het datamodel verwijderd. Bovenstaand datamodel visualiseert goed wat er gebeurt, op basis van de naam van de salesmanager alle bijbehorende data ingeladen. Er is dus nog maar één salesperson in de applicatie aanwezig.

tabel salesperson

 

 

Data-island

Maar wat nu als je toch referentiecijfers wil, zoals trends, gemiddelde cijfers en regiocijfers? Deze data zit, door het toepassen van Section Access,  niet meer in de QlikView applicatie, je beschikt immers enkel over die data die op jou van toepassing is. Om deze informatie toch te kunnen tonen, kun je gebruik maken van een data-island. In onderstaand voorbeeld zie je dat de salesperson-data twee maal wordt ingeladen.

tabel met data-island

tabel met data-island

Het standaard-datamodel blijft zo dus intact. Toegang  (Section Access) wordt bepaald op basis van de match met het eiland (ISLAND).  En dat ziet er zo uit:

Section Access;
LOAD * INLINE [
ACCESS, USERID,        ISLAND.SALESPERSON_LOGIN
ADMIN,   ADMIN,
USER,    USER,        ADVENTURE-WORKS\DAVID8
];
Section Application;

Only en Possible

Nu wordt de volgende stap om te zorgen dat je als salesmanager jouw verkoopcijfers te zien krijgt, die van de regio en die van de totale organisatie.  Dit gaan we vervolgens regelen in de applicatie zelf: Hiervoor de only en de possible gebruikt.

Door dit script:
sum({<salesperson_login=p(island.salesperson_login)>} #order_total)
wordt alleen de totale sales van de ingelogde salesmanager getoond.

QlikView neemt in deze set-analyse alleen de som van alle orders indien de SALESPERSON_LOGIN overeenkomt met een waarde in ISLAND.SALESPERSON_LOGIN.
Omdat deze alleen uit de bijbehorende user bestaat, vanwege de section access, zijn alleen de gegevens van die gebruiker te zien.

Of toegepast in gebied: sum({<territory=p(island.territory)>} #order_total) Omdat er hier ook maar één gebied mogelijk is, wordt alleen dat gebied getoond. Met de expressie in het Label-veld, wordt deze ook getoond. Er kunnen ook meerdere salesmanagers hangen aan je inlog, bijvoorbeeld als je regiomanager bent. Dit werkt in dit voorbeeld ook nog steeds prima, enkel de labels werken niet meer goed, vanwege de only-functie. Het resultaat:

possible only

Script possible en only

 

section access
Toegang tot benchmark en eigen cijfers

 

section access op inlog
Overig: alleen toegang tot totale cijfers

Eindresultaat: Section Access maar met de mogelijkheid om, waar gewenst en toegestaan, te kunnen benchmarken met het geheel.Let echter wel op: als het niet de bedoeling is om inzicht te geven in andere salesmanagers, moet de selectie daarvoor uiteraard ook verwijderd worden! Deze is immers nog aanwezig in het datamodel en kan dus geselecteerd worden. Houdt hiermee rekening ook in andere objecten, zoals searchobjects.  Ook mag het voor gebruikers niet worden toegestaan om zelf objecten te maken. Tenslotte moet een actie toegevoegd worden bij het openen van de applicatie die alle selecties verwijdert, omdat het ook mogelijk is om via de URL een selectie mee te geven bij openen.

 

Thijs dFotoe Bruijn, HippoLine