Myymäläauditointien hallinnointi – Model-driven apps

Teimme aiemmin PowerAppsilla mobiilisovelluksen myymälöiden tarkastajille. Ratkaisun tietovarastona toimi Common Data Service for Apps.

PowerApps onkin erinomainen valinta, kun rakennetaan laajalle käyttäjäjoukolle yksinkertainen sovellus joka sisältää vain ja ainoastaan käyttäjän tarvitsemat ominaisuudet.

Mutta mitä ne PowerAppsin yhteydessä usein puhutut model-driven appsit sitten oikein ovat?

Nimensä mukaisesti ne perustuvat malliin. Tarkemmin ottaen CDS for Appsin entiteetteihin sekä niiden välisiin relaatioihin. Sovellus muodostuu näistä lähes itsestään, mikä on näppärää. Sovelluksen ulkoasuun ei voi juurikaan vaikuttaa, mikä on joissain tilanteissa ehdoton showstopper. Ei toki aina.

Model-driven apps onkin erinomainen tapa rakentaa esimerkiksi sovelluksen ylläpito- ja hallintatyökalut.

Rakennetaan tällä kertaa myymälöiden auditointiratkaisulle kunnolliset hallintavermeet.

Myymäläauditointien hallinnointi – Model-driven apps

Siirrytään https://web.powerapps.com osoitteeseen, josta löytyy aiemmin tehdyn auditointiratkaisun käyttämät entiteetit (Stores, Store_Audit_Events ja Store_Audit_Periods).

Sivun vasemmasta alareunasta pääsee valitsemaan Canvas ja Model-driven tilojen välillä. Vaihdetaan tilaksi Model-driven.

Näyttö muuttuu kokonaan valkoiseksi. Luodaan uusi model-driven apps valitsemalla Apps ja sieltä Create an app.

Annetaan sovellukselle nimi ja painetaan Done.

Tarkkasilmäisimmät huomasivat heti. Unified interface URL: mytenant.crm4.dynamics.com/Apps/xxx

Halusit tai et, tervetuloa Dynamics 365 maailmaan!

Seuraavaksi avautuu pelottavan näköinen App Designer. Tällä se sovellus tehdään.  Mutta miten?

Sovelluksen navigaatio – Sitemap

App Designerin vasemmassa yläkulmassa on Site Map. Se tarkoittaa sovelluksemme päänavigointia. Klikataan sen vieressä olevaa nuolta, joka avaa Sitemap Designerin.

Sitemap on kolmitasoinen

• Area
  • Group
    • Subarea

Area ja Group tasoja käytetään ryhmittelyyn. Subarea tasolla sijaitsevat varsinaiset asiat. Meidän sovelluksessa subareat ovat auditointeihin liittyvät kolme entiteettiä.

Lisätään ne ja painetaan Save. Ja sen jälkeen Publish.

Muista model-driven appseja tehdessä. Aina Save + Publish. Aina. Tai ei ihan aina. Joskus Save + Activate. Ja joskus harvoin pelkkä Save. Selvää?

Sitemappiin lisätyt entiteetit ilmestyvät automaattisesti Apps designeriin. Jokaisen entiteetiin kohdalta löytyy Forms, Views, Charts ja Dashboards. Mielenkiintoista.

Painetaan Save. Ja vielä Publish.

Meillä on nyt toimiva sovellus. Se käynnistyy klikkaamalla sovelluksen nimeä Model driven apps -listalta.

Hmmm… Ruudulle ilmestyy selvästi kaikki myymälät. Eli Stores entiteetin tietueet. Ja ruhtinaallinen määrä kaikkea muuta tilpehööriä sen ympärille.

Avataan vasemmasta yläkulmasta vohvelin alta navigaatio (se sitemap) auki.

Sivun tietuelistauksesa näytetään ainoastaan tietueen nimi ja luontipäivä. Pelkistetty linja jatkuu kun avataan yksi auditointitapahtuma.

Oletuksena lomakkeille tulee mukaan ainoastaan pakolliset kentät.

Ehkä tätä pitää vielä hieman säätää.

Lomakkeet

Sovelluksessamme pitäisi voida muokata kaikkia merkittäviä kenttiä. Avataan App designer ja valitaan halutun entiteetin kohdalta Forms -> Create New. Esiin ilmestyvästä valikosta päätän luoda Main Form:in.

Avautuu lomake-editori, jolla päästään lisäämään lomakkeeseen kaikki tarpeellisiksi katsomamme kentät. Editori näyttää karulta, mutta se paljastuu varsin monipuoliseksi. Löytyy header, footer ja välilehdet (tabs). On useita erilaisia tapoja jakaa kentät palstoihin. Ja paljon paljon muuta. Kyllä tällä pärjää.

Vaihdetaan lomakkeen asettelu kaksipalstaiseksi (ja tallennetaan ja julkaistaan).

Olemme luoneet uuden lomakkeen. Se tulee vielä lisätä sovellukseemme App Designerissä. Valitaan kyseisen entiteetin kohdalta Forms ja ruksitaan luotu lomake oikean reunan listalta. Ja tallennus ja julkaisu…

Näyttää paljon paremmalta.

Sivut ovat responsiivisia. Niitä voi käyttää mainiosti puhelimella tai tabletilla.

Vastaavalla tavalla muokkaan lomakkeet halutunlaisiksi myös myymälöille (Stores) sekä tarkastusjaksoille (Store_Audit_Periods).

Näin meillä on sovellus, jolla voi

• luoda/muokata/poistaa uusia tarkastusjaksoja
• lisätä/muokata/poistaa myymälöitä
• muokata tarvittaessa tarkastusten tuloksia

Pikalomakkeet

Auditointitapahtuma liittyy aina tiettyyn myymälään sekä auditointijaksoon. Nämä ilmentyvät linkkeinä auditointitapahtumalomakkeelta kyseisiin tietueisiin. Voimme kutenkin näyttää myymälän ja auditointijakson tietoja suoraan auditointitapahtumalomakkeella.

Luodaan myymälälle pikalomake (Quick view form).

Avautuu jo tutuksi tullut lomakeditori. Raahataan lomakkeelle halutut kentät. Ja Save ja Publish. Lopuksi ruksitaan App Designerissä pikalomake mukaan sovellukseen. Nyt Stores entiteetillä on kaksi lomaketta

• Päälomake (Main Form), jota käytetään käyttäjän olessa sovelluksessa Stores entiteettissä ja avatessaan sieltä yhden tietueen
• Pikalomake (Quick View Form), jonka voi upottaa osaksi jonkun toisen entiteetin päälomaketta.

Upotetaan Storen pikalomake Store_Audit_Eventin lomakeelle. Lisätään insert-välilehdeltä lomakkeelle kentäksi Quick View Control ja poimitaan siihen Stores entiteetin pikalomake.

Lopputuloksena Store_Audit_Event entiteetin tietuetta katsoessa/muokatessa näemme myös siihen liittyvän myymälän tarkat tiedot. Kätevää.

Näkymät

Kun sovelluksesta avaa entiteetin, avautuu eteen lista kyseisen entiteetin tietueista.

Erilaisia listauksia voi olla useita ja niitä kutsutaan näkymiksi (view). Näkymälle voi määritellä

• Mitä sarakkeita näytetään
• Mikä on sarakkeiden oletusjärjestys
• Mitä suodatusehtoja käytetään

Entiteettien näkymiä pääsee lisäämään ja muokkaamaan tietenkin App Designeristä.

Lisätään halutut sarakkeet myymälöiden oletusnäkymään (aktiiviset myymälät). 

Sovelluksemme myymälälistaa näyttää tämän jälkeen tältä.

Voisimme tehdä vaikka Helsinki, Espoo, Vantaa, Hyvinkää jne -näkymät, joissa näytetään ainoastaan kyseisen kaupungin myyntipisteet.

Kaaviot

Seuraavaksi haluamme lisätä sovellukseemme visualisointeja. Esimerkiksi

• Montako myymälää on tarkastettu per viikko vimeisen x kuukauden aikana?
• Miten auditointien tulokset (arvosanat siisteydestä ja tuotteiden näkyvyydestä) ovat kehittyneet viikottain?
• Montako myymälää kukin tarkastaja on tarkastanut aktiivisen tarkastusjakson aikana?

Näitä voi keksiä mielin määrin lisää.

Onneksemme entiteeteille voi luoda kaavioita (Charts). Kyllä. Hyvin kattavasti erilaisia käppyröitä. Kaavioita voi hyödyntää dashboardeissa. Kaavioita ja dashboardeja pääsee luomaan tietenkin Site Designeristä.

Yksi Chart pitää sisällään yhden kuvaajaan. Niiden luominen on suoraviivaista. Kuhan muistaa tallentaa. Kaavioita ei jostain syystä tarvitse julkaista.

Alla myymälöiden tarkastuslistan yhteyteen on tuotu kuvaaja tulosten viikkotasoisista keskiarvoista.

Seuraavana yksinkertainen dashboard. Kaksi kaaviota sekä kyseiseen entiteettiin liittyävä tapahtumavirta (Activity stream).

Business Process Flow

Olisi hienoa jos voisimme visualisoida yksittäisen myymäläauditoinnin tilan

• onko tarkastaja jo nakitettu?
• onko tarkastus jo tehty?
• jos tarkastuksen arvosanat ovat ok, tilaksi tulee ”Auditointi ok”
• jos arvosanat ovat heikot, tilaksi tulee ”Ylimääräinen auditointi tarvitaan”

Kuulostaa Dynamicsin Business Process Flow:lta.

Ominaisuus pitää ensin aktivoida entiteetille. Siirrytään sovellukseen ja valitaan rattaan takaa Open in classic mode.

Sieltä Dynamics 365:n asetuksiin (Service – > Customizations).

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

Näiden joukosta löytyy myös  Store Audit Periods -entiteetti. Business process flows päälle, tallennus ja julkaisu.

Tämän jälkeen valitsemme Site Designerista Business Process Flow:n (se vihreä laatikko) ja painetaan Create New.

Jälleen uusi työkalu, Business Process Flow Designer.

Lisätään tiloiksi

• Uusi (New), jossa tehtävänä on määritellä tarkastuksen suorittava tarkastaja
• Odotetaan auditointia (Waiting for audit), jossa tehtävänä on syöttää tarkastuksen tulokset ja merkitä tarkastus tehdyksi
• Tarkastus tehty (Audit completed), johon tullaan mikäli auditinnin tulos oli ok
• Ylimääräinen tarkastus tehtävä (Additional audit requited), johon tullaan mikäli ompi kumpi tarkastettavista asioista on saanut arvosanaksi ykkösen

Tallennetaan ja aktivoidaan. Sekä lisätään luotu prosessi sovellukseemme. Ja Save ja Publish.

Nyt vanha auditointitapahtuma näyttääkin tältä. Sivun yläreunaan on ilmestynyt prosessikaavio.

Ratkaisu ei kuitenkaan ole aivan sitä mitä haimme. Tarkastajat päivittävät auditointitapahtumien tietoja sillä toisella PowerApsilla. Model-driven appsilla samaa tapahtumaa katsottaessa prosessi näyttää olevan edelleen tilassa New. Vaikka auditointi on tehty. Auditoija nimetty, pisteet annettu ja tarkastus merkitty tehdyksi.

Prosessin lopputila on sentään oikea (Audit Completed). Valitettavasti prosessikuvaajan aktiivinen tila etenee ainoastaan, mikäli vaaditut tiedot syötetään sen avulla.

Ensin kuitataan tarakstaja määritellyksi.

Sitten auditointi tehdyksi.

Ja kyseinen tarkastustapahtuma valmiiksi.

Tällaisenaan Business Process Flown ja Canvas Appsin (se perinteinen PowerApps) yhteiskäyttö on hieman vajaavaista.

Yhteenveto

Microsoft on onnistunut sekoittamaan meistä suurimman osan PowerApps / Model-Driven Apps within PowerApps / Canvas Apps tarinallaan.

Mutta tämä on oikeasti aivan yksinkertaista

• PowerApps = Canvas Apps = Se tuttu alunperin esitelty PowerApps, jolla voi tehdä pikselintarkkaa UI:ta ja joka voi käyttää tietolähteinään vaikka mitä. Peruskäyttö kuuluu Office 365 -tilaukseen.
• Model-driven apps = Dynamics xRM. Vaatii aina pohjalle Common Data Service for Appsilla tehdyn tietomallin. Sovelluksessa ei voi suoraan käyttää mitään muuta tietolähdettä. Kaikki työkalut ovat vanhoja tuttuja Dynamics 365:n työkaluja. Käyttö vaatii aina lisenssin Office 365 -lisenssin lisäksi.

Käytännössä PowerApps ja Model-driven apps ovat todella hieno yhdistelmä.

• PowerAppsilla voi rakentaa helppokäyttöisiä täsmäsovelluksia loppukäyttäjille. Sekä työasemalle että mobiiliin
• Model-driven appsilla voi rakentaa helposti koko ratkaisun hallintakäyttöliittymän, sekä muita teho/aktiivikäyttäjille suunnattuja työkaluja.

Mikäli rakennetaan monimutkaista työkalua, voi olla järkevää tehdä se kokonaan yhtenä tai useana Model-driven appsina. Jos sillä voi rakentaa yhden Dynamicsin, niin eiköhän sillä voi rakentaa paljon muutakin.