On Demand App Generation

Har du så mycket data i dina källsystem att allt inte kan läsas in i minnet samtidigt? I så fall är On Demand App Generation (ODAG) ett exempel på en bra lösning att titta närmre på.

ODAG låter först användaren arbeta i en app som har sitt data i minnet. Det handlar ofta om en app som är aggregerad - det vill säga att många rader summerats upp till färre rader. Om vi till exempel har en miljard rader i vår försäljningsstatistik kan man välja att summera upp försäljningen per dag, artikel och land. Antalet rader blir nu mycket färre än innan och applikationen fungerar bra även på en mindre server.

Säg nu att en användare arbetar med appen och har hittat något intressant - försäljningen för ett visst land ser ut att vara mycket låg en viss dag. Kanske saknas data? Användaren vill se alla order för den aktuella dagen för att kunna stämma av mot sitt affärssystem. Efter att ha gjort ett urval på de intressanta värdena kan användaren med en enkel knapptryckning låta Qlik Sense generera en ny app där detaljraderna för det aktuella urvalet tas med.

En sammanfattning av processen ser ut så här:

Aktivera ODAG i SaaS

Om man använder Qlik Sense SaaS måste först ODAG aktiveras i inställningarna för miljön. Logga in som en administratör och gå till Administration. Aktivera ODAG under On-demand data.

Aktivera ODAG i Client-Managed

Om ni har en egen installation av Qlik Sense på Windows finns inställningen för att aktivera ODAG på ett annat ställe. En administratör loggar in på Qlik Management Console, QMC, och går till On-demand apps service.

Selection-app

Det här är den app med data i minnet som användaren vanligen arbetar i. När data läses in aggregeras det ofta så att allt ska få plats i minnet. Detta sker genom vanligen genom att de SQL-satser/QVD-läsningar som ligger till grund för inläsningen görs aggregerade med group by.

I data för selection-appen ska utvecklaren skapa ett fält med hur många rader som aggregerats till en viss datarad. Detta fält används sedan för att jämföra hur många grunddatarader som användarens aktuella urval motsvarar. T.ex. kan användaren ha valt en specifik rad i selections-appen som aggregerat upp 1,000 rader i grunddatat. I bilden nedan är detta trips_count.

Utvecklaren behöver bestämma en gräns för hur många grunddatarader som användaren max ska få hämta. Antalet sätts utifrån prestandakraven (om användaren skulle läsa in samtliga rader från grunddata skulle prestandan bli lidande) och hur länge användaren kan behöva vänta (om användaren skulle läsa in samtliga rader från grunddata skulle detta kunna ta flera timmar). Gränsen jämförs sedan med det fält som säger hur många grunddatarader urvalet motsvarar.

Omladdning av Selection-appen schemaläggs med den frekvens som är lämplig - t.ex. varje natt.

När selections-appen är skapad behöver vi skapa en Details-app. När den är klar kan vi koppla ihop apparna med varandra.

Details-app

Den här appen kommer att skapas när användaren väljer att initiera ODAG och antalet motsvarande grunddatarader är lägre än gränsen som utvecklaren satt. Urvalen användaren har gjort i Selection-app kommer att tas med in i Details-app som variabler och användas i scriptet vid utläsning av data. Beroende på vilken typ av data fältet innehåller behöver scriptet använda olika typer av variabler för värdena i urvalet.

Totalt sett finns ett stort antal olika variabler, men de vanligaste är följande:

• odag_: Tar med valda (gröna) värden om val är gjort och annars möjliga (vita) värden och lägger till citationstecken för text. Denna används enklast när det handlar om textvärden som ska tas med.

• odagn_: Tar med valda (gröna) värden om val är gjort och annars möjliga (vita) värden. Denna används enklast när det handlar om numeriska värden som ska tas med.