Flow’n kanssa työskennellessä tulee välillä seinä vastaan. Haluttua toiminnallisuutta ei pysty toteuttamaan. Tai toteutuksesta tulee sellainen purkkaviritys, ettei siinä ole mitään järkeä.

Näin käy esimerkiksi silloin, kun työnkulussa tarvisi tietoonsa Dataverse-tietueen sisällön ennen sen päivitystä tai poistamista.

Flow’n käynnistyessä muutoksesta (update), sisältää se tietueen päivittyneet arvot.

Tietueen käynnistyessä poistosta (delete), saamme tietoomme ainoastaan poistetun tietueen tunnisteen (id).

Usein tämä riittää. Mutta mitäs sitten kun ei riitä?

Kaivetaan esille perinteiset työnkulut (classic workflow). Dynamics 365 -konsulteille tuttu ja turvallinen työkalu. Meille muille jotain aivan mystistä.

Tutustutaan niihin esimerkin avulla.

Esimerkki – Työntekijät ja heidän laitteensa

Luodaan sovellus, jolla ylläpidetään työntekijöitä (employee) ja heidän laitteitaan (device).

Työntekijöistä tallennamme ainoastaan nimen (Name).

Laitteista tallennamme nimen lisäksi työntekijän jolle laite kuuluu (Device owner).

Henkilö-lomake laitteineen näyttää seuraavalta.

Haluamme tietää reaaliajassa, mikä laite on kenenkin hallussa. Päivitämme työntekijöiden laitteet vaikkapa johonkin toiseen järjestelmän ja vaatimuksena on että se tulee tapahtua heti.

Ratkaisua tehtäessä on huomattava, miten flow’t käynnistyvät. Kun Timolle lisätään ylläolevalla näytöllä uusi laite, ei lisäys aiheuta työntekijä-tietueen päivittymistä (laitteesta on lookup työntekijään).

Emme siis voi seurata työntekijöiden muutoksia. Seuraamme laitteille tehtäviä muutoksia.

Päädymme kirjoittaan omaan muutosloki-tauluumme (Device change log) seuraavat tiedot kun laitteen omistaja muuttuu.

  • Laite jota muutos koskee (Device, Lookup)
  • Työntekijä jota muutos koskee (Employee, Lookup)
  • Muutoksen tyyppi (Name)

Voimme sitten flown avulla reagoida muutoslokille syntyviin riveihin ja tehdä tarvittavat toimenpiteet. Mitä ne sitten ikinä ovatkaan.

Meidän tulee reagoida neljään tilanteesen

  1. Luodaan uusi laite. Kenelle se lisättiin?
  2. Vaihdetaan laitteen omistaja. Kenelle se lisättiin?
  3. Vaihdetaan laitteen omistaja. Keneltä se otettiin pois?
  4. Poistetaan laite. Kenen hallussa se oli?

Aloitetaan helpoista. Eli tilanteista jotka voidaan toteuttaa flow’lla.

Uuden laitteen lisääminen / laitteen siirtäminen uudelle henkilölle

Kun uusi laite lisätään tai olemassa olevaa muokataan, kirjoitetaan rivi lokitauluun. Tietueen nimeksi tulee tapahtuman tyyppi (triggerBody()?[’SdkMessage’]).

Meitä kiinnostaa muutokset, joissa laitteen omistaja on muuttunut ja joissa laitteella on muutoksen jälkeen omistaja.

Asetetaan flow käynnistymään ainoastaan omistajatietoa muokatessa.

Meitä ei myöskään kiinnosta tapahtumat, joissa omistajatieto on poistettu. Rajataan nämä tilanteet ulos seuraavalla käynnistysehdolla (trigger condition). 

@not(empty(triggerOutputs()?['body/_tp_deviceowner_value']))

Luodaan Jukalle uusi laite (PS3) ja siirretään olemassaoleva (Wii Sports) Timolta Jukalle.

Lokitauluun tallentuu oikeat tiedot.

Hienoa! Sitten se tuntemattomampi osuus.

Keneltä laite siirrettiin pois?

Miten selvitämme laitteen omistajan vaihtamisen yhteydessä, kenelle laite oli aiemmin? Perinteisellä työnkululla.

Perinteinen työnkulku – Luonti

Luodaan perinteinen työnkulku (Automation -> Process -> Wokflow).

Annetaan työnkululle nimi ja määritellään taulu, jonka päivityksistä se käynnistyy. Jotta pääsemme käsiksi tietoihin ennen muutosta (before), tulee työnkulku määritellä käynnistymään reaaliaikaisesti (real-time workflow).

Siis ruksi pois kohdasta Run workflow in the background.

Meidät ohjataan (pienellä tai suurella viiveellä) 80-luvulle. Käyttöliittymää kutsutaan klassiseksi (classic view) ja sitä se kyllä onkin.

Perinteinen työnkulku – Käynnistysehdot

Vaihdetaan ensimmäisenä työnkulku käynnistymään kenen tahansa käyttäjän muokatessa laitetta (Scope = Organization).

Vaihdetaan työnkulku käynnistymään kun tietuetta muokataan (Record fields change). Määritellään (select -painikkeella), mitä tietueen kenttiä tulee muokata jotta työnkulku käynnistyy.

Meitä kiinnostaa ainoastaan laitteen omistajan (Device owner) muutokset, joten valitaan se.

Perinteinen työnkulku – Ennen vai jälkeen?

Ja sitten se tärkein koukku. Vaihdetaan työnkulku käynnistymään muutoksen jälkeen (after) sijaan ennen muutosta (before). Näin meillä on käytössämme kaikki tiedot ennen tietueen päivittämistä.

Olemme nyt määritelleet, miten työnkulku käynnistyy. Mutta mitä käynnistynyt työnkulku sitten tekee?

Perinteinen työnkulku – Toimenpiteet

Työnkulun suorittamat toimenpiteet määritellään askelien (step) avulla. Vaihtoehtoja on paljon, mutta tyydytään tällä kertaa lisäämään uusi rivi dataverseen (Create record).

Nimetään askel (Create device change log row) ja valitaan taulu, johon rivi luodaan (Device change log).

Set Properties -painikkeesta avautuu uusi dialogi, josta määritellään mitä valittuun tauluun tallennetaan.

Määritellään uuden rivin nimeksi (Name) ”Update – Before”. Omistajan voimme jättää tyhjäksi.

Haluamme luoda Device-kenttään viittauksen käyttäjän muokkaamaan laitteeseen. Se tehdään seuraavasti

  • Valitaan kenttä (1)
  • Lisätään Form Assistant -osiosta Add-painikkeella mukaan Device (2)
  • Kuitataan valinta OK:lla (3)

Device-kenttään ilmestyyy arvoksi {Device(Device)}. Eli muokatun Device-tietueen Device-kentän arvo.

Employee-kenttään tallennamme laitteen haltijan ennen muutosta. Tämä tehdään samalla tavalla.

Luotavalle tietueelle voi poimia Form Assistant:in avulla helposti vaikka mitä tietoja päivityksen kohteena olevasta, sekä siihen liittyvistä, tietueista.

Mutta tyydymme tällä kertaa näihin.

Save and Close.

Ja Save and Close.

Lopuksi työnkulku aktivoidaan (Turn on).

Toimiiko tämä? Vaihdetaan laite (Wii Sports). Jukalta Timolle.

Ja kas, lokissamme on tieto sekä siitä keneltä laite on siirtynyt (Update – Before), että kenelle se on siirtynyt (Update).

Laitteen poistaminen

Laitteen poistoon (Delete) reagoiva työnkulku tehdään vastaavalla tavalla.

Poistosta kertovassa lokimerkinnässä emme voi täyttää Device-kenttää, sillä se olisi viittaus laitteseen, joka juuri poistetaan. Laitteen poistaminen antaisi loppukäyttäjälle geneerisen SQL-virheen.

Lisätään poistetun laitteen nimi Name-kenttään lisätiedoksi.

Testataan. Poistetaan Timon hallussa oleva Wii Sports.

Tapahtumasta syntyy samantien rivi lokitauluumme!

Yhteenveto

Power Platformissa siis on (low-code) keino selvittää päivittyneen tai poistetun tietueen sisältö ennen muutosta. Mutta onhan tämä hieman sekavaa työskennellä kahdenlaisilla työkaluilla. Uusilla ja vanhoilla.

Eiköhän jollain aikavälillä kaikki ominaisuudet ilmesty myös näihin isojen massojen tuntemiin uusiin työkaluihin. Toivotaan näin.