Aktiver Ændringssporing for Dataenheder i D365

I en moderne forretningsverden er evnen til effektivt at synkronisere data mellem forskellige systemer afgørende. Uanset om det er til business intelligence, integrationer med tredjepartssystemer eller dataarkivering, er udfordringen den samme: Hvordan identificerer vi og overfører kun de data, der har ændret sig, uden at belaste systemet unødigt? Dynamics 365 Finance and Supply Chain Management (D365FSCM) tilbyder en kraftfuld, indbygget funktion til netop dette formål: Ændringssporing (Change Tracking). Denne mekanisme gør det muligt for applikationer effektivt at spore dataændringer i en database, hvilket eliminerer behovet for komplekse, specialudviklede løsninger.

Historisk set har udviklere været nødt til at bygge deres egne sporingsmekanismer ved hjælp af en kombination af triggere, tidsstempler og separate logningstabeller. Disse løsninger var ofte arbejdskrævende at udvikle og vedligeholde. Heldigvis er denne funktionalitet nu standard i D365FSCM, hvilket gør processen både enklere og mere pålidelig. I denne artikel vil vi dykke ned i, hvad Ændringssporing er, hvordan det adskiller sig fra traditionel datalogning, og hvordan du kan konfigurere det til at optimere dine dataintegrationsprocesser.

Hvad er Forskellen på Ændringssporing og Datalogning?

For at forstå styrken ved Ændringssporing er det vigtigt at skelne det fra en anden velkendt funktion: Datalogning (Database Logging), også kendt som Change Data Capture. Selvom begge funktioner sporer ændringer, tjener de forskellige formål og besvarer forskellige spørgsmål.

• Datalogning (Change Data Capture) besvarer spørgsmålet: "Hvordan har en post ændret sig, og hvem foretog ændringen?"
• Ændringssporing (Change Tracking) besvarer spørgsmålet: "Hvilke poster har ændret sig siden sidste synkronisering?"

Datalogning er et kraftfuldt værktøj til revision og sikkerhed. Det fanger en detaljeret historik over alle ændringer, inklusive de mellemliggende værdier af et felt, og gemmer disse oplysninger i en logtabel (SysDatabaseLog). Dette er uvurderligt, når man skal spore, hvem der ændrede hvad og hvornår. Prisen er dog en potentiel betydelig indvirkning på systemets ydeevne, da hver logget ændring medfører en ekstra skriveoperation til databasen.

Ændringssporing, derimod, er designet til synkronisering. Det registrerer kun, at en post er blevet ændret (oprettet, opdateret eller slettet), uden at gemme de historiske data. Den seneste version af dataene hentes direkte fra den oprindelige tabel. Denne tilgang har en minimal indvirkning på ydeevnen og kræver langt mindre lagerplads, hvilket gør den ideel til scenarier, hvor data skal holdes synkroniseret med eksterne datavarehuse eller applikationer.

Sammenligningstabel

Typiske Anvendelsesscenarier for Ændringssporing

Ændringssporing er særligt værdifuldt i integrationsscenarier, hvor data skal flyttes fra D365FSCM til et andet system. De mest almindelige anvendelser er:

1. Bring Your Own Database (BYOD)

Dette er det primære scenarie for Ændringssporing. BYOD giver virksomheder mulighed for at eksportere dataenheder fra D365FSCM til deres egen Microsoft Azure SQL-database. Denne database kan derefter fungere som et datavarehus til BI-rapportering (f.eks. med Power BI), dataanalyse eller som en mellemlanding for integration med andre systemer. Ved at aktivere Ændringssporing kan du oprette et tilbagevendende dataeksportjob (Data Management project) med 'Incremental push' slået til. Første gang jobbet kører, udføres en fuld eksport for at etablere en baseline. Alle efterfølgende kørsler vil kun eksportere de poster, der er blevet ændret siden sidste kørsel, hvilket drastisk reducerer behandlingstiden og dataoverførslen.

2. Integration via OData og Dataverse

Selvom det er mest almindeligt at 'pushe' data ud af D365, er det også muligt for eksterne systemer at 'trække' ændringer. Dette kan gøres ved at forespørge på en dataenheds OData-endpoint. Når Ændringssporing er aktiveret for en enhed, kan en ekstern applikation inkludere en 'odata.track-changes' præference i sin API-anmodning. Svaret vil indeholde de ændrede data samt et 'delta link', som kan bruges i den næste anmodning til kun at hente ændringer, der er sket siden da. Dette mønster er især nyttigt i scenarier med Microsoft Dataverse virtuelle enheder.

Sådan Konfigurerer du Ændringssporing: En Trin-for-Trin Guide

Processen for at aktivere Ændringssporing er ligetil og foregår via Data Management-arbejdsområdet. Fremgangsmåden varierer en smule afhængigt af dit scenarie.

For BYOD-Scenarier

1. Naviger til arbejdsområdet Data management.
2. Vælg feltet Configure entity export to database.
3. Vælg den måldatabase, du vil eksportere til, og klik på Publish.
4. Find den enhed, du vil aktivere sporing for (du kan bruge 'Show published only' til at filtrere listen).
5. Marker enheden, og klik på Change tracking i handlingsbåndet.
6. Vælg en af de tre sporingsmuligheder (beskrevet nedenfor) og gem.

For Andre Scenarier (f.eks. Dataverse/OData)

1. Naviger til arbejdsområdet Data management.
2. Vælg feltet Data entities for at se listen over alle enheder.
3. Find og marker den enhed, du vil aktivere sporing for.
4. Klik på Change tracking i handlingsbåndet.
5. Vælg den ønskede sporingsmulighed og gem.

Forstå de Tre Sporingsmuligheder

Når du aktiverer Ændringssporing, skal du vælge, hvor granulært systemet skal spore ændringer. Der er tre muligheder, hver med sine fordele:

1. Enable primary table (Aktiver primær tabel)

Med denne indstilling vil en ændring kun blive registreret, hvis der sker en ændring i enhedens primære tabel (root data source). Ændringer i sekundære, join'ede tabeller vil ikke udløse en sporing. Dette er den mest performance-venlige mulighed, da den minimerer antallet af 'falske positiver'. Det er dog vigtigt at bemærke, at når en ændring er udløst, vil hele posten fra enheden blive eksporteret, inklusive data fra de sekundære tabeller. Brug denne mulighed, når de vigtigste forretningsdata findes i den primære tabel.

2. Enable entire entity (Aktiver hele enheden)

Dette er den mest omfattende og enkleste mulighed. Enhver ændring i enhver tabel, der er en del af dataenheden, vil udløse en sporing. Dette sikrer, at ingen ændringer overses, men kan potentielt føre til, at flere data eksporteres, end hvad der strengt taget er nødvendigt. For de fleste standardscenarier er dette et sikkert og godt valg.

3. Enable custom query (Aktiver brugerdefineret forespørgsel)

Denne avancerede mulighed giver en udvikler fuld kontrol over, hvad der skal udløse en ændring. Det kræver, at der tilføjes en specifik metode (`defaultCTQuery`) til dataenhedens X++-kode. I denne metode defineres en brugerdefineret forespørgsel, der specificerer præcis hvilke tabeller og felter, der skal overvåges. Dette er nyttigt i komplekse scenarier, f.eks. hvor en enhed er bygget på indlejrede visninger, eller hvor du kun ønsker at spore ændringer på et meget specifikt undersæt af data.

Vigtige Overvejelser og Begrænsninger

Inden du implementerer Ændringssporing, er der et par vigtige punkter at være opmærksom på:

• Sporing af Sletninger: Ændringssporing kan spore slettede poster, men denne funktionalitet er primært understøttet for BYOD- og Dataverse-scenarier. For andre ikke-BYOD-scenarier vil sletninger typisk ikke blive fanget. Desuden spores sletninger kun for enhedens rod-datakilde.
• Den Første Kørsel: Husk altid, at den første kørsel af et inkrementelt eksportjob vil være en fuld eksport. Systemet har brug for denne indledende fulde synkronisering for at etablere en baseline, som fremtidige ændringer kan sammenlignes med.
• Ydeevne: Selvom påvirkningen er minimal, er funktionen ikke helt gratis. For ekstremt transaktionstunge tabeller bør du stadig overveje, hvilken sporingsmulighed der er mest hensigtsmæssig for at undgå unødvendig behandling.

Ofte Stillede Spørgsmål (FAQ)

Hvad er den største fordel ved Ændringssporing sammenlignet med Datalogning?

Den absolut største fordel er ydeevnen. Ændringssporing har en minimal indvirkning på systemets daglige drift, fordi det kun registrerer, at en post er ændret, uden at gemme en detaljeret historik. Dette gør det til den ideelle løsning for scenarier med hyppig datasynkronisering.

Vil den første kørsel af et inkrementelt eksportjob kun eksportere ændringer?

Nej. Den første kørsel er altid en fuld eksport af alle poster i dataenheden. Dette er nødvendigt for at SQL kan etablere en reference, som efterfølgende ændringer kan måles op imod. Alle efterfølgende kørsler af jobbet vil være inkrementelle.

Kan jeg spore sletninger af poster med Ændringssporing?

Ja, men med visse begrænsninger. Sporing af sletninger understøttes fuldt ud for BYOD- og Dataverse-scenarier. Det er vigtigt at bemærke, at det kun er sletninger i enhedens rod-datakilde, der spores.

Hvilken sporingsmulighed skal jeg vælge?

Det afhænger af dit behov. Som en tommelfingerregel: Start med 'Enable entire entity' for enkelhedens skyld. Hvis du oplever, at der eksporteres for meget data på grund af ændringer i mindre vigtige tabeller, kan du skifte til 'Enable primary table' for at forbedre ydeevnen. 'Enable custom query' er forbeholdt komplekse scenarier, der kræver udviklerindgreb for at opnå granulær kontrol.

Ved at mestre Ændringssporing i D365FSCM kan du bygge robuste, effektive og skalerbare dataintegrationer, der holder dine systemer synkroniserede med minimal indsats og systembelastning.