Artikel uit OGH Visie – Winter 2008
Door René Kuipers

In elk BI-traject kom je ze tegen: rapportagetools. Met al hun functionaliteit en geboden opties lijken het vaak méér dan rapportagetools. En dat is waar het misgaat. Te vaak worden rapportagetools ingezet voor zaken waar ze niet voor bedoeld zijn. Het resultaat: een starre, slecht onderhoudbare en bovenal trage rapportagelaag. Terwijl juist performance altijd een issue is wanneer het gaat om het opbouwen van rapporten. De paradox is daar : we willen snel onze informatie, maar doen er weinig moeite voor om functionaliteiten onder te brengen in die gebieden die er ook het beste in zijn. Toegegeven, de drempel is soms laag, maar we zijn zelf degenen die de ontwerpbeslissingen nemen en het dus, helaas maar al te vaak, op de makkelijkste manier willen in plaats van op de juiste. Dit artikel kan naar ik hoop ertoe leiden dat we betere DWH- en BI- landschappen ontwerpen. De boodschap is: laat de functionaliteit waar hij hoort: een rapportagetool hoort te rapporteren…

Onlangs kocht ik een ander huis. En zoals in elk nieuw huis moet er worden geklust: behang, verf, gordijnen, fotolijstjes ophangen. In deze context kon de vergelijking niet treffender zijn: er moest een fotolijstje worden opgehangen en een altijd bijzonder behulpzame vriend ramde de spijker met een bahco de muur in. En waarom niet, zou je denken. Nou, omdat een bahco geen hamer is, en bahco’s zijn er niet voor bedoeld om spijkers mee in de muur te slaan. De muur vond het ook wat minder:
de spijker ging eerst drie keer scheef en dat bracht de onvermijdelijke schade met zich mee aan het stucwerk.
OK, het fotolijstje hangt. Maar als straks het interieur weer op zijn kop gaat en het fotolijstje natuurlijk
ergens anders moet komen, hebben we toch meer werk dan we hadden verwacht. Het lijkt een bizarre vergelijking met een datawarehouse-/ rapportagetraject, maar hij is zo ontzettend waar. Tools worden ingezet voor taken waarvoor ze oorspronkelijk niet werden ontworpen. Het resultaat ‘doet het’, maar kom er vooral niet meer aan. En een omgeving waaraan niets meer hoeft te worden
veranderd ben ik in de IT nog niet tegengekomen. Het vreemde in dit hele verhaal is toch wel dat de bahco noch de hamer hier iets aan kunnen doen: wij nemen zelf het besluit om verkeerde dingen met onze tooling te doen. Waarom toch?

Het dilemma
In grote organisaties waar veranderingen
projectmatig worden aangepakt is het risico op toolmisbruik het grootst. Maar al te vaak is het projectresultaat belangrijker dan al het andere, dus de manier waarop dat resultaat wordt gehaald is ondergeschikt aan datzelfde resultaat.
Goed voor het project en de projectleider, maar niet voor de overall-architectuur, noch voor de beheer- en beheersbaarheid.

Voorbeeld – OBI-EE
Oracle’s Business Intelligence Suite Enterprise Edition. Een werkelijk prachtige rapportagetool ‘waarmee je alles kunt.’ Dat komt goed uit, want de klant wil ook ‘alles kunnen’. ‘De vorige rapportagetool, daar konden we niet alles mee en dus willen we een nieuwe tool.’ En daar hebben we het risico al: Wanneer je de bahco vervangt door een betere bahco blijft het probleem bestaan.

Architectuur
OBI-EE is een rapportagetool. Het biedt een platform om binnen een webbrowser rapporten te maken, dashboards te creëren, alerts af te laten gaan, businessprocessen op te starten et cetera. De basis van deze functionaliteit
vormt de Repository. Een file die door de BI Server component wordt geopend en in het geheugen wordt geladen en waarin (vergelijkbaar met Oracle Discoverer’s End-User-Layer) een semantische laag de vertaling verzorgt van de veelal technische tabelnamen naar de leesbare businesstermen die erbij horen. Maar er is meer.
Tussen de semantische laag en de fysieke laag bestaat een Business Model laag. Deze laag stelt je in staat om een logisch datamodel te maken, op basis van de fysieke laag. Dit logisch datamodel is opgebouwd uit meerdere fysieke tabellen, die verspreid kunnen liggen over meerdere gegevensbronnen. Met andere woorden: in mijn logische model kunnen klantgegevens uit Dabatase X worden aangevuld met klantgegevens uit Database Y. Aangezien de semantische laag (datgene wat de eindgebruiker te zien krijgt) bovenop de Business Model laag ligt is de oorsprong van deze data voor de gebruiker compleet
transparant. Briljant: waar voorheen de eindgebruikers zelf moesten weten uit welk systeem ze welke gegevens moesten halen kun je dit nu vanuit één front-end regelen. Op het moment dat je dat inricht komt onherroepelijk de roep om security naar voren. Immers, de gebruiker mag alleen maar die data zien waarvoor hij is geautoriseerd.

OBI-EE en Security
Toegang tot data kan worden geregeld
met behulp van OBI-EE. Door subject-areas in te richten waar alleen maar die objecten in voorkomen
die een bepaalde gebruiker mag bevragen en deze subject-areas toegankelijk te maken voor bepaalde
rapportage-gebruikersgroepen, kan worden bepaald welke gebruikers welke data mogen zien. Echter, dat is maar gedeeltelijk waar. Op deze manier wordt op objectniveau beperkt, niet op recordniveau. Als je zou willen, zou je met behulp
van OBI de omgeving dusdanig kunnen configureren en opzetten dat de rapportagetool zelfs tot op recordniveau kan filteren of een bepaald record getoond mag worden aan een bepaalde gebruiker
of niet. Mijn boodschap is dat je dat niet moet willen: autorisatie op recordniveau hoort thuis in de database!
Beveiliging van data is een algemeen issue en niet iets van een specifieke (rapportage-)tool. Stel je voor dat de security wordt ingericht door middel van OBI. Wanneer ik dan via een andere weg (ODBC, SQLPlus, andere rapportagetooling)bij dezelfde database aanklop, werkt mijn security mechanisme niet meer, want deze is namelijk ingericht in de Business Model Layer van OBI. Daarnaast is het beheer van een dergelijk mechanisme
vele malen intensiever dan wanneer de security ín de database wordt geregeld – waar hij hoort. Daar bestaat één definitie van autorisatie op recordniveau en ongeacht de manier (of de tool) waarmee ik deze data benader doet dat mechanisme zijn werk.

OBI-EE en VPD
Een manier om security op recordniveau in te richten is door gebruikte maken van Oracle’s Virtual
Private Database mechanisme. Hierdoor wordt het mogelijk om gebruikers een profiel te geven op het moment van inloggen en dat profiel, in combinatie met de policy die aan de individuele tabellen is gekoppeld, bepaalt welke records van die tabel door een gebruiker benaderd kunnen worden en welke niet. Wat hiervoor nodig is, naast de reguliere inrichting van VPD met zijn policies en profielen, is de username van de rapportage user.
Om de username van de rapportage user aan de database door te geven kan gebruik worden gemaakt van de USER variabele in OBI-EE. Deze wordt op de connectionpool definitie meegegeven, evenals de functienaam van de functie die de Context moet vullen voor VPD.

Shared-logon vs named accounts
Wanneer vanuit OBI-EE een connectie naar de database wordt opgezet, wordt gebruik gemaakt van een useraccount. Er kan gekozen worden (dat is de standaardinstelling) voor een shared logon. Dit betekent dat elke OBI front-end user onder dezelfde username inlogt in de database. Dit maakt het eenvoudig in bijvoorbeeld een webapplicatie omgeving waar anonieme gebruikers data mogen zien: je hoeft dan niet voor elke user een apart database account te hebben.
Daarnaast is het mogelijk om elke front-end user een eigen account in de database te laten hebben, zodat
elke front-end user ook uniek geïdentificeerd in de database is. Beide opties kunnen worden gebruikt
in een VPD omgeving. In het laatste geval is het inrichten van VPD gelijk aan elke andere VPD implementatie, immers de loginnamen zijn vooraf bekend. Indien wordt gekozen voor de shared-logon optie, zal de username in het OBI-frontend moeten worden meegegeven als variabele tijdens de database login zodat de inhoud van deze variabele kan worden gelezen om de context te zetten. De mogelijkheid die OBI hiervoor biedt is om SQL code uit te voeren op het moment van het opbouwen van de sessie. Deze optie is beschikbaar in het Connection Pool object.

Op het Connection Scripts tabblad kan code worden opgenomen die op gezette momenten wordt uitgevoerd:
• Tijdens het opbouwen van de DB-connectie
• Vóórdat een query start
• Nádat een query klaar is
• Wanneer een sessie wordt afgesloten
In dit geval willen we code uitvoeren wanneer de database sessie wordt opgebouwd. Immers, de databasefunctie die de context voor VPD zet moet worden aangesproken en de username van de OBI-sessie moet hieraan worden doorgegeven. Om deze echt pér sessie te kunnen uitvoeren, moet de ‘enable connection pooling’
optie worden uitgezet op het General tabblad.

De username is binnen een OBI-sessie opgeslagen in de USER variabele en kan worden uitgelezen via de :USER variabele. Bijvoorbeeld: wanneer de databasefunctie die de VPD context moet zetten de naam INITVPD heeft en een usernaam als inputvariabele vereist, kan de volgende code worden opgenomen in Execute on connect om de VPD context te zetten:

begin
initvpd(’:USER’);
end;

Hiermee wordt de username van de OBI-user overgedragen aan de database waar vervolgens het security
mechanisme wordt afgevuurd. Hierdoor ligt de inrichting en het beheer van de securitylaag bij de DBA en (nog belangrijker) zo dicht mogelijk bij de data zelf. Op deze wijze wordt de toegang tot data geregeld ín de database, daar waar het hoort. In dit artikel is een voorbeeld uitgewerkt aan de hand van security en OBI-EE. Maar uiteraard kan en moet dit concept ook worden toegepast met elk ander rapportagetool.

Conclusie
Functionaliteit hoort daar te liggen waar het hoort. Een rapportagetool moet zich focussen op rapporteren. Een database hoort zich bezig te houden met data en aanverwante zaken, zoals toegang tot data.
De zwakke schakel in het geheel zijn niet de tools die voorhanden zijn, maar de mensen die ze gebruiken
en inrichten. Zolang wij ons zelf niet de druk willen opleggen om ons aan bepaalde ontwerpstandaarden
te houden, zullen tools altijd minder dan optimaal worden ingezet met versnippering en beheersproblemen tot gevolg. Op project- en programmamanagementniveau zou vaker gekozen moeten worden voor de juiste aanpak en niet voor de snelste aanpak.

René Kuipers is SL Manager BI bij CIBER
Download de OGH Visie – Winter 2008