Jeg har tidligere skrevet om hvordan du henter data via API til Power BI.
Et populært innlegg, men stort sett en feel-good intro som ikke lenger hjelper deg når livet i API-verden blir tøft. Og det har en tendens til å bli tøft.
Og dette har bare blitt enda mer relevant nå som du kan lage egne datavarehus (Datamarts) direkte via Power BI.
Så her kommer den litt teknisk nerdete oppfølgeren med syv problemer du bør være oppmerksom på når du henter data fra API til Power BI.
Det er en fantastisk stor verden av muligheter der ute når du først får kontroll på disse problemstillingene.
Så er ikke detaljerte løsninger på problemene er ikke hensikten med dette innlegget, men du skal vite at alt her lar seg løse ved mye og god googling (eller kontakt meg, da).
1) Autentisering
Første steg knekker fort motivasjonen for noen og enhver. APIer kan nemlig ha mange ulike former for autentisering:
- Ingen autentisering
- Et enkelt passord (token)
- To koder som må kombineres til et passord via Base 64 Encoding
- Et passord som du må sende for å få et nytt passord som varer i x antall minutter
- ... sikkert mange flere metoder
For de enklere variantene går det helt fint å bruke Power BIs innebygde autentiseringsmetode, men for de mer komplekse må du herje litt i Power Query (M).
2) Headers
På samme måte som APIer stiller ulike krav til autentisering, så krever også mange at du sender spesifikk informasjon via "Headers". Dette kan være hvilket filformat du skal ha i retur eller andre tilsvarende teknikaliteter.
Dette kan løses via UI om en trykker "Advanced" når en bruker Web-connectoren, eller du kan skrive M-koden selv.
3) Paginering
Noen API gir deg all dataen du spør om. Andre sender deg litt og litt - og sier noe sånn som "det er 5340 resultater i spørringen du ber om. Her er side 1 med de 100 første".
Også her finnes det mange ulike metoder for å spørre om hver enkelt side for de 5340 resultatene, men det vil uansett medføre en del kompleksitet i spørringen (og kreve at du kjenner punktene under).
4) Functions
Ofte vil jobbing med APIer kreve at du spør etter data flere ganger. Som i eksempelet over eller om du først må hente en liste over prosjekter for å deretter hente detaljer per prosjekt.
Ved å klikke "Create Function" på en tabell i Power Query, så lager du en funksjon som kan kjøres om og om igjen. Eller så kan du legge til en "custom column" og kjøre egne API-spørringer for hver rad i datasettet.
5) Parameter
For å håndtere Paginering og Functions så trenger du ofte å bruke parameter. Dette er en fleksibelt input-kilde som lett kan endres og varieres.
For eksempel trenger et parameter i funksjonen om du vil kjøre den for å hente detaljer fra mange ulike prosjekter (og ikke bare hente detaljene for et og samme prosjekt mange ganger).
6) Relative Path
Så, etter langt om lenge, når du endelig har kommet i mål og alt fungerer greit i Power BI Desktop, så møter du det siste nådestøtet fra Microsoft: feilmelding etter feilmelding når du forsøker å oppdatere datasettet i Power BI Service.
Autentiseringsmetodikken er nemlig annerledes der enn i Power BI Desktop, så du må "lure" dem litt via å legge inn en kodesnutt med RelativePath i Power Query. Igjen, her her Google din venn - det finnes mye god dokumentasjon.
7) Manglende API-dokumentasjon
Problemstillingene du må håndtere i Power BI er ofte mye for mange av oss. Det siste vi trenger da er dårlig dokumentasjon på APIet i seg selv.
Heldigvis er de fleste populære APIene godt dokumentert, men det skjer også rett som det er at det er nødvendig informasjon som er utelatt - og du er overlatt til deg selv med mye prøving og feiling.
Lykke til!