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 obiema firmami. W ramach tej integracji muszą zachować część swoich jednostek Dynamics 365 Dataverse w synchronizacji, dopóki nie zostaną one w pełni zintegrowane. Zastrzeżona aplikacja conotso business (LOB) zużywa dane z obu systemów i musi być w stanie zaakceptować żądania, 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 z tą architekturą.
Przepływ pracy
To rozwiązanie można skompilować za pomocą kilku kroków wtyczki w ramach cyklu życia wtyczki . Gdy jednostka, którą tworzysz, 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 pretworzonej wtyczki.
- 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.
- Aplikacja Contoso LOB 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 Europy. Jak to wygląda, wywołanie interfejsu API zakończy się niepowodzeniem, ponieważ rekord nie istnieje, ponieważ synchronizacja nie działa.
- 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.
- 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 w sposób bezproblemowy. 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 używania 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 Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Szczegóły scenariusza
Organizacje od czasu do czasu uważają, że konieczne jest synchronizowanie co najmniej dwóch wystąpień platformy Power Platform, w szczególności podzbioru 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, awarie lub nieoczekiwane problemy prawdopodobnie wystąpią. 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 dzienną partię danych referencyjnych za pośrednictwem niestandardowej aplikacji logiki do wystąpienia europejskiego. 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, że rekord nie jest w pełni nawodniony.
- Musisz zaakceptować tworzenie, nawet jeśli dane nie są nadal synchronizowane.
Ten wzorzec może nie być odpowiedni w następującym scenariuszu:
- Logika jest stosowana po utworzeniu 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 błędów awarii ani przejściowych
Pobierz plik programu Visio z tą architekturą.
- Wystąpienie USA synchronizuje nowe konto z wystąpieniem Europy za pośrednictwem aplikacji logiki. Wszystkie działają, ponieważ nie wystąpiły żadne przejściowe błędy lub awarie.
- 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 została zreplikowana do wystąpienia Europy. 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 jest wyłączona lub opóźniona
Pobierz plik programu Visio z tą architekturą.
- 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, konserwacji lub innego problemu z komunikacją.
- 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 Europy. Wywołanie interfejsu API kończy się niepowodzeniem, ponieważ konto z danym identyfikatorem nie zostało utworzone w wystąpieniu Europy , a raport nie został wygenerowany.
Zagadnienia do 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ą mieć wartość null, dlatego należy upewnić się, że wszelkie 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:
- Ciągła integracja/ciągłe wdrażanie dla platformy Microsoft Power Platform
- Sztuczna inteligencja obywatela za pomocą platformy Power Platform
- Wdrażanie usługi Power Automate na dużą skalę
Wskazówki dotyczące tworzenia aplikacji internetowych: