6 skäl till att börja använda QlikView deployment framework (QDF)

QlikTech och några pilotkunder har under det senaste året arbetat med att ta fram ett ramverk för QlikView-utveckling och installation. Resultatet är ett centraliserat ramverk, QlikView Deployment Framework (QDF), som tillhandahålls av QlikTech och i gradvis takt har börjat presenterats för partners och kunder. Jag upptäckte QDF för första gång i kontakt med en av dessa medverkande pilotkunder. En stor global koncern med flera affärsområden där det bl.a. finns strikta direktiv kring hur information får delas inom koncernen. Parallellt med detta dök även QDF upp hos en annan kund inom vård och omsorgssektorn. Detta ledda till att vi haft besök på vårt Uppsalakontor av Magnus Berg, hjärnan bakom ramverket, för ett halvdagsseminar om QDF. Efter seminariet, egna laborationer och ett migreringsprojekt hos pilotkunden har vi på egbs fått upp ögonen och inser att QDF är här för att stanna. QlikTech kommer presentera QDF på bred front under detta år till alla sina partners och kunder. Vi som har haft möjlighet att få en tidig kontakt med den kommer förespråka QDF i någon form till alla nya kunder samt föra dialog kring med befintliga kunder i nya projekt.

1. Standardisering

Vi på egbs har länge använt en egen standard och ett ramverk kring hur vi sätter upp en QlikView-miljö och hur vi utvecklar. Denna standard fungerar bra även idag. När egbs vill bemanna upp pågående projekt eller introducera nya konsulter till befintliga kunder kan konsulten snabbt sätta sig in i kundmiljön och förstå koden och dataflödet. Problemet är att andra QlikView-partners inte kan vår egbs-standard, men har sin egen standard som skiljer sig från vår. Genom att ägarskapet på ramverket flyttas från resp. leverantörer till QlikTech kommer beställaren få ett ramverk som bygger på best practice och är helt oberoende av vilken partner den går med.

 

2. Snabbare utvecklingstider

Ett av skälen till att använda ett ramverk är att kunna korta ned den totala utvecklingstiden. Genom att introducera ett ramverk kapas utvecklingstid till varje nytt QlikView-dokument genom att kunna återanvända kod, infrastruktur etc. Fördelen med ett kundspecifikt ramverk är att kunden kan få det att vara och göra exakt vad kunden vill. Nackdelen med ett kundspecifika ramverk är att initialkostnaden är stor och att det därför tas genvägar där det inte finns behov idag.

Utvecklingstiden per qlikviewdokument utan ett ramverk

Utvecklingstiden per QlikView-dokument är kortare med ett kundspecifikt ramverk än utan

 

Använder man QlikTechs QDF sker själva installationen av basen endast några knapptryckningar och man kan direkt börja diskutera och ställa in hur kunden vill att ramverket ska fungera. Initialkostnaden för att få ett ramverk blir därmed lägre än tidigare vilket kommer att gynna mindre användare, de som inte har sett lönsamhet i att ha ett eget ramverk/uppsättning. Kunden drar också fördel av en central vidareutveckling av ramverket och att vi leverantörer lättare kan samla in och förmedla erfarenheter och best practice från våra befintliga kunder.

Utvecklingstiden av ett ramverk blir kortare om man har en bas som man anpassar än om man måste utveckla ett eget ramverk.

3. Mobilitet

Containers

En av baskomponenterna i QDF:en är containrar. En container är en isolerad filstruktur som innehåller allt som ett eller flera QlikView-dokument behöver. Detta för att man ska kunna flytta containern mellan servrar och datorer eller byta namn på den utan att funktionaliteten av innehållet förstörs. Denna egenskap gör att man kan bryta ut en container, ge den till en utvecklare som utvecklar lokalt på sin dator och när utvecklaren är klar läggs containern tillbaka på sin gamla plats och kan köras utan att några ändringar behövs göras.

När en container är sin egen entitet oberoende av i vilken miljö den ligger i så kan deployment från utveckling, test och produktion underlättas signifikant jämfört med en miljö utan ramverk.

4. Datasäkerhet

Det har sedan introduktionen av Section Access i QlikView 4 funnits bra möjligheter att hantera behörigheter på datanivå på front-end av av QlikView. Utöver section access finns administrationsgränssnitt i managementkonsollen (QMC) för att distribuera på användar och gruppnivå med mera. Back-end har best practice kring datasäkring inte varit lika tydlig från QlikTechs sida. All behörighet för att öppna QlikView-dokument och QlikView-datakällor styrs av Windows sin filbehörighet. Ofta har back-end filarean varit 100% tillgänglig för alla utvecklare hos de kunder jag har jobbat med. Detta är inte alltid en hållbar lösning, jag tänker t.ex. på kunden med det gemensamma ekonomisystemet där varje enhet ska ha tillgång till sitt eget data men inte de andras eller på kunden med känslig personinformation som lyder under Personuppgiftslagen (PuL) och har krav på hur deras data säkras upp.

Med den nya containertstrukturen kan man nu börja säkra upp varje container eller containerstruktur med behörigheter. Då det inte spelar någon roll var en container ligger i filstrukturen så kan man t.ex. strukturera upp de efter vilka behörighetinställningar de ska ha.

5. Skalbarhet och flexibilitet

Magnus Berg påpekade flera gånger under vår workshop hur generell QDF:en är skapat. Den kan anpassas till det oändliga för att möta kundens behov. Initialt kan hända att användaren nöjer sig med ett basuppsätt med en default Administration-container och en container per projekt.

ContainerMap-Basic

En annan kund har behov av ett mer företagsöverskiden ETL-struktur och har en container per projekt, men har även containrar för de olika extract- och transform-stegen.

ContainerMap-ETL

Det blir alltså möjligt för kunden att med ett och samma ramverk växa med QlikView. Den som börjar med en enkel installation utan behörighetsnivåer, där all produktion finns i en container kan dela upp sin utveckling, införa nya utveckling-, test-, acceptans-servrar samt gå hela vägen upp till en distribuerad klustrad miljö med ett och samma ramverk. QlikView Deployment Framework är byggd för att kunna hantera vilken QlikView-miljö som helst.

6. Centraliserad kod och variabelhantering

Med QDF kommer också ett tydligt sätt att kunna återanvända kod och variabler. När det gäller variabelhantering så införs en distinktion mellan lokala, globala och universala variabler, där de två sista är variabler som alla containrar i ramverket kommer åt. Det kan t-ex. vara kopplingsträngen till SQL-databasen eller vilka färger som ska användas i användardokumenten. På egbs har vi t.ex. färgvariabeln vG.egbsColor.Orange som är definerad till RGB(255, 102, 0), med att centralisera den variabeln behöver vi ändra på endast ett ställe för att färgändringen ska slå igenom på alla våra dokument.

———–
Vegar Lie Arntsen
QlikView-konsult på egbs consulting ab
LinkedIn Twitter

Share on LinkedInTweet about this on TwitterShare on Google+Share on FacebookEmail this to someone

3 kommentarer om “6 skäl till att börja använda QlikView deployment framework (QDF)

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *