Konečná konzistence mezi několika instancemi Power Apps

Tento článek popisuje scénář, ve kterém hypotetický zákazník založený na USA, Contoso nedávno získal další společnost založenou v Evropě a je v procesu CRM a ERP systémů mezi těmito dvěma společnostmi. V rámci této integrace musí udržovat část entit Dynamics 365 Dataverse synchronizované, dokud je nebude možné plně integrovat. Obchodní aplikace Conotso využívá data z obou systémů a musí být schopná přijímat žádosti, když data čekají na synchronizaci nebo když chybí. Následující průvodce ukazuje, jak zohlednit konečnou konzistenci mezi instancemi Power Platform.

Architektura

Modul plug-in nebo tok, který bude vždy upsertovat na základě identifikátoru GUID nebo alternativního klíče

stáhnout soubor Visia této architektury.

Pracovní postup

Toto řešení je možné sestavit pomocí několika modulů plug-in kroků v rámci životního cyklu modulu plug-in. Pokud je entita, kterou vytváříte, povinná, použijtekroku PreValidation . preValidation proběhne před spuštěním jakýchkoli databázových transakcí. Je to upřednostňovaná možnost, pokud je pole povinné. V některých scénářích ale stačí krok modulu plug-in PreCreate.

1. Instance USA se pokusí synchronizovat nový účet s Europe Instance prostřednictvím aplikace logiky. Instance Europe je nedostupná kvůli výpadku nebo upgradu.
2. Obchodní aplikace Contoso čte hlavní entity účtu zinstance USA . Hodlá odeslat volání rozhraní API, které odkazuje na entitu účtu, která nebyla replikována do instance Europe. Jak je uvedeno, volání rozhraní API selže, protože záznam neexistuje, protože synchronizace nefunguje.
3. Modul plug-in PreValidationPreValidationPreCreate však nejprve provede upsert na základě zadaného identifikátoru GUID entity a poskytnutých referenčních dat. Pokud už existuje, nic se nezmění. Pokud neexistuje, vytvoří se nový účet s většinou prázdných polí.
4. Volání rozhraní API proběhne úspěšně, protože účet s daným ID existuje v systému. Modul plug-in zachytil operaci a úspěšně zpracoval chybějící záznam. Sestava z obchodní aplikace se úspěšně vygeneruje.

Alternativy

Výše popsaný scénář používá jako metodu replikace vlastní aplikaci logiky. Existuje však několik způsobů replikace dat mezi instancemi Dataverse, mezi které patří, ale nejsou omezeny na:

• Logic Apps
• Aplikace funkcí ve službě Azure Functions
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

Podrobnosti scénáře

Organizace občas potřebují synchronizovat dvě nebo více instancí Power Platform, konkrétněji podmnožinu entit Dataverse. K tomuto požadavku může dojít, když organizace záměrně přidala nové instance pro geografickou izolaci, ale potřebuje společnou datovou sadu napříč všemi geografickými oblastmi. Nebo k tomu může dojít, když se dvě organizace sloučí před dokončením konsolidace Power Platform.

Když proces synchronizace funguje tak, jak je navržený, nemají obchodní aplikace, které využívají obě instance, problémy. Mechanismy synchronizace ale nikdy nejsou důkazem o chybách, k výpadkům nebo neočekávaným problémům pravděpodobně dojde. V takovém případě musí být vaše obchodní aplikace, která využívá data z obou instancí, sestavena tak, aby zpracovávala neúplná data.

Aby byla nová evropská pobočka společnosti Contoso integrovaná do obchodní struktury společnosti Contoso, musí synchronizovat účty a kontakty z jedné instance Power Platform do jiné. V tomto scénáři instance Power Platform v USA synchronizuje denní dávku referenčních dat prostřednictvím vlastní aplikace logiky s evropskou instancí. Proprietární obchodní aplikace Contoso generuje hlášení o problémech lístků, které uživatelé vytvořili. K dokončení této úlohy obchodní aplikace načítá uživatelská data z obou instancí Dataverse, aby získala relevantní data, primární referenční klíče z instance USA a data lístku z instance Evropy. Pokud se proces synchronizace nedokončil kvůli výpadku, údržbě nebo jinému problému s komunikací, žádost způsobí chybu kvůli chybějícím entitám v instanci Evropa.

Potenciální případy použití

Tento vzor může být užitečný v následujících situacích:

• Systém, který odesílá referenční data, je dole.
• Synchronizace dat trvá dlouho nebo je proces zpožděný.
• Využívání systémů nemá žádnou logiku při vytváření vytvářené entity.

Kdy použít tento přístup

Tento přístup použijte v následujících scénářích:

• Chcete zaručit, že záznam s daným klíčem existuje a nezajímá vás, že záznam není plně hydratovaný.
• Musíte přijmout vytvoření, i když se data stále nesynchronují.

Tento model nemusí být vhodný v následujícím scénáři:

• Logika se použije při vytvoření záznamu. Vzhledem k tomu, že data nebudou hydratovaná, není bezpečné spoléhat se na určité vlastnosti, které jsou k dispozici.

Příklady

Následující příklady ukazují potenciální cesty a výsledek zpoždění synchronizace.

Příklad 1 – Úspěšná cesta bez výpadku nebo přechodných chyb

stáhnout soubor Visia této architektury.

1. Instance USA synchronizuje nový účet s Europe Instance prostřednictvím aplikace logiky. Všechny fungují, protože nedošlo k přechodným chybám nebo výpadkům.
2. Obchodní aplikace Contoso čte hlavní entity účtu z instance USA a hodlá odeslat volání rozhraní API, které odkazuje na entitu účtu replikovanou na instanci Europe. Funguje to, protože všechno bylo v pořádku a nedošlo k žádným výpadkům nebo přechodným chybám. Sestava z obchodní aplikace se úspěšně vygeneruje.

Příklad 2 – Neúspěšná cesta, kde je synchronizace mimo provoz nebo zpožděná

stáhnout soubor Visia této architektury.

1. Instance USA se pokusí synchronizovat nový účet s Europe Instance prostřednictvím aplikace logiky. Instance Europe je nedostupná kvůli výpadkům, údržbě nebo jinému problému s komunikací.
2. Obchodní aplikace Contoso čte hlavní entity účtu z instance USA a hodlá odeslat volání rozhraní API, které odkazuje na entitu účtu, která nebyla replikována na instanci Europe. Volání rozhraní API selže, protože účet s daným identifikátorem nebyl vytvořen v instanci Europe a sestava se negeneruje.

Úvahy

Zvažte dopad jakékoli obchodní logiky na entitu, která ještě není hydratovaná. Představte si scénář, kdy entita ještě není plně hydratovaná a synchronizovaná. Některé vlastnosti budou mít hodnotu null, takže při použití tohoto přístupu je potřeba zajistit, aby při použití tohoto přístupu byla zahrnuta veškerá rozhodnutí o datech.

Další kroky

• Power Platform
• Co je Power Apps?
• Co je Azure Logic Apps?
• Začínáme s Power Automate

Související prostředky

Související architektury:

• citizen AI s power platformou
• nasazení Power Automate ve velkém měřítku

Pokyny pro vývoj pro web:

• deset principů návrhu pro aplikace Azure
• osvědčené postupy pro nasazení služby App Service
• rozhraní Microsoft Azure Well-Architected Framework