Tjänstebaserad Business Intelligence med Power BI i en webbapplikation

Tjänstebaserad Business Intelligence

med Power BI i en webbapplikation

Service Based Business Intelligence using Power BI in a web application

Sigrid Österling Sicking

Vidar Hegna Tengstål

Fakulteten för hälsa, natur- och teknikvetenskap Datavetenskap

Examensarbete 15p

Handledare: Kerstin Andersson Examinerande lärare: Per Hurtig Oppositionsdatum: 2018-06-05

Sammanfattning

Business Intelligence handlar om att verksamheter och företag, med hjälp av verktyg och applikationer, ska kunna analysera och visualisera data och information för att sedan med hjälp av denna information kunna fatta verksamhetsnyttiga beslut. Företaget QBIM i Karl-stad arbetar med att leverera tjänstebaserad Business Intelligence till kunder i många olika branscher. De sammanställer datan med hjälp av mjukvaran Microsoft Power BI (benämns Power BI), och de levererar reslutatet via bland annat portalen SKI-ANALYTICS. Porta-len i nuläget har många brister, och därför kommer detta arbete kretsa kring att identifiera dessa brister och förbättra portalen ur ett användarperspektiv. Detta utförs genom att im-plementera innehållet i de tre delmålen: inbäddning av Q&A, inbäddning av rapport samt mobilanpassning. Förbättringarna kommer att implementeras med hjälp av Power BI REST API samt Power BI JavaScript API. Slutresultatet är en mer användarvänlig och attraktiv kundportal som är enkel att använda, där de tre delmålen implementerats. Arbetet inkluderar även en diskussion kring fördelar och nackdelar kring användandet av ett färdigt API som lämnar lite frihet till utvecklaren.

Abstract

Business Intelligence is about helping companies making business beneficial decisions by analysing and visualising data with the help of tools and applications. QBIM is a company in Karlstad that provides their customers with service based BI in various branches. They use a software called Power BI to compile the data from their customers and display the results in their portal SKI-ANALYTICS. The portal has as of now many flaws, and this report will focus on identify and improve those flaws. This goal will be split up and done in three parts; Q&A embedding, report embedding and mobile adaptation. The improvements will be implemented with the use of Power BI REST API and Power BI JavaScript API. The result is a more user friendly and attractive customer portal, where the three part goals are implemented. The report also includes a discussion on pros and cons of the use of an API that severely limits the freedom of the developer.

Tillkännagivande

Vi vill tacka Kerstin Andersson, vår handledare på Karlstads Universitet för väderfullt stöd och synpunkter under arbetets gång, och som peppat oss att köra på och kommit med förslag när vi inte riktigt vetat i vilken riktning vi ska röra oss.

Tack till Mikael och Daniel på QBIM, som tagit emot oss med öppna armar och fått oss att känna oss som en del av QBIM. Vi är också tacksamma över att ni gav oss förtroendet för detta projekt och det ansvar som kom med det, samt att vi fick mycket frihet att på egen hand ta fram lösningsförslag och idéer till förbättringar. Även ett stort tack att vi fick lov att följa med på ett lärorikt studiebesök till Stockholm och Microsoft Tech Summit.

Innehåll

1 Introduktion 1 1.1 Mål och syfte . . . 1 1.2 Projektsammanfattning . . . 2 1.3 Resultat . . . 2 1.4 Disposition . . . 3 2 Bakgrund 4 2.1 Uppdragsgivaren . . . 4 2.1.1 QBIM AB . . . 4 2.1.2 SKI-ANALYTICS . . . 5 2.1.3 Skidata . . . 5 2.2 Delmål . . . 5 2.2.1 Inbäddning av Q&A . . . 6 2.2.2 Inbäddning av rapport . . . 6 2.2.3 Mobilanpassning . . . 6 2.3 Business Intelligence . . . 7 2.3.1 Definition . . . 7

2.3.2 Tjänstebaserad BI hos QBIM . . . 8

3 Mjukvara och verktyg 11 3.1 Alteryx Designer . . . 11

3.2 Microsoft Azure . . . 13

3.3 Microsoft Power BI . . . 14

3.3.1 DirectQuery . . . 14

3.3.2 Beståndsdelar och termer . . . 15

3.3.3 Power BI REST API och Power BI Javascript API . . . 17

3.3.5 Q&A . . . 18

3.3.6 Rapport . . . 19

4 Teknisk lösning och kodexempel 21 4.1 Nuvarande system: SKI-ANALYTICS . . . 21

4.2 Inbäddning av Q&A och rapport . . . 24

4.2.1 Åtkomsttoken . . . 25

4.2.2 Inbäddningstoken . . . 25

4.2.3 Inbäddning i vyn . . . 26

4.3 Mobilanpassning . . . 28

5 Projektimplementation och resultat 30 5.1 Inbäddning av Q&A . . . 30

5.1.1 Arbetsprocess . . . 30

5.1.2 Alternativa lösningar och problematik . . . 32

5.2 Inbäddning av rapport . . . 33

5.2.1 Arbetsprocess . . . 34

5.2.2 Alternativa lösningar och problematik . . . 35

5.3 Mobilanpassning . . . 37

5.3.1 Arbetsprocess . . . 37

5.3.2 Alternativa lösningar och problematik . . . 38

6 Slutsats 39 6.1 Projektutvärdering . . . 39

6.2 Problem . . . 40

6.2.1 Problematik kring Power BI REST API och Power BI JavaScript API 40 6.3 Vidareutveckling . . . 41

Figurer

2.1 Dataflöde BI . . . 9

2.2 Dataflöde QBIM [1] . . . 10

3.1 Exempelflöde Alteryx Designer . . . 12

3.2 Power BI service instrumentpanel . . . 16

3.3 Vy för att skapa rapport i Power BI service . . . 16

3.4 Q&A . . . 19

4.1 Skärmdump SKI-ANALYTICS . . . 22

4.2 Skärmdump SKI-ANALYTICS, mobilvy . . . 23

4.3 Översikt av Systemet . . . 24

4.4 Åtkomsttoken . . . 26

4.5 Inbäddningstoken . . . 27

4.6 Konfigurationsobjekt . . . 28

4.7 Inställningsobjekt . . . 29

5.1 Q&A i ruta på startsidan . . . 31

5.2 Q&A i pop-up . . . 32

5.3 Resultat av rapportinbäddning . . . 35

1

Introduktion

Den här rapporten redovisar arbetsprocess och resultat från ett examensarbete utfört hos QBIM AB. Uppgiften var att förbättra deras kundportal SKI-ANALYTICS som används för att presentera tjänstebaserad Business Intelligence (BI i denna rapport).

1.1

Mål och syfte

Termen BI innefattar applikationer och verktyg som används i verksamheter för att analy-sera data, med målet att få ut värdefull företagsnyttig information. Informationen används sedan för att analysera konkurrenter, omvärld och den egna verksamheten och ligger ofta till grund för att kunna ta affärsnyttiga beslut.

Målet med det här arbetet är att förbättra QBIMs kundportal SKI-ANALYTICS som används för att leverera tjänstebaserad BI. Portalen ska vara lättanvänd, attraktiv samt erbjuda en interaktiv kundupplevelse, och den ska lätt kunna anpassas efter varje kunds unika behov. Arbetet kan sammanfattas i tre delmål:

Inbäddning av Q&A

Inbäddning av rapport

Mobilanpassning

Syftet är att öka tillgänglighet och användbarhet för kunderna att komma åt sin tjäns-tebaserade BI, samt göra portalen mer anpassningsbar för varje individuell kund då företa-gets kundkrets kontinueligt expanderar. Detta för att QBIM efter arbetets slutförande ska kunna fokusera mer på att leverera bra BI istället för att spendera tid på att underhålla portalen.

1.2

Projektsammanfattning

Under arbetets gång utvecklades portalen i lokalerna på Karlstad Business Center där QBIM AB hyr arbetsplats. Där gavs tillgång till arbetsstationer och skärmar som behöv-des för att utföra arbetet. Arbetet skedde i nära kontakt med medarbetare på QBIM för att säkerställa att resultatet motsvarade de förväntningar och förhoppningar som fanns. Tillgång gavs till företagets server samt den mjukvara som krävdes för att utföra arbe-tet. För att få bättre insikt i den mjukvara som används gjordes även ett studiebesök på Microsoft Tech Summit [2] i Stockholm.

1.3

Resultat

Det förväntade resultatet är en användbar kundportal där det ska vara möjligt att enkelt presentera och tillgängliggöra just den information som varje enskild kund värdesätter. Portalen ska vara lättanvänd och interaktiv för att ge största möjlighet till detta. Den ska även kännas modern och attraktiv, samt fungera bra på mobila enheter då telefon och surfplatta blir ett allt vanligare arbetsverktyg hos portalens användare idag. Det värdesätts också att koden har hög återanvändbarhet, då QBIMs kundkrets expanderar in i många olika branscher och därför enkelt ska kunna anpassas efter nya behov som uppstår.

Det uppnådda resultatet motsvarar de förväntningar som fanns till viss del, med po-tential för vidare förbättring. Då ett färdigt API användes och mycket av koden i och med detta var otillgänglig visade det sig snabbt att många förändringar som önskades inte var möjliga eller svåra att genomföra. De problem som detta skapade var framför allt att det fanns tydliga begränsningar till vad som gick att förändra utseendemässigt, vilket gjorde att slutresultatet inte blev riktigt så rent som hoppats. Bland annat skapades en grå mar-ginal runt innehållet på startsidan som inte gick att ta bort. Trots dessa problem så är det uppnådda resultatet en tydlig förbättring från föregående system och levererar en snygg, interaktiv lösning till kund som är enkel att förändra allt eftersom nya behov uppstår.

1.4

Disposition

Kapitel 2 innehåller bakgrundsinformation kring uppdragsgivaren, det nuvarande systemet och dess kunder. Den innehåller även en kort bakgrund till de tre delmålen, se avsnitt 1.1, samt en introduktion till BI vilket är området rapporten kommer att fokusera på. Kapitel 3 beskriver vilka verktyg och den mjukvara som används i arbetsflödet hos QBIM, från rå kunddata till att de presenterar färdig BI i portalen som utvecklas. Detta för att skapa förståelse kring portalens funktion, BI samt hur företaget levererar BI till sina kunder. Kapitel 4 innehåller praktiska kodexempel för hur lösningen har implementerats. Kapitel 5 beskriver ingående arbetsprocessen för de olika delarna i projektet samt resultat och problematik som stöttes på under arbetets gång. Kapitel 6 sammanfattar projektet i sin helhet och ger en diskussion kring problematiken med användning av ett färdigt API.

2

Bakgrund

I det här kapitlet behandlas den bakgrundsinformation som behövs för att förstå de olika delarna i projektet och denna rapport.

Avsnitt 2.1 beskriver uppdragsgivaren och deras verksamhet. Avsnittet ger en kort in-troduktion till Skidata [3], en kund till QBIM som kommer att vara grund till de exempel som finns i rapporten samt det nuvarande systemet, portalen SKI-ANALYTICS, som an-vänds för att leverera tjänstebaserad BI till kund och som ligger som grund för rapporten i sin helhet. Avsnitt 2.2 beskriver mer ingående bakgrunden till de tre delmålen i projektet. Avsnitt 2.3 beskriver begreppet BI som är ett återkommande område i detta arbete och som är basen i den tjänst som QBIM levererar till sina kunder.

2.1

Uppdragsgivaren

Det här avsnittet presenterar uppdragsgivaren, QBIM AB. Kapitlet kommer även ge en kort introduktion till det nuvarande systemet SKI-ANALYTICS, kundportalen som QBIM levererar till sina kunder och som det här arbetet kretsar kring. Till sist ges en översikt-lig presentation av företaget Skidata, den av QBIMs kunder som använder sig av SKI-ANALYTICS i sin verksamhet.

2.1.1 QBIM AB

QBIM (Quality Business Intelligence Mobile) AB [4] håller till i Karlstad och har över 17 års erfarenhet som konsulter inom BI. Genom att ta emot och analysera källdata skapar de rapporter och visualiseringar som kunder kan använda för att ta viktiga affärskritiska beslut och analysera verkligheten på ett enkelt och tillgängligt sätt. Företaget har kunder inom flera olika branscher som industri, transport, försäljning och skidanläggningar. En av kunderna är Skidata, för vilka QBIM har utvecklat en portal för tjänstebaserad BI med hjälp av Microsoft Azure [5] och Power BI [6] - SKI-ANALYTICS - som används för visuell

presentation av data som är relevant för Skidatas kunder och verksamhet. Denna portal kommer att ligga i fokus under detta projekt.

Grundare och ägare av QBIM AB är Mikael Hyensjö.

2.1.2 SKI-ANALYTICS

SKI-ANALYTICS är en portal utvecklad av QBIM med hjälp av Power BI och Microsoft Azure, skräddarsydd för företaget Skidata och deras kunder. I portalen presenteras rap-porter och visualiseringar av data som är relevant för kundens verksamhet, bland annat information kring bokningar, väder, liftkort etc. Mer ingående teknisk beskrivning disku-teras i kapitel 4.

2.1.3 Skidata

Företaget Skidata [3] har många års erfarenhet inom tillträdeshantering för bland annat skidanläggningar och alpina sportområden. De erbjuder lösningar för biljetter och person-tillträde, så som passersystem och biljettförsäljningslösningar [7]. De servar skidorter över hela världen, bland annat Aspen (USA), Niseko United (Japan) och Obertauern (Öster-rike). De har även ett antal kunder i Sverige, som Kläppen, Branäs och Hemavan. De erbjuder sina kunder bland annat entréläsare och vändkors, betalautomater, biljetthante-ring och statistik kopplat till verksamheten.

Ett antal av Skidatas kunder i Sverige använder sig av SKI-ANALYTICS, den BI-portal som QBIM erbjuder Skidata för möjlighet att analysera sin data tillsammans med annan verksamhetsrelevant information [4]. Resultatet presenteras som rapporter och visualise-ringar i portalen som denna rapport är uppbyggd kring.

2.2

Delmål

Det här avsnittet introducerar de tre delmålen som implementerats i det här projektet, Inbäddning av Q&A, inbäddning av rapport och mobilanpassning. Här beskrivs

vad delmålen innebär och innefattar, samt varför dessa ska implementeras.

2.2.1 Inbäddning av Q&A

Q&A [8] är en funktion i verktygspaketet Power BI [6] som kan jämföras med en sökmotor där en fråga relaterad till kundens data skrivs in och ett svar genereras i form av en datavisualisering, ex. ett pajdiagram eller en graf. Den här funktionen ger kunden möjlighet att hitta ny information utifrån den data som finns att tillgå utan att en visualisering redan har skapats manuellt. Förhoppningen är att denna funktion implementerad i SKI-ANALYTICS ska kunna agera som en förlängd arm när kunden vill ha svar på sina frågor och som ett komplement till de rapporter som QBIM skapar. Ingående beskrivning av Q&A finnes i avsnitt 3.3.6.

2.2.2 Inbäddning av rapport

Rapporter är ytterligare en funktion i Power BI, där datavisualiseringar i form av ex. pajdi-agram eller grafer skapas för att visa upp utvald information och data. Dessa går sedan att interagera med genom att exempelvis klicka på staplar och värden för att få ut ytterligare information om dessa. Rapporter används av QBIM för att kunna skapa interaktiva sidor för kunder att hämta iformation ifrån via SKI-ANALYTICS. En rapport ska bäddas in på startsidan i portalen för att ge portalen helt ny funktionalitet som förhoppningsvis gör den mer attraktiv och användbar till skillnad från de icke-interaktiva rutor som fanns på portalens framsida från början. Ingående beskrivning av rapporter finnes i avsnitt 3.3.7.

2.2.3 Mobilanpassning

Mobilanpassning av SKI-ANALYTICS innebär att skapa en version av portalen som är optimerad för mobiler och surfplattor. Anledningen till denna åtgärd är för att öka an-vändarvänligheten för kund, då många av portalens användare håller till ute i fält där de använder mobila enheter och inte inne på ett kontor med tillgång dator. Problematiken

i nuläget ligger i att rapporter och visualiseringar blir för små för att kunna avläsas och användas på mobila enheter.

2.3

Business Intelligence

Det här avsnittet beskriver begreppet BI som är centralt i det här arbetet. Här förklaras först vad den allmänna definitionen av BI är, och sedan en mer djupgående beskrivning av vad BI innebär i arbetet hos uppdragsgivaren QBIM.

2.3.1 Definition

BI är definerat enligt Gartner IT Glossary som följande:

Business intelligence (BI) is an umbrella term that includes the applications, infrastructure and tools, and best practices that enable access to and analysis of information to improve and optimize decisions and performance [9].

I dagens samhälle med den teknologi som finns att tillgå ökar möjligheten och behovet av att samla in, spara och analysera olika typer av data hela tiden. Loshin [10] skriver att genom att filtrera ut relevant data ur mängden går det att med rätt verktyg få ut värdefull information som underlag för att kunna ta rätt beslut vid rätt tillfällen. Detta är ett kraftfullt verktyg för företag i dagsläget för att på bästa möjliga sätt kunna konkurrera på marknaden oavsett vilken denna marknad är. För att kunna göra en sådan analys i större utsträckning krävs ofta någon form av verktyg eller teknologi, och det är detta som kallas för BI. BI kan exemplevis användas hos företag som hjälpmedel för att få tillväxt på försäljning, förbättra kundfokus och generellt öka vinsten medan kostnader reduceras.

Statistik och data samlas konstant in via de verktyg och affärssystem som används, och att få ut användbar information ur denna djungel av data är avancerat. Loshin påpekar att mer data betyder inte nödvändigtvis mer och bättre information - snarare tvärtom. Rå data är rörigt och kan vara av varierande kvalitet, och det gäller att välja ut och presentera

den information som är relevant för situationen den ska användas för. Detta är varför ett verktyg för BI är användbart och ofta nödvändigt, då det går att anpassa information utifrån den individ som ska använda den och de beslut som informationen ska ligga som grund för.

Målet och utmaningen med BI är att kombinera rätt data med rätt mätteknik, skapa rätt relationer mellan dessa och rätt sätt att utföra mätningar för att inte dra felaktiga slutsatser - och sedan paketera detta i en rapport och visualiseringar som går enkelt att analysera. Detta är extra viktigt, då den information som utvinns är värdelös om inte rätt personer kan avläsa och utnyttja den. Finns det ett kommunikationsgap mellan BI och användare går informationen till spillo, skriver Loshin.

2.3.2 Tjänstebaserad BI hos QBIM

QBIM AB [4] är erfarna konsulter inom BI och använder sig bland annat av verktyget Power BI för att leverera tjänstebaserad BI till sina kunder, där de strävar efter just att presentera och visualisera denna information på ett sätt som är anpassat efter vardera kunds behov. Med tjänstebaserad BI menas att kunder ska kunna köpa in ett färdigt paket med visualiseringar och analyser på sin egen data utan att själva behöva köpa in licenser och ha kunskapen och resurserna som krävs för att utföra dataorganisering och analyser. SKI-ANALYTICS är en av dessa tjänster, en portal anpassad efter de behov som finns hos Skidata och deras kunder. I nuläget ser QBIM brister i presentationen av portalen, och det är där detta arbete kommer in i bilden. Målet är att förbättra portalen så att Skidata och deras kunder på bästa sätt kan utnyttja den som BI-verktyg i sin verksamhet, se avsnitt 1.1.

Chaudhuri et al. [11] förklarar hur dataflödet i BI kan förenklat beskrivas med figur 2.1. Den illustrerar hur data och statistik samlas in från olika källor, i varierande filformat och av varierande kvalité. Processen kan sammanfattas i att datan extraheras, organiseras och kopplas ihop, och omvandlas till samma format för att sedan lagras i ett gemensamt

Figur 2.1: Dataflöde BI

datalager.

Utifrån datan i datalagret skapas passande visualiseringar i form av exempelvis diagram och grafer, interaktiva bilder eller kartor med hjälp av frågor till datalagret. Visualiseringens form avgörs av vad för information som ska framgå. BI är mellanhanden, länken, mellan de olika stegen i processen. Denna process är generell för BI i allmänhet, men kan hanteras olika hos olika former av BI. Den här rapporten kommer främst att rikta in sig på det sista steget i processen - visualiseringen.

QBIM beskriver sin process enligt figur 2.2, med kunden Skidata som exempel. De får in data från tre olika datakällor och system som används av Skidata, både historisk data och realtidsdata från bokningssystem, kassasystem och liftsystem. Allt detta är nyckeldata för skidanläggningarna för att få en översikt över verksamhetens status dagligen.

Denna data kommer in till QBIM flera gånger om dagen. QBIM använder sig sedan av verktyget Alteryx Designer [12] för att med hjälp av databasfrågor sätta ihop ett automa-tiserat flöde, där datan från de olika källorna förbereds, kombineras och analyseras. Detta flöde sätts ihop manuellt en gång, men är sedan schemalagt att köras en gång i timmen,

vil-Figur 2.2: Dataflöde QBIM [1]

ket innebär att ny data kan förberedas utan vidare manuell inblandning. Resultatet sparas i ett datalager som ligger i molnet hos Microsoft Azure, och det är sedan detta datalager som kopplas till Power BI. Rapporter och visualiseringar skapas sedan med hjälp av Power BI och läggs därefter upp på SKI-ANALYTICS-portalen där kunder kan komma åt och ta användning av dem i sin verksamhet. En djupgående beskrivning av flödet i figur 2.2 presenteras i nästa kapitel.

3

Mjukvara och verktyg

I det här kapitlet presenteras den mjukvara och de verktyg som används som hjälpmedel under projektet, för att skapa djupare förståelse för hur arbetet utförts och QBIMs flöde från rå kunddata till färdiga visualiseringar. Detta flöde illustreras i figur 2.2.

Avsnitt 3.1 beskriver Alteryx designer, det verktyg som QBIM använder sig av för att sammanfoga och förbereda sin kunddata inför lagring i molnet innan den kan användas för att skapa visualiseringar. Avsnitt 3.2 ger en kort beskrivning av Microsoft Azure som är den molntjänst som QBIM använder sig av vid lagring och hantering av kunddata. I avsnitt 3.3 beskrivs Power BI som är det visualiseringsverktyg som används i portalen och som är sista steget i processen för att presentera kunddatan i portalen och huvudfokus i denna rapport. Här beskrivs först DirectQuery [13], den funktion hos Power BI som QBIM använder sig av för att integrera sitt datalager hos Microsoft Azure och visualiseringsverktyget hos Power BI på ett smidigt sätt. Här beskrivs sedan de beståndsdelar och termer som Power BI är uppbyggt kring, hur rappporter och visualiseringar skapas, samt två av de funktioner som verktyget har att erbjuda och som ska implementeras som en del av projektet, se avsnitt 1.1.

3.1

Alteryx Designer

Alteryx Designer [12] är en mjukvaruprodukt utvecklad av Alteryx och används till att ska-pa automatiserade dataflöden från kunders datafiler till ett enhetligt datalager. Den data som kommer in från kund kan levereras i många olika filformat och från olika datakällor. Från Skidata tar QBIM emot data från bl.a. boknings- kassa- och liftsystem i filformatet .csv [14].

Verktyget har ett smidigt användargränssnitt där användaren med hjälp av ikoner och drag-and-drop skapar flöden för att sammanfoga, förbereda och analysera data. Varje ikon motsvarar en process som utförs på datan, och dessa placeras visuellt i den ordning

använ-Figur 3.1: Exempelflöde Alteryx Designer

daren vill att dataprocesserna ska utföras. På så sätt blir det tydligt för användaren vad som sker med datan och inga djupare kunskaper i databasspråk som SQL [15] krävs eftersom allt sköts av verktyget i den ordning som ikonerna placerats. Flödena kan schemaläggas att köras exempelvis dagligen eller en gång i timmen, detta för att hålla databasen uppdaterad utan manuell inblandning. Ett exempel på ett sådant flöde visas i figur 3.1. Flödet i figuren i sin helhet representerar i QBIMs fall processen från hämtning av rå data från kundkälla (grön boksymbol till vänster i figuren) till sammanställd data hos Microsoft Azure (grön symbol till höger i bild).

Några av de olika verktygsgrupper som finns att använda är Inmatning/Utmatning (in-put/output), Förberedelse (preparation) och Sammanfoga (join). Gruppen Inmatning/Utmatning innehåller processer för att exempelvis hämta data från filer, dataströmmar och databaser, sätta datastämplar på inkommande eller utgående data eller spara output från ett komplett flöde till en databas eller fil. Dessa hjälpmedel används för att kunna ansluta och hantera flera datakällor som sedan ska sammanfogas. I figur 3.1 representeras dessa processer i form av gröna ikoner, vilka symboliserar start och slut på flöden.

automa-tisera storlek på fält för att minska minnesanvändningen och datarengöring. Datarengöring ett verktyg för att exempelvis ta bort onödiga ”whitespace” och nullvärden. Dessa används för att förbereda och snygga till data och tabeller innan (och/eller efter) sammanfogning. I figur 3.1 representeras dessa funktioner med blåa ikoner, som används för att organisera datan.

Verktygsgruppen sammanfoga representeras av lila ikoner i figur 3.1 och används för att på olika sätt kombinera de datakällor som förberetts med andra hjälpmedel. Många av processerna i denna grupp kan jämföras med olika typer av unioner i databasspråket SQL, som innebär att två datamängder läggs ihop.

Alteryx Designer innehåller i övrigt en hel del andra tillgängliga funktioner för att på bästa sätt kunna förbereda datan för vidare hantering i molnet. Funktionerna represen-teras av ikoner i andra färger, exempelvis rött som visas i figur 3.1, men de kommer inte presenteras här då de inte är relevanta för detta arbete.

3.2

Microsoft Azure

Efter att kunddatan organiserats och sammanfogats med hjälp av Alteryx Designer använ-der QBIM tjänsten Microsoft Azure [16] från Microsoft för att lagra datan i molnet. På så sätt behövs inga egna servrar, och datan kan lagras säkert hos ett externt datalager. För att leverera SKI-ANALYTICS använder de sig av två tjänster hos Microsoft Azure; Micro-soft Azure SQL Database och MicroMicro-soft Azure Web Apps. MicroMicro-soft Azure SQL Database ger möjligheten att skapa egna databaser som sedan lagras på Microsofts servrar. Några fördelar med att använda sig av detta är att det lätt går att integrera med Power BI, det verktyg som QBIM främst använder i sin verksamhet, det är skalbart, men framför allt så kommer den med stark inbyggd säkerhet och kryptering av datan vilket är en viktig del oavsett vilken verksamhet ett företag bedriver [16].

För att skapa och underhålla portalen SKI-ANALYTICS använder sig QBIM av tjäns-ten Microsoft Azure Web Apps. Microsoft Azure Web Apps är en tjänst inom Microsoft

Azure och är ett verktyg för att publicera och underhålla webbapplikationer. Användaren laddar upp sin kod till tjänsten med hjälp av program som Git [17], Team Foundation Server [18], GitHub [19] eller Visual Studio Team Services [20]. Via tjänsten kan använ-daren sedan säkert publicera uppdateringar utan avbrott och med bra versionshantering och kontroller innan publicering. Tjänsten stödjer många olika språk och ramverk. Det går även att se statistik över användarens server som t.ex. dess resursanvändning och är enkelt skalbart [5].

3.3

Microsoft Power BI

Power BI [6] är ett licensbaserat verktygspaket utvecklat av Microsoft som förenklar BI-processen hos företag och organisationer. De erbjuder bl.a. enkla sätt att koppla ihop och integrera olika datakällor samt applikationer för att skapa rapporter och visualiseringar på datan. För detta erbjuder de en skrivbordsapplikation (Power BI Desktop), en webbappli-kation (Power BI Service) samt en mobilappliwebbappli-kation (Power BI Mobile) för hantering av data, rapporter, instrumentpaneler och visualiseringar. De erbjuder även Power BI REST API för att företag och organisationer enkelt ska kunna bädda in rapporter och visualise-ringar i applikationer som sedan kan användas av den egna organisationen eller organisa-tionens kunder. Det krävs en licens för att använda sig av Power BI, men applikationer med inbäddade objekt kan efter att de publicerats visas för andra användare, även utan licens. I korthet används Power-BI-applikationen för att samla data, skapa rapporter och visualiseringar av data och statistik, och sedan kan Power BI REST API och Power BI JavaScript API användas för att bädda in dessa i egna applikationer och webbsidor [21].

3.3.1 DirectQuery

DirectQuery [13] är ett sätt att ansluta datan i molnet hos Microsoft Azure till Power BI. Med DirectQuery så ansluts Power BI direkt till datans källa, i det här fallet Micro-soft Azure, istället för att behöva kopiera datan till Power BI först. Fördelarna med att

använda DirectQuery är att datan som används i Power BI alltid kommer vara aktuell. Aktuell data innebär datan från den senaste uppdatering. Dessutom gör DirectQuery det möjligt att använda stora mängder data till visualiseringar i Power BI eftersom det inte behövs kopieras vilket tar tid och plats. Dock finns det även ett antal begränsningar med DirectQuery. Bland annat så måste alla tabeller hämtas från samma databas, till skillnad fråb den så kallade import-metoden där databaser kan kombineras. T.ex. skulle det kunna vara önskvärt att kombinera ett företags databas med en lokal excel-fil, vilket ej går med DirectQuery. Eftersom datan hämtas direkt så behövs det även en god nätverkshastighet så att det inte tar allt för lång tid att ställa frågor mot databasen [13].

3.3.2 Beståndsdelar och termer

Power BI består av ett antal byggstenar som allt grundas på: visualiseringar, dataupp-sättningar, rapporter, instrumentpaneler och rutor. Figur 3.2 visar ett exempel på hur en instrumentpanel kan se ut i Power BI service.

Visualiseringar är bildliga representationer av data, exempelvis diagram och grafer. Dessa används för att få en visuell bild av den information som finns att tillgå, vilket underlättar för användaren att förstå och ta in informationen i jämförelse med till exempel en vanlig tabell i Excel. Nummer ett i figur 3.2 visar en ruta innehållande en visualisering [22].

Datauppsättningar är de samlingar av data som ska visualiseras. Datan kan hämtas in på olika sätt, bland annat från Excelfiler, SQL-databaser, och tjänster som Facebook och Twitter. Det går att kombinera olika hämtningssätt till samma datauppsättning. Det går också att filtrera bort den data som inte behövs efter att den har laddats in. QBIM använder sig av tjänsten Alteryx Designer för att göra detta. Datan laddas sedan upp i molnet hos tjänsten Microsoft Azure. Eftersom Microsoft Azure och Power BI båda är tjänster som Microsoft erbjuder är integrationen mellan de två smidig. För detta använder QBIM Power BI funktionen DirectQuery.

Figur 3.2: Power BI service instrumentpanel

Instrumentpaneler är även de uppsättningar av visualiseringar. Skillnaden mot rappor-ter är att instrumentpaneler endast tar upp en sida, även kallad en duk, för att snabbt kunna visa en eller flera visualiseringar som inte behöver vara interaktiva. Instrumentpa-neler kan tas direkt från rapporter, eller sättas ihop av enskilda visualiseringar. Nummer två i figur 3.2 markerar en instrumentpanel. Instrumentpaneler är inte interaktiva på sam-ma sätt som rapporter, då instrumentpaneler kan innehålla utvalda visualiseringar från rapporter och källor med olika datauppsättningar.

Rutor är de platser som visualiseringarna läggs in i en rapport eller instrumentpanel. Varje ruta innehåller en visualisering. Nummer ett i figur 3.2 visar en ruta.

3.3.3 Power BI REST API och Power BI Javascript API

Power BI förser utvecklare med två stycken API:er för att de skall kunna använda sig av Power BI-objekt i egna webbapplikationer. De båda API:erna är Power BI REST API och Power BI JavaScript API.

Power BI REST API:t är ett såkallat Representational State Transfer API som inne-håller metoder för hur datorer kommunicerar med varandra över internet [23]. I detta fall förser API:t utvecklaren med metoder för att kommunicera med Microsoft Azure-servern för att komma åt tokens och de beståndsdelar som ska bäddas in.

Power BI JavaScript API innehåller metoder för att underlätta vid inbäddning av ob-jekt i HTML-filerna samt att kunna interagera med obob-jekten, som att t.ex. lägga till en händelsehanterare till ett objekt eller ändra dess layout. Exempel på hur Power BI Java-Script API används visas i kapitel 4.

3.3.4 Inbäddning

Med hjälp av Power BI REST API kan rapporter och visualiseringar bäddas in i appar och hemsidor för att de sedan ska kunna interageras med på olika sätt. Detta är ett kraftfullt verktyg då det enkelt tillåter manipulering av visuliseringar och kan ge en mer givande

upplevelse för användaren. På så sätt ger API:t möjligheten för kunden att enklare förstå och skapa sig en uppfattning om den information som finns att tillgå. Eftersom detta i skrivande stund är en förhållandevis ny funktion som gjorts tillgänglig i Power BI så används inte i nuläget inbäddning i portalen. QBIM tror att denna funktionalitet kan addera en ny dimension till kundupplevelsen för Skidata och deras kunder och därför är detta en funktionalitet som ska undersökas och implementeras i projektet. En grundligare teknisk beskrivning kommer att vidare presenteras i kapitel 4.

3.3.5 Q&A

Q&A [8] är en av många funktioner som finns hos Power BI, som fungerar som ett hjälp-medel för kunden att snabbt och enkelt få ut den information som eftersöks och som går att addera till en webbapplikation med hjälp av inbäddning. Det fungerar så att frågor kan ställas till applikationen för att snabbt få ut specifik statistik och data. Exempelvis ska frågor i stil med ”Vad var antal sålda årskort i Branäs 2017?” och ”Hur många vux-na använde skidliften Järpen i Kläppen vecka 9?” kunvux-na ställas och utifrån detta ska en passande visualisering genereras. Frågorna görs om till SQL-frågor i verktyget, baserat på nyckelord som hämtas ur frågan som ställs. Utifrån detta genereras sedan ett svar, som visualiseras i lämpligt format. Allt detta sker dolt i själva verktyget hos Power BI. Q&A väljer automatiskt en passande visualisering utifrån den data som finns att tillgå, exem-pelvis en karta om datan är kategoriserad som städer. Det går även att själv lägga till den visualiseringsmetod man vill ha direkt i sin fråga, men för att detta ska fungera krävs det att datan faktiskt kan visualiseras på det valda sättet.

Figur 3.4 är ett exempel på hur Q&A ser ut. Överst i rutan finns ett sökfält där en fråga kan ställas. Under sökfältet visas förslag på nyckelord att söka på. Dessa kan väljas ut manuellt, annars väljs de ut baserat på nyckelord i datauppsättningen och tidigare ställda frågor. När en fråga ställs ersätts förslagen under sökrutan med en lämplig visualisering baserat på frågan som ställts. Visualiseringarna liknar de som visas i figur 3.2 och ser alltså

Figur 3.4: Q&A

ut som de visualiseringar som skapas manuellt. Alternativ för att utöka frågan och förfina resultatet dyker upp till höger om frågan.

Q&A är en av de färdiga funktioner tillgängliga hos Power BI som QBIM önskar få implementerat i SKI-ANALYTICS, detta för att kunder ska kunna hitta den information de behöver på ett mer effektivt och enkelt sätt. Förhoppningen är att denna funktion ska kunna ersätta en del av arbetet att sätta ihop rapporter till kunder, då Q&A i princip genererar egna rapporter utifrån just den information som kunderna själva eftersöker i stunden. Detta ska då kunna kombineras med att QBIM skapar vissa rapporter, samtidigt som kunden själv ska kunna hitta viktig information med hjälp av Q&A.

3.3.6 Rapport

Rapporter är uppsättningar av visualiseringar som användaren kan sätta ihop för att visa upp information och data som rör olika sammanhängande områden på en och samma sida, exempelvis kvartalsrapporter. Dessa rapporter är basen i den tjänst som QBIM erbjuder

sina kunder. Rapporter är interaktiva på så sätt att det går att klicka på värden och områ-den i visualiseringar för att få djupare förståelse för vissa delar i rapporten. Exempelvis kan en rapport för ett handelsföretag med hjälp av tabeller, diagram och kartor visa statistik för sålda och inköpta varor i hela Sverige. Om sedan användaren klickar på Stockholmsre-gionen på kartan genereras nya siffror och diagram för att visa sålda och inköpta varor i regionen.

Rapporter skapas direkt i Power BI service. I figur 3.3 visas vyn för att skapa en rapport. Verktyget är mycket användarvänligt och tillåter användaren att enkelt skapa visualiseringar och sätta ihop dem till en komplett rapport. Olika storlekar kan väljas på rapportytan för att passa olika ytor, exempelvis webbvy och mobilvy. En visualisering skapas genom att till höger under rubriken ”fält” välja lämpliga fält ur en datauppsättning, under rubriken ”visualiseringar” välja en lämplig visualiseringstyp samt grafiska element och inställningar, sedan genom att klicka och dra placera den färdiga visualiseringen på rapportytan. Visualiseringen genereras automatiskt i verktyget utifrån de kontroller som valts. Det går att flytta runt, ändra storlek och anpassa alla visualiseringar efter eget tycke och smak. Alla visualiseringar i rapporten kan interagera med varandra så länge de kommer från samma datauppsättning, vilket ger fler användningsområden och mer information än en statisk visualisering.

Längst nere i vyn i figur 3.3 syns flikar. En rapport kan skapas i flera flikar ifall det behövs. I exemplet i figuren finns det en flik för information kring liftar, en för besökare m.fl. Det finns även möjlighet att skapa dolda vyer som då inte syns direkt till kunden om inte den vyn specifikt laddas upp. Ett exempel på ett sådant användningsområde är en mobilvy som enbart visas om kunden använder en mobil enhet. När dessa sidor ska visas är något som görs i programkoden och inte direkt i Power BI.

4

Teknisk lösning och kodexempel

Det här kapitlet kommer att fokusera på att gå djupare ner i de tekniska detaljerna kring projektet kopplat till Power BI och dess funktioner. I avsnitt 4.1 beskrivs det nuvarande systemet, dess begränsningar samt de förändringar som ska utföras i det här arbetet kopplat till den problematik som finns. Avsnitt 4.2 handlar om inbäddning och innehåller teknisk beskrivning och kodexempel för hur detta fungerar med hjälp av Power BI REST API. Avsnitt 4.3 beskriver närmare hur inbäddning av rapporter och förändring av deras layout kan användas för att mobilanpassa en rapport.

4.1

Nuvarande system: SKI-ANALYTICS

Den portal som QBIM tillhandahåller kunden Skidata kallar de för SKI-ANALTYICS. Den används för att ge kunden tillgång till de rapporter, instrumentpaneler och visualiseringar som QBIM skapar åt dem.

Portalen består av en startsida, en flik för sparade instrumentpaneler, en för sparade rapporter samt en där kunden kan skapa en egen rapport med hjälp av den data som finns att tillgå. Instrumentpaneler och rapporter skapas av QBIM och innehåller visualiseringar som kunden kan ha nytta av, men kräver att kunden själv letar upp rätt rapport eller instrumentpanel som innehåller just den information som eftersöks. Ofta finns inte den tiden till förfogande då kunden vill ha svar på sina frågor snabbt, och därför ligger den mest relevanta informationen direkt på startsidan för kunden att lätt komma åt den. Ett exempel på hur startsidan kan se ut visas i figur 4.1. I det nuvarande systemet består startsidan av en bakgrundsbild samt ett antal rutor innehållande icke interaktiva visuali-seringar. Dessa kan exempelvis innehålla specifika nyckeltal, så som de två översta raderna av rutor i figur 4.1, eller diagram och grafer så som i den nedre raden i figuren. Dessa läggs i nuläget till i en gömd instrumentpanel i Power BI och laddas sedan in manuellt en och en i vardera ruta på startsidan, där även varje ruta manuellt måste storleksanpassas efter det

Figur 4.1: Skärmdump SKI-ANALYTICS

valda innehållet. Detta är ett problem då det är både tids- och resurskrävande. Dessutom, i och med att innehållet i rutorna är statiskt istället för interaktivt då det hämtas från en instrumentpanel går kunden potentiellt miste om värdefull information vid första anblick. Istället vill QBIM att framsidan ska vara interaktiv, d.v.s. innehålla inbäddade rapporter eller delar av rapporter, så att kunden själv, snabbt och enkelt kan filtrera fram den in-formation den vill åt. De hoppas på att lösa detta problem med hjälp av inbäddning av rapport samt med implementering av Q&A.

Ett annat problem med det nuvarande systemet är att det inte är anpassat för mobila enheter. Ett exempel på hur mobilvyn kan se ut i det nuvarande systemet visas i figur 4.2. Skidatas kunder består av olika skidanläggningar, och i och med att detta är ett väldigt rörligt jobb där personal i praktiken inte sitter inne på ett kontor utan ofta är ute och rör sig på anläggningen är det nödvändigt att portalen är användbar även på mindre, mobila enheter ute i fält. I nuläget är rutorna i mobilvyn små och icke interaktiva. Diagram och tabeller, till höger i figur 4.2 blir väldigt små och blir därmed inte användbara i praktiken. Det går inte att få ut ytterligare information genom att klicka på bilder, och det blir

Figur 4.2: Skärmdump SKI-ANALYTICS, mobilvy

mycket ”död yta” i form av vit bakgrund där diagrammen inte täcker hela den givna ytan eftersom varje ruta storleksanpassas manuellt. Den nuvarande lösningen är inte heller estetiskt tilltalande då den gömmer bakgrundsbilden. Förhoppningen är att lösa detta med hjälp av mobilanpassning.

I och med att varje ruta måste anpassas individuellt till varje element och varje element läggs till manuellt är det ett tidskrävande arbete att underhålla portalen, särskilt som QBIMs kundkrets blir allt större. Det är tydligt att det finns många problem med det nuvarande systemet, och dessa ska undersökas och förhoppningsvis lösas med hjälp av detta projekt och de tre delmålen som vi väljer att kalla inbäddning av Q&A, inbäddning av rapport samt mobilanpassning.

Figur 4.3: Översikt av Systemet

4.2

Inbäddning av Q&A och rapport

Inbäddning med hjälp av Power BI REST API och Power BI JavaScript API används för att bädda in en eller flera Power BI-beståndsdelar i en webbsida eller applikation, som sedan kan användas och visas även av personer som inte har licens till Power BI. Detta är användbart exemplevis i fallet för QBIM då de kan skapa rapporter, instrumentpaneler och visualiseringar som sedan kan användas i deras kunders organisation utan att kunderna själva behöver betala för verktyget. I det här avsnittet beskrivs hur det går till när man med hjälp av åtkomst- och inbäddningstokens kan bädda in Power BI-beståndsdelar i en webbapplikation.

Figur 4.3 visar hur inbäddningen går till i stora drag. Det första som sker är att kon-trollen skickar en begäran om tokens och annan information om inbäddningsobjektet till Microsoft Azure med hjälp av Power BI REST API (steg 1). Den övriga informationen

inkluderar inbäddningsobjektets URL, id och annan valfri information. Microsoft Azure autentiserar användaren och kollar att denna har tillåtelse att se och/eller ändra på in-bäddningsobjektet, och skickar sen tillbaka tokens och den information som begärts till kontrollen (steg 2). Kontrollen skickar informationen vidare till vyn där inbäddningsob-jektet ska bäddas in (steg 3). I vyn skapas ett konfigurationsobjekt som ska innehålla all information och som kommer att användas av Power BI JavaScript API vid inbäddning-en. Med hjälp av Power BI JavaScript API skickas innehållet i konfigurationsobjektet till Mircosoft Azure för att begära inbäddningsobjektet (steg 5). Microsoft Azure kontrollerar tokens och skickar sen tillbaka inbäddningsobjektet till vyn. Inbäddningsobjektet bäddas tillslut in i IFramen (steg 6).

Inbäddning används i det här projektet för att lösa målen inbäddning av rapport och inbäddning av Q&A.

4.2.1 Åtkomsttoken

För att bädda in en Power BI-beståndsdel till en ASP.NET-app behövs det först hämtas en åtkomsttoken (Access Token). Denna fås när en Power BI-användare autentiserar sig mot en autentiseringsserver. Detta görs genom att vid inloggning och hämtning av ny sida använda sig av Power BI REST API med koden som visas i figur 4.4. AuthorityUrl är en sträng innehållande autentiseringsserverns webaddress. ResourceUrl är en sträng innehållande Power BI REST API:s webaddress. ClientId är Power BI-användarens id.

4.2.2 Inbäddningstoken

En åtkomsttoken används för att generera inbäddningstoken, en för varje Power BI-bestånds-del som ska bäddas in. Dessa tokens är till för att bevisa att användaren har tillgång till beståndsdelarna. Inbäddningstokens kan antingen genereras i en kontroller (en del av ASP.NET MVC strukturen [24]) med hjälp av Power BI REST API, eller direkt i den vy där den behövs, med hjälp av Power BI JavaScript API. I detta fall genereras

inbäddnings-Figur 4.4: Åtkomsttoken

token i en kontroller, i den metod som körs innan vyn där inbäddningen ska ske laddas, och sedan skickas inbäddningstoken med till vyn via vydatan, "view data". Koden i figur 4.5 används för att generera en inbäddningstoken i en kontroller, denna token tillhör en rapport. I koden hämtas först den rapport som ska bäddas in. Sedan förbereds en förfrågan om en token, med åtkomstnivån ändring, vilket innebär att den inbäddade rapporten även ska kunna ändras på. Sedan skickas förfrågan till Power BI-servern som svarar med ett tokensvar innehållande en inbäddningstoken.

Förutom en inbäddningstoken så behövs även beståndsdelens id skickas med, samt en sträng innehållande webbaddressen som beståndsdelen hämtas ifrån. Webbaddressen fås antingen med hjälp av Power BI REST API, eller att använda strängen

https://app.powerbi.com/reportEmbed?reportId= följt av rapportens id.

4.2.3 Inbäddning i vyn

I vyn bäddas varje beståndsdel in genom att först skapa en behållare, exempelvis en div i HTML [25], där inbäddningsobjektet ska ligga. Med inbäddningsobjekt menas det objekt som ska bäddas in, i detta fall en Power BI beståndsdel. Sedan skapas ett konfigurations-objekt där typ av inbäddningskonfigurations-objekt, token, id och webbaddress läggs in tillsammans med

Figur 4.5: Inbäddningstoken

ytterliggare frivilliga inställningar om inbäddningsobjektet. De frivilliga inställningarna skiljer sig en del beroende på vilken beståndsdel som bäddas in. T.ex. har rapporter sä-kerhetsinställningar för om rapporten ska gå att ändra på eller ej, vilken av rapportens sida som ska visas när rapporten laddas in m.m. Ett exempel på hur ett konfigurations-objekt kan se ut visas i figur 4.6. Sedan skickas konfigurationskonfigurations-objektet och en referens till behållaren med som argument till en metod som hämtar Power BI-beståndsdelen från webaddressen och bäddar in den i en IFrame inuti behållaren.

En IFrame (Inline Frame, eller Inline-ram på svenska) är ett HTML-objekt som används för att bädda in andra HTML-dokument i det HTML-dokument som IFrame:n befinner sig i [26]. HTML-dokumenten kan både hämtas lokalt eller från en extern källa. Här används IFrames till att bädda in beståndsdelarna från Power BI. Detta görs abstrakt med Power BI JavaScript API. Beståndsdelarna räknas som externa dokument eftersom de hämtas från Microsoft Azure. Eftersom beståndsdelarna är externa går det ej att ändra på deras innehåll där de bäddats in i en IFrame p.g.a. den så kallade ”same-origin policy”:n [27]. Policyn innebär att en webbsida endast kan ändra innehållet av en annnan webbsida om de kommer från samma ursprung. Detta begränsar en del det som skulle önskas göra med Power BI:s besåndsdelar vid inbäddning.

Figur 4.6: Konfigurationsobjekt

4.3

Mobilanpassning

Inbäddning av rapporter skiljer sig en del från inbäddning av övriga beståndsdelar på det sätt att det även går att ändra deras layout vid inbäddningen. Med layouten menas visualiseringarnas positioner och storlek inuti rapporten, vilka visualiseringar som ska visas, m.m. Med hjälp av detta kan t.ex. rapportens layout anpassas till mobiler genom att lägga alla visualiseringar under varandra på en enda kolumn ifall skärmstorleken motsvarar en liten enhet.

För att anpassa en rapports layout vid inbäddning så skickas ett inställningsobjekt med till konfigurationsobjektet. Figur 4.7 visar ett kodexempel av ett sådant inställningsobjekt. I inställningsobjektet sätts layouttypen (layoutType i exemplet) till anpassad. Sedan kan ett anpassat layoutobjekt (customLayout) läggas till i inställningsobjektet. I det anpassade layoutobjektet väljs hur den nya layouten ska se ut. Utöver layouten går det även att ställa in sidstorlek (pageSize) och utseendealternativ (displayOption). Den nya layouten görs ge-nom att skapa ett objekt med samma namn som den sida layouten tillhör (”ReportSection1”

Figur 4.7: Inställningsobjekt

i kodexemplet). Sedan i det objektet skapas ett objekt för varje visualisering med visua-liseringens namn (”VisualContainer1” i exemplet). Där specifieras visuavisua-liseringens storlek och position, eller om den ska vara dold. Det går även att skapa ett standardobjekt (de-faultLayout) som gäller för alla visualiseringar som ej specificeras.

5

Projektimplementation och resultat

Det här avsnittet beskriver arbetsprocessen under projektets gång, vilka problem som har uppstått och lösningar som genomfördes. I avsnitt 5.1 beskrivs arbetsprocessen kring inbäddning av Q&A samt de problem som uppstod. Avsnitt 5.2 beskriver inbäddning av rapport i portalens startsida, samt den problematik som fanns kring detta. I avsnitt 5.3 följer en beskrivning av hur mobilanpassning implementerades, tillsammans med arbetsprocessen och problemen kring detta.

5.1

Inbäddning av Q&A

Som beskrivet i avsnitt 4.2 så bäddas Power BI:s beståndsdelar in genom att hämta en inbäddningstoken med hjälp av Power BI REST API, samt en webbaddress där bestånds-delen hämtas ifrån. Dessa skickas till vyn där de sedan bäddas in. Q&A är som tidigare nämnts en färdig beståndsdel som hanteras av Power BI, och den bäddas in på samma sätt som andra beståndsdelar med hjälp av Power BI REST API.

5.1.1 Arbetsprocess

Målet gällande Q&A från QBIMs sida var att det skulle integreras i portalen på ett sådant sätt att den lätt kunde användas av kunder för att snabbt få svar på de frågor de eftersökte just i stunden. Därför fanns en ursprunglig idé om att bädda in funktionen på portalens startsida tillsammans med de rutor som redan låg där. Till höger i figur 5.1 visas ett exempel på hur detta såg ut när det implementerades i portalen.

Denna lösning valdes bort ganska fort då det konstaterades att startsidan med de många rutorna inte var gångbara prestandamässigt, då startsidan hämtades och laddades upp långsamt. Detta berodde på att varje ruta behövde hämta var sin inbäddningstoken från Microsoft Azure, och varje ruta behövde även bäddas in var för sig. Istället byttes rutorna ut mot en rapport, se avsnitt 4.2. När detta genomfördes lades Q&A istället nedanför

Figur 5.1: Q&A i ruta på startsidan

rapporten, som ett tillägg till den interaktiva startsidan. Detta gjorde dock att sidan kändes stökig, då både rapporten och Q&A tog mycket plats.

Flera andra varianter testades, där Q&A lades på olika positioner tillsammans med rapporten på startsidan. Den valdes till slut att tas bort från startsidan helt då den antingen uppfattades som att den tog för mycket fokus från rapporten, som bör vara huvudfokus, eller att den helt enkelt inte syntes tillräckligt för att vara ett användbart och tillgängligt verktyg. En ny lösning behövde därför tas fram där Q&A kan kombineras med rapporten på ett sätt som gör att den inte tar för mycket fokus eller känns i vägen.

Med denna kunskap i bagaget togs ytterligare en idé fram där det valdes att placera en knapp i övre menyraden som vid klick genererar en separat pop-up innehållande Q&A. Vi ser ett exempel på detta i figur 5.2. Denna lösning ger användaren möjlighet att själv bestämma om den vill utgå från den information som finns färdigställd i rapporten på startsidan, eller enkelt med hjälp av ett knapptryck söka specifik information utifrån egna nyckelord och söktermer.

Figur 5.2: Q&A i pop-up

dyker upp i en ruta som bara delvis täcker rapporten. Vid klick utanför ruta, exempelvis på rapporten eller i navigationsbar, minimeras den. När en fråga ställs dyker svaret upp i samma ruta utan att påverka rapporten och startsidan. På detta sätt får användaren känslan av att hen fortfarande befinner sig på startsidan vilket gör att det känns enklare att navigera mellan de två. På så sätt finns Q&A där som ett stöd och komplement utan att ta något ifrån rapporten som bör vara den främsta källan till information för användaren. Det finns fortfarande brister i lösningen i figur 5.2, dessa samt förslag på ytterligare förbättringar diskuteras i avsnitt 5.1.2.

5.1.2 Alternativa lösningar och problematik

Problemet med inbäddning av Q&A, som med inbäddning av många andra beståndsdelar, är bristen på att själv kunna påverka utseendet av beståndsdelen. Det skulle vara önskvärt att t.ex. göra Q&A-delen dynamisk genom att ändra storlek på den när den sätts i fokus, och att endast ha en smal textruta då den ej är i fokus, vilket skulle göra startsidan betydligt

snyggare och mer användbar än om funktionen i sin helhet låg inbäddad under eller ovanför rapporten. Det skulle då resultera i att Q&A inte tar för mycket fokus från rapporten då den bara finns synlig som en smal textruta när den inte används. Ett annat alternativ som diskuterades var att ha en enkel sökruta högst upp på sidan, ovanför rapporten, exempelvis i navigationsbar, där användaren kan skriva in en fråga, och först när ett svar genereras byts startsidan ut mot svaret på frågan, alternativt att en pop-up renderas för att visa svaret. Denna lösning är mycket lik den lösning som visas i figur 5.2, skillnaden är just funktionen att ha en ordentlig sökruta för att göra funktionen synligare och tyligare för användaren, för att uppmuntra att den används i större utsträckning.

Med båda dessa alternativ tar Q&A enbart fokus från rapporten om användaren själv tycker att startsidan inte ger de svar hen önskar och därför väljer att använda Q&A istället. Ett annat alternativ skulle vara att lägga in Q&A som en del av en rapport, med samma ”genomskinliga” utseende som delarna i rapporten. Det skulle ge ett snyggt enhetligt intryck då exempelvis bakgrunden skulle inkludera även Q&A. På så sätt förändras inte det rena helhetsintrycket av rapporten, och de två funktionerna kan fungera sida vid sida som komplement till varandra.

I dagsläget är ingen av dessa lösningar möjliga, då en så liten del av beståndsdelarna i Power BI går att förändra i programkoden. De olika delarna som bäddas in kan grafiskt förändras ytterst lite och kommer i färdiga behållare, och på så sätt ges väldigt lite frihet till utvecklaren, se avsnitt 4.2.3.

5.2

Inbäddning av rapport

En stor del av arbetet var att byta ut de statiska rutor som från början fanns på portalens startsida till ett mer interaktivt alternativ för att skapa fler möjligheter för användaren att upptäcka information. Det var även viktigt att lösningen tillgodoser behovet att enkelt kunna använda och interagera med portalen via en mobil enhet. Ett lösningsförslag till detta var att ta bort startsidans rutor och ersätta dessa med en hel, interaktiv rapport.

5.2.1 Arbetsprocess

I portalens utgångsläge bestod framsidan av ett antal rutor, cirka tio stycken. Problemet med detta var att sidan tog avsevärt lång tid att ladda, eftersom renderingen av varje enskild ruta kräver hämtning av en egen åtkomsttoken, samt inbäddning var och en för sig. Rutor går heller inte att interagera med, vilket är en mycket önskvärd möjlighet ur ett användarperspektiv.

Ett förslag på en lösning var att enbart bädda in en hel, interaktiv rapport på startsidan, där alla visualiseringar som ska vara på startsidan lagts in i förväg, med hjälp av Power BI Service. Lösningen gör det även enkelt att skräddarsy varje startsida efter varje specifik kund, i och med att enbart en rapport bäddas in på startsidan och att själva utseendet, bakgrunden, innehållet mm. enkelt anpassas direkt i rapporten i Power BI Service. Detta gör även koden mer användbar i framtiden, då den som inte kan programmera enkelt kan förändra startsidan genom det enkla användargränssnitt som Power BI erbjuder vid skapande av en rapport. Det gör också att steget för att förändra startsidan efter behov känns betydligt mindre.

Lösningen var enkel att utföra med hjälp av den teknik, inbäddning, som beskrivs i avsnitt 4.2. I figur 5.3 visas resultatet av denna lösning. I jämförelse med utgångsläget i figur 4.1 så ger den nya lösningen ett renare, mer enhetligt och professionellt intryck med hjälp av bl.a. att bakgrunden syns och binder samman de olika beståndsdelarna. Den nya löningen ger också möjligheten till interaktion med exempelvis valmöjligheter för att välja säsong eller veckodag, samt att staplar och diagram går att klicka på och interagera med för att få ut ytterligare information. Rapporten i figur 5.3 är helt skapad i och hämtad direkt från Power BI, så de olika visualiseringarna kan enkelt flyttas runt, anpassas och pusslas ihop i Power BI helt utan att komma i kontakt med koden. Den nya lösningen resulterade dessutom i en betydlig förbättring i tid för att ladda portalen vid inloggning eftersom enbart en beståndsdel behöver laddas.

Figur 5.3: Resultat av rapportinbäddning

5.2.2 Alternativa lösningar och problematik

Problemet med inbäddning av rapporter i en applikation på detta sätt är mycket detsamma som med Q&A, bristen på att själv som utvecklare kunna påverka utseende och funktioner i den utsträckning som i vissa fall kan vara önskvärd.

Ett tydligt exempel på detta visas i figur 5.4. I figuren ser man tydligt en grå marginal som skiljer den övre navigationsbaren och den inbäddade rapporten åt, något som självklart inte är önskvärt. Denna kant går inte att eliminera, då den orsakas av att dimensionerna på rapporten ändras någorlunda i förhållande till dimensionerna på den behållare den ligger i om den ändrar storlek från sitt ursprungsläge. Båda dessa mått ligger hos Power BI och är något som inte går att förändra i koden. Det Power BI vill åstadkomma med detta är att anpassa rapporten till den yta som finns tillgänglig så bra som möjligt. Om den yta som finns att tillgå har perfekta proportioner i förhållande till de ursprungliga dimensionerna på en rapport anpassas rapporten efter detta och fyller hela utrymmet - utan grå marginal. Om ytan sedan ändras, exempelvis vid förminskning av fönstret, försöker Power BI att

Figur 5.4: Exempel på grå marginal

kompensera för detta och därmed lägga till denna gråa marginal i över- och underkant eller till höger och vänster om rapporten, och ibland läggs även en scrollfunktion till, allt för att kunna visa rapporten så komplett som möjligt på den yta som finns att tillgå. Rapporten centreras även automatiskt på ytan. Detta sker alltså även om själva ytan också anpassar höjd och bredd efter ursprungsdimensionerna på rapporten, och därmed alltså fortfarande borde ha perfekta proportioner för en rapport. Detta är ett bra exempel på kod som finns där för att hjälpa någon som inte har programmeringskunskaper men som kan ställa till det om man själv vill kunna anpassa sin applikation på en mer avancerad nivå. Många försök gjordes för att försöka få bort den gråa marginal som uppstår men det finns i nuläget ingen enkel väg runt detta problem.

En alternativ lösning till den som valdes är att bädda in enskilda visualiseringar istället för en hel rapport. Då skulle alltså de rutor som fanns på startsidan i utsprungsportalen, se figur 4.1, finnas kvar men istället innehålla interaktiv data. En ensamstående visualisering

är ungefär detsamma som en rapport som endast innehåller en enda visualisering. Genom att bädda in en ensamstående visualisering istället för en ruta, så blir det möjligt att inte-ragera med visualiseringen, som om den skulle ha legat i en rapport. Visualiseringarna kan användas tillsammans med rutor på en startsida istället för en rapport för att kringå några av de nackdelar som förekommer med rapporter. Till exempel kan bakgrundsbilder m.m. läggas in och layouten ställas in i vyn istället för att de läggs in och automatiskt följer med rapporten. Detta är ett bra alternativ exempelvis om inte så många visualiseringar behöver finnas tillgängliga på startsidan, och det löser även problemet med att kunna lägga delar som exempelvis Q&A på andra placeringar än under eller över rapportdelar. Anledningen till att denna lösning valdes bort var återigen den tid det skulle ta att visualisera alla rutor var för sig då det i det här fallet behövs så pass många rutor och visualiseringar.

5.3

Mobilanpassning

Som tidigare nämnts har många av portalens användare ett väldigt rörligt jobb där de använder mobiler och surfplattor istället för datorer, därför anses det viktigt att få en bra layout på startsidan till mobiler och surfplattor. För att anpassa startsidans utseende till mobila enheter är det önskvärt att visualiseringarna i rapporten exempelvis hamnar på en enda kolumn så att varje visualisering syns bättre och är lättare att interagera med, samt att storlek på text och dylikt blir större så att den enkelt kan läsas på en liten skärm.

5.3.1 Arbetsprocess

Första versionen av mobilanpassning gjordes genom att lägga in en anpassad layout till samma rapport som användes för stationära och bärbara datorer, där varje visualiserings position och storlek ändrades manuellt i HTML-filen med hjälp av Power BI JavaScript API. Detta gjordes genom att hämta alla visualiseringar ur rapporten med hjälp av Power BI REST API. Visualiseringarna sorterades sedan i storleksordning med största först, då de största visualiseringarna ofta är de viktigaste och vill ses vara först i ordningen, och

efter det lades alla på en kolumn så att mobilskärmen endast tar upp en visualisering i bredd. Detta fungerade för att ändra layouten till en mer mobilanpassad vy, men löste inte problemet med exempelvis liten text. Alla visualiseringar såg fortfarande likadana ut som i webbläsare på stor skärm, vilket resulterade i att de blev alldeles för små och detaljerade och inte användbara.

Nästa version gjordes genom att, istället för en anpassad layout på samma rapport, skapa en ny rapport i Power BI Service som var anpassad till att endast visas i mobiler och surfplattor. I koden kontrolleras vilken storlek skärmen har, och är det en mobil enhet bäddas denna rapport in istället för ursprungsrapporten. Denna version var lättare att få till ett bra utseende på då det kunde göras visuellt direkt i Power BI Service istället för med kod. Dessutom kunde varje mobilanpassad rapport skräddarsys istället för att ha samma layout till alla rapporter. Även saker som bakgrundsbild och innehåll går enkelt att förändra med denna metod.

5.3.2 Alternativa lösningar och problematik

Även om det finns stöd för anpassad layout för att ändra rapportens utseende även från koden så är det ej tillräckligt för allt som önskas. Bland annat skulle det vara önskvärt att kunna ändra på bakgrunden så att den är fixerad till bildskärmen istället för att följa med rapporten. Detta skulle kunna gå om en extern bakgrundsbild användes och att IFrame gjordes transparent, men i dagsläget går innehållet i iframen ej att påverka utseendemäs-sigt. Orsaken är att då innehållet är externt så tillåts det inte att ändras på, på grund av säkerhetsskäl. Även detta är ett exempel på kod som ligger hos Power BI och som under-lättar för användare som inte vill behöva programmera, men istället sätter käppar i hjulet för den som vill anpassa innehållet ytterligare.

6

Slutsats

I det här kapitlet presenteras och diskuteras resultatet och slutsatsen av det här projektet. Avsnitt 6.1 utvärderar projektet i sin helhet, inte utifrån ett tekniskt perspektiv utan uti-från tankar och känslor kring arbetets gång. Avsnitt 6.2 presenterar problem som uppstått och en diskussion kring användandet av ett färdigt API, i detta fallet Power BI REST API. Avsnitt 6.3 behandlar hur vidareutveckling kan ske kring portalen, och framför allt i för-hållande till Power BI. Avsnitt 6.4 är en sammanfattande avslutning på det här projektet.

6.1

Projektutvärdering

Projektet var lärorikt att utföra, speciellt då vi fick jobba tillsammans med ett företag, något som var nytt för oss. Vi fick chansen att testa att jobba med nya verktyg och mjukvara som vi inte tidigare stött på, och lärde oss ett helt nytt område, BI, som ingen av oss tidigare var kunniga inom. Mycket av det vi hade väntat och föreställt oss att uppdraget skulle innebära innan vi började visade sig inte alls stämma överens med verkligheten. Trots detta var det ett väldigt givande uppdrag.

Det tog ett tag att sätta sig in i den kod och det material som vi försågs med, mestadels då vi behövde lära oss att hantera mycket ny mjukvara och verktyg. Det var mycket läsning till en början vilket var en utmaning, då mycket av det material som finns skrivet om de områden projektet behandlat antingen är väldigt ytligt och därför inte ger en djupare förståelse, eller väldigt tekniskt och detaljerat vilket var svårt att förstå för en icke insatt. Trots den ganska långsamma uppstarten har projektet i sin helhet varit mycket givande, och tack vare en kontinuerlig dialog med QBIM har vi fått mycket insikt och fått göra mycket, vilket har varit motiverande och roligt. I slutändan presenterar vi ett slutresultat både vi och QBIM är nöjda med.

6.2

Problem

I projekt som detta är det oundvikligt att stöta på problem av olika storlek och grad. Även under detta projekt fanns uppförsbackar att bestiga. De flesta problemen var mindre problem, oftast länkade till praktiska saker så som exempelvis att hitta en bra rutin för att alla inblandade ska ha samma uppdaterade kod, för att publicera rätt kod på webbplatsen och inte av misstag tappa bort saker som redan gjorts för att koden skrivs på olika datorer. Kortfattat hade bättre versionshantering behövt, då GitHub användes men inte korrekt och regelbundet. Dessa problem hade kunnat undvikas om exempelvis GitHub hade använts kontinuerligt och på ett bra sätt, men i och med att projektet var väldigt kort och författare och mentorer inte var vana vid att använda GitHub så föll det mellan stolarna. Problemet hade även kunnat lösas med den funktion som ingår i Microsoft Azure Web Apps vilket diskuteras i avsnitt 3.2. som ordnar detta på ett smidigt sätt. Dock var ingen av oss medvetna om denna funktion förens sent i projektet, och detta är därför något som föreslås som ett hjälpmedel vid vidareutveckling av portalen för att slippa just denna problematik.

6.2.1 Problematik kring Power BI REST API och Power BI JavaScript API

Det största problemet som uppstod under projektets gång var det kring användandet av ett färdigt API, och med detta bristen på att kunna påverka innehållet av de funktioner som bäddades in med hjälp av Power BI API:erna. Detta problem uppstod eftersom det ej gick att ändra i koden direkt då extern kod som bäddas in ej kan ändras på på grund av säkerhetsskäl. Inbäddningsobjekten kan endast påverkas med hjälp av Power BI REST API samt Power BI JavaScript API, vilket begränsar till stor del det som går att använda Power BI till. Detta är väldigt smidigt i situationer där utvecklaren antingen inte har så mycket kunskap, eller där hen vill ha en enkel lösning och inte behöver anpassa innehållet väldigt specifikt. I detta projekt gav det dock väldigt liten frihet och var därmed ett hinder i arbetet, då mycket av det som önskades inte gick att utföra p.g.a. att så mycket redan är färdigt och inte går att påverka. Många av de idéer som fanns slopades helt enkelt,

antingen för att de inte var genomförbara eller för att lösningarna skulle bli alldeles för komplicerade för den lilla resultatskillnad den skulle bidra med.

6.3

Vidareutveckling

Power BI är ett relativt nytt system som ständigt är i utveckling. Därför kommer det med stor sannorlikhet nya funktioner till Power BI som senare skulle kunna implemente-ras till SKI-ANALYTICS-portalen. Detta projekt har även enbart berört och fokuserat på portalens framsida. De andra av portalens sidor, så som sidan för rapporter och instru-mentpaneler, även om de i nuläget är befintliga, skulle kunna gå att se över om de behövs förbättras för att kunna erbjuda en ytterligare nivå av användbarhet.

Utöver de funktioner som Power BI erbjuder så skulle projektet behöva en del övri-ga funktioner för att fungera bra som ett system i helhet. Bland annat skulle det vara önskvärt att implementera ett supportsystem där portalens användare kan ställa frågor eller rapportera buggar angående portalen till någon supportansvarig, då detta inte finns i nuläget.

Som tidigare nämnts hade det även varit en bra idé att ta till vara på de resurser som Microsoft Azure erbjuder för en smidig versionshantering och publicering till webb. Hade detta använts under detta projekt hade den stora andel tid som lagts på detta istället kunnat läggas på att lösa problem med portalen.

6.4

Sammanfattning

Projektet gick i stora drag bra. De tre målen som fanns vid projektstart - Inbäddning av Q&A, inbäddning av rapport och mobilanpassning har implementerats och är vid projektslut uppfyllda. Det största problemet med att göra ett examensarbete om BI var att Power BI var ganska begränsad i antalet användningsområden som går att ha med i projektet. Även de användningsområden som fanns var ganska begränsade i vad som gick att göra med varje område vad gäller inbäddning till portalen. Det mesta Power BI används

till görs i själva Power BI Service eller Power BI Desktop. En anledning är att Power BI är relativt nytt och är ständigt under utveckling. I slutet uppnåddes ändå ett resultat som går att använda i praktiken och som uppnår de önskemål som uppdragsgivaren hade vid projektstart. Vid framtida vidareutveckling föreslås att ytterligare utnyttja de hjälpmedel som erbjuds och tillhandahålls med Power BI och Microsoft Azure.