Power Platform on tarkoitettu kansalaiskehittäjille, IT-ammattilaisille, konsulteille, kehittäjille jne. Tästä johtuen sillä toteutetaan hyvin erilaisia ja kokoisia ratkaisuja. Pienistä hupailuista aina laajoihin liiketoimintasovelluksiin.
Jälkimmäisten kohdalla nousee usein esiin termi ALM (Application Lifecycle Management, sovelluksen elinkaaren hallinta). Microsoft on varautunut aiheeseen hyvin. Power Platformille ja ALM:lle on pyhitetty kokonainen osio Docsissa.
Kaikki siis hyvin!
Paitsi ettei ole.
Ratkaisupaketit (solution package) näyttelevät keskeisestä roolia Power Platformin ALM tarinassa. Ratkaisupaketit ovat tuttuja Dynamics 365 -taustaisille tekijöille, sillä niitä on käytetty D365 maailmassa jo pitkään. Office 365 -taustaiset tekijät eivät ole niistä välttämättä koskaan kuulleetkaan. Ja vaikka olisivatkin, eivät he niitä juurikaan käytä.
Mikseivät?
Koska niistä on toistaiseksi enemmän haittaa kuin hyötyä. Jotta syy tähän selviää kaikille, käydään läpi mitä ratkaisupakettien hyödyntäminen Office 365 -pohjaisissa Power Platform -ratkaisuissa oikeasti tarkoittaa.
Aloitetaan kuitenkin alkeista.
Mitä ratkaisupaketit ovat?
Idea on yksinkertainen. Kun ratkaisua lähdetään tekemään, luodaan ensimmäiseksi ratkaisupaketti (kuvassa alla ”Leasingauto”). Tämän jälkeen kaikki ratkaisun elementit kasataan tämän ratkaisupaketin sisään.
Lopputuloksena ratkaisu kaikkine elementteineen voidaan siirtää yhdellä kertaa ympäristöstä toiseen (tyypillisesti kehityksestä testiin ja sieltä tuotantoon).
Kun ratkaisua kehitetään edelleen, voidaan muutokset viedä jälleen testiin ja tuotantoon nätisti ratkaisupakettina.
Hienoa.
Tämä on mahdollista koska ratkaisupaketti sisältää kuvaukset myös ratkaisun käyttämistä entiteeteistä. Niiden sisällöistä ja suhteista. Käytännössä tietomalli siirtyy paketin mukana. Asennuksen yhteydessä kohdejärjestelmään luodaan puuttuvat entiteetit ja/tai niistä puuttuvat kentät jne.
Tilanne muuttuu, kun ratkaisu käyttää tietovarastona mitä tahansa muuta kuin CDS:ää. Paketissa ei ole silloin jälkeäkään tietomallista tai tietolähteistä.
Kun viemme tällaisen ratkaisupaketin toiseen ympäristöön, viemme sinne käytännössä kasan canvas Power Appseja ja Flow’ta, jotka hyödyntävät SharePoint-listoja. Paketilla ei kuitenkaan ole mitään käsitystä näistä SharePoint-listoista.
- Onko kohdeympäristössä tarvittavia listoja olemassa ollenkaan?
- Ovatko käytettävien listojen sarakkeet samat kuin lähdeympäristössä?
- Missä listat fyysisesti sijatsevat (mikä sivusto, mikä lista ko sivustolla)?
Mihin tämä tietämättömyys vaikuttaa? Katsotaan.
Ratkaisupaketin luominen
Luodaan uusi ratkaisupaketti (Demo connection references) ja luodaan sen sisään seuraavat elementit.
- Flow, joka käynnistyy aina kun SharePoint-listalle X luodaan uusi rivi
- Flow, joka käynnistyy ajastetusti päivittäin ja muokkaa SharePoint-listan X rivejä
- Flow, joka käynnistyy Power Appsista ja joka lisää SharePoint-listalle X uuden rivin
- Power Apps, jolla voi päivittää SharePoint-listan X rivejä ja josta voi käynnistää edellisen Flow’n
Lopulta ratkaisupakettimme näyttää tältä.
Nyt voimme siirtää sen toiseen tenanttiin ja ympäristööön.
Ratkaisupaketin vieminen ja tuominen
Ensimmäiseksi ratkaisupaketti tallennetaan siirrettävään muotoon (zip) tuo (Export) -toiminnolla.
Siirrytään kohdetenanttiin ja luodaan sinne ratkaisun käyttämät SharePoint-listat. Esimerkissämme on vain yksi simppeli lista. Luodaan se.
Sinun tehtäväsi on varmistaa että lista on saman niminen kuin lähdeympäristössä (tärkeää Power Appsille) ja että sen sarakkeet ovat identtiset lähdeympäristön listan kanssa.
Siirrytään kohdeympäristöön (environment) ja aloitetaan ratkaisupaketin tuonti (import).
Ensimmäisen tuonnin aikana määritellään mitä yhteyksiä kohdeympäristössä käytetään. Voit käyttää olemassaolevia ja/tai luoda uusia.
Mikäli käytät ympäristömuuttujia (environment variable), niin myös niiden arvot kysytään tuonnin yhteydessä.
Toimiiko tuonnin jälkeen mikään?
Ei.
Flow:t tuonnin jälkeen
Kaikki Flow’n toiminot (action) hyödyntävät nyt kohdeympäristön yhteyksiä. Niitä ei tarvitse päivittää (kuten aiemmin piti). Kaikki SharePoint-toiminot osoittavat kuitenkin edelleen lähdeympäristön listoihin. Ratkaisupaketilla kun ei ole mitään käsitystä käyttämistäsi tietolähteistä.
Jokainen toiminto tulee käydä käsin läpi ja päivittää sekä sivusto että lista oikeiksi. Mikäli toimintoja on paljon, vie tämä hetken. Aikaa ja hermoja.
Korjauksen jälkeen kaikki toimii.
Mikäli käynnistät Flow’n Power Appsista, saattaa sen muokkaaminen hajottaa sen.
No ei se oikesti hajoa. Kunhan et lisää siihen uusia toimintoja.
Power Apps tuonnin jälkeen
Power Appsin yhteydet (connection) käyttävät myöskin kohdeympäristön yhteyttä, mutta alkuperäistä tietojoukkoa (dataset). Joka asuu tietenkin lähdeympäristössä.
Kaikki (SharePoint/OneDrive/Sql) yhteydet tulee siis korjata. Käytännössä poistaa ja luoda uudelleen.
Myös Power Appsista käynnistettävä Flow on kadonnut. Sekin tulee poistaa ja lisätä uudelleen.
Huoh.
Ratkaisun päivittäminen
Tehdään työnkulkuihin ja Power Appsiin muutoksia lähdeympäristössä ja tuodaan päivitetty versio kohdeympäristöön.
Miltä tilanne näyttää nyt?
Aivan samalta. Kaikki toiminnot ovat jälleen hajalla.
Samoin ovat Power Appsin yhteydet.
Tupla huoh.
Muuttujien hyödyntäminen
Tilannetta voi helpottaa hieman hyödyntämällä muuttujia (variable).
Määritellään Flow’n alussa omiin muuttujiinsa
- sivustojen osoitteet, joista tarvittavat listat löytyvät
- kunkin käytettävän listan tunniste (GUID).
Muuttujia käytetään kaikissa toiminnoissa valittavien arvojen sijaan. Siirrettäessä Flow’ta ympäristöstä toiseen, tarvitsee päivittää vain Flow’n alussa olevien muuttujien arvot.
Huomattavasti vähemmän näksyttelyä.
Muuttujien käyttö vaikuttaa SharePoint-toimintoihin. Flow ei enää tiedä listojen rakennetta ja tästä syystä päivitykset ja lisäykset annetaan JSON-muodossa item-kenttään.
Muutujien arvot tulee tietenkin päivittää jokaisen tuonnin yhteydessä uudelleen.
Huoh.
Ympäristömuuttujien hyödyntäminen
Mikset käytä ympäristömuuttujia?
Dynamics 365 -konsultti
Koska niitä käytetään premium-yhdistimen (Common Data Service) avulla. Jos meillä olisi sen edellyttämiä Power Apps / Flow planeja käytössämme, emme käyttäisi tietovarastona SharePointia alunperinkään (vaan Common Data Serviceä).
Ympäristömuuttujat olisivat kyllä käteviä. Niiden arvot tallennetaan ympäristön Environment Variable Values -entiteettiin. Eli arvot annetaan vain ensimmäisen tuonnin yhteydessä. Päivityksissä niistä ei tarvitse enää murehtia.
Merkittävästi vähemmän työtä!
Muttei vieläkään täydellistä.
Ongelmaksi jäävät Flow’t, jotka käynnistyvät SharePoint-listoille tehtyjen muutosten perusteella. Emme voi hyödyntää triggereissä sen enempää tavallisia kuin ympäristömuuttujiakaan. Ne joutuu käymään jokaisen tuonnin jälkeen edelleen käsin läpi.
Myöskään Power Appsissa muuttujien käyttö ei helpota ongelmaamme. Yhdistimet joutuu edelleen korjaamaan jokaisen tuonnin jälkeen.
Ratkaisupaketin manipulointi
Voimme toki avata ratkaisupaketin (zip-tiedosto) ja käydä muuttamassa kaikkien paketin Flow’den kuvaustiedostoista datasettien (SharePoint-listan sisältävä sivusto) ja taulukoiden (listan id) arvot.
SharePoint-listan muutoksista käynnistyvän Flow’n sisältö näyttää tältä.
Vaihdetaan arvot vastaamaan kohdejärjestelmän tietoja, pakataan tiedosto uudelleen ja tuodaan kohdeympäristöön.
Ja kas, Flow ilmestyy kohdeympäristöön oikein!
Mutta haluammeko oikeasti manipuloida ratkaisupaketin tiedostoja jokaisen siirron yhteydessä?
Minä en halua.
Yhteenveto
Office 365 näkökulmasta katsottuna Power Platformin ALM tarina on vielä puutteellinen. Mutta se kehittyy.
Aluksi canvas appseja ei voinut lisätä osaksi ratkaisupaketteja. Nyt voi.
Tällä viikolla tuli mahdolliseksi luoda tuonnin yhteydessä lähdeympäristön yhteyksiä vastaavat yhteydet myös kohdeympäristöön (connection references). Merkittävä helpotus!
Jäämme odottamaan, mikä on seuraava kehitysaskel. Vielä ratkaisupaketit eivät ole valmiita käytettäviksi Office 365 -pohjaissa ratkaisuissa. Uskon ja toivon että tulevaisuudessa ne ovat.
Common Data Serviceä hyödyntävissä ratkaisuissa tilanne on aivan toinen. Silloin ratkaisupaketteja kannattaa ehdottomasti käyttää.
Timo Pertilä 