Synkronisere data på tvers av dataverse miljøer ved hjelp av Power Platform

Denne referansearkitekturen viser hvordan du synkroniserer hoveddata mellom to dataverse miljøer ved hjelp av Power Automate og dataflyter i Power Platform. Det demonstrerer et synkroniseringsmønster fra én til én der ett miljø fungerer som den autoritative kilden, og et annet mottar data.

Arkitekturdiagram

Workflow

Følgende trinn beskriver arbeidsflyten som vises i eksempelarkitekturdiagrammet:

1. Hendelsesdrevet synkronisering via Power Automate

   • CRUD-operasjoner (opprette, lese, oppdatere, slette) i det primære dataverse-miljøet utløser Power Automate flyter.

   • Hendelsesdrevet synkronisering bruker en totrinns flytkjede:

     1. En skyløsning sender en HTTP POST til et publisert endepunkt.
     2. En abonnentskyflyt utløses av webhooken, behandler nyttelasten og bruker oppdateringen i det sekundære dataversmiljøet i nær sanntid.

   • Endepunkter er parameterisert for behandling av programlivssyklus (ALM) og sikkerhetsgrupper administrerer tilgang.

2. Massesynkronisering via dataflyter

   • Det sekundære dataversmiljøet inneholder dataflytene.

   • Hver dataflyt kobles til det primære dataversmiljøet som datakilde.

   • Dataflyter kjøres etter en fast tidsplan (for eksempel hver natt eller etter at en annen dataflyt kjøres) eller ved behov (for eksempel for første installasjon).

   • Upserts utføres ved hjelp av en alternativ nøkkel for å unngå duplikater. Denne metoden oppdaterer eksisterende data og setter inn nye poster når det ikke finnes noen treff.

   • Statusfelt administreres gjennom en dedikert «synkroniseringsstatus»-kolonne. En Power Automate flytprosess oppdaterer statusfeltet i henhold til faktisk status. Denne flyten kjører etter dataflyten og kreves fordi en dataflyt ikke kan endre radstatuser eller slette poster som er fjernet (fraværende) i det primære dataverse miljøet.

3. Feilbehandling og avstemming

   • Nattlige dataflyter i det sekundære miljøet retter opp eventuelle tapte eller mislykkede hendelsesdrevne oppdateringer.

   • Manuell inngripen kan være nødvendig for problemer med datakvalitet (for eksempel manglende nøkler).

Komponenter

• Microsoft Dataverse: Støtter kravet om to miljøer.

• Dataflyter for Power Platform: Ideell for masseoperasjoner, for eksempel innledende datapopulasjon og synkronisering. Bruk masseutpakking, transformering og innlasting (ETL) for planlagt synkronisering, konfigurert i det sekundære miljøet.

• Power Automate cloud flows: Gi raske, postspesifikke oppdateringer og kompenser for begrensninger i dataflyter. Skyflyter kan utløse en dataflyt når en annen dataflyt fullføres (for eksempel når én tabell inneholder et oppslagsfelt til et annet, og den refererte posten må allerede finnes i det sekundære dataversmiljøet), sende en feilmelding når en dataflyt mislykkes, oppdatere poststatuser og slette poster.

• Sikkerhetsgrupper og tjenestekontoer: Gi tilgangsadministrasjon og eierskap.

Scenariodetaljer

Denne arkitekturen er utformet for en én-til-én-relasjon: et enkelt MDM-miljø (Master Data Management) som er koblet til et annet enkeltmiljø. Scenarioer der ett hovedmiljø må synkroniseres med flere andre miljøer, krever en mer skalerbar eller distribuert løsning.

Forretningsproblem

Denne løsningen tar for seg utfordringen med å synkronisere flere tabeller mellom to distinkte dataverse miljøer. Det primære miljøet fungerer som den autoritative kilden, mens det sekundære miljøet inneholder eksisterende tabeller som du må fylle ut og oppdatere med hoveddata.

Bruk av virtuelle tabeller er ikke mulig når de sekundære systemtabellene allerede finnes og krever sikkerhet på radnivå.

Eksempel på brukstilfelle

En fritids- og gjestfrihetsorganisasjon administrerer sine viktigste hoveddata, for eksempel hoteller og romlager, i et dedikert Dataverse-miljø. Det primære miljøet inkluderer en modelldrevet app som hovedteamet for databehandling bruker utelukkende for å opprettholde nøyaktig og up-to-date driftsinformasjon.

En egen avdeling i samme organisasjon er ansvarlig for flere økonomiske og avstemmingsprosesser. Avdelingen ønsker å bygge sin egen modelldrevne app i et isolert dataversmiljø for å effektivisere disse prosessene. Programmet krever imidlertid fortsatt tilgang til grunnleggende hoveddata, for eksempel hotell- og romdetaljer.

Teamet avviste virtuelle tabeller fordi finansteamet trengte å berike poster med avdelingsspesifikke attributter styrt av streng sikkerhet på radnivå.

Innebygging av finansappen i det primære MDM-miljøet er heller ikke et alternativ. Hvis du tillater finansutviklere eller administratorer i MDM-miljøet, vises koblinger, løsninger, API-tillatelser og sensitive data som må forbli begrenset til MDM-utviklingsteamet.

Disse kravene førte til at organisasjonen vedtok synkroniseringsarkitekturen som er beskrevet i denne artikkelen.

Verdi opprettet

Denne arkitekturen leverer en robust, vedlikeholdbar løsning for synkronisering av hoveddata mellom to dataverse miljøer når virtuelle tabeller ikke er et alternativ. Direkte utfylling og oppdatering av eksisterende tabeller i det sekundære miljøet sikrer datakonsekvens og driftspålitelighet.

Tilnærmingen bruker bare Power Platform-komponenter, for eksempel dataflyter og Power Automate, noe som resulterer i en løsning som er enkel å distribuere, enkel å administrere og unngår unødvendig kompleksitet.

Fordi arkitekturen er skreddersydd for en miljørelasjon fra én til én, minimerer den overhead og maksimerer gjennomsiktigheten. Det er ideelt for organisasjoner som trenger enkel, pålitelig hoveddatasynkronisering uten storskala administrasjon av flere miljøer.

Vurderinger

Disse hensynene tar i bruk prinsippene i Power Platform Well-Architected, et sett med veiledende prinsipper som forbedrer kvaliteten på en arbeidsbelastning. Finn ut mer i Microsoft Power Platform Well-Architected.

Pålitelighet

• Nattlige dataflyter sikrer konsekvens.

• Hendelsesdrevne flyt leverer rask oppdatering.

• Manuell overvåking oppdager problemer med datakvalitet.

Sikkerhet

• Tjenestekontoer og sikkerhetsgrupper for tilgangskontroll. Når du bruker dataflyter, kan du ikke tilordne tjenestekontohavere som eiere.

• Parameteriserte HTTP-endepunkter for ALM-kompatibilitet.

• Dataflyter i isolerte løsninger for å unngå unødvendig manuelt arbeid. Det er en bestemt grunn til å isolere dataflyter i en dedikert løsning: Etter hver distribusjon må du opprette dataflyttilkoblingen manuelt. Ved å plassere dataflyter i en egen løsning som du distribuerer bare når du endrer dataflytene, unngår du unødvendig manuelt arbeid når du distribuerer andre komponenter i hovedløsningen.

Driftskvalitet

• Automatisert planlegging og orkestrering av dataflyter.

• Overvåking og varsling for mislykkede synkroniseringer.

Ytelseseffektivitet

• Dataflyter optimalisert for masseoperasjoner.

• Hendelsesdrevne Power Automate flyter reduserer ventetiden for kritiske oppdateringer på postnivå. Når du utformer hendelsesdrevne flyter, må du sørge for at handlingsvolum og samtidighet forblir innenfor Power Automate tjenestegrenser. Høyfrekvent CRUD-aktivitet kan utløse begrensning, spesielt i scenarioer der flyter utfører titusenvis av handlinger per dag. For forretningskritiske eller høygjennomstrømmingsintegreringer kan du bruke passende Power Automate-lisensiering for å øke gjennomstrømningskapasiteten og unngå uventet begrensning. Denne tilnærmingen reduserer eskaleringsrisiko og sikrer forutsigbar ytelse.

Opplevelsesoptimalisering

• Krever minimal manuell inngripen.

• Skiller tydelig masse- og hendelsesdrevne synkroniseringer.

Bidragsytere

Microsoft vedlikeholder denne artikkelen. Følgende bidragsytere skrev denne artikkelen.

Hovedforfattere:

• Lothar van Diessen, løsningsarkitekt

Beslektede ressurser

• Hva er dataflyter?
• Power Automate-maler for dataflyt-tilkoblingen
• Datavers som et hoveddatasystem
• Forstå plattformgrenser og unngå struping
• CRM-dataoverføring til datavers: Viktig innsikt og anbefalte fremgangsmåter
• Migrer data mellom Microsoft Dataverse miljøer ved hjelp av OData-koblingen for dataflyter