Spójność ostateczna między wieloma wystąpieniami usługi Power Apps

W tym artykule opisano scenariusz, w którym hipotetyczny klient z siedzibą w USA, Contoso, niedawno nabył inną firmę z siedzibą w Europie i jest w procesie systemów CRM i ERP między dwiema firmami. W ramach tej integracji muszą zachować część jednostek usługi Dynamics 365 Dataverse w synchronizacji do momentu ich pełnej integracji. Zastrzeżona aplikacja biznesowa (LOB) firmy Conotso korzysta z danych z obu systemów i musi mieć możliwość akceptowania żądań, gdy dane oczekują na synchronizację lub gdy ich brakuje. W poniższym przewodniku pokazano, jak uwzględnić spójność ostateczną między wystąpieniami platformy Power Platform.

Architektura

Wtyczka/przepływ do zawsze upsert na podstawie identyfikatora GUID lub klucza alternatywnego

Pobierz plik programu Visio tej architektury.

Przepływ pracy

To rozwiązanie można skompilować za pomocą kilku kroków w ramach cyklu życia wtyczki. Gdy utworzona jednostka jest obowiązkowa, użyj kroku PreValidation. prevalidation ma miejsce przed rozpoczęciem transakcji bazy danych. Jest to preferowana opcja, jeśli pole jest obowiązkowe. Jednak w niektórych scenariuszach wystarczy krok wtyczki PreCreate.

1. Wystąpienie US próbuje zsynchronizować nowe konto z wystąpieniem Europe za pośrednictwem aplikacji logiki. Usługa Europe Instance jest niemożliwa do osiągnięcia z powodu przestoju lub uaktualnienia.
2. Aplikacja Contoso LOB odczytuje główne jednostki konta z US Instance. Zamierza przesłać wywołanie interfejsu API, które odwołuje się do jednostki konta, która nie została zreplikowana do wystąpienia Europe Instance. Jak to wygląda, wywołanie interfejsu API zakończy się niepowodzeniem, ponieważ rekord nie istnieje, ponieważ synchronizacja nie działa.
3. Jednak wtyczka PreValidation/PreCreate najpierw wykonuje upsert na podstawie podanego identyfikatora GUID jednostki i dostarczonych danych referencyjnych. Jeśli już istnieje, nic się nie zmieniło. Jeśli nie istnieje, zostanie utworzone nowe konto z większością pól pustych.
4. Wywołanie interfejsu API powiedzie się, ponieważ konto o danym identyfikatorze istnieje w systemie. Wtyczka przechwyciła operację i obsłużyła brakujący rekord bezpiecznie. Raport z aplikacji LOB jest generowany pomyślnie.

Alternatywy

W opisanym powyżej scenariuszu użyto niestandardowej aplikacji logiki jako metody replikacji. Istnieje jednak wiele sposobów replikowania danych między wystąpieniami usługi Dataverse, które obejmują, ale nie są ograniczone do następujących elementów:

• Logic Apps
• Aplikacje funkcji w usłudze Azure Functions
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

Szczegóły scenariusza

Organizacje od czasu do czasu wyszukują konieczność synchronizowania co najmniej dwóch wystąpień platformy Power Platform, w szczególności podzestawu jednostek usługi Dataverse. To wymaganie może wystąpić, gdy organizacja celowo dodała nowe wystąpienia do izolacji geograficznej, ale wymaga wspólnego zestawu danych we wszystkich obszarach geograficznych. Może się to zdarzyć, gdy dwie organizacje scalają się przed ukończeniem konsolidacji platformy Power Platform.

Gdy proces synchronizacji działa zgodnie z projektem, aplikacje biznesowe korzystające z obu wystąpień nie mają problemów. Jednak mechanizmy synchronizacji nigdy nie są dowodem na błędy, prawdopodobnie wystąpią awarie lub nieoczekiwane problemy. W takim przypadku aplikacja biznesowa, która korzysta z danych z obu wystąpień, musi zostać skompilowana w celu obsługi niekompletnych danych.

Aby nowa europejska spółka zależna firmy Contoso musiała zostać zintegrowana ze strukturą biznesową firmy Contoso, muszą synchronizować konta i kontakty z jednego wystąpienia platformy Power Platform do innego. W tym scenariuszu wystąpienie amerykańskiej platformy Power Platform synchronizuje codzienną partię danych referencyjnych za pośrednictwem niestandardowej aplikacji logiki z wystąpieniem europejskim. Zastrzeżona aplikacja LOB firmy Contoso generuje raporty dotyczące biletów problemów utworzonych przez użytkowników. Aby wykonać to zadanie, aplikacja LOB odczytuje dane użytkownika z obu wystąpień usługi Dataverse w celu ściągnięcia odpowiednich danych, podstawowych kluczy referencyjnych z wystąpienia USA i danych biletu z wystąpienia Europy. Jeśli proces synchronizacji nie został ukończony z powodu przestoju, konserwacji lub innego problemu z komunikacją, żądanie spowoduje wystąpienie błędu z powodu braku jednostek z wystąpienia Europy.

Potencjalne przypadki użycia

Ten wzorzec może być przydatny w następujących sytuacjach:

• System, który wysyła dane referencyjne, nie działa.
• Synchronizacja danych trwa długo lub proces jest opóźniony.
• Korzystanie z systemów nie ma logiki tworzenia tworzonej jednostki.

Kiedy należy użyć tego podejścia

Użyj tego podejścia w następujących scenariuszach:

• Chcesz zagwarantować, że rekord z danym kluczem istnieje i nie obchodzi cię, że rekord nie jest w pełni nawodniony.
• Musisz zaakceptować tworzenie, nawet jeśli dane nadal nie są synchronizowane.

Ten wzorzec może nie być odpowiedni w następującym scenariuszu:

• Logika jest stosowana podczas tworzenia rekordu. Ponieważ dane nie będą nawodnione, nie można bezpiecznie polegać na dostępnych pewnych właściwościach.

Przykłady

W poniższych przykładach przedstawiono potencjalne podróże i wynik opóźnień synchronizacji.

Przykład 1 — pomyślna ścieżka bez awarii lub błędów przejściowych

Pobierz plik programu Visio tej architektury.

1. Wystąpienie USA synchronizuje nowe konto z wystąpieniem Europe za pośrednictwem aplikacji logiki. Wszystkie działają, ponieważ nie wystąpiły błędy przejściowe ani awarie.
2. Aplikacja Contoso LOB odczytuje główne jednostki konta z US Instance i zamierza przesłać wywołanie interfejsu API odwołujące się do jednostki konta, która została zreplikowana do wystąpienia Europe. Działa, ponieważ wszystko było w górę, a nie wystąpiły awarie ani przejściowe błędy. Raport z aplikacji LOB jest generowany pomyślnie.

Przykład 2 — nieudana ścieżka, w której synchronizacja nie działa lub opóźniona

Pobierz plik programu Visio tej architektury.

1. Wystąpienie US próbuje zsynchronizować nowe konto z wystąpieniem Europe za pośrednictwem aplikacji logiki. Wystąpienie Europe jest niemożliwe do osiągnięcia z powodu przestojów, konserwacji lub innego problemu z komunikacją.
2. Aplikacja LOB firmy Contoso odczytuje główne jednostki konta z US Instance i zamierza przesłać wywołanie interfejsu API odwołujące się do jednostki konta, która nie została zreplikowana do wystąpienia Europe. Wywołanie interfejsu API kończy się niepowodzeniem, ponieważ konto z danym identyfikatorem nie zostało utworzone w Europe Instance, a raport nie jest generowany.

Zagadnienia dotyczące

Rozważ wpływ dowolnej logiki biznesowej na jednostkę, która nie jest jeszcze nawodniona. Rozważmy scenariusz, w którym jednostka nie jest jeszcze w pełni nawodniona i zsynchronizowana. Niektóre właściwości będą miały wartość null, dlatego należy upewnić się, że wszystkie decyzje dotyczące danych są uwzględniane podczas korzystania z tego podejścia.

Następne kroki

• Power Platform
• Co to jest usługa Power Apps?
• Co to jest usługa Azure Logic Apps?
• Rozpoczynanie pracy z usługą Power Automate

Powiązane zasoby

Powiązane architektury:

• Citizen AI z platformą Power Platform
• wdrażanie usługi Power Automate na dużą skalę

Wskazówki dotyczące tworzenia aplikacji internetowych:

• Dziesięć zasad projektowania dla aplikacji platformy Azure
• najlepsze rozwiązania dotyczące wdrażania usługi App Service
• Microsoft Azure Well-Architected Framework