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

Microsoft Power Platform
Microsoft Dataverse
Azure Logic 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

Diagram przedstawiający wtyczkę dataverse zapewniającą rozwiązanie do nieudanej synchronizacji z wieloma systemami.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

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

  1. Wystąpienie USA próbuje zsynchronizować nowe konto z wystąpieniem Europy za pośrednictwem aplikacji logiki. Wystąpienie Europy nie jest osiągalne z powodu przestoju lub uaktualnienia.
  2. Aplikacja LOB firmy Contoso odczytuje główne jednostki konta z wystąpienia USA. Zamierza przesłać wywołanie interfejsu API, które odwołuje się do jednostki konta, która nie została zreplikowana do wystąpienia w Europie. 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 PreValidate/ najpierw wykonuje operację 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.

Uwaga

Firma Microsoft zaleca wprowadzenie wzorca wyłącznika w kodzie niestandardowym, aby wycofać się i ponowić próbę w ramach tego rozwiązania w celu obsługi awarii platformy podczas odwoływania się do obu wystąpień. Aby uzyskać więcej informacji na temat korzystania z wyłącznika, zobacz Wzorzec wyłącznika.

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

Diagram przedstawiający pomyślną synchronizację z wieloma systemami.

Pobierz plik programu Visio z tą architekturą.

  1. Wystąpienie USA synchronizuje nowe konto z wystąpieniem Europy 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 wystąpienia USA i zamierza przesłać wywołanie interfejsu API odwołujące się do jednostki konta, która została zreplikowana do wystąpienia w Europie. 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 jest opóźniona

Diagram przedstawiający nieudaną synchronizację z wieloma systemami.

Pobierz plik programu Visio z tą architekturą.

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

Kwestie wymagające rozważenia

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

Powiązane architektury:

Wskazówki dotyczące tworzenia aplikacji internetowych: