Tento článek popisuje scénář, ve kterém hypotetický zákazník v USA, Contoso, nedávno získal jinou společnost se sídlem v Evropě a mezi těmito dvěma společnostmi probíhá proces crm a ERP systémů. V rámci této integrace musí udržovat část svých Dynamics 365 entit Dataverse synchronizované, dokud je nebude možné plně integrovat. Proprietární obchodní aplikace Conotso využívá data z obou systémů a musí být schopná přijímat požadavky, když data čekají na synchronizaci nebo když chybí. Následující příručka ukazuje, jak zohlednit případnou konzistenci mezi instancemi Power Platform.
Architektura
Modul plug-in/tok pro vždy upsert na základě GUID nebo alternativního klíče
Stáhněte si soubor aplikace Visio s touto architekturou.
Pracovní postup
Toto řešení je možné vytvořit pomocí několika kroků modulu plug-in v rámci životního cyklu modulu plug-in. Pokud je entita, kterou vytváříte, povinná, použijte krok Předběžné ověření. Předběžné ověření probíhá před spuštěním databázových transakcí. Je to upřednostňovaná možnost, pokud je pole povinné. V některých scénářích však bude stačit krok modulu plug-in PreCreate .
- Instance USA se pokusí synchronizovat nový účet s instancí Europe prostřednictvím aplikace logiky. Instance Europe je nedostupná kvůli výpadku nebo upgradu.
- Obchodní aplikace Contoso čte entity hlavního účtu z instance USA. Má v úmyslu odeslat volání rozhraní API, které odkazuje na entitu účtu, která nebyla replikována do instance Europe. V tomto případě by volání rozhraní API selhalo, protože záznam neexistuje, protože synchronizace nefunguje.
- Modul plug-in PreValidation/PreCreate však nejprve provede upsert na základě zadaného identifikátoru GUID entity a zadaných referenčních dat. Pokud už existuje, nic se nezmění. Pokud neexistuje, vytvoří se nový účet s většinou polí prázdnými.
- Volání rozhraní API je úspěšné, protože účet s daným ID existuje v systému. Modul plug-in zachytil operaci a řádně zpracoval chybějící záznam. Sestava z obchodní aplikace se úspěšně vygenerovala.
Poznámka
Microsoft doporučuje zavést do vlastního kódu vzor jističe, který v rámci tohoto řešení zpozoruje a zkusí to znovu, aby bylo možné řešit výpadky platforem při odkazování na některou z instancí. Další informace o použití jističe najdete v tématu Model jističe.
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é mimo jiné patří:
- Logic Apps
- Aplikace funkcí v Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Podrobnosti scénáře
Organizace občas zjišťují potřebu udržovat dvě nebo více instancí Power Platform synchronizované, konkrétněji podmnožinu entit Dataverse. K tomuto požadavku může dojít v případě, že 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 podle návrhu, obchodní aplikace, které využívají obě instance, nemají problémy. Mechanismy synchronizace ale nikdy neprokazují chybu, pravděpodobně dojde k výpadkům nebo neočekávaným problémům. 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 mohla být nová evropská pobočka 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 lístcích problémů, které uživatelé vytvořili. K dokončení tohoto úkolu obchodní aplikace načte 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 Europe. 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ě v instanci Europe.
Potenciální případy použití
Tento model může být užitečný v následujících situacích:
- Systém, který odesílá referenční data, je mimo provoz.
- Synchronizace dat trvá dlouho nebo je proces zpožděný.
- Systémy, které využívají, nemají žá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 je vám jedno, že záznam není plně hydratovaný.
- Vytvoření musíte přijmout, i když data stále nejsou synchronizovaná.
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 dostupnost určitých vlastností.
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áhněte si soubor aplikace Visio s touto architekturou.
- Instance USA synchronizuje nový účet s instancí Europe prostřednictvím aplikace logiky. Všechny fungují, protože nedošlo k žádným přechodným chybám nebo výpadkům.
- Obchodní aplikace Contoso čte entity hlavního účtu z instance USA a má v úmyslu odeslat volání rozhraní API, které odkazuje na entitu účtu, která byla replikována do instance Europe. Funguje to, protože všechno bylo vzhůru a nedošlo k žádným výpadkům nebo přechodným chybám. Sestava z obchodní aplikace se úspěšně vygenerovala.
Příklad 2 – Neúspěšná cesta, kde je synchronizace mimo provoz nebo je zpožděná
Stáhněte si soubor aplikace Visio s touto architekturou.
- Instance USA se pokusí synchronizovat nový účet s instancí Europe prostřednictvím aplikace logiky. Instance Europe je nedostupná kvůli výpadku, údržbě nebo jinému problému s komunikací.
- Obchodní aplikace Contoso čte entity hlavního účtu z instance USA a hodlá odeslat volání rozhraní API, které odkazuje na entitu účtu, která nebyla replikována do instance 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.
Požadavky
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 je potřeba zajistit, aby při použití tohoto přístupu byla zahrnuta veškerá rozhodnutí týkající se dat.
Další kroky
Související prostředky
Související architektury:
- CI/CD pro Microsoft Power Platform
- Citizen AI with the Power Platform
- Nasazení Power Automate ve velkém měřítku
Pokyny pro vývoj webů: