Dataintegrationsmønstre for Microsoft Industry-clouds

Artikel
10/27/2023

Gælder for:

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

Branchedatamodeller fungerer som udgangspunkt for deres respektive Microsoft Industry-clouds. Løsninger med integration med andre systemer kræves muligvis, afhængigt af udløbsniveauet for dataejendom.

Valg af det rette integrationsmønster er et vigtigt element for at sikre en vellykket implementering mellem Microsoft Industry-cloudsløsninger og eksterne systemer. I denne artikel beskrives de integrationsmønstre, værktøjer og teknologier, der er relevante for integration, sammen med de faktorer, der skal tages i betragtning i forbindelse med beslutninger.

Behovet for integration

Tredjepartssystemer kan have separate processer og endda anden forretningslogik. Hvis tredjepartssystemet bruger den samme underliggende Industry Cloud Common Data Model (CMD); Behovet for overførsel af data, synkronisering og programmering for at transformere dataene elimineres.

I følgende scenarier bruges dataintegrationsmønstre:

Primære eller transaktionsmæssige data, der ikke er den centrale del af en enkelt, løbende administrationsproces. Data synkroniseres mellem en proces i ét system og Microsoft Industry Cloud.
Data deles eller udveksles mellem systemer, når det er nødvendigt i forbindelse med beregninger.
Data deles eller udveksles mellem systemer, så når der sker handlinger i det ene system, afspejles i det andet system.
Aggregerede data fra et system med et detaljeret dataniveau udveksles til et system med en repræsentation af data på et højere niveau.

Sådan vælges det rette integrationsmønster

Der er mange tekniske muligheder for integrationsudvikling, og de alle har sine egne fordele og muligheder. Du kan identificere det rigtige mønster for integrationsudvidelser ved at overveje følgende faktorer og vægte dem på tværs af indstillingerne:

Beslutningsfaktor	Beskrivelse
Datatyper og formater	Hvilken type og format af data skal integreres?
Dataforskellighed	Fra lav eller langsom ændring til høj eller hurtig ændring.
Datamængde	Fra data med lave mængder af data til store mængder.
Datatilgængelighed	Hvornår skal dataene være klar fra kilde til mål? Er det nødvendigt i realtid, eller har du bare brug for at indsamle alle dataene i slutningen af dagen og sende dem i en planlagt batch til målet?
Servicebeskyttelse og -begrænsning	Sikre ensartet tilgængelighed og ydeevne for alle ved at anvende begrænsninger. Grænseværdierne bør ikke kun påvirke normale brugere, hvis anmodninger imødekommes. Almindeligt mønster for onlinetjenester skal bruges til at angive fejlkoder, når du foretager for mange forespørgsler.
Påkrævet datatransformationsniveau	Krav om at konvertere eller aggregere kildedataene til målet.
Udløsere og udløserhandlinger	Hvilken handling udløser afsendelse af data fra kilden til destinationen? Hvilke specifikke handlinger, der skal automatiseres, når dataene ankommer til målet?
Fejlhåndtering	Overvågning, der skal registrere eventuelle problemer med grænsefladerne.
Skalérbarhed	Håndter de forventede transaktionsmængder på nuværende, kort og lang sigt.
Postsystem	Overvej hvilket system i postsystemet, eller ejer, af oplysningerne.
Retning for dataflow	Skal destinationssystemet trække i det, eller skal kildesystemet trykke på det?

Ud fra disse faktorer kan du identificere integrationsmønsteret og også vælge det rigtige værktøj eller den rette teknologi til implementering.

Integrationsmønstre

I dette afsnit undersøger vi følgende integrationsmønstre, der kan bruges, mens du integrerer med Dataverse.

Realtidsintegration eller synkron integration
Nær realtidsintegration eller synkron integration
Batch-integration
Præsentationslag-integration

I hvert mønster vises en entydig struktur, og den kan gøres til aktuel ved hjælp af et eller flere mønstre. De efterfølgende afsnit giver indsigt i, hvordan disse mønstre materialiseres med bestemte teknologier, sammen med overvejelser og de scenarier, de skal anvendes i.

Realtidsintegration eller synkron integration

Integration i realtid fungerer kun i scenarier, hvor kildesystemet kræver øjeblikkelige eller minimale latensvar på de data, det sender. Dette krav bliver vigtigt, når både kilde- og destinationssystemer i forretningen skal forblive synkroniseret, så de to objekter hele tiden bliver synkroniseret. Synkron integration bliver vigtig, når destinationssystemet giver en hurtig respons, så der problemfrit kan fortsættes med en løbende proces, så efterfølgende handlinger kan udføres til tiden.

Denne form for integration er ofte synonym med synkron integration. I følgende diagram illustreres det fremherskende mønster for synkron integration, hvor program A starter en anmodning til et program B og modtager straks et svar og sikrer, at data udveksles til tiden og reagerer hurtigt.

Nogle af de nævnte teknologivalg kan udvides til at omfatte et system, der fungerer som et relay for at lette transaktionsprocessen. Denne videresendelsesindstilling adskiller effektivt kilden og målprogrammer ved at administrere kommunikationen mellem anmodninger og svar på deres vegne.

Du kan implementere disse synkrone dataintegrationsmønstre med forskellige teknologier, der findes i vores branchecloud-løsninger til branchen. Følgende tabel indeholder bedste praksis for, hvornår de skal bruges.

Teknologiindstilling	Dataretning	Formål	Bruges når
Dataverse Web API	Træk/push-data fra ekstern til Dataverse	Implementering af OData v4 for at levere CRUD-handlinger ved hjælp af et standardsæt af grænseflader, der giver en brugergrænseflade, der er åben for en publikum.	Mest i forbindelse med transaktionsappintegration, når der kræves separate CRUD-handlinger. Kan også bruges til alle brugerdefinerede integrationer, men de leveres med kompleksiteter, der relaterer sig til begrænsning, parallelitet og forsøgslogik, især på store datamængder.
API'er udgivet af Microsoft Industry-clouds	Træk/push-data fra ekstern til Dataverse	Brugerdefinerede API'er oprettet af Microsoft Industry-clouds til at understøtte særlige funktioner som adgang til data, der er relateret til dit Azure-forbrug.	Specifikke handlinger udgivet af Microsoft Industry-clouds. Prioriter brugen af disse brugerdefinerede API'er, før du opretter dine egne brugerdefinerede API'er.
Brugerdefineret Dataverse API	Træk/push-data fra ekstern til Dataverse	Oprettelse af din egen API i Dataverse.	Når en eller flere handlinger skal samles i en enkelt handling eller skal vise en ny type udløsende hændelse.
Virtuelle tabeller	Træk/push-data fra Dataverse til Ekstern	Opret forbindelse til eksterne datakilder, og behandl dem som indbyggede Dataverse-objekter.	Lige fra referencedata og scenarier med lave mængder af CRUD-scenarier.
Connectors	Tovejs	Muliggøre problemfri udveksling af data mellem Microsoft Services og eksterne systemer, programmer og datakilder.	Microsoft-publicerede connectorer er til almindeligt anvendte integrationer, f.eks. oprettelse af forbindelse mellem Microsoft Services og programmer fra første part. Godkendte connectorer, der publiceres , anvendes til specialiseret integration med tredjepartsprogrammer for at sikre kompatibilitet og stabilitet. Brugerdefinerede connectorer kan bruges, når Microsoft- eller partnertilslutninger ikke løser kundens forretningsbehov.

Nær realtidsintegration eller synkron integration

Asynkron integration anbefales i scenarier, hvor der ikke umiddelbart er behov for responser i realtid i en forretningsproces eller handling. De bruges typisk, når der er betydelig kommunikation i meddelelser mellem programmer og systemer. Asynkrone integrationsmønstre sikrer, at kommunikation mellem systemer ikke blokerer eller sinker processer, så de enkelte systemer kan arbejde uafhængigt og asynkront. Nogle af de mest almindelige måder at implementere asynkrone integrationer på er ved hjælp af meddelelseskøer, publicering af abonnement og batchintegration. Du kan bruge disse integrationer separat eller samlet, afhængigt af kravene. Ofte omtales de som arrangementsdrevne arkitekturer (EDA).

I det følgende mønster for meddelelseskøen anvender afsenderen en hændelsesbaseret ramme, og forbruger opretter en binding direkte til en hændelse. Når meddelelsen sendes, får modtageren direkte besked og modtager de data, der er indeholdt i hændelsesmeddelelsen.

I det følgende mønster for udgivelse og abonnement opretter udgiveren en meddelelse i et standardiseret publiceret format og sender den til en særlig publicerings-/abonnementskanal, som kan have en eller flere abonnenter. Alle abonnenter abonnerer på en bestemt kanal eller emne, så de kan modtage og behandle den udgivne meddelelse (hændelse) efter behov. Mønsteret for udgivelse og abonnement vælges i en til mange-kommunikationsscenarier, da flere abonnenter uafhængigt kan modtage og behandle meddelelserne (hændelser).

Disse asynkrone dataintegrationsmønstre kan implementeres med forskellige indstillinger. I følgende tabel kan du se de tilgængelige indstillinger og bedste praksis for, hvornår du skal bruge dem.

Teknologiindstilling	Arrangementsbaseret eller publicer-abonnement	Formål	Overvejelser	Bruges når
Power Automate	Både	Behov for automatisering af lav kode.	Følg Power Automate og hver connector-begrænsning, f.eks. begrænsning.	Brug til Dataverse-udløserforløb, eller når du vil køre Power Automate-flow efter en tidsplan.
Brugerdefinerede connectorer baseret på logikappsstruktur	Hændelsesbaseret	Opbygning af data-connectorer til løsningen for at hente data direkte fra ISV-løsninger.	Du skal gennemgå beskyttelse af personlige oplysninger, sikkerhed og overholdelse af gennemgang, før de flyttes til produktionen.	Brug af ISV-integrationsscenarier, hvor der ikke findes indbyggede connectors.
Logikapps og Azure Service Bus	Publicer-abonnement	Når udgiveren modtager meddelelser fra udgiveren til en tjenestebus og logicapp, forbruges den meddelelse, der skal sendes til abonnementsprogrammer.	Følg grænseværdierne for konfiguration og udførelse af Logic Apps.	Brug af indbyggede udløsere i Logic Apps-connectors og brugerdefineret integration med flere abonnementsscenarier.
Azure-funktioner, webappsfunktion i Azure App Service og Azure Service Bus	Publicer-abonnement	Brug en meddelelseskø til at implementere kommunikationskanalen mellem programmet og forekomsterne af forbrugertjenesten.	Overvej bestilling af meddelelser og andre designovervejelser.	Scenarier med store mængder og sårbarheder, hvor integration ikke kan udvikles med lave kodeindstillinger (Power Automate eller Logic Apps).
Serviceslutpunkt	Både	Afsendelse af kontekstoplysninger til en kø, emne, webhook eller hændelseshub.	Egner sig ikke til længerevarende transaktioner.	Når integrationskravet stort set opfyldes ved at sende Dataverse-konteksten til målet direkte, og det er ikke vigtigt at bestille meddelelser.

Batch-integration

Batchkørsel er en praksis med at indsamle og transportere et sæt meddelelser eller poster i en batch for at begrænse chatter-trafik og spild. Batchbehandling indsamler over en periode data og behandler derefter i batches. Denne fremgangsmåde er nyttig, når den bruges til store mængder data, eller når behandlingen kræver store ressourcer. Dette mønster gør det også muligt at replikere de oprindelige data til et replikeringslager med henblik på analyse.

Teknologiindstilling	Dataretning	Formål	Overvejelser	Bruges når
Azure Data Factory	Begge retninger	Oprettelse af dataflows for at transformere de data, der modtages fra Dataverse eller før, til Dataverse	Grænser for tjenesten Data Factory	Scenarie for masseeksport eller dataeksport med en kompleks transformering med flere faser.
Power Automate	I/R	Automatisere arbejdsprocesser og opgaver for Microsoft	Begrænset skalerbarhed og lang behandling	Brug Power Automate, når du har brug for at automatisere tilbagevendende opgaver, udløse handlinger på baggrund af hændelser og integrere programmer uden udvikling af kode.
Power Query-dataflow	Fra eksterne systemer til Dataverse	Værktøj til forberedelse af data, der giver dig mulighed for at transformere og indlæse data i Dataverse-miljøer.	Begrænsninger	Grundlæggende scenarier, hvor destinationen er Dataverse, og eksisterende forbindelser, er ikke egnede og andre givne scenarier Power BI.
Azure Synapse-pipelines	Begge retninger	Oprettelse af pipelines for at transformere de data, der modtages fra Dataverse eller før, til Dataverse	I/R	Analyse- og dataoptimeringsscenarier.
Azure Synapse Link for Dataverse	Fra Dataverse til Azure Synapse Analytics eller Azure Data Lake Storage v2	Replikering af Dataverse-data til Azure Synapse Analytics eller ADLS v2 og mulighed for at køre analyser, Business Intelligence, maskinel indlæring og tilpasset rapporteringsscenarier på dine data.	Tabeller, der ikke understøttes.	Dataanalyser og tilpasset rapport. Også som en mellemliggende fase i dataeksporten.
Azure Logic Apps	I/R	Opret arbejdsprocesser med effektive integrationsfunktioner.	Komplekse batchhandlinger kan kræve en betydelig konfiguration og organisering. Ikke optimeret til specielle batchbehandlingsscenarier.	Azure Logic Apps er velegnet til organisering af forretningsprocesser og integration af servicer.
SQL Server Integration Services	Begge retninger	Brug af en tilslutning fra tredjepart til at trække og skubbe data fra og til Dataverse.	Da det ikke er en PaaS-løsning, skalering, hukommelsesforbrug, ydeevne og omkostninger skal evalueres.	Eventuelle begrænsninger i forbindelse med udpakning, transformering og indlæsning af værktøjer (ETL) er måske ikke en mulighed.

Præsentationslag-integration

Præsentation eller User Interface Integration er øverst på systemniveau, og det er det, som brugeren kan se og kommunikere med. I visse tilfælde skal integration ske på dette niveau. Denne integration kombinerer oplysningerne fra forskellige systemer eller datakilder og viser dem på en enkelt brugergrænseflade. Modelbaserede programmer bidrager til den omfattende brugeroplevelse ved at muliggøre datadrevne interaktioner og problemfri navigation i det integrerede miljø. Brug præsentationsintegration, når du vil bevare den eksisterende forretningslogik eller programstruktur med følgende fordele:

Aktivering af dataaggregering
Tilpasning af brugergrænseflade
Forbedret brugeroplevelse

Modsat har den indbyggede begrænsninger, herunder:

Kompleksitet i integration og vedligeholdelse
Betydelig afhængighed mellem integrerede systemer
Konsekvenser for potentiel ydeevne
Overvejelser om ensartede data

Teknologiindstilling	Formål	Overvejelser	Bruges når
Integration af oprindelige brugergrænseflader med første part	Brug af Microsoft Bing-kort, Microsoft Teams og andre integrationer på førstepart af oprindelige UI-integrationer.	Kan ikke tilpasses i de fleste tilfælde.	Specifikke scenarier, der understøttes i oprindelig integration med brugergrænsefladen.
Brugerdefinerede sider	Integrering af et lærred-app i en modelbaseret app.	Kendte begrænsninger	Foretrukket at benytte en fremgangsmåde med lav kodeintegration, og når en lærredsapp er velegnet til anvendelighed.
Power Apps component framework (PCF)	Et brugerdefineret kontrolelement, der kan genbruges, og som viser eller kommunikerer med slutbrugeren, samtidig med at det reaktionsbaserede design bevares.	Power Apps-komponentbegrænset framework.	Foretrukken metode, når en brugerdefineret brugergrænseflade skal udvikles i modelbaseret, hvis der ikke er en lærredsapp.
Power BI-felter	Få vist Power BI-feltet i en modelbaseret appformular.	Power BI-licenser, godkendelse af Power BI-data.	Visning af et Power BI-felt i en modelbaseret app
Power BI-integreret dashboard	Visning af Power BI-integreret dashboard i den modelbaserede app.	Power BI-licenser, godkendelse af Power BI-data.	Visning af de analyser, der hostes i Power BI.
Indlejring som HTML iFrame	Indlejring af den anden brugergrænseflade i en modelbaseret app.	Enkelt logon (SSO), CORS-konfiguration (Cross-Origin Resource Sharing) og responsivt design.	Komplekse scenarier på brugergrænsefladen, hvor der ikke er nogen tilgængelig service.
Brugerdefineret webressource	Oprettelse af et brugerdefineret brugergrænsefladelayout i modelbaseret app.	Vurdere, hvordan den brugerdefinerede brugergrænseflade er tilgængelig og responsiv.	Scenarier, hvor andre integrationer på brugergrænsefladen ikke er en indstilling.

Oversigt over integrationsmønstre

I en verden med softwareintegration findes der forskellige mønstre og mekanismer, der kan udveksle data mellem forskellige systemer. Hvert mønster har sine egne fordele og ulemper, og hvis du vælger den rette, kan det have en stor indvirkning på de integrerede systemers ydeevne og effektivitet.

Følgende tabel indeholder en oversigt over disse integrationsmønstre: realtidsintegration eller synkron integration, asynkron integration, integration af batchkørsel og integration af præsentationslag. Du kan undersøge mekanismer, udløsere, fagfolk, arbejdssager og brugssager for hvert mønster for at hjælpe dig med at træffe en velovervejet beslutning, når du vælger en integrationsstrategi for dit system.

Integrationsmønster	Mekanisme	Udløser	Fordele	Ulemper	Bruges når
Realtid eller synkron	Data udveksles synkront og anvender handlinger via punkt til punkt-integration eller ved hjælp af relæ.	Brugerhandling eller systemhændelse.	Hurtig forespørgsel og svar tur/retur. Værdier og oplysninger i realtid.	Generelt er det ikke bedste praksis at bruge programmet på grund af risikoen for, at processer går i stå og skaber en tæt integration af lige muligheder. Risiko for effekt på grund af midlertidige fejl. Følsomme over for ventetid.	Brug, når oplysninger i realtid er vigtigt.
Asynkron	Data udveksles eller indtages uovervåget i en periode eller som et trickle-feed ved hjælp af meddelelsesmønstre.	Planlagt til en periode eller udløst af en ny meddelelse, der er udgivet af kildesystemet.	Løs sammenkobling af systemer gør løsningen robust. Belastningsjustering over tid og ressourcer. Det kan være meget tæt på realtid. Rettidig fejlhåndtering.	Forsinkelse i svar og synlighed for ændringer på tværs af systemer.	Næsten behov for synkronisering af realtidsdata for lave eller mellemstore dataenheder.
Batchkørsel	Batchkørsel er en praksis med at indsamle og transportere et sæt meddelelser eller poster i en batch for at begrænse chatter-trafik og spild.	Planlagt eller manuel udløser.	Perfekt til brug med meddelelsestjenester og andre asynkrone integrationsmønstre. Færre individuelle pakker og mindre meddelelsestrafik.	Opdatering af data er lavere. Belastningen i det modtagende system kan påvirkes, hvis forretningslogikken køres ved modtagelse af meddelelser.	Scenarier med store mængder eller forskelligheder, hvor indsamling og transport af et sæt meddelelser eller poster i et batchjob er scenarier til indsamling og replikering af data.
Præsentationslag	Oplysninger fra ét system er problemfrit integreret i brugergrænsefladen i et andet system.	I/R	Eliminerer kompleksiteten af datasynkronisering, som da dataene forbliver i det oprindelige system. I visse brancher elimineres blokeringer, der vedrører dataopbevaring, på grund af lovgivningskrav.	Det er svært at bruge dataene til beregninger til behandling, kompleksiteter for at tilfredsstille enkeltlogon, ressourcedeling på tværs af oprindelsessiden og godkendelsesjustering.	Når kravet opfyldes, skal kildesystemet eller brugergrænsefladen vises direkte, uden at det er nødvendigt at synkronisere data mellem kilde- og destinationssystemet.