Udostępnij za pośrednictwem

Wzorce integracji danych w chmurach branżowych Microsoft industry cloud

Dotyczy:

  • Microsoft Cloud for Sustainability
  • Microsoft Cloud for Financial Services
  • Microsoft Cloud for Healthcare
  • Microsoft Cloud for Retail

Modele danych w branżach pełnią funkcję podstawy w odpowiednich chmurach branżowych firmy Microsoft. W zależności od poziomu dojrzałości infrastruktury danych może być konieczna integracja rozwiązania z innymi systemami.

Wybranie odpowiedniego wzorca integracji jest kluczowym aspektem zapewnienia udanej implementacji pomiędzy rozwiązaniami w chmurach branżowych firmy Microsoft a systemami zewnętrznymi. Ten artykuł prezentuje wzorce integracji, narzędzia i technologie związane z integracją oraz czynniki, które należy uwzględnić przy podejmowaniu decyzji.

Potrzeba integracji

Systemy innych firm mogą mieć oddzielne procesy a nawet inną logikę biznesową. Jeśli w systemie innej firmy jest używany ten sam podstawowy model danych w chmurze (CMD,common data model), konieczność przekazywania danych, synchronizacji i programowania w celu przekształcenia danych jest eliminowana.

Wzorce integracji danych są wykorzystywane w następujących scenariuszach:

  • Dane podstawowe lub transakcyjne, które nie są centralną częścią jednego, ciągłego procesu zarządzania. Dane są synchronizowane między procesem w jednym systemie a chmurą branżową Microsoft industry cloud.
  • Dane są udostępniane lub wymieniane między systemami, jeśli są potrzebne do obliczeń.
  • Dane są udostępniane lub wymieniane między systemami, dzięki czemu działania mające miejsce w jednym systemie są odzwierciedlane w drugim.
  • Zagregowane dane z systemu na szczegółowym poziomie danych są wymieniane na system z odzwierciedleniem danych na wyższym poziomie.

Jak wybrać odpowiedni wzorzec integracji

Do projektowania integracji jest dostępnych wiele opcji technicznych — każda z nich ma swoje zalety i wady. W celu zidentyfikowania odpowiedniego wzorca rozszerzenia integracji można rozważyć poniższe czynniki i rozważyć każdy z nich na tle opcji:

Czynnik decydujący Popis
Typy i formaty danych Jaki typ i format danych jest integrowany?
Zmienność danych Od niskiej zmienności/powolne zmiany do wysokiej zmienności/szybkie zmiany.
Ilość danych Od danych w małej ilości do dużej ilości.
Dostępność danych Kiedy dane mają być gotowe, od źródła do miejsca docelowego? Czy są potrzebne w czasie rzeczywistym, czy też wystarczy tylko zebrać wszystkie dane pod koniec dnia i wysłać je w partii o określonej porze do miejsca docelowego?
Ochrona i ograniczanie usługi Zapewnienie spójności dostępności i wydajności przez stosowanie ograniczeń. Te ograniczenia nie powinny mieć wpływu na zwykłych użytkowników, a tylko na klientów wykonujących nadzwyczajne żądania. Gdy jest zbyt wiele żądań, należy użyć typowego wzorca dla usług online do przekazywania kodów błędów.
Wymagany poziom transformacji danych Wymagania dotyczące konwertowania lub agregowania danych źródłowych na docelowe.
Wyzwalacze i akcje wyzwalania Jaka akcja powoduje wyzwolenie wysyłania danych ze źródła do miejsca docelowego? Jakie konkretne działania należy zautomatyzować po dotarciu danych do miejsca docelowego?
Obsługa błędów Monitorowanie wprowadzone w celu wykrywania problemów z interfejsami.
Skalowalność Obsługiwanie oczekiwanych ilości transakcji obecnie, krótkoterminowo i długoterminowo.
System rekordu Rozważenie, który system jest systemem rekordu lub właściciela informacji.
Kierunek przepływu danych Czy system docelowy musi je ściągać, czy też system źródłowy musi je wypychać?

Na podstawie tych czynników można zidentyfikować wzorzec integracji i wybrać odpowiednie narzędzie lub technologię do wdrożenia.

Wzorce integracji

W tej sekcji przedstawiono następujące wzorce integracji, których można używać podczas integracji z usługą Dataverse.

  • Integracja w czasie rzeczywistym lub synchroniczna
  • Integracja prawie w czasie rzeczywistym lub asynchroniczna
  • Integracja partii
  • Integracja warstwy prezentacji

W każdym wzorcu jest unikatowa struktura, która może zostać zaktualizowana za pomocą jednego lub większej liczby wzorców. W kolejnych sekcjach opisano sposób urzeczywistniania tych wzorców przy użyciu określonych technologii wraz z rozważaniami i odpowiednimi scenariuszami, w których należy je zastosować.

Integracja w czasie rzeczywistym lub synchroniczna

Integracja w czasie rzeczywistym jest niezbędna w sytuacjach, gdy system źródłowy wymaga błyskawicznej lub z minimalnym opóźnieniem odpowiedzi na wysyłane przez niego dane. To wymaganie staje się niezbędne, gdy sprawa będzie dotyczyć zarówno systemu źródłowego, jak i docelowego w celu zapewnienia spójności, co pozwala zagwarantować nieprzerwane przetwarzanie danych między dwoma jednostkami. Integracja synchroniczna staje się konieczna, gdy w systemie docelowym zostanie wyedytowana natychmiastowa odpowiedź, co pozwoli na bezproblemowe wykonywanie bieżącego procesu i terminowe wykonywanie kolejnych akcji.

Ten rodzaj integracji jest często nazywany integracją synchroniczną. Na poniższym diagramie przedstawiono typowy wzorzec integracji synchronicznej, gdzie aplikacja A inicjuje żądanie do aplikacji B i szybko otrzymuje odpowiedź zapewniającą dzięki temu terminową i szybką wymianę danych.

Diagram przedstawiający wzorzec integracji w czasie rzeczywistym

Niektóre wymienione tu opcje technologii można rozszerzyć na systemy natychmiastowe służące do przekazywania danych w celu ułatwienia transakcji. Ta opcja przekazywania umożliwia efektywne oddzielenie aplikacji źródłowych i docelowych przez zarządzanie komunikacją żądań i odpowiedzi w ich imieniu.

Diagram przedstawiający wzorzec integracji w czasie rzeczywistym z usługą przekazywania

Te synchroniczne wzorce integracji danych można zaimplementować przy użyciu różnych technologii dostępnych w naszych rozwiązaniach chmury branżowej. W poniższej tabeli przedstawiono najlepsze rozwiązania wzorców oraz podano, kiedy należy ich używać.

Opcja technologii Kierunek przekazywania danych Cel Użyj, kiedy
Dataverse, interfejs API sieci Web Ściąganie/wypychanie danych ze źródła zewnętrznego do Dataverse Wdrożenie OData v4 w celu zapewnienia operacji CRUD przy użyciu standardowego zestawu interfejsów, zapewniając interfejs otwarty na różnych odbiorców technologicznych. Zwykle do integracji z aplikacją do transakcji, gdy są wymagane dyskretne operacje CRUD. Można także stosować do każdej integracji niestandardowej, ale dochodzą złożoności związane z ograniczaniem, równoległością i logiką ponownej próby, szczególnie w przypadku dużych ilości danych.
Interfejsy API opublikowane przez Microsoft Industry Cloud Ściąganie/wypychanie danych ze źródła zewnętrznego do Dataverse Niestandardowe interfejsy API utworzone w chmurach branżowych Microsoft obsługują specjalne operacje, na przykład uzyskiwanie dostępu do danych dotyczących emisji związanych z używaniem platformy Azure. Konkretne operacje opublikowane przez Microsoft Industry Cloud. Przed utworzeniem własnych niestandardowych interfejsów API należy określić priorytet korzystania z tych niestandardowych interfejsów API.
Niestandardowy API usługi Dataverse Ściąganie/wypychanie danych ze źródła zewnętrznego do Dataverse Tworzenie własnego interfejsu API w Dataverse. Gdy jedna lub więcej operacji musi zostać skonsolidowana w jedną operację lub musi uwidocznić nowy typ zdarzenia wyzwalającego.
Tabele wirtualne Ściąganie/wypychanie danych z Dataverse do źródła zewnętrznego Łącz się ze źródłami danych zewnętrznych i traktuj je jako encje macierzyste Dataverse. Ściągnie danych referencyjnych i scenariuszy CRUD z małymi ilościami.
Łączniki Dwukierunkowe Umożliwianie bezproblemowej wymiany danych między usługami Microsoft Services a systemami zewnętrznymi, aplikacjami i źródłami danych. Łączniki opublikowane przez firmę Microsoft są najczęściej używane w integracjach, takich jak łączenie między sobą usług Microsoft Services lub z aplikacjami własnymi. Sprawdzone opublikowane łączniki są stosowane do specjalistycznej integracji z aplikacjami innych firm, co zapewnia ich zgodność i niezawodność. Łączniki niestandardowe mogą być używane, gdy łączniki firmy Microsoft lub partnera nie rozwiązują potrzeb biznesowych klienta.

Integracja prawie w czasie rzeczywistym lub asynchroniczna

Zaleca się integrację asynchroniczną w sytuacjach, gdy nie istnieją natychmiastowe wymagania dotyczące odpowiedzi w czasie rzeczywistym w procesie biznesowym lub w działaniu. Ponadto zwykle jest ona używana, gdy między aplikacjami a systemami jest duża komunikacja. Wzorce integracji asynchronicznej zapewniają, że komunikacja między systemami nie blokuje ani nie spowalnia procesów, co pozwala każdemu systemowi pracować niezależnie i asynchronicznie. Niektóre najbardziej typowe sposoby implementacji integracji asynchronicznych to kolejkowanie komunikatów, publikowanie-subskrybowanie i integracja partiami. Tych rodzajów Integracji można używać oddzielnie lub razem, w zależności od wymagań. Często jest to określane łącznie jako architektura oparta na zdarzeniach (EDA).

We wzorcu kolejkowania komunikatów nadawca przyjmuje strukturę opartą o zdarzenia, a odbiorca tworzy powiązanie bezpośrednio ze zdarzeniem. Po wysłaniu komunikatu odbiorca jest bezpośrednio powiadamiany i odbiera dane zawarte w komunikacie zdarzenia.

Diagram przedstawiający wzorzec integracji asynchronicznej z użyciem kolejkowania komunikatów.

W poniższym wzorcu publikowane-subskrybowanie wydawca tworzy komunikat w standardowym formacie opublikowania i przekazuje ją do dedykowanego kanału publikowania/subskrypcji, który może mieć jednego lub więcej subskrybentów. Każdy subskrybent subskrybuje określony kanał lub temat, co pozwala na odbieranie i przetwarzanie opublikowanego komunikatu (zdarzenia) w razie potrzeby. Wzorzec publikowani-subskrybowanie jest wybierany w przypadku scenariuszy komunikacji jeden do wielu, ponieważ wielu subskrybentów może niezależnie odbierać i przetwarzać komunikaty (zdarzenia).

Diagram przedstawiający wzorzec integracji asynchronicznej z użyciem subskrybenta publikującego.

Wzorce asynchronicznej integracji danych można wdrożyć przy użyciu różnych opcji. W poniższej tabeli przedstawiono dostępne opcje i najlepsze rozwiązania dotyczące korzystania z nich.

Opcja technologii Wzorzec oparty na zdarzeniach lub publikowanie-subskrypcja Cel Kwestie wymagające rozważenia Użyj, kiedy
Power Automate Oba Niskokodowe wymagania automatyzacji. Postępuj zgodnie z Power Automate i ograniczeniami poszczególnych łączników, na przykład ograniczania. Użyj przepływów Power Automate wyzwalanych z Dataverse lub gdy chcesz uruchamiać automatyczne przepływy pracy zgodnie z harmonogramem.
Łączniki niestandardowe oparte na aplikacji Logic Apps Na podstawie zdarzeń Tworzenie łączników danych dla rozwiązania w celu uzyskania danych z rozwiązań ISV. Przed przeniesieniem do produkcji muszą przejść przeglądy prywatności, zabezpieczeń i zgodności. Używanie scenariuszy integracji ISV, w których nie istnieją łączniki macierzyste.
Aplikacje Logic Apps i usługa Azure Service Bus Publikowanie-subskrybowanie Odbieranie komunikatów przez wydawcę do usługi Service Bus i aplikacji Logic Apps używa komunikatu, by wysłać go do aplikacji subskrybenta. Postępuj zgodnie z ograniczeniami konfiguracji i wykonywania usługi Logic Apps. Użycie natywnych wyzwalaczy w łącznikach usługi Logic Apps i niestandardowej integracji z wieloma scenariuszami subskrybenta.
Azure Functions, funkcja Web Apps usługi Azure App Service, Azure Service Bus Publikowanie-subskrybowanie Używaj kolejki komunikatów do implementowania kanału komunikacji między aplikacją a wystąpieniami usługi klienta. Uwzględnij zamawianie komunikatów i inne zagadnienia dotyczących projektowania. Scenariusze dużych ilości i zmienności, gdzie nie można utworzyć integracji z opcjami niskokodowymi (Power Automate lub aplikacjami Logic Apps).
Punkt końcowy usługi Oba Wysyłanie informacji kontekstowych do kolejki, tematu, elementu webhook lub centrum zdarzeń. Nieodpowiednie do transakcji długotrwałych. Gdy wymaganie integracji jest w większości spełnione, wysyłanie kontekstu Dataverse do miejsca docelowego i zamawianie wiadomości nie ma krytycznego znaczenia.

Integracja partii

Dzielenie na partie to sposób zbierania i transportowania zestawu wiadomości lub rekordów w partii w celu ograniczenia zbędnej komunikacji i narzutów. Przetwarzanie w partiach zbiera dane w czasie, a następnie przetwarza je w partiach. Ta metoda jest przydatna w przypadku, gdy przetwarzania jest duża ilość danych lub gdy przetwarzanie wymaga znaczących zasobów. Ten wzorzec obejmuje również replikowanie głównych danych do magazynu repliki na potrzeby analizy.

Opcja technologii Kierunek przekazywania danych Cel Kwestie wymagające rozważenia Użyj, kiedy
Azure Data Factory Oba kierunki Tworzenie przepływów danych w celu przekształcenia danych odebranych od Dataverse lub przed pozyskiwaniem do Dataverse Ograniczenia dotyczące usługi Data Factory Scenariusz masowego pozyskiwania lub eksportu danych ze skomplikowaną transformacją wieloetapową.
Power Automate Brak Automatyzowanie przepływów pracy i zadań dla firmy Microsoft Ograniczona skalowalność i długie przetwarzanie Użyj usługi Power Automate w sytuacji, gdy konieczne jest zautomatyzowanie powtarzalnych zadań, wyzwalanie akcji na podstawie zdarzeń i integrowanie aplikacji bez projektowania w tym celu kodu.
Przepływ danych Power Query Z systemów zewnętrznych do Dataverse Narzędzie do przygotowywania danych, które pozwala na przetwarzanie, przekształcanie i ładowanie danych w środowiskach Dataverse. Ograniczenia Podstawowe scenariusze, w których miejscem docelowym jest Dataverse, a istniejące łączniki nie są odpowiednie oraz inne scenariusze Power BI.
Azure Synapse Potoki Oba kierunki Tworzenie potoków w celu przekształcenia danych odebranych z Dataverse lub przed pozyskiwaniem do Dataverse Brak Scenariusze analizy i magazynów danych.
Azure Synapse Link for Dataverse Z usługi Dataverse do Azure Synapse Analytics lub Azure Data Lake Storage v2 (ADLS) Replikowanie danych Dataverse do systemu Azure Synapse Analytics lub usługi ADLS w wersji 2 umożliwia uruchomienie analiz, analizy biznesowej, uczenia maszynowego i niestandardowych scenariuszy raportowania dla danych. Tabele, które nie są obsługiwane. Analiza danych i raportowanie niestandardowe. Także jako etap pośredni eksportu danych.
Azure Logic Apps Brak Tworzenie przepływów pracy z zaawansowanymi możliwościami integracji. Złożone operacje wsadowe mogą wymagać znacznej konfiguracji i aranżacji. Nie są one zoptymalizowane pod kątem scenariuszy przetwarzania wsadowego. Aplikacje Azure Logic Apps są odpowiednie do aranżacji procesów biznesowych i integrowania usług.
SQL Server Integration Services Oba kierunki Używanie łącznika innej firmy do ściągania i wypychania danych z i do Dataverse. Ponieważ nie jest to rozwiązanie PaaS, należy oceniać skalowanie, użycie pamięci, wydajność i koszt. Wszelkie ograniczenia podczas stosowania narzędzi wyodrębniania, przekształcania i ładowania w chmurze (ETL) mogą nie być dostępne.

Integracja warstwy prezentacji

Prezentacja lub User Interface Integration znajdują się na najwyższym poziomie systemu; to je widzi użytkownik i z nimi wchodzi w interakcje. W niektórych przypadkach użycia integracja musi nastąpić na tym poziomie poprzez połączenie informacji z różnych systemów lub źródeł danych i przedstawienie ich w jednym interfejsie użytkownika. Aplikacje oparte na modelu są tego komponentem, przyczyniają się do uniwersalnego interfejsu użytkownika, umożliwiając interakcje dotyczące danych oraz ułatwiają bezproblemową nawigację w zintegrowanym środowisku. Integracja prezentacji jest potrzebna, gdy istnieje potrzeba utrzymania istniejącej logiki biznesowej lub struktury aplikacji, jednocześnie umożliwiając łatwą agregację danych, dostosowywanie interfejsu użytkownika lub ulepszanie doświadczenia użytkownika. I odwrotnie, niesie ze sobą nieodłączne ograniczenia, w tym złożoność integracji i konserwacji, znaczną współzależność między zintegrowanymi systemami, potencjalny wpływ na wydajność oraz kwestie dotyczące spójności danych.

  • Włączanie agregacji danych
  • Dostosowywanie interfejsu użytkownika
  • Ulepszone środowisko użytkownika

I odwrotnie, ma nieodłączne ograniczenia, między innymi:

  • Złożoność integracji i konserwacji
  • Znaczne zależności między zintegrowanymi systemami
  • Potencjalnie konsekwencje związane z wydajnością
  • Rozważania dotyczące spójności danych
Opcja technologii Cel Kwestie wymagające rozważenia Użyj, kiedy
Własne natywne integracje interfejsu użytkownika Korzystanie z map Bing, usługi Microsoft Teams i innych własnych, natywnych integracji interfejsu użytkownika. W większości przypadków nie można ich dostosowywać. Konkretne scenariusze obsługiwane w integracji natywnej interfejsu użytkownika.
Strony niestandardowe Osadzenie aplikacji kanwy w aplikacji opartej na modelu. Znane ograniczenia Preferowane jest podejście integracji niskokodowej i wtedy, gdy aplikacja kanwy nadaje się do używania.
Struktura składników Power Apps (PCF) Niestandardowa kontrolka z możliwością ponownego użycia w celu wyświetlania lub interakcji z użytkownikiem końcowym przy jednoczesnym zachowaniu responsywności projektu. Struktura ograniczenia składników Power Apps. Preferowana metoda, gdy trzeba opracować niestandardowy interfejs użytkownika w aplikacji opartej na modelu, w przypadku braku aplikacji kanwy.
Kafelki Power BI Wyświetlanie kafelka Power BI w formularzu aplikacji opartej na modelu. Licencjonowanie Power BI, autoryzacja danych Power BI. Wyświetlanie kafelka Power BI w aplikacji opartej na modelu
Power BI osadzony pulpit nawigacyjny Wyświetlanie pulpitu nawigacyjnego Power BI embedded w aplikacji opartej na modelu. Licencjonowanie Power BI, autoryzacja danych Power BI. Wyświetlanie analizy hostowanej w Power BI.
Osadzanie jako kod HTML iFrame Osadzanie drugiego systemowego interfejsu użytkownika w aplikacji opartej na modelu. Logowanie pojedyncze (SSO), konfiguracja udostępniania zasobów między pochodzenia (CORS) i projekt responsywny. Złożone scenariusze interfejsu użytkownika, w których nie jest dostępna żadna usługa.
Niestandardowy zasób sieci web Tworzenie niestandardowego układu interfejsu użytkownika w aplikacji opartej na modelu. Ocena dostępności i projektowania responsywneo, niestandardowego interfejsu użytkownika. Scenariusze, w których inne integracje interfejsu użytkownika nie są możliwe.

Podsumowanie wzorców integracji

W świecie integracji oprogramowania istnieją różne wzorce i mechanizmy dostępne w celu wymiany danych między różnymi systemami. Każdy wzorzec ma swoje zalety i wady, a wybranie odpowiedniego może znacznie wpłynąć na wydajność i efektywność zintegrowanych systemów.

Poniższa tabela przedstawia podsumowanie następujących wzorców integracji: integracja w czasie rzeczywistym lub synchroniczna, integracja asynchroniczna, integracja w partiach i integracja warstwy prezentacji. Możesz poznawać mechanizmy, wyzwalacze, zalety, wady oraz korzystać z opisów przypadków zastosowań poszczególnych wzorców, by podjąć właściwe decyzje związane z wyborem podejścia do integracji w swoim systemie.

Wzorzec integracji Mechanizm Wyzwalacz Plusy Minusy Użyj, kiedy
Czas rzeczywisty lub synchroniczny Dane są wymieniane synchronicznie, akcje są wywoływane poprzez integrację między punktami lub za pomocą przekazywania. Akcja użytkownika lub zdarzenie systemowe. Szybka runda żądań i odpowiedzi. Wartości i informacje w czasie rzeczywistym. Ogólnie rzecz biorąc, nie jest to najlepszym rozwiązaniem ze względu na ryzyko utknięcia procesów i utworzenia ściśle sprzężonej integracji. Ryzyko wystąpienia błędów numerowania od błędów przejściowych. Poufne do opóźnienia. Użyć, gdy informacje w czasie rzeczywistym mają krytyczne znaczenie.
Asynchroniczny Dane są wymieniane lub pozyskiwane w sposób nienadzorowany w harmonogramie okresowym lub jako cząstkowy kanał informacyjny korzystający z wzorców obsługi wiadomości. Zaplanowane na okres lub wyzwalane przez nową wiadomość opublikowaną przez system źródłowy. Luźne sprzężenie systemów sprawia, że rozwiązanie jest niezawodne. Równoważenie obciążenia w czasie i na zasobach. Może być bardzo zbliżone do czasu rzeczywistego. Terminowa obsługa błędów. Opóźnienie odpowiedzi i widoczności zmian w systemach. Wymagania prawie jak przy synchronizacji danych w czasie rzeczywistym dla niskiej lub średniej ilości danych.
Dzielenie na partie Dzielenie na partie to sposób zbierania i transportowania zestawu wiadomości lub rekordów w partii w celu ograniczenia zbędnej komunikacji i narzutów. Zaplanowany lub ręczny wyzwalacz. Doskonały do korzystania z usługami obsługi wiadomości oraz innymi wzorcami integracji asynchronicznej. Mniej poszczególnych pakietów i mniejszy ruch komunikatów. Niższy poziom odświeżania danych. Na obciążenie systemu odbierającego może mieć wpływ to, czy logika biznesowa zostanie wykonana po otrzymaniu komunikatu. Scenariusze dużych ilości lub zmienności, w których gromadzenie i transportowanie zestawu wiadomości lub rekordów w partii jest wykonalne, scenariusze replikacji danych.
Warstwa prezentacji Informacje z jednego systemu są bezporblemowo integrowane w interfejsie użytkownika innego systemu. Brak Eliminuje złożoności synchronizacji danych, ponieważ dane pozostają w systemie źródłowym. W niektórych branżach eliminuje się w ten sposób ograniczenia związane z miejscem przechowywania danych ze względu na wymagania prawne. Trudność użycia danych do obliczeń na potrzeby przetwarzania, więcej złożoności, by spełnić wymogi jednokrotnego logowania, współdzielenia zasobów między źródłami i wyrównanie autoryzacji. Jeśli wymagane jest wyświetlenie systemu źródłowego lub interfejsu użytkownika bezpośrednio bez konieczności synchronizowania danych między systemem źródłowym a docelowym.

Następne kroki

Microsoft Cloud for Sustainability

Microsoft Cloud for Financial Services

Microsoft Cloud for Healthcare