Power Platformin pyyntörajat (Requests limits)

Käyttäjäkohtaiset pyyntörajat (requests limits) tulivat Power Platformiin jo lokakuussa 2019. Niiden ylittämisestä ei edelleenkään seuraa välittömästi mitään. Todennäköisesti juuri tästä johtuen harva tiedostaa, mitä nämä rajat oikeastaan edes ovat.

Mutta syytä olisi.

Pyyntörajat ovat keskeinen muuttuja monia Power Platform -ratkaisuja suunniteltaessa.

Tutustutaanpa niihin hieman tarkemmin.

Paljonko käyttäjä voi tehdä pyyntöjä?

Aloitetaan helposta. Paljoko näitä mystisiä pyyntöjä eri käyttäjillä on käytössään (per rullaava 24h). Se riippuu käyttäjän lisensseistä. Eri lisenssit kerryttävät määriä seuraavasti.

Lisenssi	Ohjelmointirajapintapyyntöjen määrä / 24 tuntia
Power Apps per user plan	5000
Power Automate per user plan	5000
Office-lisenssi	2000
Power Apps per app plan	1000
Dynamics 365 Enterprise -sovellukset	20000
Dynamics 365 Professional	10000
Dynamics 365 Team Member	5000

Mikäli käyttäjällä on useita lisenssejä, lasketaan niiden antamat pyyntömäärät yhteen.

Dataverse-ratkaisuissa käytetään usein myös erilaisia lisensoimattomia käyttäjiä (esim palvelutunnuksia). Näiden yhteiseen käyttöön tulee 25 000, 50 000 tai 100 000 pyyntöä riippuen siitä, millaisia lisenssejä organisaatiolla on käytössään.

Oikaistaan esimerkissämme hieman ja kuvitellaan käyttäjillämme olevan ainoastaan Office 365 -lisenssit. Eli kaikilla käyttäjillä on vuorokaudessa 2000 pyyntöä käytettävissään.

Onko se paljon vai vähän?

Mikä on Power Platform -pyyntö?

Ensin täytyy ymmärtää mikä kaikki lasketaan Power Platform -pyynnöksi, eli mikä kuluttaa esimerkkikäyttäjämme 2000 pyynnön saldoa.

Power Apps

Power Appsissa kaikki yhdistimien (connector) avulla tehdyt toiminnot ovat Power Platform pyyntöjä. Yksinkertaista.

Kun haet galleriaan rivit tietovarastosta, on se yksi pyyntö.

Käyttäjän selatessa gallerian rivejä alaspäin, generoituu jossain kohtaa seuraava pyyntö Power Appsin hakiessa galleriaan seuraavan nipun rivejä.

Käyttäjän profiilitietojen tai kuvan hakeminen on myös yksi pyyntö.

Tietojen tallennus tietovarastoon on jälleen yksi pyyntö. Tehdään se sitten SubmitForm tai Patch komennolla.

Ja niin edelleen.

Myöskin käyttäjän tietojen hakeminen (User()) on yksi pyyntö.

Kaavojen käyttö taas ei muodosta pyyntöä. Kuvassa näkyvä kokoelman pyörittely on yhteensä nolla pyyntöä.

Power Apps on tältä osin selkeä. Mikäli sovellus on yhtään järkevästi tehty, ei sen päivittäinen käyttö generoi järjetöntä määrää pyyntöjä.

Flow

Flow onkin sitten mielenkiintoisempi. Voit ajatella että jokainen flow’n laatikko on yksi pyyntö. Riippumatta siitä mitä siinä tehdään.

Tarkastellaan esimerkki flow’ta joka suoritetaan päivittäin. Se

• Alustaa laskuri-muuttujan, jossa ylläpidetään käyttäjän Pertilä tekemien tilausten lukumäärää
• Hakee tilaukset (SharePoint-listalta)
• Tekee jokaisen tilauksen tiedoilla http-kutsun ulkoiseen palveluun
• Tarkistaa onko tilaus Pertilän tekemä
• Jos on, kasvattaa laskuria yhdellä

Kuvitellaan että meillä on 500 tilausta, joista 50 on minun tekemiä. Montako pyyntöä flow’n suorittaminen vie?

1+1+1+500+500+500+50 = 1553.

Päivittäinen 2000 raja ei kuulostakaan enää paljolta.

Entä jos käy niin onnettomasti, että kutsumamme rajapinta on solmussa ja sen suoritus epäonnistuu? Tällöin kutsua yritetään yhteensä neljä kertaa, ennen kuin luovutetaan. Jokainen kerta lasketaan.

1+1+1+500+2000 = 2503.

Kyllä. Käyttäjän päiväkohtainen raja paukahti yhdellä yksinkertaisella flow’lla ja sen yhdellä suorituksella.

Kenen saldosta pyynnöt vähennetään?

Power Appsissa luonnollisesti käyttäjän, joka Power Appsia käyttää. Flow onkin jälleen hieman monimutkaisempi.

Pääperiaate on, että pyynnöt vähennetään siltä, joka flow’n on käynnistänyt.

Flow’n käynnistystapa	Maksaja
Ajastettu	Flow’n omistaja
Power Appsista	Power Appsin käyttäjä
Painikkeella	Painikkeen painaja
Muutokseen reagointi (esim. SharePoint-listan riviä muokataan)	Flow’n omistaja
Käynnistetään suoraan SharePoint-listalta (valitulle riville/dokumentille)	Flow’n käynnistäjä

Tämä avaa meille mahdollisuuden hajauttaa kulutettavia pyyntöjä eri käyttäjien kesken. Tästä kirjoitan lisää myöhemmin.

Entä jos käytän Logic Appsia?

Mikäli sama toiminnallisuus on mahdollista toteuttaa Logic Appsilla, voit toki käyttää sitä. Tällöin hinnoittelu on täysin käyttöperusteista.

Mutta…

Dataverse on Power Platformin ydin ja (lähes) kaikki siihen kohdistuvat toimenpiteet kuluttavat aina päiväkohtaista saldoa. Riippumatta siitä, millä työkalulla kutsu tehdään. Esimerkiksi kuvan Logic Apps, joka päivittää viidensadan Dataversessä asuvan rivin tietoja, kuluttaa sekin 501 Power Platform pyyntöä.

Yllättäen maksatkin toiminnoista tavallaan kahteen kertaan. Logic Appsin suoriteperusteista maksua + kulutat Power Platformin pyyntösaldoa.

Sama juttu vaikka päivittäisit Dataversen rivejä Azure Functionsilla, Dataflow’lla tai omalla työasemallasi pyörivällä koodinpätkällä. Tätä et pääse karkuun mitenkään.

Mistä näen paljonko pyyntöjä on kulutettu?

Valitettavasti et kauhean hyvin mistään. Paras näkymä löytyy Power Platform admin centeristä Dataverse-osiosta (Analyticsin alla).

Huomaa että raportti näyttää tilanteen aina yhden ympäristön (environment) osalta ja luvuissa on mukana ainoastaan Dataverseen kohdistuneet pyynnöt.

Pyyntörajat ovat kuitenkin tenant-tasoisia ja Dataverseen kohdistuvat pyynnöt ovat vain osa kokonaisuudesta. Eli ei tämäkään raportti kovin autuaaksi tee.

Yhtä hyödytön on samaisesta paikasta löytyvä Power Automate -raportti. Se kertoo flow’den suoritusten määrän, ei niiden käyttämien pyyntöjen määrää.

Jokaisen flow’n kohdalla pääset sentään katsomaan, paljonko kyseinen flow on suorittanut pyyntöjä.

Tämä näkymä ei taas kerro mitään siitä, kenen käyttäjien pussista pyynnöt ovat menneet.

Parannusta raportointiin kaivataankin kipeästi.

Keväällä Power Platform admin centeriin on tulossa uusi raportti, jonka avulla näkee flow’t ja niiden käyttämät pyynnöt tenant-tasolla. Vihdoinkin.

Mutta mikä parasta, tulossa on myös raportti, jonka avulla voi tarkastella yksittäisten käyttäjien pyyntöjen käyttöä.

Mitä tapahtuu jos pyyntörajat ylittyvät?

Mikäli käyttäjä käyttää 14 päivän ajan toistuvasti enemmän pyyntöjä kuin hänellä on, voidaan hänen tunnuksensa automaattisesti disabloida. Tähän en ole käytännössä törmännyt.

Mikäli taas yksittäinen flow käyttää 14 päivän ajan toistuvasti merkittävän määrän pyyntöjä, voidaan kyseinen flow laittaa automaattisesti pois päältä. Flow’n suoritusta voidaan 14 vuorokauden aikana myös tästä syystä hidastaa. Tätä näkee silloin tällöin.

Tästä tulee myös ilmoitus flow’n omistajalle. Onkin oleellista että flow’lla on oikea omistaja, jonka sähköpostilaatikkoa luetaan.

Kaikki pilalla?

Ei sentään. Peruskäytössä käyttäjäkohtaiset rajat ovat varsin riittävät. Flow’n kanssa kannataa kuitenkin hieman keskittyä ja

• Optimoida edes hieman pyyntöjen käyttöä (triggeröidään vain kun tarpeen, hyödynnetään filter queryä jne)
• Miettiä kannattaako massapäivityksiä tehdä flow’lla ja jos tekee niin millä tunnuksella

Näiden rajojen taustalla on aivan perusteltu syy. Power Platformin käytön lisääntyessä, on Microsoftin jollain tapaa rajoitettava sen holtitonta käyttöä. Yksi ikuisessa silmukassa pyörivä flow generoi vuorokaudessa reippaan määrän pyyntöjä.

Pahimmillaan konsultit ja kansalaiskehittäjät voisivat yhdessä tiedostamattaan luoda Power Platformiin kohdistuvia palvelunestohyökkäyksiä. Ja siitä kärsisimme kaikki.