Niin mainio kuin flow onkin, on siinä omat haasteensa. Esimerkiksi tilanteessa, jossa käsitellään paljon rivejä ja/tai suoritetaan toimintoja (flow’n mittapuulla) nopeasti.
Pureudutaan tällä kertaa näihin ongelmiin tarkemmin. Tutkitaan edellisen jutun flow’ta. Flow lähettää työntekijöistä palautepyyntöjä henkilöille, joiden kanssa he pääasiassa työskentelevät.
Ratkaisu toimii mainiosti pienessä organisaatiossa (50 henkeä), mutta mitä tapahtuu kun organisaatiossa onkin 2500 työntekijää?
Silmukan rinnakkainen suorittaminen (max 50)
Ensimmäinen ongelma flow’ssa on muokattavan kortin lähetys. Jäämme odottamaan vastausta lähetettyyn kysymykseen (Post adaptive card and wait for a response). Flow jatkaa etenemistään vasta kun vastaus on annettu.

Oletuksena flow lähettää yhden palautepyynnön ja jää odottamaan vastausta. Seuraava palautepyyntö lähetetään vasta edellisen vastattua omaansa. Jos käyttäjä ei vastaa kyselyyn, pysähtyy prosessi siihen.
Hienoa.
Tilannetta voi paikata asettamalla ulomman silmukan (Apply to each) rinnakkaisuuden asteeksi täydet (50). Sisemmässä silmukassa voidaan käyttää arvoa 4 (enempää ei lähetetä palautepyyntöjä yhdestä työntekijästä).

Nyt palautepyyntöjä lähtee samanaikaisesti 50. Ratkaisu toimii siis 50 hengen organisaatiossa. Mutta eipä juuri isommassa. 1000 hengen organisaatiossa olemme nopeasti tilanteessa, jossa 50 henkilöä ei vastaa palautepyyntöön. Ja prosessi pysähtyy siihen.
Alityönkulku (child flow) – Palauteen kerääminen yhdestä henkilöstä
Ongelma ratkeaa alityönkululla (child flow). Ne ovat käteviä, sillä niiden avulla
- monimutkainen flow voidaan jakaa useaan erilliseen flow’hun, jotka kutsuvat toisiaan
- voidaan samaa flow’ta kutsua useasta eri paikasta
Logiikasta saadaan helpommin ylläpidettävää. Mutta sen avulla voidaan lisätä myös rinnakkaisten suoritusten määrää. Siihen pyrimme tänään.
Alityönkulkumme hoitaa palautteen keräämisen yhdestä henkilöstä. Se
- saa parametrina henkilön tiedot
- selvittää kenelle palautepyynnöt lähetetään
- lähettää palautepyynnöt
- tallentaa vastaukset, mikäli sellaisia tulee
Flow näyttää tältä.

Jotta flow’ta voidaan käyttää alityönkulkuna, tulee sen palauttaa kutsujalle paluuarvo. Emme halua odottaa suorituksen loppuun, joten palautamme vastauksen heti alussa rinnakkaisessa haarassaan.

Alityönkulun toiminnot tulee suorittaa aina samalla yhteydellä (connection), ei käynnistäjän yhteydellä. Tämä määritellään asetuksissa (Run only users).

Tarvimme vielä toisen flow’n, joka kutsuu tätä alityönkulkua.
Päätyönkulku
Varsinaiseen työnkulkuun ei jää paljoa tehtävää. Siinä haetaan henkilöt, joista palautetta kysytään, ja käynnistetään kunkin kohdalla alityönkulku.

Alityönkulkuja voi käynnistää rajoittamattoman määrän (kunhan ei rajoita sen käynnistyksen rinnakkaisuutta). Huomaa että alityönkulun kutsuminen on premium ominaisuus. Se ei onnistu pelkällä M365 lisenssillä.
Huomioitavat pullonkaulat
Vihdoin pääsemme varsinaiseen aiheeseen. Käsittelemme flow’n mittapuulla jo kohtuullista joukkoa (2500) palautteen kohteita. Mitä tässä tulisi huomioida?
Sivutus
Palautteen kohteet haetaan Excel-tiedostosta. Yhtä hyvin ne voitaisiin hakea Office 365 Käyttäjät -toiminnolla, AAD / M365 ryhmästä, SharePoint listalta, Dataversestä tms.
Rivejä palauttavissa toiminnoissa on paluujoukon sivutus oletuksena pois päältä. ”Hae rivit SharePoint-listalta” palauttaa tällöin ainoastaan 100 riviä. Excel-taulukosta palautuu 256 riviä jne.
Mikäli rivejä on enemmän, tulee ensin asettaa toiminnon asetuksista sivutus (Pagination) päälle ja määritellä maksimi käsiteltävä rivimäärä (Threshold).

Microsoft 365 -lisenssillä rivimääräksi voi asettaa enintään 5000. Power Automate per User -lisenssillä rivimäärän voi kasvattaa 100 000:een.
2500 riviimme riittäisi M365-lisenssi.
Yhteyden rajoittaminen (connection throttling)
Käynnistetään flow. Se käynnistää alityönkulkuja 1-2 kpl sekunnissa.

Pian havaitsemme osan alityönkuluista päätyvän virheeseen.

Syyllinen on Teams-toiminto.

The request failed. Response content: '{"statusCode":403,"message":"Out of call volume quota. Quota will be replenished in 00:40:25."}'.
Mitäs tämä nyt on?
Kullakin yhdistimellä (connector) on omat rajoituksensa. Teams-yhteydellä voi suorittaa max 100 API-kutsua minuutissa. Et myöskään voi tehdä kuin 300 kutsua tunnissa. Nyt teemme 1800+ tunnissa…
Alityönkulkumme tekee enintään 4 Teams-toimintoa. Voimme siis käynnistää tunnissa enintään 75 alityönkulkua. Pyöristetään turvallisesti alaspäin ja käynnistetään yksi minuutissa.
Lisätään päätyönkulkuun minuutin viive alityönkulun käynnistyksen jälkeen. Huomaa että silmukkaa ei suoriteta rinnakkain, vaan yksi kerrallaan (oletus). Emme kaipaa yhtään lisää vauhtia silmukan suoritukseen.

Näin flow etenee riittävän hitaasti eikä rajoitukset ylity.
Ja laskit oikein. 2500 henkilön läpikäynti vie nyt aikaa yli 40h.
Viiveen lisääminen tuo 2500 henkilöllä myös 2500 ylimääräistä Power Platform palvelupyyntöä.
Power Platform pyynnöt
Flow’mme menee nyt kunnialla maaliin. Mutta miltä näyttää Power Platform pyyntöjen osalta?
Yksi alityönkulun suoritus aiheuttaa 15 pyyntöä. 2500 suoritusta tekee yhteensä 37500 pyyntöä. 35000 näistä tehdään heti. 2500 hajaantuu pidemmälle ajalle, sillä ne suoritetaan kun palautepyyntöihin vastataan.
Päätyönkulku vie 7502 pyyntöä.
Kaikenkaikkiaan syntyy 45002 pyyntöä.
Millainen lisenssi ratkaisun suoritukseen tarvitaan?
- Office käyttäjä voi suorittaa 6000 pyyntöä / 24h. Ei riitä.
- Power Automate per User -lisenssillä voi suorittaa 40000 pyyntöä / 24h. Tämä riittää, sillä flow’n suoritus kestää ~40h, jolloin myös pyynnöt jakautuvat kahdelle vuorokaudelle. Samalla tunnuksella ei kyseisinä päivinä voi tehdä juurikaan muita pyyntöjä tai rajat paukkuvat
- Power Automate per flow -lisenssillä voi suorittaa 250 000 pyyntöä / 24h. Ei mitään ongelmia.
Palautepyyntöjen lähettämistä voi myös tietenkin hajauttaa. Lähetetään esimerkiksi eri päivinä eri yksiköiden palautepyynnöt.
Yhteenveto
Mitä tästä opimme? Kun flow’lla käsittelee tuhansia rivejä, tulee eteen uusia hämmentäviä haasteita.
Kehittäjän näkökulmasta flow’n suoritus on usein tuskaisen hidasta. Samaan aikaan se on kuitenkin niin nopeaa, että ylittää helposti yhteyksien käyttöön liittyvät rajoitukset.
Eivätkä nämä ongelmat tule esiin, kun flow’ta testaa pienellä testiaineistolla.
Mieti siis flow’ta tehdessäsi aina
- kauanko flow’n suoritus tulee oikealla aineistolla kestämään
- miten paljon ja nopeasti flow suorittaa yhdistimien toimintoja (tarkista ko toiminnon rajoitukset)
- miten paljon flow muodostaa Power Platform palvelupyyntöjä