Tässä blogikirjoituksessa käsittelen eri tapoja hyödyntää Microsoft Dynamics 365 for Finance and Operations (D365 F&O) -toiminnanohjausjärjestelmästä saatavaa dataa analytiikan tarpeisiin. Artikkelin kirjoitushetkellä F&O:n dataa voidaan lukea ja siirtää ulkoisten järjestelmien käyttöön neljällä eri tavalla, jotka kuvaan seuraavaksi.
OData-rajapinta
Yksinkertaisin, mutta myös rajoittunein tapa on lukea F&O:n dataentiteettejä suoraan järjestelmästä OData-yhteydellä. Tämän tavan hyvänä puolena voidaan nähdä sen yksinkertaisuus sekä itse yhteydenmuodostuksen näkökulmasta, mutta myös siten, että se ei vaadi mitään muita datan tallennusjärjestelmiä – eikä siten myöskään aiheuta lisäkustannuksia. Data voidaan siis lukea suoraan Power BI:hin ja data tallennetaan semanttiseen malliin, mistä sitä voidaan hyödyntää raporteissa.
ODataa käyttäen tiedot pyydetään suoraan järjestelmästä, muilla tavoilla data viedään ulkoiseen tallennusmediaan F&O:n toimesta. Tämä datan lukutapa soveltuu pienten ja selkeiden kokonaisuuksien lataamiseen. Kirjanpidon pääkirjan tyyppisiä entiteettejä en suosittele ladattavaksi ODataa käyttäen, eikä sitä suosittele Microsoft itsekään.
ODatan ehdottomana huonona puolena voidaan pitää latauksen vasteaikaa, tämä on selkeästi hitain tapa lukea dataa ulos F&O:sta. Myös se, että data luetaan jokaisen semanttisen mallin päivityksen yhteydessä suoraan lähteestä, voidaan nähdä sen ajantasaisuudesta huolimatta huonona puolena: mikäli yhdenkin entiteetin lataus päätyy virheeseen, koko semanttisen mallin päivitys pysähtyy, eikä mikään osa datasta päivity malliin. Käytä ODataa siis vain yksinkertaisissa ja ei-liiketoimintakriittisissä käyttötapauksissa, tai ad-hoc -tyyppisessä tarkastelussa. OData voisi olla käyttökelpoinen esimerkiksi yksinkertaisessa osto- tai myyntitilausten raportoinnissa tai kevyessä projektiraportoinnissa.
Bring Your Own Database (BYOD)
Seuraava tapa on replikoida F&O:n data Azure SQL -tietokantaan käyttäen Bring Your Own Database (BYOD) ominaisuutta. Tässä tavassa vaatimuksena on Azure SQL-tietokanta ja siten myös Azure-tilaus. Tietokannan tulee olla provisoidussa mallissa, eli saatavissa jatkuvasti ja välittömästi, ja datan määrä asettaa myös vaatimuksia tietokannan suorituskykyyn ja siten myös suoraan kustannuksiin.
Jokainen F&O-instanssi, josta halutaan viedä dataa ulos (Prod, Test, Dev), vaatii oman tietokantansa, joten vastaavien kerrosten rakentaminen data-alustalle edellyttää näiden tietokantojen perustamista. BYODia käyttäen data viedään tietokantaan eräkäsittelyssä ajastettuna.
Datan vientiin käytetään F&O:n entiteettejä, kuten ODatassakin, ja sen päivitys voidaan määritellä tehtäväksi joko koko datan päivityksenä (Full push) tai vain muutosten osalta (Incremental). Myös näiden erilaisia yhdistelmiä käytetään; data voidaan päivittää SQL-kantaan arkipäivisin vain järjestelmään syntyneiden muutosten osalta ja viikonloppuisin suoritetaan datan täyspäivitys. Tällä saavutetaan tilanne, jossa mahdolliset yksittäiset päivityspuutteet korjaantuvat viikonlopun täyspäivityksessä.
BYODin hyvinä puolina voidaan pitää datan laajempia käyttömahdollisuuksia. SQL-tietokannasta dataa voidaan lukea useisiin eri järjestelmiin ja kopio datasta on käytettävissä ilman pääsyä F&O:iin. Myös datan lukeminen SQL-tietokannasta on nopeampaa eikä kuormita tarpeettomasti lähdejärjestelmää.
BYODin huonoina puolina voidaan pitää siitä aiheutuvia kustannuksia. Microsoftin suosittelema SQL-tietokannan minimitaso on S4, jonka suorituskyvyn rajat saattavat tulla vastaan nopeastikin. Toinen huono puoli on datan päivityksen rajoitteet eräkäsittelyn ja entiteettien näkökulmasta; päivitykset pitää ajastaa F&O:ssa käyttäen eräkäsittelyä, ja tilanteessa, jossa dataa halutaan viedä tietokantaan useita kertoja päivässä, voidaan päätyä tilanteeseen, jossa samaa dataa viedään kahdessa käsittelyssä. Tämä vaatii käytännössä aina käyttäjän toimia, jossa viivästynyt käsittely lopetetaan manuaalisesti. Kolmas huono puoli on entiteettien rajallisuus. Kaikkia ODatan kautta saatavia entiteettejä ei ole mahdollista viedä BYODiin ilman ylimääräistä ohjelmointia. Myös entiteettien muokkaus on lähes aina tarpeen, tavallista on lisätä tietosarakkeita, jotta eri entiteettien rivit voidaan yhdistää tietokannassa. Klassinen esimerkki on myyntitilausrivin yhdistäminen myyntilaskuriviin, joka vaatii tapahtumatunnuksen lisäyksen entiteettiin. Tämä on toki myös ODatan huono puoli, eikä rajoitu vain BYODiin, koska molemmissa pelataan samojen entiteettien kanssa, vaikkakin eri rajapintojen kautta.
BYODia voidaan käyttää tietovaraston rakentamisessa, mikäli datan päivitysten aikataulut ja rajoitteet eivät aseta kohtuuttomia vaatimuksia. BYOD voi olla myös käyttökelpoinen tilanteessa, jossa F&O:n data pitää saada sellaisen ulkoisen järjestelmän käyttöön, jossa on rajoittuneet integraatiomahdollisuudet. BYOD ei sovellu lähes reaaliaikaisen replikoinnin vaatimuksiin, päivätason vaatimukset sillä voidaan kuitenkin täyttää hyvin.
Export to Data Lake
Kolmas tapa on Export to Data Lake. Tai pitäisikö sanoa oli. Tämä oli todellakin väliaikainen tapa saada F&O:n data ulos ja käytettäväksi laajemmin. Microsoft on ilmoittanut, että olemassa olevat toteutukset toimivat 1.11.2024 saakka, mutta uusia toteutuksia ei tämän varaan ole syytä rakentaa.
Otetaan tästä kuitenkin lyhyt kuvaus, koska se toimii alustuksena seuraavan tavan kuvaukseen. Export to Data Lake mahdollistaa datan replikoinnin Azuren Data Lakeen CDM-formaatissa taulutasolla. CDM-formaatti on lyhyesti kansiorakenne, jossa csv-tiedostot sisältävät datan ja json-tiedosto kuvaa rakenteen ja muut metatiedot. Export to Data Lakessa taulujen lukumäärä on rajoitettu 350 kappaleeseen ja kun otetaan huomioon se, että yksi entiteetti voi koostua kymmenistä yksittäisistä tauluista, tämä rajoite voi tulla nopeastikin vastaan.
Export to Data Laken hyvänä puolena olen kokenut sen luotettavuuden ja vasteajan. Aktivoimalla ”Near-real time data changes”, muutokset päivittyvät data lakeen minuuteissa, mistä se on käytettävissä data-alustalla käytännössä heti. Toinen hyvä puoli tässä tavassa ovat kustannukset. Datan tallentaminen data lakeen on huomattavasti halvempaa, kuin SQL-tietokantaan.
No sitten ne huonot puolet. Ensiksi itse datan tallennusformaatti csv. Se vie tarpeettomasti tilaa, on hitaampi käsitellä kuin esimerkiksi Parquet ja ei sisällä datan rakennetta tai tietotyyppejä. Nämä kuvataan toisessa tiedostossa, joka taas on json-muodossa. Tästä aiheutuu ilmeinen haaste datan hyödyntämiseen: datan ja sen rakenteen yhdistäminen luotettavasti ja mielellään yksikertaisesti. Tähän on kuitenkin tarjolla muutamia eri tapoja ja varmasti yleisin käytössä oleva tapa on hyödyntää CDMUtils-nimistä sovellusta joko komentoriviltä tai sen Data Factory versioita, jotka molemmat ovat vapaasti saatavilla Microsoftin Git reposta. CDMUtilin avulla luodaan Synapseen joko SQL-näkymät tai -taulut, ja joita voidaan sitten käyttää datan jatkokäsittelyssä.
Data siis säilyy data lakessa, mutta sen päälle virtualisoidaan SQL-rajapinta, mikäli halutaan käyttää Synapsea. Data voidaan lukea myös esimerkiksi Snowflakeen, mutta siihen ei ole tarjolla out-of-the-box sovellusta, mikä tekisi taulujen skeemat valmiiksi. Sparkille löytyy connector myös Microsoftin Git reposta.
Entäs ne entiteetit, joista aiemmissa tavoissa oli puhetta? Noh, onhan nekin siellä, tavallaan. Export to Data Lake mahdollistaa datan viennin käyttäen ”Enhanced Metadata” ominaisuutta. Käytännössä tämä mahdollistaa F&O:n käyttöliittymässä taulujen viennin kerralla siten, että valitaan haluttu entiteetti ja sen aktivointi vie kaikkien tarvittavien taulujen datat yhdellä kertaa data lakeen. Tämä ei kuitenkaan materialisoi valittua entiteettiä, vaan tallentaa SQL-scriptin, jossa on kuvattu kyseisen entiteetin rakenne, lähdetaulut ja niiden liitokset sekä mahdolliset datan rajauksen. Valitettavasti nämä entiteettirakenteet eivät ole 100 % toimivia, vaan saattavat vaatia joko muokkausta tai sitten jokin viitattu taulu ei ole saatavissa. Täysin automaattinen tämä prosessi ei siis ole, mutta puutteistaan huolimatta parempi ratkaisu, kuin BYOD tai OData-yhteys.
Azure Synapse Link for Dataverse
Mikä sitten käyttöön uusien toteutusten pohjaksi? Azure Synapse Link for Dataverse korvaa Export to Data Laken, ja on tällä hetkellä se tapa, millä dataa otetaan ulos F&O:sta. Synapse Link ei ole F&O:n sisäänrakennettu toiminnallisuus, vaan sitä hallinnoidaan Power Apps Maker -portaalissa. F&O on siis linkitettävä Power Platformin kanssa, jotta toiminnallisuus saadaan käyttöön. Synapse Link mahdollistaa taulujen ja entiteettien viemisen data lakeen, mutta poikkeuksena Export to Data Lake toiminnallisuuteen, Synapse Link vaatii toimiakseen Azure Synapse Workspacen ja Synapse Spark Poolin.
Sparkia käytetään data lakeen tallennetun CDM-muotoisen datan muuttamiseksi Delta Lake-muotoon. Delta Lake-formaatti on CDM:n tapaan tietynlainen kansiorakenne, jossa data tallennetaan parquet-tiedostoihin ja json-tiedostoissa ylläpidetään historia datan muutoksista, joka mahdollistaa mm. datan tarkastelun tietyltä ajanhetkeltä. Kuten jo edellisessä luvussa osin sivuttiin, csv on vain “tyhmä” tekstitiedosto, joka täytyy lukea aina kokonaan, kun sen dataa käytetään. Parquet sen sijaan on pakattu tiedostomuoto, se sisältää tietotyypit ja kolumnaarisuuden ansiosta siitä voidaan lukea vain halutut sarakkeet, jolloin tilankäyttö, datan eheys ja suorituskyky ovat merkittävästi paremmat kuin csv-perusteisella CDM-formaatilla. Kääntöpuolena Delta Lake-muunnoksen vaatima Synapse Workspacen perustaminen ja siellä Spark Pool ajaminen aiheuttaa lisäkustannuksia.
Synapse Linkin, kuten myös Export to Data Laken, paras ominaisuus on automaattinen datan päivitys. BYODista poiketen, enää ei ole tarvetta ajastaa datan päivitystä ulos F&O:sta, vaan kaikki muutokset viedään automaattisesti Synapsen Linkin avulla data lakeen, ilman tuntien viivettä. Kun data on päivitetty data lakeen, muodostetaan siitä Sparkilla Lake Database Synapse Workspaceen. Tätä virtuaalista tietokantaa voidaan kysellä kuten mitä tahansa muutakin Azuren SQL-tietokantaa, mutta sen data on tallennettuna avoimessa Delta Lake-formaatissa data lakessa, josta sitä voidaan hyödyntää myös muilla työkaluilla suoraan esimerkiksi Machine Learning-käyttötapausten datalähteenä.
Mikäli käytössä on Microsoft Fabric, voidaan F&O:n data tuoda saataville OneLakeen Link to Microsoft Fabric ominaisuudella. Kuten Synapse Workspacen tapauksessa, datan päivitystä ei tarvitse ajastaa, mutta siitä poiketen dataa ei siirretä ulos Dataversestä, vaan data tallennetaan Dataversen sisällä Delta lake-formaatissa. Fabric-työtilaan luotavaan Lakehouseen muodostetaan linkkien avulla ulkoiset taulut, jotka lukevat suoraan näitä Dataversen Delta-tauluja. Fabricissa dataa ei tarvitse siirtää tai kopioida, vaan se on suoraan hyödynnettävissä OneLakesta kaikkien Fabric-työkuormien välillä. Tämä on hyvin luonnollinen symbioosi, koska koko Fabricin datan tallennusfilosofia perustuu Delta Lakeen riippumatta siitä onko moottorina Spark, SQL tai Power BI:n tabular.
Loppusanat
Kuten voidaan todeta, kaikissa edellä mainituissa tavoissa on rajoitteensa, mutta hyvänä puolena todettakoon, että ne eivät ole toisiaan poissulkevia, vaan tarvittaessa dataa voidaan viedä BYODilla tietokantaan ja sitä voidaan täydentää ODatan kautta luettavilla entiteeteillä Power BI:n semanttisessa mallissa. Suuremmissa toteutuksissa ja tapauksissa, joissa tarvitaan entiteettien lisäksi myös F&O:n tauluja, lienee kuitenkin paikallaan ottaa käyttöön Synapse Link.
Me Trilakella olemme toteuttaneet ja olleet sparraamassa lukuisia ratkaisuja, joissa on suunniteltu sopivin/sopivimmat tavat lukea F&O:n dataa ja näin ollen saatu valjastettua se analytiikan tarpeisiin! Ota yhteyttä, niin katsotaan Teille paras ratkaisuehdotus ja aletaan hommiin!