PowerAppsien hallinnointi

Organisaatiot ovat nyt todella kiinnostuneita PowerAppseista. Mitä ne ovat? Miten voisimme niitä hyödyntää? Miten niitä tehdään? Kuka niitä voisi tehdä?

Heti kun organisaatiolle (ja sen IT-vastaaville) selviää mistä PowerAppseissa on kyse, alkaa huolestuminen. Onko meillä pian jos jonkinnäköistä sekavaa PowerApps-sovellusta käytössä? Kuka vastaa niiden ylläpidosta? Kuka varmistaa että ne on tehty järkevästi? Tilanne saattaa muistuttaa aikanaan täysin käsitä lähtenyttä SharePoint-ympäristöä, jonne kaikki tekivät omia minisovelluksiaan.

Heikkona hetkenä tekee mieli kieltää tenantista koko PowerAppsit.

Helpoin tapa välttyä ongelmilta on toki kieltää koko tekeminen. Mutta älä edes harkitse. Niin paljosta jäätte silloin paitsi.

Jonkinlainen niskalenkki PowerAppseista on kuitenkin syytä ottaa. Käydään tällä kertaa läpi muutama käytännön asia jolla pääsee alkuun.

PowerApps plan 2 -lisenssi

Hankkikaa aivan ensimmäiseksi ympäristöstä vastaaville henkilöille (tai osalle heistä) PowerApps plan 2 -lisenssit. Listahinta tänään on 33,70€/kk/käyttäjä. Kuulostaa paljolta, mutta näitä ei tarvi olla montaa.

Lisenssin haltijat pääsevät https://admin.powerapps.com -sivustolle, josta löytyy esimerkiksi seuravaat hyödylliset tiedot/ominaisuudet.

Lista ympäristön PowerAppseista

PowerAppsin hallintakeskuksesta (Admin center) näkee kaikki ympäristön PowerAppsit yhdestä paikasta. Listalla on PowerAppsien perustiedot:

• nimi
• omistaja
• milloin sitä on viimeksi muokattu
• PowerAppsin tyyppi: perinteinen PowerApps / SharePoint listan lomake joka on korvattu PowerAppsilla

SharePoint -listan lomakkeen räätälöinti PowerAppsilla tarkoittaa usein, että listan varaan on tehty pieni liiketoimintasovellus.

Tämä on se keskitetty paikka mistä nämä usein piilossa olevat räätälöinnit löytyvät.

Listan avulla tunnistat henkilöt, jotka tekevät paljon PowerAppseja (heidät voi esimerkiksi houkutella innostamaan myös muita tekemään niitä).

Lataamalla sovelluslistan omalle työasemallesi saat edellämainittujen tietojen lisäksi esille kunkin PowerAppsin käyttämät yhdistimet (lukumäärä + yhdistimien tyypit). Yhdistimien tyypit (esim. SharePoint, OneDrive ja AzureAD) saattavat avata paremmin mitä sovelluksella tehdään. Tai soittaa varoituskelloja. Mitä tämä sovellus tekee AzureAD:n tiedoilla?

DLP (Data loss policies)

PowerAppsilla on helppo kytkeytyä (connectorien avulla) eri tietolähteisiin ja palveluihin. PowerApps voi olla kiinni useassa tietolähteessä. Osa tietolähdeyhdistelmistä kuulostaa vaarallisilta. Mitä ajattelet PowerAppsista joka on yhteydessä sekä Dynamics 365:een että Dropboxiin? Tai samaan aikaan OneDrive Businekseen ja tavalliseen OneDriveen.

Hmmm… yrityksen tietoja saattaa epähuomiossa siirtyä palveluihin, joihin niitä ei ole soveliasta tallentaa.

Tätä varten on olemassa DLP (Data loss policies). DLP:n avulla voit ryhmitellä yhdistimet kahteen ryhmään:

1. ainoastaan liiketoimintadataa käsittelevät yhdistimet
2. muuta kuin liiketoimintadataa käsittelevät yhdistimet

Oletuksena kaikki yhdistimet kuuluvat jälkimmäiseen ryhmään ja kaikki yhdistinyhdistelmät ovat sallittuja. Mutta jos siirrät SharePoint, Dynamics 365 ja OneDrive for Business -yhdistimet ryhmään 1, niin käyttäjän lisättyä PowerAppsiin minkä tahansa näistä yhdistimistä, ei hän voi lisätä siihen enää mitään yhdistimiä ryhmästä 2. Esimerkiksi Dropboxia tai Twitteriä.

DLP:n kanssa tulee olla tarkkana, ettei rajoita yhdistimien käyttöä huomaamattaan liikaa. Vaikka jotkut työkalut ovat omassa organisaatiossa kiellettyjä, voivat ne olla kumppanien tai asiakkaiden aktiivisesti käyttämiä. Tällöin niiden kieltäminen ei aina olekkaan järkevää (PowerApps hakee tietoja kumppanin DropBoxista ja organisaation omasta OneDrivesta).

Ympäristöt (environments)

Pienimuotoinen PowerApps -kehitys on suoraviivaista. Valmis PowerApps julkaistaan (publish) käyttäjille, jonka jälkeen se on käytettävissä. PowerAppsin kehittämistä voidaan  jatkaa julkaisemattomien versioiden avulla. Näihin pääsee käsiksi vain PowerAppsin omistaja ja muokkaajat (editors).

Kun pienimuotoisesta tekemisestä siirrytään kohti ammattimaisempaa sovelluskehitystä, ei tämä enää riitä. Silloin luodaan omat ympäristöt kehitykselle, testaamiselle ja tuotannolle.

Kullakin ympäristöllä on omat käyttöoikeutensa (ketkä saavat luoda ympäristöön PowerAppseja jne), omat DLP-sääntönsä sekä omat Common Data Servicet (CDS)

Sovelluskehitysnäkökulmasta en kuitenkaan voi (vielä) suositella erillisten ympäristöjen käyttöä. PowerAppsien siirtäminen (deployment) ympäristöjen välillä on lapsenkengissä. Kuvitellaan seuraavanlainen tilanne:

• Tenantissa on kaksi ympäristöä (test / prod)
• Testiympäristöä varten Office 365 testitenantissa on SharePoint -lista, jota testi PowerApps käyttää tietolähteenä
• Tuotantoympäristöä varten Office 365 tuotantotenantissa on SharePoint -lista, jota tuotanto PowerApps käyttää tietolähteenään
• PowerAppsin avulla päivitetään ko SharePoint -listan tietoja vaivalla muokattua lomaketta käyttäen.

Aina kun siirrämme PowerAppsin testistä tuotantoon, pitää tuotannossa määritellä käytettävä tietolähde uudelleen. Tämän yhteydessä lomakkeelle tehdyt muutokset katoavat.

Snif.

PowerAppsin sisar – Flow

PowerAppsien ja Flow-työnkulkujen hallinnointi on niputettu yhteen. Hankituilla PowerApps plan 2 -lisensseillä pääsee täten hallitsemaan myös Flow:lla tehtyjä työnkulkuja.

Lista ympäristön Flow-työnkuluista

Hallintakeskuksesta näkee PowerAppseja vastaavalla tavalla kaikki ympäristön työnkulut. Kuka ne omistaa, onko ne päällä ja milloin niitä on viimeksi muokattu.

Työnkulkujen suorituskerrat

Office 365 -tenantissa voi ajaa kuukausittain ilmaiseksi tietyn määrän Flow-suorituksia. Määrä määräytyy lisensoitujen käyttäjien perusteella. Hallintakeskus on paikka, josta näet paljonko kuukauden Flow-kapasiteetista on käytetty.

Kuvan tenantissa on ajettu huhtikuussa 32 / 400 000 Flow-suoritusta. Väitän että tilanne on samansuuntainen useimmissa Office 365 -ympäristössä. Käyttämätöntä kapasiteettia löytyy.

Flow:n käytön yleistyessä kannattaa säännöllisesti ladata ajoraportti Exceliin. Varsinkn viimeinen sarake (Runs Consumed) on kiinnostava. Sen avulla tunnistat

• suositut työnkulut
• mahdollisesti liian usein käynnistyvät (ajastetut) työnkulut
• mahdollisesti huonosti tehdyt työnkulut
• turhat työnkulut

Jokainen näistä vaatii toimenpiteitä. Suosituista pitää oppia ja muut tulee korjata.

DLP (Data loss policies)

Ympäristöille määritetyt DLP-säännöt koskevat myös Flow-työnkulkuja.

Yhteenveto

Organisaation IT:lle on tarjolla työkaluja PowerAppsien sekä Flow-työnkulkujen seurantaan ja hallinnointiin. Niillä pääsee hyvin alkuun, mutta odotan lähitulevaisuudessa esimerkiksi seuraavia lisäyksiä:

• Kehittyneemmät export ja import -työvälineet PowerAppsien siirtoon eri ympäristöjen välillä
• PowerApps ja Flow -listoihin tiedoksi viimeisimmän suorituskerran ajankohta. Tämä helpottaisi ympäristön siivoamista.
• PowerAppsien käytön raportointi. Yksittäisestä PowerAppsista on tarjolla raportit käytöstä, suorituskyvystä sekä käyttäjien sijainnista. Vastaavat raportit olisi tarpeen koko PowerApps kokoelmasta, jolloin nähtäisiin esimerkiksi ympäristön käytetyimmät PowerApps:it, millä niitä käytetään ja missä.

Esittelemäni työkalut auttavat PowerAppsien ja Flow-työnkulkujen hallinnassa ja seurannassa. Varsinkin isommissa organisaatiossa on kuitenkin syytä miettiä kevyen hallintamallin rakentamista PowerAppsien ympärille.

Mutta se on jo aivan oma tarina se.