SÅ BYGGER DU EN POWER BI-LÖSNING DIREKT MOT NAV

Den här bloggen kommer att ge råd kring hur du kan bygga en Power BI-lösning direkt mot Dynamics Navision med hjälp av oData.

MÖJLIGHETER OCH UTMANINGAR MED LÖSNINGEN
När vi tänker på en Microsoft BI-lösning så innebär det ofta en lösning som innehåller såväl ett källsystem som en databas, eventuellt en analyskub samt rapporter skapade i Power BI. Det innebär dels att varje del i lösningen gör det som den är bäst på och att det därmed också går att minimera svagheter som respektive del annars skulle kunna ha bidragit till. Samtidigt kan det vara så att det av någon anledning kan vara ett bättre alternativ att bygga en BI-lösning direkt i Power BI, dels för att snabbare ta fram färdiga rapporter som sedan går att utvärdera men även för att hålla nere investeringskostnaderna under en utvärderingsfas. Frågan blir då, går det att bygga en Power BI-lösning mot NAV och hur går det i så fall till?

Baserat på tidigare erfarenhet vill jag med den här bloggen diskutera kring vilka möjligheter och utmaningar det finns med att bygga denna typ av lösning. Vilka tekniska förutsättningar som kan tänkas finnas inledningsvis samt även vilka avvägningar som kan vara viktiga att betrakta under resans gång.

För den som endast vill använda Power BI är mycket möjligt att göra både när det kommer till att transformera och modellera datan men även att utföra kraftfulla analyser med hjälp av DAX-kod.

POWER BI, NAV och odata
För att Power BI ska kunna koppla upp sig mot Microsoft Dynamics NAVISION, nedan kallad NAV, används oData som en mellanliggande anslutning vilket ger en högre säkerhet då användaren kopplar upp sig mot oData och inte mot NAV SQL- databasen direkt. Användaren måste även sättas upp som en användare i NAV och  kan då endast se det som den har tillgång till i NAV. Det ger en möjlighet att på ett bra sätt rapportera mot företagets data.

UTMANINGARNA
Det finns ett antal olika utmaningar när det gäller att bygga en sådan här lösning. Den första är att ta reda på men även förstå vilket utgångsläge som man startar ifrån. Dels vilken version av NAV som används men även hur strukturen i källsystemet ser ut. När det gäller struktur handlar det om vilka tabeller som ska användas för att svara på de frågor som lösningen ämnar besvara. Nästa utmaning är att bygga Power BI-lösningen mot källdatasystemet utan mellanliggande databas, då all logik och modellering behöver göras i Power BI.

MÖJLIGHETERNA
För att kunna koppla upp Power BI mot NAV så behöver först ett antal inställningar i NAV-instansen göras. En användare och ett lösenord behöver skapas som sedan används för att få tillgång till data från Power BI. Dessutom behöver de tabeller som ska användas först skapas som en Page eller Query i form av en oData URL. De behöver sedan exponeras för oData som en webbtjänst.

 

4 RÅD PÅ VÄGEN NÄR DU BYGGER DIN LÖSNING!

  1. Beroende på vilken version av NAV som används så ändras även det bästa sättet att koppla upp sig mot NAV. NAV finns i versioner fram tom 2018, senare versioner går sedan över till Dynamics 365 Business Central även kallad BC. För senare versioner av NAV samt för BC finns det färdiga kopplingar “connectors” som tagits fram för att göra uppkopplingen bättre och mer effektiv. Därför kan det vara en bra idé att se till att uppdragsgivaren har en senare version av NAV. Om det ej är möjligt kan mer tid behöva läggas på utveckling.
  2. Det är viktigt att ta reda på hur den nuvarande rapportlösningen ser ut och vilka behov och önskemål som finns. Utifrån den här informationen går man igenom vilka tabeller som behövs för att sätta ihop Power BI-lösningen. Det kräver att det finns en god insikt i hur NAV/BC-instansen är konstruerad med sin databasdesign.
  3. Då datamängden kan bli väldigt stor kan det vara bra att begränsa den data som importeras till Power BI genom att sätta en begränsning i NAV-queryn men det går även att använda sig av filtermöjligheter från Power BI’s sida. Filtrering kan göras på såväl datum som kolumn eller kategori, och denna filtrering görs direkt i den oData URL-adress som används för att hämta data från NAV via oData. Några exempel är Top, Select och Filter.
  4. En god förståelse för hur data transformeras, modelleras och analyseras krävs. Det innebär att en djup kunskap i Power BI’s utvecklingsapplikation behövs, då Power Query editor och DAX-kod används mycket. Ett exempel är ifall nya kolumner ska skapas i Power Query med M eller i Desktop med DAX. Generellt ska så många kolumner som möjligt skapas i Queryn då de annars tar upp kapacitet i den datamodell som laddas in i Power BI.

SÅ ANVÄNDER DU DITT DATA PÅ BÄSTA SÄTT!
I takt med att tillgången och mängden data blir allt större så blir det också allt viktigare att använda sin data på bästa sätt. Ett av sätten är att använda BI-verktyg direkt tillsammans med sitt källsystem.

Några frågor ni behöver besvara för att veta att ni har rätt förutsättningar på plats:

  • Har ni gått igenom de frågor som lösningen ämnar att svara på?
  • Är alla tabeller och kolumner som behövs identifierade?
  • Är lösningen byggd på ett effektivt sätt med hänsyn till den mängd data som hämtas och laddas in i datamodellen?
  • Hur kan lösningen byggas efter god datamodelleringsmetodik?
  • Används DAX för att ge den analytiska kapacitet som är möjlig?
  • Har visuellt tilltalande rapporter skapats samt hur kan de göras tillgängliga till de i företaget som skulle ha mest nytta av att ta del av dem?

Hör gärna av er ifall ni har några frågor eller funderingar!

MikaelNilsson

Mikael Nilsson
mikael.nilsson@advectas.se
Jag som skriver detta heter Mikael Nilsson och arbetar som Business Intelligence-konsult. Mitt fokus är Microsofts BI-verktyg och Tableau. Jag är utbildad ekonom och har tidigare arbetat som controller. På Advectas sysslar jag främst med kravställning, rapportutveckling och att skapa Dashboards.

Alla inlägg av Mikael Nilsson

BI- & Data Science Day - i år digitalt och helt kostnadsfritt!

Mer info & anmälan