Tag Power Automate

How to migrate your Power Automates to Azure Logic Apps and why?

Toni Saarinen Leave a comment

It’s really easy to implement and use Microsoft Power Automate (previously named as Microsoft Flow) to support your or your team’s daily work. You can use different triggers and ready made connectors to automate processes, react to any input and move data in context of Microsoft solutions. Also hundreds of 3rd party software is supported and Power Automate alongside with other Power Platform products allows you to achieve complex solutions easily even without any actual integration or coding skills.

However Power Automates can easily be really complex ones and in some point (especially if you have developer or architect background) you may start to miss a better editor than browser based UI and maybe also a better support for versioning and deployment etc.

Then it may be correct time to check what Azure Logic Apps has to offer for you. Power Automate is actually a almost same thing as Azure Logic App but it’s separated to Office 365 context to be available within Office 365 licensing model.

Possible why’s to start using Azure Logic Apps?

  • Export / Import to create Logic App from Power Automate is fairly easy and automatic operation.
  • Starting to work directly with Azure Logic apps is easy if you have a basic knowledge from Azure components, available Azure subscription and contribute rights at least to one Azure resource group
  • All Azure extensibility options, monitoring, logging and other Azure services are available to support your Logic App approach – Azure Key Vault at least to mention to store you Logic App related secrets
  • You can actually use Visual Studio 2019 or Visual Studio Code to modify or deploy your Logic Apps (Azure Logic Apps Tools for Visual Studio or Azure Logic Apps extension are required)
  • DevOps (version control and automated deployment) and better manageability – Power Platform is advancing all the time but still it lacks complete DevOps story and capabilities
  • Logic App pricing model (pay-as-you-go / per action) differs from Power Automate (Licensing with seeded, per app or per user options) and it could be beneficial to compare these approaches in terms of overall costs
  • Allows usage of Azure Integration Accounts for approaches which can benefit from them

How to import Power Automate as Azure Logic App?

In my case Logic App is handling Microsoft Teams related data through GraphAPI on top of SharePoint custom list.

1. Go to Power Automate center and export your current Power Automate in JSON form – Open your Power Automate and select Export | Logic Apps template .json

2. Access your Azure portal and select “Create a resource” and find option “Template deployment” and select “Create | Build your own template in the editor”

3. Now upload your exported JSON file to editor with “Load file” option and press save to define necessary information for your Logic App

4. If deployment goes fine that’s all and you can start develop your Logic Apps in Azure. One step however is to re-authenticate Azure API connections (former Power Automate connections) used by Logic App in App Edit mode. All connections requiring re-authentication are highlighted and you have to enter credentials or select already created working connection.

5. Please note in addition to Azure default Logic app editor you can now use Visual Studio Code Or Visual Studio 2019 to connect and manage your Logic Apps. It seems this approach actually offer a more stable way compared to browsers to modify your Logic Apps.

6. Instead of Azure template deployment, you can also create a Visual Studio “Azure Resource Group” typed project and select Logic App template to connect and deploy Logic App to your Azure subscription. You can replace the highlighted file with your Power Automate export(s) and deploy your project to Azure directly.

Encountered issues & Considerations

  • All connectors from Power Automate are not necessary available in Logic Apps. You can import Power Automates that have equivalent connectors in Azure Logic Apps. For example, the Button trigger, the Approval connector, and Notification connector are specific to only Power Automate https://docs.microsoft.com/en-us/azure/connectors/apis-list
  • By default for Logic Apps “Apply to each” loops enables concurrency which causes issues when using for Logic App variables with SharePoint Update item connector for example. So setting concurrency “Degree of Parallelism” setting from apply to each control settings to 1 helps but this will have a effect for performance
  • It seems that in my case multiple SharePoint API connections within single Logic App JSON definition causes error in deployment. If needed you can clear the extra connections from Power Automate UI and export the JSON manifest again. Alternatively you can manually clear these “extra references” from JSON (with Notepad++ for example) to get Power Automate imported correctly. It should be fairly easy to identify and change connection references from JSON file.

So if you have a wider workflow needs (real enterprise scenarios with premium connector needs for example) in your hands on Office 365/Azure cloud environment and you are thinking to use or already using Power Automate, it could be worth to check what Azure Logic apps has to offer and could this be more viable approach for you.

Microsoft Power Platformin käyttöönoton ensiaskeleet

Toni Saarinen Leave a comment

Microsoftin Power Platform on yhä vahvempi tekijä, kun puhutaan nk. “low-code” alustoista. Ne mahdollistavat monia sovelluskehityksen ja sovellusautomaation mahdollisuuksia graafisen käyttöliittymän kautta ilman työlästä sovelluskehitystä. Tämä malli leikkaa tyypillisesti sovelluksen käyttöönottoon tarvittavaa aikaa sekä erityisesti kustannuksia. Alustan avulla loppukäyttäjät voivat tehdä monia asioita, jotka aiemmin eivät olleet mahdollisia ainakaan ilman raskaita ja kalliita sovelluskehityksen ponnisteluita. Power Platformin käyttöönotto voikin parhaimmillaan tehostaa työntekijöiden ajankäyttöä merkittävästi ja tuoda tätä kautta kustannussäästöjä, yleistä tehokkuuden paranemista sekä lisätä henkilöstön yleistä tyytyväisyyttä.

Myös Gartner listasi aiemmin syksyllä Microsoftin Power Platformin low-code alustojen tämän hetkiseksi markkinajohtaksi: https://powerapps.microsoft.com/en-us/blog/gartner-names-microsoft-a-leader-in-enterprise-low-code-application-platforms-2019-magic-quadrant/

Kirjoittelin tämän vuoden MS Igniten pohjalta yhteenvetoa jo aiemmin, ja sieltä löytyy muutama sananen myös Power Platformista: https://newway2work.blog/2019/11/13/ms-ignite-2019-loppukayttaja-ottaa-modernin-tyon-yha-vahvemmin-omiin-kasiinsa/

Lähde: Microsoft Ignite 2019 – POWA10: Enabling everyone to digitize apps and processes with Power Apps and the Power Platform

Tässä blogissa esittelen yksinkertaistettuna Power Platform -ympäristön käyttöönoton perustarpeet. Oletus on, että organisaatio haluaa hyödyntää ja lähteä liikkeelle seuraavilla kokonaisuuksilla:

  • Graafiset Canvas-tyyppiset Power Appsit ja niiden päälle rakennetut kevyet sovellukset
  • Työnkulut ja sovellusautomaatio niiltä osin, kun tarpeita on tunnistettu
  • Em. kokonaisuudet halutaan tuoda kaikkien työntekijöiden saataville sekä toisaalta halutaan tehdä muutamia “virallisia” sovelluksia organisaatiolle

Mitä pitää vähintään huomioida?

1) Power Platform-ympäristöt

Kaikkiin Office 365 -tenantteihin muodostuu automaattisesti yksi default -ympäristö (Environment). Tähän ympäristöön päätyvät oletuksena kaikki luotavat Power Appsit ja Power Automate-työnkulut. Lisäksi kaikilla käyttäjillä on oikeus luoda em. komponentteja ympäristöön.

Ympäristöjä voidaan hallita Power Platformin Admin Centerin kautta osoitteessa https://admin.powerplatform.microsoft.com/environments.

Organisaation tarpeista riippuen pitäisi luoda ainakin toinen ympäristö tuotantokäyttöön (Type “Production”), johon kasataan organisaation viralliset sovellukset. Tähän ympäristöön voidaan antaa rajatummat käyttöoikeudet ympäristökohtaisen nk. maker-roolin puitteissa, jolloin kokonaisuus on paremmin hallittava. Tähän liittyy myös ympäristön kesken jaettujen datayhteyksien tietoturva ja tarvittaessa myös ympärisökohtaiset DLP-policyt. Lisäksi voidaan perustaa esim. kehitysympäristö, johon voidaan myös määrittää erikseen oikeuksia tyypillisesti default- ja tuotantoympäristön välimaastosta.

Esimerkki Power Platform-ympäristöistä tenantissa

2) Erillinen automaatiotunnus

Power Platformin käyttöön kannattaa luoda erillinen automaatiotunnus, joka omistaa lähtökohtaisesti tuotanto-ympäristön sovellukset. Ei ole väliä, onko tämä tunnus lokaali AD:n tunnus vai “Cloud Only”-tyyppinen Azure AD-tunnus. Tämän omistajatunnuksen rinnalle voidaan tuoda co-owner roolissa esim. IT:n henkilöiden tunnukset / ryhmät. Tätä kautta säilytetään hyvä näkyvyys kaikkiin ympäristössä oleviin sovelluksiin sekä mahdollistetaan tarvittavat huoltotoimet.

Hyviä syitä automaatiotunnuksen luomiseen ovat ainakin:

  • Perinteinen sovelluksen omistajan lähtö yrityksestä -> Orvot työnkulut ja Power Appsit
  • Tarvittaessa kaikilla hallintorooleilla pääsy sovelluksiin yhden tunnuksen kautta
  • Sovelluksen sisäiset datayhteydet määritellään usein samalle tunnukselle, joka omistaa sovelluksen -> Huomioi tunnuksen näkyvyys loppukäyttäjille tietyin yhdistimin, kuten esim. sähköpostin lähetys tai Teams-viestin lähetys
  • Yhdistimien vaatimat oikeudet taustalla voivat olla järeitä Office 365 admin-rooleja -> selkeä luvitusmalli
  • Tarvittaessa MFA-autentikaatio voidaan pitää voimassa myös tässä mallissa

3) Lisensointitarpeet

Lisensointitarpeet on hyvä selvittää heti alkuun. Perusyhdistimet ja esim. SharePoint-listan hyödyntäminen tietovarastona kuuluvat peruslisensointiin ja itse asiassa näillä päästään peruskäyttötapauksissa ja perussovelluksissa hyvinkin pitkälle.

Esimerkki saatavilla olevista perusyhdistimistä

Erikseen maksullisia Per App ja Per User -lisensointimalleja tarvitaan ainakin seuraavissa tapauksessa mikäli:

  • Hyödynnetään premium-yhdistimiä
    • Dynamics 365-yhdistimet
    • Azure-yhdistimet ml. Azure SQL / Cosmos DB
    • GraphAPI ja sitä vasten tehtävät operaatiot
  • Käytetään Common Data Serviceä (CDS) tietovarastona
  • Käytetään ominaisuuksia, jotka tarvitsevat toimiakseen CDS:ää esim. AI Builder, Portal-tyyppiset Power Appsit, Power Virtual Agents jatkossa
  • Käytetään OnPremise Data Gateway:tä tapauksissa, joissa datalähde sijaitsee lokaalissa konesalissa

Lisensointi tulee aina miettiä tapauskohtaisesti ja esim. se, onko organisaatiolla käytössä Dynamics 365, vaikuttaa Power Platformin käyttömahdollisuuksiin merkittävästi. Uusin ohjeistus lisensointiin löytyy täältä https://docs.microsoft.com/en-us/power-platform/admin/powerapps-flow-licensing-faq.

4) Virallisten Canvas-tyyppisten Power Appsien ulkoasu ja käytettävyys

Liian usein tulee vastaan graafisia Power Appseja, joiden ulkoasu on jotakin “sinne päin”. Jotta loppukäyttäjien olisi mukava käyttää sovelluksia, edes perus saavutettavuusvaatimukset täyttyisivät ja applikaatiosta kävisi selkeästi ilmi minkä organisaation sovellus on kyseessä esim. vieraskäyttötapauksissa, olisi organisaation sähköisten kanavien ulkoasuun muutenkin sovellettavat ohjeet syytä huomioida myös Power Appsien puolella mahdollisuuksien mukaan. Esimerkkejä:

  • Perusilme aina samanlainen – Ylä- ja alatunnisteen sisältö
  • Perusnavigoitavuus ja esim. “koti”-painikkeen lokaatio
  • Käyttöliittymän suunnittelu jonkinlaisen “parhaan käytännön” mukaisesti niin, että liittymän perusasiat ovat kunnossa
  • Organisaation värimaailma ja logo applikaatiossa
  • Saavutettavuuden perusasiat: Riittävän suuri ja selkeä fontti, selkeät ja erottuvat elementit, riittävät kontrastit elementeissä jne.
Valmiita saatavilla olevia Canvas Power Apps-templaattimalleja

5) Sovelluksen loppukäyttäjät

Miksi sovellus olikaan olemassa? Todennäköisesti helpottaakseen loppukäyttäjien elämää ja päivittäisen työn tekemistä. Näin ollen loppukäyttäjät tulee huomioida monella eri rintamalla:

  • Ks. kohta 4. yhtenä tärkeimmistä
  • Loppukäyttäjien ja koko henkilöstön mahdollisuus ja tuki alustan ominaisuuksien hyödyntämiseen. Alustan perusominaisuudet käytössä kaikilla työntekijöillä Office 365 Business / E1 / E3 / E5-lisensointitasoilla ja myös F1 -lisensointi mahdollistaa sovellusten käytön
  • Tarvittava koulutus, jotta peruseväät ja “uskallus” hyödyntää ominaisuuksia ovat olemassa
  • Power Platform tulee ottaa osaksi käyttöönoton- ja muutoksen tukea organisaatiossa. Jos olette määritelleet esim. Office 365 -käytön Pelikirjaa, tulisi Power Platformin elementtien olla myös mukana Pelikirjassa
  • Yrityksen käytössä oleva mobiililaitteisto ja laitekanta

6) Kevyt hallintomallitarve virallisille sovelluksille

Vaikka Power Platform tuo kevyen mallin sovellusten rakenteluun ja hyödyntämiseen, ei sekään toimi ilman perushallintomallin määrittelyä. Organisaatiossa IT:n tai alustastavastaavien tahojen pitää pysyä perillä tilanteesta myös Power Platformin suhteen ja tarvittaessa esim. tarjota tukea, jos loppukäyttäjillä tulee ongelmia virallisten sovellusten kanssa. Samoin jos esim. sovelluskumppanin halutaan tekevän kehitystä alustalle, pitää kokonaisuuteen olla määriteltynä selkeä malli.

Hallintomallin tulisi sisältää vähintään seuraavat määrittelyt:

  • Kehitys- ja tuotantoonvienti prosessi virallisille applikaatioille – Missä ympäristössä kehittäminen tapahtuu? Kuka vie sovellukset tuotantoon? Missä ympäristössä bugikorjaukset tehdään? Miten jatkokehitys hoidetaan?
  • Sovellusten versiointi ja varmistus – Liittyy suuresti edelliseen kohtaan, mikä myös määrittelee sovellusten ja työnkulkujen versiointia. Vaikka sovellukset säilyvätkin ympäristöissä ja kuuluvat esim. Microsoftin perusvarmistusten piiriin, halutaanko uusista versioista viedä exportatut sovelluspaketit (ja tarvittaessa esim. SharePointin listatemplaatit) vielä erikseen organisaation versionhallintaan?
  • Yhtenevät nimeäsmiskäytännöt – Vaikka rakennettu sovellus muodostuisi esim. Canvas Power Appsista, Power Automate työnkulusta ja SharePointin listasta, ei suoraa linkitystä näiden elementtien välillä välttämättä ole sovellusnäkökulmasta. Dokumentaatio sovelluksista on hyvä olla olemassa ja eri komponentit tulee myös nimetä niin, että myöhemmin on helppo kertoa mitkä niistä liittyvät a) toisiinsa b) mihinkin toiminnalliseen kokonaisuuteen.
  • Power Appsien uudelleenjulkaisu ja yhdistimen versiopäivitykset tietyllä syklillä – Jotta Microsoftin päivitykset ja esim. yhdistimien suorituskykyyn liittyvät parannukset tulevat voimaan, tulisi Power App-sovellukset aika-ajoin julkaista uudelleen. Lisäksi Power Automaten yhdistimissä tapahtuu parannuksia ja versiopäivityksiä (kuten esim. juuri nyt Outlook-yhdistimen version päivittyminen V3 -> V4) ja nämä versiopäivitykset eivät automaattisesti päivity työnkulkuihin.
  • Ympäristöjen ja applikaatioiden monitorointi – Admin Centerin hallintaliittymien kautta on saatavilla jatkossa dataa siitä miten esim. Power Appseja käytetään organisaatiossa. Käyttöä tulisi mitata ja dataa pystyä hyödyntämään samalla tavoin kuin muutakin Office 365:n tuottamaa vastaavaa analytiikkaa toimintapojen kehittämisessä.
  • Virhetilanteiden selvitys ja tukitoiminnot – Power Platformin sovellukset ovat sovelluksia siinä missä kaikki muutkin sovellukset. Vastaavalla tavalla niissä ilmenee välillä loppukäyttäjillä ongelmia, joihin tarvittaessa pitää pystyä vastaamaan. Yrityksellä tulisi olla selkeä tukimalli esim. oman IT:n ja tarvittaessa vaikkapa sovelluskumppanin kautta.

Hyödyllisiä linkkejä ja dokumentteja, joilla päästä alkuun Power Platformin parissa

Lopuksi vielä muutamia linkkejä ja dokumentteja, jotka helpottavat Power Platformin käynnistelyä. Kun perusasiat ovat kunnossa, on vakaalla pohjalla mukavaa lähteä rakentamaan sovelluksia ja tätä kautta parantamaan työntekijöiden arkea ja päivittäistä työskentelyä.