Delen via


Operationeel data estate

Inleiding

In omgevingen met toepassingen voor financiële dienstverlening is efficiënt beheer van operationele gegevens een belangrijke voorwaarde voor succes. Microsoft Cloud for Financial Services introduceert op maat gemaakte operationele gegevensmodellen voor specifieke processen, zoals een enkele klantweergave of onboarding-toepassingen.

Het artikel gaat dieper in op het bouwen van een operationeel data estate dat is gesynchroniseerd met uw belangrijkste bank- en andere registratiesystemen.

Referentiearchitectuur voor operationeel data estate

Microsoft Cloud for Financial Services-implementaties beginnen met het implementeren van het gegevensmodel voor de geselecteerde mogelijkheden voor Dataverse. Voor het gegevenspersistentiescenario van Dataverse toont het volgende diagram de stappen voor het opnemen, transformeren, opslaan en modelleren van de operationele gegevensreferentiearchitectuur in Microsoft Cloud for Financial Services.

Een diagram dat de oplossingsonderdelen van de referentiearchitectuur voor de operationele data estate toont

Download een afdrukbare PDF van dit oplossingsarchitectuurdiagram.

De referentiearchitectuur omvat drie onderdelen: ingebouwde gegevensonderdelen, onderdelen voor gegevensintegratie en optioneel onderdelen voor gegevensuitbreiding.

Ingebouwde gegevensonderdelen

De Microsoft Cloud for Financial Services-oplossing gebruikt Dataverse om app-gegevens op te slaan en te beveiligen. De gegevens in Dataverse worden gemodelleerd op basis van het CDM-gegevensschema (Common Data Model). Het Common Data Model biedt een reeks gestandaardiseerde, uitbreidbare gegevensstructuren. De oplossing implementeert een aantal kant-en-klare basiselementen (dat wil zeggen kerngegevensmodel voor bankieren) en op capaciteiten gebaseerde gegevensmodellen die het CDM-gegevensschema gebruiken. Zoals vermeld in de soorten bewerkingsgegevens, slaat Dataverse de vier kerngegevenscategorieën (hoofd, transactioneel, configuratie en afgeleid) op als standaardtabellen.

Onderdelen voor gegevensintegratie

In financiële instellingen kunnen verschillende financiële en klantgegevens worden beheerd door verschillende registratiesystemen. Zoals aangegeven moet u met behulp van de persistentieoptie in Dataverse gegevensonderdelen uit deze systemen hydrateren en aanleveren in Dataverse. U kunt opname- en transformatiebewerkingen op de vereiste gegevenselementen uitvoeren met behulp van verschillende asynchrone en batchverwerkingstechnologieën, waaronder Azure Logic Apps, Azure Data Factory, Data Flow en Azure Functions. We raden u aan om met het ontwerp te beginnen, onafhankelijk van de integratieaanpak van uw keuze, door een gegevenstoewijzing te maken tussen de bronsystemen en het gegevensmodel voor financiële services.

Onderdelen voor gegevensuitbreidingen (optioneel)

Op basis van uw vereisten moet u het gegevensmodel mogelijk uitbreiden met meer gegevensonderdelen. Dataverse biedt u de mogelijkheid om het gegevensmodel uit te breiden met nieuwe tabellen, velden en keuzes die zich boven op de onderliggende gegevensmodellen van de Microsoft Cloud for Financial Services-oplossing bevinden.

Voor sommige eerder genoemde uitbreidingsscenario's wilt u wellicht de mogelijkheid verkennen om gebruik te maken van virtuele tabellen of elastische tabellen (preview) om gegevensproliferatie te voorkomen of om te gaan met aanzienlijke gegevensvolumes, zoals de interactiegeschiedenis en accounttransacties. Het is echter essentieel om zorgvuldig de implicaties en overwegingen te evalueren die gepaard gaan met de implementatie van virtuele tabellen en elastische tabellen in uw ontwerp.

Traject van gegevensimplementatie

Het gegevensimplementatietraject omvat het beoordelen van de huidige status van de gegevens en de toewijzing hiervan aan de relevante Microsoft Cloud for Financial Services-gegevensmodellen. De verduidelijkingen van de toewijzingsregels en het opschonen van gegevens vinden ruim vóór het daadwerkelijke gegevenssynchronisatieproces plaats. Tijdens de gegevenssynchronisatie gebruikt het conversieproces de gegevens die zijn geëxtraheerd uit oudere toepassingen en worden deze getransformeerd door middel van toewijzing en conversie. Vervolgens worden de gegevens geladen in de gegevensmodellen van Microsoft voor Financial Services. Het proces voorziet verder in integratietests en -validatie om de consistentie en integriteit van de gehydrateerde gegevens te bevestigen.

Het gegevensimplementatietraject voor Microsoft Cloud for Financial Services kan worden opgesplitst in de volgende fasen om een ​​naadloze en effectieve ingebruikname van het platform te garanderen.

  • Ontdekken en analyseren
  • Planning en ontwerp
  • Implementatie en test
  • Implementatie en ingebruikname

Een diagram dat het gegevensimplementatietraject van het operationele data estate laat zien

Download een afdrukbare PDF van dit diagram.

Dit zijn de belangrijkste fasen van het gegevensimplementatietraject:

Ontdekken en analyseren

Verzameling van vereisten

Werk samen met belanghebbenden, deskundigen en eindgebruikers om inzicht te krijgen in de bedrijfsdoelstellingen, gegevensbehoeften en processen binnen het domein. Documenteer de vereisten en zorg voor duidelijkheid over de informatie die in het model moet worden weergegeven. Zorg ervoor dat u niet-functionele vereisten opneemt, zoals specifieke vereisten voor naleving van regelgeving en wetgeving inzake gegevensbescherming. Neem ook specifieke gegevensbeveiligingsvereisten op om gevoelige financiële informatie te beschermen en ongeautoriseerde toegang te voorkomen.

Het bestaande gegevenslandschap documenteren

Documenteer het bestaande gegevenslandschap door elke gegevensbron, de gegevenskwaliteit (juistheid, opgeruimdheid en volledigheid), connectiviteit en gegevensbeheerpraktijken te identificeren om eventuele gegevensgerelateerde uitdagingen en kansen te identificeren. Evalueer de kenmerken en mogelijkheden van de gegevensplatforms om ervoor te zorgen dat deze aansluiten bij de gegevensvereisten en langetermijndoelstellingen van de organisatie. Het belangrijkste punt voor het gegevenslandschap is het maken van een holistisch beeld van de gegevensopslagplaatsen, hun relaties met andere systemen, een conceptuele gegevensstroom en eigendom. Deze informatie helpt om aan de integratievereisten te voldoen en biedt een referentie voor het bredere projectteam.

Wanneer u uw gegevenslandschap voorbereidt, kunt u de volgende vragen als leidraad gebruiken.

  • Wat zijn de belangrijkste entiteiten die nodig zijn om de vereiste processen te modelleren voor Cloud for FSI-oplossingen zoals Geharmoniseerd klantprofiel of Onboarding van klanten? Voorbeelden hiervan zijn klanten, financiële bezittingen, werknemers, filialen, enz.
  • Wat is het registratiesysteem voor deze gegevenselementen? Is het één enkel systeem of worden deze entiteiten in verschillende gegevensopslagplaatsen bewaard? Zijn er gegevenssilo's?
  • Hoe beheert u uw gegevens en integreert u deze in uw bedrijfstakken?
  • Wat zijn de privacy- en beveiligingsaspecten van de gegevens?

Het gegevenslandschap voor een typische financiële instelling kan zich uitstrekken over vele registratiesystemen, zoals hier geïllustreerd:

Entiteitsrelatiediagram van mogelijkheden voor levensgebeurtenissen en financiële doelen in toepassing voor geharmoniseerde klantprofielen

Download een afdrukbare PDF van dit diagram.

Beschrijving van gegevensmodellen in Microsoft Cloud for Financial Service

Presentatie met behulp van de kant-en-klare gebruikersinterface en de toewijzing aan de onderliggende gegevensmodellen. Het volgende diagram illustreert de toewijzing van het tabblad Beleggingsdetails aan het kerngegevensmodel voor bankieren.

Een diagram met het contextuele gegevenslandschap van de financiële service.

Download een afdrukbare PDF van dit diagram.

U kunt het visio-bestand downloaden, inclusief de entiteitsrelatiediagrammen (ERD) van elke first-party oplossing.

Planning en ontwerp

Strategie voor gegevensconversie

Een geslaagde gegevensconversie-implementatie van bronsystemen naar Microsoft Cloud for Financial Services vereist doorgaans een goed gedefinieerde gegevensconversiestrategie. In de strategie moeten verschillende essentiële elementen worden gedocumenteerd, zoals:

  • Bereik en doelstellingen: duidelijk gedefinieerde doelen en doelstellingen voor het gegevensconversieproces, inclusief welke gegevens wel en niet worden geconverteerd en eventuele specifieke doelen of meetwaarden die moeten worden gehaald.
  • Gegevensbeoordeling en profilering: details over hoe brongegevens worden beoordeeld en geprofileerd, inclusief analyse van de gegevenskwaliteit, afhankelijkheden en structuurevaluatie.
  • Gegevenstoewijzing en transformatie: informatie over hoe gegevens worden toegewezen van bronsystemen aan het doelsysteem, inclusief transformatieregels en -logica. U kunt de details van dit element bekijken in de volgende sectie.
  • Gegevens opschonen en verrijken: strategieën en processen voor het opschonen en verrijken van gegevens om de nauwkeurigheid en volledigheid te waarborgen.
  • Integratiebenadering: uitleg van de ETL- of integratietools, -methodologieën en -processen die moeten worden gebruikt bij het extraheren, transformeren en laden van gegevens in het doelsysteem. Tijdens of na voltooiing van de gegevenstoewijzingsoefening kunt u de verzamelde informatie gebruiken en het juiste integratiepatroon voor de eerste lading en het synchroniseren van wijzigingen van bron naar doel bepalen. Zie het artikel Integratiepatronen voor meerdere bedrijfstakken voor informatie over integratiepatronen.
  • Gegevensvalidatie en kwaliteitsborging: beschrijving van de toegepaste validatieprocessen, kwaliteitscontroles en gegevensafstemmingsmethoden om de nauwkeurigheid en integriteit van gegevens te garanderen.
  • Gegevensbeveiliging en naleving: maatregelen en protocollen voor gegevensbeveiliging, inclusief toegangsbeheer, encryptie en naleving van relevante regelgeving en standaarden voor de specifieke branche en het land of de regio.
  • Risicobeheer: identificatie van potentiële risico's en risicobeperkingsstrategieën met betrekking tot gegevensconversie, zoals gegevensverlies, downtime of prestatieproblemen.
  • Testen en validatie: een plan voor het testen van de geconverteerde gegevens om ervoor te zorgen dat deze aan de vereiste normen voldoen en klaar zijn voor productiegebruik.
  • Documentatie en logboekregistratie: richtlijnen voor het documenteren van het gehele gegevensconversieproces, inclusief gegevenswoordenboeken, transformatieregels, migratielogboeken en alle relevante metagegevens.
  • Resource- en tijdlijnplanning: toewijzing van resources (menselijk en technisch) en een gedetailleerde tijdlijn voor elke fase van het gegevensconversieproject.
  • Nood- en terugdraaiplan: zorgt voor de afhandeling van onverwachte problemen of fouten, inclusief een noodplan en procedures om zo nodig de vorige staat te herstellen.
  • Controle en prestatieoptimalisatie: strategieën voor het controleren van gegevens in het doelsysteem na de conversie en het optimaliseren van de gegevensprestaties.

De grootte van de omgeving bepalen

Gegevensconversietaken vereisen schaalbaarheid van de omgeving. We raden u aan een schaalbare infrastructuur te gebruiken op basis van een hoog volume voor de initiële belasting en voor eventuele deltabelastingen. Zie voor meer informatie het artikel Prestatie-efficiëntie van Well-Architected Framework - Toepassingen ontwerpen voor schaalbaarheid.

Gegevensmodellering

Entiteiten identificeren: identificeer de belangrijkste objecten of entiteiten die nodig zijn voor de processen. Deze entiteiten staan voor de fundamentele concepten of zaken die van belang zijn binnen de organisatie. Voer een geschiktheids-/hiaatanalyse uit om te bepalen of deze entiteiten bestaan ​​binnen het Microsoft Cloud for Financial Services-gegevensmodel.

Relaties bepalen: stel relaties tussen de entiteiten vast om te laten zien hoe ze gerelateerd zijn of met elkaar verbonden zijn. Relaties kunnen een-op-een, een-op-veel of veel-op-veel zijn. Een contactentiteit heeft bijvoorbeeld een veel-op-veel-relatie met een entiteit financieel bezit.

Conceptueel gegevensmodel ontwerpen: het ontwerpen van een conceptueel gegevensmodel biedt een vereenvoudigde en abstracte weergave van de gegevensentiteiten en hun koppelingen, waarbij de nadruk meer ligt op de bedrijfsconcepten dan op de technische implementatiedetails. Hieronder volgt een voorbeeld van een conceptueel gegevensmodel dat is ontwikkeld voor het tabblad Investeringsdetails in Kerngegevensmodel voor bankieren.

Voorbeeld van een conceptueel gegevensmodel dat is ontwikkeld voor het tabblad Investeringsdetails in Kerngegevensmodel voor bankieren

Beoordelen en valideren: beoordeel het conceptuele gegevensmodel met belanghebbenden om er zeker van te zijn dat het de zakelijke vereisten en relaties nauwkeurig weergeeft.

Herhalen en verfijnen: herhaal en verfijn het conceptuele gegevensmodel zo nodig op basis van feedback en veranderende bedrijfsbehoeften.

Kenmerken identificeren: identificeer en definieer voor elke tabel de kenmerken of eigenschappen die de entiteit beschrijven. Beoordeel het hergebruik van bestaande velden in het gegevensmodel en identificeer velden voor uitbreiding.

Het model documenteren: documenteer het gegevensmodel grondig, inclusief een gegevenswoordenboek waarin alle entiteiten en kenmerken in detail worden gedefinieerd. Deze documentatie dient als referentie voor toekomstige inspanningen op het gebied van gegevensmodellering. Geef het gegevensmodel visueel weer met behulp van een entiteitsrelatiediagram. De volgende afbeelding illustreert een entiteitsrelatiediagram voor de mogelijkheid Geharmoniseerd klantprofiel - Basisprofiel.

Entiteitsrelatiediagram voor de mogelijkheid Geharmoniseerd klantprofiel - Basisprofiel

Gegevenstoewijzing

Voor gegevensconversie hebt u een gegevenstoewijzing nodig tussen de gegevenselementen van het bronsysteem en elk kenmerk in het geïdentificeerde gegevensmodel. U kunt deze stappen volgen om de gegevens samen te stellen:

  • Verzamel informatie van elke gegevensbron. De informatie omvat connectiviteit met de openbare cloud, extractiebenadering (platte bestanden, csv, directe query) voor elke gegevensbron, volatiliteit (frequentie van verandering) en volume (grootte van gegevens).
  • Identificeer de bronindeling. U moet informatie verzamelen over elk gegevenselement in de gegevensbron dat is bestemd voor toewijzing. De te verzamelen informatie omvat gegevensindelingen en hun volledigheid (of opschoning noodzakelijk is).
  • Documenteer de transformatielogica. U moet elke transformatieregel documenteren die u vóór opname op de brongegevens moet toepassen. U moet deze naast andere controles opnemen, zoals verplichte velden, standaardwaarden, optiesetwaarden, enzovoort.

U kunt Gegevenshydratatie voor Microsoft Cloud for Financial Services gebruiken om uw gegevenstoewijzingsdocumentatie te starten. U kunt ook uw eigen gegevenstoewijzingsdocument starten door een export van de gegevensmodelelementen op te halen met behulp van het hulpmiddel van de XRMToolbox-community.

Gegevens opschonen en verrijken

We raden het team van gegevensanalisten aan te beginnen met het identificeren, consolideren, ontdubbelen en opschonen van de gegevens op juistheid en volledigheid. De doelen zijn om het aantal transformaties dat nodig is tijdens de conversie te beperken, de gegevens te cureren en ervoor te zorgen dat deze aan de vereiste kwaliteitsnormen voldoen en deze waar nodig te verrijken met meer relevante informatie. Hoe meer logica er nodig is om te transformeren, hoe langer het duurt om de gegevensimport te laden.

Implementatie en tests

Gegevensconversiestroom

Na voltooiing van de plannings- en ontwerpactiviteiten omvat de implementatiefase activiteiten zoals:

  • Het inrichten van de omgeving voor ontwikkelen en testen
  • Het voorbereiden van productieachtige migratiegegevens voor ontwikkeling en testen
  • Het maken en vullen van configuratietabellen ter ondersteuning van bulk- en initiële ladingen vanuit hetzelfde script
  • De ontwikkeling van regels voor datatransformatie, zoals gegevensopschoning en conversiescripts
  • De ontwikkeling van gegevensvalidatiescripts
  • De registratie en controle van het laden van gegevens

Deze activiteiten worden uitgevoerd als onderdeel van de onderstaande gegevensconversiestroom, waarbij elke stap van de stroom als volgt wordt beschreven:

Een diagram dat de gegevensconversiestroom voorstelt

Download een afdrukbare PDF van dit diagram.

  • Laad referentiegegevens in hoofdtabellen voor gegevensconversie. U moet referentiegegevens opgeven voor zoekopdrachten en optiesets in de tabel die u in conversiescripts kunt gebruiken. Deze gegevens moeten regelmatig worden bijgewerkt wanneer nieuwe zoekopdrachten worden geïntroduceerd om eventuele fouten vanwege referentiële integriteit te voorkomen.

  • De ETL/ELT-tool van uw keuze extraheert onbewerkte gegevens naar Data Lake Storage Gen2

  • De ETL/ELT-tool van uw keuze laadt de onbewerkte gegevens in SQL Database en/of Data Lake Storage Gen2, waar de onbewerkte gegevens worden klaargezet voor verwerking.

  • Scripts voor het opschonen en verrijken van gegevens worden uitgevoerd om ongewenste gegevenselementen te verwijderen (op te schonen) en ontbrekende of extra benodigde gegevenselementen toe te voegen (verrijken) aan de onbewerkte gegevens.

  • Scripts voor gegevenstransformatie worden uitgevoerd om opgeschoonde en verrijkte gegevens te transformeren naar de doelgegevensindeling. Deze scripts worden ontwikkeld op basis van de informatie die is vastgelegd in de gegevenstoewijzing. We raden u aan de gegevens naar dezelfde indeling te transformeren als het doelgegevensmodel, zodat gegevensvalidaties vóór het laadproces kunnen worden uitgevoerd.

Deze scripts moeten worden geordend op basis van afhankelijkheden. Volg de richtlijnen in Gegevenshydratatie voor Microsoft Cloud for Financial Services om de tabellen in de aangegeven volgorde te laden.

  • Voer gegevensvalidatiescripts uit voordat het laadproces wordt gestart om fouten tijdens het laadproces te voorkomen en de gegevensintegriteit te waarborgen. Het grootste risico dat deze aanpak helpt te voorkomen, is mogelijke gegevensbeschadiging veroorzaakt door het conversiescript. U kunt voor elke tabel een gegevensvalidatiescript maken en de volgende controles toevoegen:

    • Zijn alle hoofdzoekopdrachten voor verouderde hoofdcodes opgelost?
    • Zijn alle optiesetwaarden voor verouderde waarden opgelost?
    • Is alle vereiste verplichte informatie voor bedrijven opgelost?
  • Laad getransformeerde gegevens in Dataverse met behulp van de API (methode ExecuteMultipleRequest). U kunt ook connectors van derden gebruiken voor Dataverse om de stappen voor het genereren van payloads, parallelle threaduitvoeringen en mechanismen voor opnieuw proberen te vereenvoudigen en het laadresultaat vast te leggen.

  • Registreer de uitvoering van elke laadactie. Registreer succesvolle en mislukte records voor logboekregistratie en de logica voor opnieuw proberen. U kunt een tabel als de volgende maken om logboekinformatie over de uitvoering van pakketten op te slaan.

Kolomnaam Omschrijving
SeqId Identiteitskolom
ExecutionInstanceGuid Huidige pakketuitvoerings-id
PackageName Huidige pakketnaam
StartTime Begintijd van pakket
EndTime Eindtijd van pakket
PackageStatus Huidige status van het pakket: Actief, Mislukt of Geslaagd
InitialRowCount Oorspronkelijke aantal rijen
CreatedRowCount Aantal records gemaakt in Dataverse
UpdatedRowCount Aantal records bijgewerkt in Dataverse
ErrorRowCount Aantal mislukte records tijdens gegevensconversie
Bericht Bericht (indien aanwezig). Bevat het foutbericht als PackageStatus = Mislukt

U kunt een foutentabel maken om foutberichten voor elke mislukte record op te slaan.

  • Maak een rapportage om de cyclus van elke gegevensconversie te bewaken en maak waarschuwingen fouten met betrekking tot de drempelwaarde.

  • De oplossing moet platformservices gebruiken voor samenwerking, prestaties, betrouwbaarheid, beheer en beveiliging: **

    • Microsoft Purview biedt services voor gegevensdetectie, classificatie van gevoelige gegevens en governance-inzichten in het gehele data estate.
    • Azure DevOps biedt continue integratie en continue implementatie (CI/CD) en andere geïntegreerde versiebeheerfuncties.
    • Azure Key Vault beheert geheimen, sleutels en certificaten veilig.
    • Microsoft Entra ID biedt eenmalige aanmelding (SSO) voor gebruikers van ETL/ELT-tools.
    • Azure Monitor verzamelt en analyseert telemetrie van Azure-resources. De service identificeert proactief problemen en maximaliseert de prestaties en betrouwbaarheid.
    • Power Platform-beheercentrum voor Dataverse-analyse inclusief API-aanroepstatistieken

Initiële lading en deltalading

Een gegevensconversieproces omvat een extractie van gegevens uit een bronsysteem, het transformeren van de gegevens en het laden in een bestemmingssysteem (in dit geval Dataverse met een Microsoft Cloud for Financial Services-gegevensmodel). U hebt een initiële lading nodig waarbij eerst de referentiegegevenscatalogus wordt geïmporteerd, gevolgd door de hoofdtransactiegegevens die worden geladen om de essentiële tabellen voor bedrijfsprocessen te hydrateren. Een deltalading verwijst doorgaans naar het vastleggen van de wijzigingen in het bronsysteem (maak-, bijwerk- en verwijderbewerkingen) die hebben plaatsgevonden sinds de initiële lading of de laatste deltalading en het toepassen van alleen die wijzigingen op de bestemming.

Het belangrijkste aspect bij het ontwikkelen van een gegevensconversieplan is het waarborgen van de gegevensintegriteit. Het grootste risico dat deze aanpak helpt te voorkomen, is mogelijke gegevensbeschadiging veroorzaakt door het conversiescript.

Bugs in het gegevensconversiescript kunnen de gegevensintegriteit gemakkelijk in gevaar brengen, waardoor het hele systeem beschadigd kan raken en onbruikbaar wordt. Het risico van gegevensbeschadiging is ernstig en moet uitgebreid worden getest, vooral op complexe gebieden van de dataconversie. De beste manier om de gegevensintegriteit te waarborgen, is door het simpel te houden.

Hieronder volgen enkele belangrijke vragen bij het overwegen van deltaladingen als onderdeel van een gegevensmigratie:

  • Hoe worden de wijzigingen in het bronsysteem vastgelegd en in welke indeling?
  • Wat is het registratiesysteem voor een bepaald gegevenselement? Vinden er veranderingen plaats in Dataverse die moeten worden gesynchroniseerd met het oude systeem, zoals gegevenselementen in het documentinformatie- of onboardingproces?
  • Zijn de gegevensstructuren gelijk in de bron en het doel? Vindt er normalisatie of denormalisatie plaats in het transformatieproces?
  • Voor hoeveel entiteiten wordt verwacht dat u delta's afhandelt? Wat is het complexiteitsniveau van het gegevensmodel voor deze entiteiten?
  • Welke complicaties kunnen er optreden als er afhankelijke onderliggende records moeten worden gemaakt of verwijderd voordat de bovenliggende record wordt gemaakt of verwijderd? Dergelijke aspecten zijn voor delta’s vaak complex.
  • Zijn er gegevenselementen die in beide systemen kunnen worden gewijzigd? Zo ja, hoe moeten conflicten dan worden opgelost als beide systemen wijzigingen hebben voor dezelfde record?

U kunt uw gegevensconversiescripts zo structureren dat deze een upsert-bewerking bevatten om zowel de initiële lading als de deltalading te verwerken. Met de upsert-bewerking kunt u uw conversiescript zo structureren dat hetzelfde script zowel nieuwe records als gewijzigde records kan verwerken. U hebt de GUID's van Dataverse nodig voor de upsert om al bestaande records bij te werken, anders worden er nieuwe records gemaakt. Voor de GUID's kunt u uw GUID's vooraf in uw code maken met behulp van een functie als NEWID() of u kunt de GUID vastleggen die is gemaakt door Dataverse en weer opslaan in uw doelfaseringstabel voor die record.

Best practices voor de implementatie van gegevensconversies

  • Gebruik de Bulkbewerkingen-API (preview) of Batch-API om de records in een set van 1000 in één keer te laden in plaats van de records één voor één te laden.
  • Verzend parallelle aanvragen: de beste resultaten worden bereikt als er niet meer dan twee threads tegelijkertijd worden uitgevoerd bij gebruik van de Bulkupdate-API. Als er meer dan twee threads worden gebruikt, kan de bewerking de fout retourneren dat de server bezet is en kan de bereikte doorvoer nooit beter zijn dan wat kan worden bereikt door twee threads te gebruiken.
  • Maak productieachtige gegevens voor ontwikkel- en testdoeleinden. De gegevens kunnen worden gegenereerd vanuit het productiesysteem en moeten worden gemaskeerd, versluierd of geanonimiseerd voordat ze voor ontwikkeling kunnen worden gebruikt. Met systeemtests met geconverteerde gegevens worden zoveel mogelijk problemen van tevoren geïdentificeerd. In dat geval kunnen testers, deskundigen en sprintteams meteen met de echte gegevens aan de slag.
  • Probeer pipelines voor parallelle uitvoering tot stand te brengen terwijl u rekening houdt met de sequentiële afhankelijkheden tussen tabellen om de doorvoer te maximaliseren.
  • Volg de gedeelde best practices om de prestaties voor bulkbewerkingen te optimaliseren.
  • Houd rekening met de API-limieten voor servicebescherming (Dataverse) in uw laadontwerp, zoals nieuwe uitvoeringen op basis van de API.
  • Er is een reeks tekens die niet kunnen worden opgeslagen in tekenreeks- of memokolommen. Bekijk dit artikel om de stappen te implementeren die nodig zijn om het probleem op te lossen.

Implementatie en ingebruikname

Na succesvolle implementatie- en testinspanningen kunt u de ingebruiknamefase uitvoeren door de overgangsactiviteiten en bedrijfsvalidatie te volgen.

Overgang en uitvoering

De overgangstijd waarin de productie-implementatie moet plaatsvinden, is van cruciaal belang in de implementatiestrategie. Als de gegevensmigratietijd de overgangstijd overschrijdt, kunt u een paar dagen vóór de ingebruikname met een volledige lading beginnen en tijdens het overgangstijdplan kunt u alleen de deltalading uitvoeren. Een deltalading vereist ontwerpoverwegingen voor het identificeren van gewijzigde en nieuwe records. Volg deze gedeelde best practices voor het overgangsplan en de uitvoering:

Zakelijke validatie

Tijdens overgangsactiviteiten is het van cruciaal belang om ervoor te zorgen dat de bedrijfsprocessen en gegevens worden gevalideerd voordat de toepassing wordt geopend voor gebruik voor andere gebruikers. Hier volgen enkele belangrijke bedrijfsvalidaties die in aanmerking moeten worden genomen:

  • Gegevensintegriteit: verifieer de nauwkeurigheid en volledigheid van de gegevensconversie en zorg ervoor dat essentiële hoofd- en transactiegegevens, zoals klantinformatie, financiële producten en financiële bezittingen correct worden overgedragen.

  • Procescontinuïteit: valideren dat kritieke bedrijfsprocessen, zoals het onboardingproces, naadloos en zonder verstoringen in de nieuwe omgeving kunnen worden uitgevoerd.

  • Beveiliging en toegangsbeheer: zorg ervoor dat gebruikersrollen en machtigingen correct zijn geconfigureerd om de gegevensbeveiliging en naleving van het organisatiebeleid te handhaven. Bevestig dat alleen geautoriseerd personeel toegang heeft tot gevoelige informatie.

  • Integratiepunten: valideer de integratie met andere systemen, indien van toepassing, om te bevestigen dat gegevens soepel tussen Dataverse en andere gegevensbronnen stromen, waarbij de gegevensconsistentie gehandhaafd blijft.

Best practices voor de ingebruikname van gegevensconversies

  • Volgorde: de laadvolgorde van de gegevens is belangrijk en in sommige gevallen mislukken records als ze niet correct zijn geordend. Records waarnaar wordt verwezen, moeten bestaan ​​als ze in een record als opzoekwaarde voorkomen. Ze moeten dus in de juiste volgorde worden geïdentificeerd en geladen.

  • Uitvoeringen van invoegtoepassing en Power Automate omzeilen: alle invoegtoepassingen/werkstromen/bedrijfsregels moeten worden uitgeschakeld tijdens de initiële gegevensmigratie. Als u invoegtoepassingen ingeschakeld laat, kan dit niet alleen van invloed zijn op de prestaties, maar ook op de integriteit van de gegevens. Voor deltaladingen hebt u misschien echter niet de luxe om aangepaste bedrijfslogica en automatiseringen uit te schakelen terwijl het systeem door de gebruikers wordt gebruikt. U kunt speciale optionele parameters doorgeven met uw laad-API-verzoeken om aangepaste invoegtoepassingen en Power Automate te omzeilen, zoals hier beschreven. Het gebruik van optionele parameters kan elk risico van onbedoelde gegevensgeneratie tijdens deltaladingen vanwege actieve invoegtoepassingen en Power Automate elimineren.

  • Herstelpunt en terugdraaiactie: er zijn meerdere opties voor het maken van back-ups en herstelacties (handmatige en systeemback-ups). On-demand back-ups moeten worden gemaakt voordat met de eerste laadoefening wordt begonnen. Als er fouten optreden tijdens de initiële lading, kan de instantie worden hersteld om de startmomentopname te overbruggen.

Zie ook

Volgende stappen