Több Power Apps-példány végleges konzisztenciája

Ez a cikk egy olyan forgatókönyvet vázol fel, amelyben egy feltételezett amerikai ügyfél, a Contoso nemrég szerzett be egy másik európai székhelyű vállalatot, és a két vállalat közötti CRM- és ERP-rendszereken dolgozik. Az integráció részeként a Dynamics 365 Dataverse-entitások egy részét szinkronban kell tartaniuk, amíg teljesen integrálhatók. A Conotso saját fejlesztésű üzletági (LOB) alkalmazás mindkét rendszer adatait felhasználja, és képesnek kell lennie arra, hogy fogadja a kéréseket, amikor az adatok szinkronizálásra várnak, vagy ha hiányoznak. Az alábbi útmutató bemutatja, hogyan lehet figyelembe venni a Power Platform-példányok közötti végleges konzisztenciát.

Architektúra

Beépülő modul/folyamat mindig a GUID vagy alternatív kulcs alapján történő frissítéshez

Töltse le az architektúra Visio-fájlját.

Munkafolyamat

Ez a megoldás több beépülő modul lépéssel is felépíthető a beépülő modul életciklusán belül. Ha a létrehozott entitás kötelező, használja a PreValidation lépést. A preValidation az adatbázis-tranzakciók elindítása előtt történik. Ez az előnyben részesített beállítás, ha a mező kötelező. Bizonyos esetekben azonban elegendő a PreCreate beépülő modul lépése.

1. Az USA-példány egy logikai alkalmazáson keresztül kísérel meg egy új fiókot szinkronizálni az Európa-példánysal . Az Európa-példány nem érhető el állásidő vagy frissítés miatt.
2. A Contoso LOB alkalmazás beolvassa az USA-példány fő fiókentitásait. Olyan API-hívást kíván küldeni, amely egy olyan fiókentitásra hivatkozik, amelyet nem replikáltak az Európa-példányra. A jelenlegi állapot szerint az API-hívás meghiúsulna, mert a rekord nem létezik, mert a szinkronizálás nem működik.
3. A PreValidation/PreCreate beépülő modul azonban először végrehajt egy upsertet a megadott entitás GUID-azonosítója és a megadott referenciaadatok alapján. Ha már létezik, semmi sem változik. Ha nem létezik, létrejön egy új fiók, amelyben a legtöbb mező üres.
4. Az API-hívás sikeres, mert a megadott azonosítóval rendelkező fiók létezik a rendszerben. A beépülő modul elfogta a műveletet, és elegánsan kezelte a hiányzó rekordot. A LOB alkalmazásból származó jelentés létrehozása sikeresen megtörtént.

Alternatív megoldások

A fent leírt forgatókönyv egy egyéni logikai alkalmazást használ replikációs módszerként. A Dataverse-példányok között azonban többféleképpen is replikálhatóak az adatok, amelyek közé tartoznak, de nem korlátozódnak a következőkre:

• Logic Apps
• Függvényalkalmazások a Azure Functions
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

Forgatókönyv részletei

A szervezetek időnként úgy találják, hogy két vagy több Power Platform-példányt kell szinkronizálni, pontosabban a Dataverse-entitások egy részét. Ez a követelmény akkor fordulhat elő, ha egy szervezet szándékosan adott hozzá új példányokat a földrajzi elkülönítéshez, de minden földrajzi helyen közös adatkészletre van szüksége. Vagy akkor fordulhat elő, ha két szervezet egyesül a Power Platform konszolidációja előtt.

Ha a szinkronizálási folyamat a tervezésnek megfelelően működik, a két példányból származó üzletági alkalmazásoknak nincsenek problémáik. A szinkronizálási mechanizmusok azonban soha nem bizonyítják a hibát, a kimaradások vagy a váratlan problémák valószínűleg felmerülnek. Ebben az esetben a két példány adatait használó üzletági alkalmazást a hiányos adatok kezeléséhez kell létrehozni.

Ahhoz, hogy a Contoso új európai leányvállalata integrálható legyen a Contoso üzleti struktúrájába, szinkronizálnia kell a fiókokat és a kapcsolatokat a Power Platform egyik példányáról a másikra. Ebben a forgatókönyvben a Power Platform amerikai példánya egy napi referenciaadat-köteget szinkronizál egy egyéni logikai alkalmazással az európai példán keresztül. Egy saját fejlesztésű Contoso LOB-alkalmazás jelentést készít a felhasználók által létrehozott problémás jegyekről. A feladat elvégzéséhez a LOB alkalmazás beolvassa a felhasználói adatokat mindkét Dataverse-példányból, hogy lekérje a releváns adatokat, az USA-példány elsődleges referenciakulcsait és az Európa-példány jegyadatait. Ha a szinkronizálási folyamat nem fejeződött be állásidő, karbantartás vagy más kommunikációs probléma miatt, a kérés hibát fog eredményezni az európai példányból hiányzó entitások miatt.

Lehetséges használati esetek

Ez a minta a következő helyzetekben lehet hasznos:

• A referenciaadatokat küldő rendszer leállt.
• Az adatok szinkronizálása hosszú időt vesz igénybe, vagy a folyamat késik.
• A fogyasztó rendszerek nem rendelkeznek logikával a létrehozandó entitás létrehozására.

Mikor érdemes ezt a megközelítést használni?

Használja ezt a megközelítést a következő forgatókönyvekben:

• Garantálni szeretné, hogy egy adott kulccsal rendelkező rekord létezik, és nem törődik azzal, hogy a rekord nincs teljesen hidratálva.
• Akkor is el kell fogadnia a létrehozást, ha az adatok még mindig nincsenek szinkronizálva.

Előfordulhat, hogy ez a minta nem megfelelő a következő forgatókönyvben:

• A rendszer logikát alkalmaz a rekord létrehozásakor. Mivel az adatok nem lesznek hidratálva, nem biztonságos bizonyos tulajdonságokra támaszkodni.

Példák

Az alábbi példák a lehetséges folyamatokat és a szinkronizálási késések eredményét mutatják be.

1. példa – Sikeres elérési út kimaradási vagy átmeneti hibák nélkül

Töltse le az architektúra Visio-fájlját.

1. Az USA-példány egy logikai alkalmazással szinkronizál egy új fiókot az Európa-példányhoz . Mindegyik működik, mert nem történt átmeneti hiba vagy kimaradás.
2. A Contoso LOB alkalmazás beolvassa az USA-példány fő fiókentitásait, és olyan API-hívást kíván küldeni, amely egy , az Európa-példányba replikált fiókentitására hivatkozik. Ez azért működik, mert minden rendben volt, és nem történt kimaradás vagy átmeneti hiba. A LOB alkalmazásból származó jelentés létrehozása sikeresen megtörtént.

2. példa – Sikertelen elérési út, ahol a szinkronizálás leáll vagy késik

Töltse le az architektúra Visio-fájlját.

1. Az USA-példány egy logikai alkalmazáson keresztül kísérel meg egy új fiókot szinkronizálni az Európa-példánysal . Az Európa-példány nem érhető el állásidő, karbantartás vagy más kommunikációs probléma miatt.
2. A Contoso LOB alkalmazás beolvassa az USA-példány fő fiókentitásait, és olyan API-hívást kíván küldeni, amely egy olyan fiókentitásra hivatkozik, amelyet nem replikáltak az Európa-példányba. Az API-hívás meghiúsul, mert a megadott azonosítóval rendelkező fiók nem lett létrehozva az Európa-példányban , és a jelentés nem jön létre.

Megfontolandó szempontok

Vegye figyelembe, hogy az üzleti logika milyen hatással van egy még nem hidratált entitásra. Vegyünk egy olyan forgatókönyvet, amelyben az entitás még nincs teljesen hidratálva és szinkronizálva. Egyes tulajdonságok null értékűek lesznek, ezért gondoskodnia kell arról, hogy az adatokkal kapcsolatos döntések figyelembe legyenek adva ennek a megközelítésnek a használatakor.

Következő lépések

• Power Platform
• Mi az a Power Apps?
• Mi az Azure Logic Apps?
• Első lépések a Power Automate-ben

Kapcsolódó források (lehet, hogy a cikkek angol nyelvűek)

Kapcsolódó architektúrák:

• CI/CD a Microsoft Power Platformhoz
• Citizen AI a Power Platformmal
• A Power Automate nagy léptékű üzembe helyezése

Útmutató webfejlesztéshez:

• Tíz tervezési alapelv Azure-alkalmazásokhoz
• Tervezési és megvalósítási minták
• ajánlott App Service üzembe helyezési eljárások
• Microsoft Azure Well-Architected Framework