Mobiilisovellus myymälöiden tarkastajille 2.0 – Common Data Service for Apps

Yksi tämän vuoden kuumista jutuista (Microsoft-maailmassa) on Common Data Service (CDS) for Apps. Pöhinään nähden on hämmästyttävää, miten vähän siitä loppujen lopuksi yleisesti tiedetään.

CDS for Apps tarjoaa monenlaisia mahdollisuuksia, mutta tarkastellaan sitä tällä kertaa seuraavasta näkökulmasta.

CDS for Apps tarjoaa loppukäyttäjän käyttöön tietokannan ominaisuudet. Suorituskyvyn, skaalautuvuuden, relaatiot, näkymät ja indeksit. Siten ettei käyttäjän tarvitse ymmärtää tietokannoista juuri mitään.

PowerAppsin, Flown, SharePointin ja Power BI:n avulla voi hyvin vähäisellä teknisellä osaamisella rakentaa aivan oikeita ratkaisuja. Asioiden monimutkaistuessa muodostuu usein juurikin tietovarasto (SharePoint) rajoitteeksi. Korvaamalla SharePointin listat CDS for Apps:llä, voidaan rakentaa entistä laajempia (lue monimutkaisempia) kokonaisuuksia. Ilman ulkopuolisia kehittäjiä.

Houkuttelevaa. Mutta onko se totta?

On aika kokeilla tätä ihmelaitetta.

Esimerkki – Mobiilisovellus myymälöiden tarkastajille 2.0

Aiemmassa kirjoituksessa teimme mobiiliratkaisun myymälöiden auditointiin. 499 myymälää, jotka käytiin arvioimassa kerran. Tehdään tällä kertaa ratkaisu, joka mahdollistaa myymälöiden tarkastamisen vaikka kuukausittain.

Tietomallimme monimutkaistuu heti. Tarvitsemme omiin tauluihinsa

• Myymälät – Nimi, osoite, kuvaus, sijainti jne
• Tarkastusjaksot  – Jakson nimi, alku- ja loppupäivä
• Tarkastukset – Varsinainen tarkastustapahtuma. Tarkastuksen tulos, aika ja tarkastaja. Jokainen tarkastus liittyy yhteen myymälään sekä yhteen tarkastusjaksoon.

Kuvana suurinpirtein näin.

Ei vielä hirveän monimutkaista. Otetaan ratkaisun pohjaksi CDS for Apps ja katsotaan mitä tästä tulee.

Tietomalli

Entiteettien luonti

CDS for Apps:iin pääsee luomaan uusia ”tauluja” eli entiteettejä osoitteessa https://web.powerapps.com/ ja valitsemalla Data -> Entities.  Luodaan ensimmäisenä entiteetti myymälöille (Stores).

Haluamme tallentaa myymälöistä seuraavat tiedot

• Nimi
• Osoite
• Postinumero
• Kaupunki
• Tyyppi
• Lisätiedot
• Latitude
• Longitude
• Id

Nämä ovat entiteetin kenttiä (field). Kenttien tietotyypit kannattaa laittaa heti kohdilleen. Valikoima on riittävä.

Pienen näpyttelyn jälkeen Stores-entiteetti näyttää seuraavalta.

Luodaan seuraavaksi tarkastusjaksot -entiteetti (Store audit periods), joka sisältää seuraavat kentät

• Jakson nimi
• Jakson alkupäivä
• Jakson loppupäivä

Viimeiseksi luodaan koko ratkaisun pihvi, myymälöiden tarkastustapahtumat (Store audit events). Kentät ovat seuraavat

• Myymälän siisteys
• Tuotteiden näkyvyys myymälässä
• Auditoinnin suoritushetki
• Auditoija
• Auditointi suoritettu (kyllä / ei)

Relaatioiden rakentaminen

Kukin myymälän tarkastuskäynti liitty yhteen myymälään ja yhteen tarkastusjaksoon.

Lisätään nämä relaatiot malliimme Add relationship -toiminnolla. Kyseessä on auditointitapahtumien näkökulmasta monen suhde yhteen (Many-to-one) relaatiot.

Monen suhde yhteen relaatiot näkyvät entiteetissä lookup-kenttinä.

Tietomallimme runko on valmis. Entiteettien kentät sekä entiteettien väliset suhteet on määritelty.

Voimme ryhtyä viilaamaan.

Logiikan sisällyttäminen tietomalliin (rollups, calculations)

CDS for Appsin kantava idea on että saman tietomallin päälle voi helposti rakentaa useita sovelluksia. Tällöin on järkevää toteuttaa osa laskennasta / logiikasta suoraan tietomalliin.

Montako myymälää tällä tarkastusjaksolla on tarkastettu?

Lasketaan kullakin tarkastusjaksolla tarkastettujen myymälöiden lukumäärä. Tämä on helppo toteuttaa ns. rollupin avulla. Lisätään Store Audit Periods entiteetille uusi kenttä (Audit Count) ja luodaan Rollup.

Rollupin avulla voimme tehdä laskentaa hyödyntäen entiteettiin (relaatioiden avulla) liitettyjen toisten entiteettien arvoja. Tekemämme rollup laskee yhteen kuhunkin tarkastusjaksoon liittyvien tarkastusten lukumäärän. Ja ainoastaan ne joiden tila on ”tehty”.

Mikä tarkastusjakso on parhaillaan käynnissä?

Myöhemmin toteutettavan mobiilisovelluksen avulla käyttäjä voi suorittaa tarkastuksia ainoastaan nykyisellä tarkastusjaksolla. Sovelluksen toteuttamista helpottaa, kun tiedetään mikä tarkastusjaksoista on menossa.

Toteutetaan tämä suoraan tietomalliin. Luodaan tarkastusjaksolle uusi kenttä (Current Day), jonka arvoksi laitetaan laskennallista kenttää hyödyntäen kuluva päivä.

Tämän jälkeen lisätään toinen kenttä (Current Period), joka kertoo onko tarkastusjakso parhaillaan käynnissä (osuuko kuluva päivä tarkastusjakson alku- ja loppupäivän väliin).

Minkä nimisellä tarkastusjaksolla tarkastus on tehty?

Lisätään lopuksi myymälöiden tarkastus -entiteettiin laskennallinen kenttä, jonka arvoksi tulee sen tarkastusjakson nimi, johon kyseinen tarkastustapahtuma on liitetty. Tämä on typerää, sillä sama tieto löytyyy lookupin takaa. En kuitenkaan nopeasti keksinyt, miten saisin PowerAppsini muutoin toimimaan, joten mennään tällä.

Aineiston lataaminen tietomalliin

Entiteetteihin voi ladata sisältöä lukuisista tietolähteistä.

Meillä on myymälät myös Azuren SQL-kannassa, joten lataamme ne sieltä. Ensiksi yhteys tietokantaan.

Valitaan oikea taulu.

Aineistoa voi käsitellä monipuolisesti. Tehdä tietotyyppimuunnoksia, poistaa rivejä, korvata arvoja jne.

Lopuksi mäpätään SQL-kannan kentät entiteetin kenttiin. Voit halutessasi luoda aineiston pohjalta myös uuden entiteetin.

Voit määritellä poistetaanko entiteetin kaikki vanhat rivit ennen päivitystä, vai lisätäänkö ainoastaan uudet ja muokataut rivit.

Lopuksi voit ajastaa latauksen mikäli haluat.

Hetkinen, tämähän on lähes sama työkalu kuin Power BI:ssä!

Huom! Sisällön päivitys on yhdensuuntainen. Lähdejärjestelmässä päivitetyt rivit päivittyvät CDS for Apps:iin. Mutta CDS for Apps:ssa päivitetyt tiedot eivät siirry lähdejärjestelmään.

Auditointitapahtumien automaattinen luonti

Tarkastuskäyntien suunnittelua helpottaa, mikäli myös tulevien tarkastusjaksojen  tarkastuskäynnit löytyvät valmiiksi järjestelmästä.

Käytännössä aina kun järjestelmään lisätään uusi tarkastusjakso, luodaan 499 tarkastustapahtumaa kyseiselle tarkastusjaksolle. Tämä on luontevaa toteuttaa Flow:lla.

Mutta… Eihän tämä Flow:n Common Data Service -triggeri koskaan laukea. Miksei?

Tässä kohtaa on tarpeen tehdä paljastus. Koko kuuma CDS 2.0 on kasa Dynamics 365:n ominaisuuksia. Osa uusia ja osa vanhoja uusiin kääreisiin naamioituna. Se ei tee siitä huonoa (päinvastoin). Mutta tämä on hyvä tiedostaa, niin jotkut asiat eivät sekoita päätä kokonaan.

Kuten se, että luomamme Flow ei käynnistynyt koska kyseisellä entiteettillä (Store Audit periods) ei ole muutosten jäljitys (change tracking) päällä Dynamics 365:ssa.

Kyllä. Luit oikein. Kiltisti siis Dynamics 365:n asetuksiin (Service – > Customizations).

Customize the System avaa uuden ikkunan, josta löydät entiteetit.

Näiden joukosta löytyy myös meidän Store Audit Periods -entiteettimme. Change tracking päälle, tallennus ja julkaisu.

Tämän jälkeen Flow:mme toimii.

Näkymät

Entiteetteihin voi tehdä näkymiä (Views).

Tein Store Audit Events -entiteettiin näkymän, joka näyttää auditoinnit, jotka liittyvät parhaillaan käynnissä olevaan tarkastusjaksoon.

Voit hyödyntää näkymissä relaatioiden takana olevia tietoja. Harmiksemme entiteettien näkymiä ei voi käyttää Canvas PowerAppsissa (toisin kuin esimerkiksi Azure SQL:n näkymiä).

Model-Driven PowerAppseissa näkymiä voi hyödyntää. Mutta siitä lisää myöhemmin.

Tietojen ylläpito

CDS for Apps:n sisältämää dataa voi muokata helposti kahdella tavalla. Avaamalla entiteetin excelissä tai luomalla tätä varten yksinkertaisen PowerAppsin.

Tehdään PowerApps, jolla voi lisätä uusia tarkastusjaksoja.

Lisätään tekemällämme PowerAppsilla muutama tarkastusjakso CDS for Apps:iin.

Flow käynnistyy ja luo kutakin tarjastusjaksoa kohden 499 auditointiriviä.

Kaikki alkaa olla valmista varsinaisen sovelluksen rakentamista varten.

PowerApps myymälöiden tarkastajille

Tämä on helppoa, olemmehan vastaavan ratkaisun tehneet jo kertaalleen.

Tehdään tyhjä powerApps ja lisätään tietolähteeksi Store Audit Events.

Lisätään galleria, jossa näytetään tarkastustapahtumat. Tässä kohtaa CDS for Appsin relaatiot astuvat kehiin. Voin näyttää galleriassa tarkastettavan myymälän nimen, vaikkei se ole Store Audit Events -entiteetissä, vaan siihen liittyvässä Stores -entiteetissä.

Haluamme tarkastella mobiilisovelluksessa kuluvan tarkastusjakson tarkastamattomia kohteita.

Ensin pitää selvittää mikä on kuluva tarkastusjakso. Se onnistuu tekemällä LookUp Store Audit Period -entiteettiin. Helppoa, koska tietomallissamme on tieto siitä mikä tarkastusjaksoista on aktiivinen.

LookUp(Store_Audit_Periods,crd01_currentperiod = true).crd01_primaryname

Asetetaan LookUpin arvo tekstikentän (txtCurrentPeriod) arvoksi ja käytetään sitä hyväksi filtteröidessä tapahtumia galleria-kontrollillemme.

Filter(Store_Audit_Events, crd01_auditperiod = txtCurrentPeriod.Text,crd01_auditcompleted = false)

Loppuosa PowerAppsin tekemisestä onkin identtistä aiemman esimerkin kanssa.

Lopputulos näyttää tältä.

Mitä Common Data Service for Apps maksaa?

Jos oiotaan rajusti mutkia, niin

• Kaikilla PowerAppsin käyttäjillä ja niiden kehittäjillä tulee olla PowerApps Plan 1 -lisenssi (5,90€/kk/käyttäjä)
• Kaikilla entiteettien muokkaajilla tulee olla PowerApps Plan 2 -lisenssi (33,70€/kk/käyttäjä).

Harmiksemme tähän liittyy lukuisia poikkeuksia. Yleensä ne liittyvät Dynamics 365:en käyttöön. Joko sen omien entiteettien tai esim reaaliakaisten työnkulkujen hyödyntämiseen.

Yhteenveto

CDS for Apps on useissa tilanteissa erinomainen vaihtoehto perinteiselle tietokannalle. Isommilla käyttäjämäärillä kannattaa kuitenkin laskea lisenssikulut auki ennen kuin innostuu.

Seuraavassa kirjoituksessa jatketaan saman esimerkin kanssa ja rakennetaan siihen raportointi. Sisältäen tulevien tarkastusten nakittamisen tarkastajille. Suoraan raportilta.