Power Series: Bemutatkozik a Power Automate alkalmazás
A Power Series célja az, hogy az egyes epizódokban Power Platform megoldásokat hozzunk létre és bővítsük, mind low-coding, mind pure-coding kódolási technológiák felhasználásával.
Létrehozzuk az adatfolyamunkat, amely értesítési e-maileket küld az elõfizetőknek.
A folyamat akkor fut, ha Lehetőséget-t hozunk létre vagy azt egy új felhasználóhoz rendeljük. Ezután meg fogja találni azt a Kontaktot, amelyik ugyanazzal az email címmel rendelkezik, mint a Lehetőség tulajdonosa, meghatározza, hogy a kapcsolatnak van-e aktív Előfizetése a meghatározott Előfizetési Csatornára, és szükség esetén elküldi az e-mailt.
Megjegyzés: Azért választottuk a Kontakt használata helyett a Felhasználókat, mert ez az egyetlen módja annak, hogy bárki előfizetővé váljon, nem csak azoknak, akik a környezetünkben engedéllyel rendelkeznek. Ezenkívül, ha kibővítjük alkalmazásunkat egy Power App Portallal, akkor a Kontaktokat fogja használni a hitelesítéshez.
Új folyamat létrehozása:
Mivel egy megoldás közepén vagyunk, használhatjuk a Common Data Service (aktuális környezet) konnektort. Ez nem ugyanaz, mint a Common Data Service konnektor, ezért érdemes minden esetben ellenőrizni, hogy a folyamatban bármilyen művelet létrehozásakor a megfelelőt használjuk-e!
Megjegyzés: A két konnektor közötti fő különbség az, hogy az elsőhöz nem kell meghatároznia az aktuális környezetet. Ettől eltekintve, számos új művelethez fér hozzá, és a folyamatban lehetősége van definiálni egy eseményindítót több eseményre a CDS-en belül (például létrehozás és frissítés).
Egyszerre végigmegyünk a folyamat minden lépésén. Így ha elakad valahol, vagy nem ért valamit, ne aggódjon. A folyamat a megoldás része, amelyet a cikk végén tölthet le!
Az eseményindítónk meghatározza, hogy akkor kell futnia, amikor valaki a szervezeten belül létrehoz vagy frissít egy Lehetőséget. Amint láthatjuk, meghatároztuk a Szűrés attribútumot, amely azt mondja nekünk, hogy a folyamat csak akkor fusson, ha a tulajdonos-attribútum megváltozott.
2. Adjon hozzá egy feltételt a Művelet hozzáadása elemre kattintva az eseményindítónk után. Válassza a Vezérlés elemet, majd kattintson a Feltétel elemre. Ez a feltétel megszünteti a folyamatot, ha a Tulajdonos (Típus) nincs beállítva rendszerhasználókra.
Találkoztam egy buggal, ahol a Tulajdonos (Típus) mező kiválasztása nem működött megfelelően, ezért ahelyett, hogy közvetlenül a Dinamikus tartalomból választaná ki a mezőt, használja a következő kifejezést: triggerBody()?['_ownerid_type']
A feltétel kötelező, mert sajnos nem tudjuk meghatározni a típusszűrést az indító szűrőattribútumaiban.
3. A könnyebb konfiguráció érdekében egy Változót adunk hozzá a folyamatunkhoz egy új művelet hozzáadásával, a Változó kiválasztásával és a Változó inicializálása gombra kattintással. Ezután adjon Nevet a változónak, adja meg a Típust karakterláncként, és az érték legyen az Előfizetési Csatorna Csatorna Címe.
Később a folyamatunkban feliratkozásokat keresünk erre az előfizetési csatornára. De ahelyett, hogy folyamatosan kódolnánk benne, azt tanácsoljuk, hogy tegye egy változóba, amelyet később könnyebben lehet módosítani.
4. Adjon hozzá új műveletet a Közös Adatszolgáltatás (aktuális környezet) konnektor és a Felvétel művelet kiválasztásával. Állítsa be az Entitás Nevét felhasználónak, az Elem Azonosítóját pedig Tulajdonosnak (Érték).
Ki kell töltenünk a saját Felhasználói rekordot, hogy lekérjük a felhasználó e-mail címét. Ezt az e-mail címet fogjuk használni a megfelelő Kapcsolat kereséséhez.
5. Adjon hozzá egy új Lista rekordok műveletet a CDS-ből (aktuális környezet).
Az Entitás névnek Kontaktok-nak kell lennie, és a Szűrő lekérdezésnek pedig emailaddress1 eq '@{outputs('Get_owner_user')?['body/internalemailaddress']}' kell lennie.
Vegye figyelembe, hogy a szűrő lekérdezés feltételezi, hogy az előző lépést átnevezte a Tulajdonos felhasználó megszerzése pontra. Ha nem, akkor a dinamikus értéket kicserélheti a visszakeresett felhasználó Elsődleges Email címére, ahogy az a fenti képen látható.
A beolvasott Kontaktokat az aktív előfizetések keresésére használjuk. Ezért volt szükségünk egy kontaktra pontosan ugyanazzal az e-mail címmel, mert a felhasználó e-mail címével fogunk kontaktokat keresni.
Megjegyzés: Az ok amiért a Lista rekordokat használjuk a Rekord lekérdezése helyett, az az, hogy egyetlen rekord csak a GUID segítségével állítható elő. Jelenleg a CDS-konnektor nem támogatja az alternatív gombok használatát egyetlen elem lekéréséhez.
6. Adjon hozzá egy újabb Lista rögzítési műveletet a CDS-ből (Aktuális környezet) az Előfizetési Csatornák felsorolásához.
A Szűrő lekérdezést gaborg_title eq '@{variables('Subscription Name: E-mail Notifications')}' and statecode eq 0 értékre érdemes állítani.
Vegye figyelembe, hogy a tulajdonság előtagja és a változó neve eltérő lehet a folyamatban, győződjön meg arról, hogy mindkettőt helyesen adta-e hozzá, mint ahogy a fenti képen is látható.
A szűrőlekérdezés eq 0 állapotkódja meghatározza, hogy csak aktív Előfizetési Csatornákat keresünk. Ez a művelet lekérdezi az előfizetési csatornák listáját, amelyen keresztülmegyünk – egyéb esetben csak egy rekord lesz.
7. Adjon hozzá két beágyazott Alkalmazást a Vezérlők minden hurokjához. A külső huroknak a Kontakt Lista értékein kell keresztül mennie, míg a belső huroknak az Előfizetési Csatorna Lista értékein.
Kattintson a Kimenet kiválasztása az előző lépésekből elemre. Látni fogja, hogy mindkét Listarekord művelet értéktulajdonságot adott vissza. A fentiek szerint minden hurokhoz ki kell választania a megfelelőt.
Mindegyik Kontaktokhoz, amelyet a saját Felhasználó e-mail címére találtunk, aktív előfizetéseket fogunk keresni az összes lekért Előfizetési Csatornára.
8. A legbelső hurok belsejébe újabb Listarekord műveletet fogunk hozzáadni a CDS-ből (aktuális környezet), hogy listázni tudjuk az aktuális Kapcsolat és Előfizetési Csatorna előfizetéseit. Csak aktív előfizetéseket fogunk keresni.
Kérjük, ellenőrizze, hogy minden tulajdonsághoz a megfelelő előtagokat használja-e, és az előző lépésekből hozzáadta-e a megfelelő dinamikus értékeket. A Contact tulajdonság a Felhasználói kapcsolat lekérdezéséből származik, míg az Előfizetői Csatorna tulajdonsága az Előfizetői csatornák lekérdezése lépésből származik.
A példánkban szereplő Szűrő lekérdezése a következő: _gaborg_subscriber_value eq @{items('Send_notification_to_contacts')?['contactid']} and _gaborg_subscriptionchannel_value eq '@{items('Get_subscriptions_for_channel_found_by_name')?['gaborg_subscriptionchannelid']}' and statecode eq 0
A művelet lekérdezi az aktív Előfizetések listáját, ahol az Előfizető mező tartalmazza a hurok aktuális Kontaktját és a hurok aktuális Előfizetési Csatornáját.
9. Végül, de nem utolsósorban, Feltételt adunk hozzá annak ellenőrzéséhez, hogy az Előfizetési lista tartalmaz-e elemet. Ha igen, akkor az Outlook 365 használatával Emailt küldünk a Kapcsolat e-mail címére egy üzenettel.
Használhatja a length () kifejezést az Előfizetések Listájának visszatért értékével, és összehasonlíthatja, ha az nem egyenlő 0-val.
Ez a folyamat utolsó lépése, ahol értesítést küldünk, ha az elején találtunk aktív előfizetést arra a csatornára, amelyet a változóban definiáltunk.
A folyamat - és látszólag a teljes megoldás - teszteléséhez hozzon létre egy új Lehetőséget környezetében, ahol az Ön felhasználója a tulajdonos lesz. A folyamatot el kell indítani, és értesítési e-mailt kell kapnia.
Megjegyzés: Próbálja meg inaktiválni az Előfizetést az e-mail értesítésekhez, és hozzon létre egy újabb Lehetőséget. Ezúttal viszont nem kéne kapnia értesítést.
Ebben az első epizódban megteremtettük megoldásunk alapjait, ahol manuálisan konfigurálhatjuk kapcsolataink előfizetését az egyes csatornákhoz, és létrehoztunk egy példát a Power Automate folyamatra, amely e-mail értesítéseket küld az előfizető kapcsolatoknak.
A következő részben kibővítjük a jelenlegi megoldást azzal a lehetőséggel, hogy előfizetőink leiratkozhassanak az e-mail értesítésekről. Ezenkívül létrehozunk egy Vászonalkalmazást, ahol az emberek kezelhetik saját előfizetéseiket, és push értesítéseket kaphatnak!
Gulyás Gábor
Software Developer
Qualysoft Informatikai Zrt.