Työnkulun suoritus voi kestää hyvinkin kauan. Tunteja tai jopa päiviä. Erilaiset hyväksyntätyönkulut (Approval) ovat tästä tyypillinen esimerkki.

Mutta estääkö työnkulun pitkä suoritus sen päivittämisen? Mitä tapahtuu jos työnkulkua muokataan sun sen suorituksia on edelleen käynnissä?

Bonuksena selvitetään mitä tapahtuu jos Dataverseen tai SharePointiin lisätään rivejä uusista riveistä käynnistyvän flow’n ollessa poissa päältä.

Flow’n muokkaaminen kesken suorituksen

Työnkulkumme suoritus kestää noin 10 minuuttia. Käynnistetään se.

Lisätään työnkulkuun uusi toiminto (Step 0).

Käynnistetään työnkulku uudelleen. Nyt meillä on käynnissä kaksi suoritusta

Tarkistetaan suoritusten päätyttyä mitä flow’t tekivät. Ensimmäisenä käynnistetty flow näyttää tältä.

Kun taas toisena käynnistetty flow näyttää tältä.

Flow’ta voi muokata vaikka sen suorituksia on kesken. Käynnistyneet flow’t suoritetaan loppuun flow’n käynnistyshetken versiolla. Muutokset eivät vaikuta niihin.

Voit siis tuoda flow’n sisältävän ratkaisupaketin ympäristöön, vaikka kyseisestä flow’sta olisi kohdeympäristössä suorituksia kesken.

Erinomaista.

Ympäristömuuttujien päivittäminen

Miten sitten käyttäytyy ympäristömuuttuja (environment variable), kun sen arvo vaihtuu kesken flow’n suorituksen?

Luodaan uusi ympäristömuuttuja, johon talletetaan sähköpostiosoite (notification email).

Käytetään ympäristömuuttujan arvoa työnkulun lopussa.

Käynnistettään flow.

Käydään päivittämässä ympäristömuuttujan arvo toiseksi.

Ensimmäisen flown suoritus on edelleen kesken. Käytännössä menee useita tunteja ennen kuin se ehtii kohtaan, jossa ympäristömuuttujan arvoa käytetään.

Kumpaa ympäristömuuttujan arvoa flow käyttää? Arvoa, joka ympäristömuuttujalla oli flow’n käynnistyshetkellä vai arvoa joka ympäristömuuttujassa on sillä hetkellä kun flow’ssa käytetään ympäristömuuttujaa ensimmäistä kertaa?

Flow’ssa käytetään ympäristömuuttujan arvoa flow’n käynnistyshetkeltä.

Flow’n sammuttaminen kesken suoritusten

Meillä on flow, joka käynnistyy uuden rivin ilmestyessä Dataversen tauluun.

Lisätään kolme uutta riviä, jolloin flow’sta käynistyy kolme suoritusta.

Mitä tapahtuu kun flow sammutetaan (turn off)?

Uusia suorituksia ei käynnisty, mutta kesken olevat suoritetaan kauniisti loppuun.

Flow’n käynnistäminen uudelleen

Käynnistetään flow uudelleen (turn on). Flow’n ollessa poissa päältä on tauluun lisätty uusia rivejä. Reagoiko flow käynnistyttyään niihin? Ei.

Näin siis Dataverseä käytettäessä.

Entä jos teemme saman testin SharePoint-listan kanssa?

Luodaan flow, joka käynnistyy kun SharePoint-listalle lisätään uusi rivi.

Lisätään kaksi riviä ja työnkulku käynnistyy.

Sammutetaan työnkulku. Tämän jälkeen lisätään kaksi uutta riviä SharePoint-listalle.

Lopuksi käynnistämme työnkulun uudelleen. Mitä ihmettä! Muutaman minuutin kuluttua uudet rivit käynnistävät työnkulun. Rivit, jotka luotiin flow’n ollessa pois päältä.

Miksi Dataverse ja SharePoint -triggerit toimivat eritavalla?

Kyse on triggerin toteutuksesta. Se voi olla

  • Pollaava, jolloin triggeri käy säännöllisesti tarkastamassa onko edellisen tarkastuksen jälkeen tapahtunut muutoksia joihin sen tulisi reagoida. SharePoint-triggeri on tällainen.
  • Webhook, jolloin se saa käynnistysherätteen suoraan triggerin kohteelta. Dataverse-triggeri on tällainen.

Mikäli flow’n triggeri on pollaava, prosessoi se käynnistyksen yhteydessä kaikki tapahtumat, jotka ovat tapahtuneet edellisen tarkastuskerran jälkeen (ennen flown sammuttamista).

Mikäli flow’n triggeri on tyypiltään webhook, prosessoi se kaikki tapahtumat jotka tapahtuvat sen käynnistyksen jälkeen.

Merkittävä ero, joka tulee ottaa huomioon flow’ta sammuttaessa ja käynnistäessä.

Mistä tiedän kumpaa toteutustapaa trigger edustaa?

Kolmen pisteen takaa pääsee tarkastelemaan triggerin koodia (peek code).

Pollaavan triggerin koodissa on määritelty miten usein trigger käy tarkistamassa mahdolliset muutokset (recurrence -> interval).

Näemme että SharePointin kohdalla tarkastus tehdään minuutin välein.