UDF?

Mitä eroa on UDF:llä ja UDF:llä? Microsoft Fabricin kontekstissa paljonkin. UDF voi viitata Microsoft Fabricin User Data Functions -ominaisuuteen, jolla kehittäjät voivat uudelleen käyttää ja kutsua Pythonilla kirjoitettua logiikkaa Fabric-työtilassa.

Tämä artikkeli käsittelee kuitenkin toista UDF:ää; User Defined Functionia, joka on uusi Power BI:n semanttisiin malleihin kehitetty DAX-kielen ominaisuus. Sen avulla DAX-logiikkaa on mahdollista kierrättää ja hallinnoida keskitetysti. Aikaisemmin vastaavaa logiikan kierrätystä varten DAX:ssa on täytynyt tehdä mittariviittauksia tai muuttujia mittarin sisällä. Tämä on voinut aiheuttaa haasteita DAX:n tunnetusti hieman oikukkaan filtterikontekstin kanssa sekä heikentää perfomanssia kerrostetun laskentalogiikan takia.

Funktion rakenne

UDF:t koostuvat kolmesta eri osasesta: nimestä, parametreista ja lopuksi itse rungosta eli mitä parametreilla halutaan tehdä. Runkoa muista osasista erottaa ‘=>’-symboli.

Esimerkkifunktio, jossa suoritetaan parametrien a ja b välinen vähennyslasku

Kyseistä yksinkertaista esimerkkiä voisi käyttää mittarissa esimerkiksi seuraavalla tavalla:

Kaksi mittaria asetettu funktion parametreiksi

Tässä parametreina käytetään mittareita Planned Budget ja Actual Spend. Funktion tehtävä on tehdä vähennylasku näiden arvojen kesken. Funktiolle annetut parametrit voisivat yhtä hyvin olla myös vaikka numeerisia arvoja.

Funktion parametreille voidaan kuitenkin etukäteen asettaa syötettävän arvon tyyppi, alatyyppi ja parametrin tila tai mode. Tästä voisi ajatella, että UDF toimii kuin DAX-funktio eli se sallii vain tietyn tyyppisiä parametreja ja vääräntyyppinen arvo aiheuttaisi aina virheen, mutta funktio iteasiassa castaa vääräntyyppisen arvon automaattisesti sille asetettuun tyyppiin, jos mahdollista. Automaattinen castaus voi vaikeuttaa funktion debuggausta tietyissä skenaarioissa.

Funktiolle annettu parametrien tyypit ja arvoiksi numerot 20 ja 15

Tulos

Esimerkissä parametreille on annettu tyypiksi int64 ja modeksi val. Funktio palauttaa tuloksena 5. Nyt jos muutamme toista numeerista arvoa desimaaliluvuksi:

Toinen kokeilu, jossa luvun 20 tilalla 19.5

Mitä ihmettä, sama tulos

Tulos on edelleen 5 vaikka sen pitäisi olla 4.5. Arvo 19.5 on siis castattu kokonaisluvuksi 20, mutta funktio tekee tämän automaattisesti ilman sen suurempia herjoja. Vastaavanlainen tilanne ei toki ole mahdollinen esim. string -> integer -tilanteissa, jos funktion logiikka on rakennettu vain toista tyyppiä tukevaksi.

Tätä duoa ei näillä määrityksillä yhdistetä

Parameter passing mode

Funktion parametrille voidaan kertoa, että sen tulisi ottaa vastaan joko VAL tai EXPR-arvoja eli lausekkeita. Parametrit ovat oletusarvoisesti VAL-tyyppiä. Näitä parametreja voi verrata DAX-mittareista tuttuihin muuttujiin, sillä ne palauttavat arvoja.

EXPR-tyyppiset parametrit voivat olla lausekkeita ja ovat lähempänä mittariviittauksia, mutta poikkeavat niistä hieman. Mittari määritellään aina nykyisessä suodatin- ja rivikontekstissa, funktio luo oman kontekstinsa kutsuttaessa ja EXPR-parametrit ottavat tämän huomioon. Tämän eroavaisuuden kanssa on oltava tarkkana, varsinkin monimutkaisempien käyttötapausten suhteen.

Näiden kahden moodin eroavaisuutta voidaan demonstroida seuraavalla esimerkkifunktiolla:

Funktion runko voi olla myös monimutkaisempi lauseke

Tämän funktion lausekkeen tulisi laskea parametrin ‘amount’ arvo, kun ChannelName on Email. Syötetään parametrille nyt esimerkiksi mittari Planned Budget:

Budjetti-mittari sisään ja...

Funktio antaa tuloksen, kaikki näyttää toimivan mukavasti. Katsotaanpa kuitenkin vielä mitä tapahtuu, jos annamme parametrille modeksi EXPR:

Kokeilussa parameter passing modena EXPR

Hetkinen, lukuhan on paljon pienempi

Palautettu arvo on aivan eri luokkaa kuin ensimmäisessä esimerkissä, miksi? Kuten tämän kappaleen alussa mainittiin, parametrit ovat oletusarvoisesti VAL-muotoisia. Ensimmäisen esimerkin parametrille ei ole määritelty modea, joten funktio olettaa sen olevan VAL. Mihin tämä sitten vaikuttaa? VAL-modessa olevat parametrit käyttäytyvät tosiaankin hyvin samankaltaisesti kuin DAX-muuttujat eli ne palauttavat kiinteitä arvoja. Nämä parametrit eivät ota huomioon muutoksia kontekstissa, kuten esimerkissä ehtona olevaa kanavan nimeä. Funktio siis itseasiassa palauttaa koko budjetin summan, kanavasta välittämättä.

Jälkimmäisessä esimerkissä parametrille annetaan modeksi EXPR eli parametrin käytös muuttuu. Palautettava arvo ottaakin nyt huomioon parametrin ympärille annetun kontekstin ja palauttaa vain Email-nimisen kanavan budjetin.

Loppusanat

Funktiot tuovat DAX-kieleen ominaisuuksia, jotka tekevät semanttisten mallien logiikan rakentamisesta keskitetympää ja tehokkaampaa. Funktiot yhdistelevät ominaisuuksia sekä muuttujista että mittareista, mutta tuovat tämän lisäksi vielä uusia ominaisuuksia kehittäjän palettiin.

Esimerkki käyttötapauksesta funktioille voisi olla esimerkiksi semanttinen malli, jossa joudutaan toistamaan samaa koodilogiikkaa useissa eri mittareissa. Jos esimerkiksi edellä mainittujen Actual Spend ja Planned Budget-mittarien logiikkaan sisältyisi useita ehtoja ja molemmissa nämä olisivat samoja, (esim. kaudet saavat olla vain 1-10, tulosyksiköt 2 j 5 suljetaan ulos tms.). Funktioita käyttämällä logiikka on keskitetty ja sen hallinnoiminen on yksinkertaisempaa.

Mikäli funktioiden rakentelu itse ei kuitenkaan nappaa, ei tarvitse kokonaan luopua ajatuksesta käyttää niitä. Joukko ahkeria kehittäjiä rakentaa UDF-kirjastoa osoitteessa https://daxlib.org/, josta voi tarvittaessa hakea vetoapua tai ideoita. Omasta mielestäni erityisen kiinnostava kehityssuunta on funktioiden hyödyntäminen SVG-visuaalien luomiseen. Tästä aiheesta saattaisi irrota asiaa toiseen blogitekstiin hieman myöhemmin.