14/04/1999
At tilpasse et komplekst forretningssystem som Microsoft Dynamics 365 Finance and Operations (D365 F&O) kan virke som en skræmmende opgave. Mange virksomheder har unikke behov, der kræver felter og funktionalitet, som ikke findes i standardopsætningen. Heldigvis tilbyder D365 en robust og sikker metode til at foretage disse ændringer gennem udvidelser (extensions). Denne tilgang giver udviklere mulighed for at tilføje nye felter, logik og brugergrænsefladeelementer uden at røre ved Microsofts originale kode. Dette sikrer, at fremtidige opdateringer fra Microsoft kan installeres gnidningsfrit, uden at dine tilpasninger går i stykker. I denne omfattende artikel vil vi dykke ned i, hvordan du trin for trin kan tilføje et nyt felt til en eksisterende tabel og efterfølgende gøre det synligt på en formular for brugerne.

Hvorfor er udvidelser den foretrukne metode?
Før D365 F&O var det almindeligt at tilpasse systemet ved hjælp af en metode kaldet 'overlaying' (overlejring). Dette betød, at udviklere direkte ændrede i systemets standardkode (SYS-laget). Selvom det var effektivt på kort sigt, skabte det enorme udfordringer ved systemopgraderinger. Hver opdatering fra Microsoft risikerede at overskrive tilpasningerne, hvilket førte til tidskrævende og komplekse fletteprocesser og fejlfinding.
Med introduktionen af extensions-frameworket har Microsoft låst standardkoden. I stedet for at ændre den, bygger man nu ovenpå den. En udvidelse er en separat pakke af kode, der kompileres til sin egen fil (DLL). Denne fil 'hægter' sig på standardobjekterne og tilføjer den ønskede funktionalitet. Fordelene er markante:
- Opgraderingssikkerhed: Da basiskoden aldrig ændres, kan systemopdateringer installeres uden frygt for konflikter. Dine udvidelser fortsætter med at fungere, så længe de standardobjekter, de refererer til, stadig eksisterer.
- Vedligeholdelse: Det er langt nemmere at administrere, fejlfinde og spore tilpasninger, når de er isoleret i deres egne modeller og projekter.
- Stabilitet: Risikoen for at introducere fejl i systemets kernefunktionalitet er minimeret.
- Cloud-klar: Denne model er essentiel for et cloud-baseret system som D365, hvor Microsoft løbende udsender opdateringer.
Trin-for-trin: Tilføjelse af et brugerdefineret felt
Lad os gennemgå processen med et praktisk eksempel. Vi ønsker at tilføje et nyt tekstfelt kaldet 'Bemærkninger' (CustRemarks) til kundetabellen (CustTable) og vise det på kundens detaljeside.
Del 1: Oprettelse af en tabeludvidelse
Det første skridt er at udvide den tabel, hvor dataene skal gemmes. I vores tilfælde er det CustTable. Dette gøres ved at oprette en tabeludvidelse i Visual Studio.

- Opret en model og et projekt: Alt udviklingsarbejde i D365 F&O skal ske inden for en model, som er en del af en pakke. Hvis du ikke allerede har et passende projekt, skal du oprette et. Under oprettelsen af modellen er det vigtigt at referere til de standardpakker, du vil udvide, typisk 'Application Suite'.
- Find standardtabellen: Åbn 'Application Explorer' (AOT - Application Object Tree) i Visual Studio (findes under menuen 'View'). Naviger til Data Model > Tables, og find 'CustTable'.
- Opret udvidelsen: Højreklik på 'CustTable' og vælg 'Create extension'. Dette vil tilføje en ny fil til dit projekt, f.eks. CustTable.MyExtension.xml, i Solution Explorer under en ny mappe kaldet 'TableExtensions'.
- Tilføj det nye felt: Dobbeltklik på den nye udvidelsesfil for at åbne den i designeren. Du vil se en struktur, der ligner den originale tabel. Højreklik på 'Fields'-noden og vælg 'New' > 'String' for at tilføje et nyt tekstfelt.
- Konfigurer feltets egenskaber: Når feltet er oprettet (f.eks. med standardnavnet 'FieldString1'), skal du justere dets egenskaber i 'Properties'-vinduet:
- Name: Giv feltet et sigende navn, f.eks. 'CustRemarks'. Dette er det tekniske navn i databasen.
- Label: Angiv den tekst, som brugeren skal se. Brug en label for at understøtte flere sprog, f.eks. '@MinModel:CustomerRemarksLabel', eller skriv teksten direkte, f.eks. 'Bemærkninger'.
- Extended Data Type (EDT): Hvis det er relevant, kan du basere dit felt på en eksisterende EDT, f.eks. 'Description'. Dette sikrer konsistens i udseende og adfærd på tværs af systemet.
- Byg og synkroniser: Når feltet er konfigureret, skal du bygge dit projekt (højreklik på projektet i Solution Explorer > Build). Efter en succesfuld build skal du synkronisere databasen. Højreklik på projektet > Dynamics 365 > Synchronize database with project. Dette trin opretter fysisk den nye kolonne i SQL-databasen. Uden synkronisering eksisterer feltet kun i din kode.
Del 2: Visning af feltet på en formular
Nu hvor feltet findes i databasen, skal vi gøre det synligt for brugerne. Dette gøres ved at oprette en formularudvidelse for den relevante formular, i dette tilfælde kundedetaljeformularen (CustTable form).
- Find standardformularen: Gå tilbage til Application Explorer (AOT) og naviger til User Interface > Forms. Find formularen 'CustTable'.
- Opret formularudvidelsen: Højreklik på 'CustTable'-formularen og vælg 'Create extension'. En ny fil, f.eks. CustTable.MyExtension.xml, vil blive tilføjet dit projekt under 'FormExtensions'.
- Tilføj feltet til designet: Dobbeltklik på formularudvidelsen for at åbne den i designeren. I venstre side ser du formularens designstruktur (paneler, faner, grupper osv.). I højre side ser du formularens datakilder. Udvid datakilden 'CustTable', og find dit nye felt 'CustRemarks'.
- Placer feltet: Træk dit 'CustRemarks'-felt fra datakilden over til det ønskede sted i designet. Du kan f.eks. placere det i fanen 'General'. Visual Studio hjælper med at vise, hvor du kan placere feltet.
- Byg og test: Byg dit projekt igen (F6). Når det er færdigt, kan du køre formularen ved at højreklikke på den i Solution Explorer og vælge 'Set as Startup Object' og derefter trykke på Ctrl+F5. Naviger til en kundepost, og dit nye 'Bemærkninger'-felt skulle nu være synligt på den placering, du valgte.
Sammenligning: Overlejring vs. Udvidelser
For at understrege vigtigheden af den moderne tilgang, er her en tabel, der sammenligner den gamle metode (overlejring) med den nye (udvidelser).
| Funktion | Overlejring (Gammel Metode) | Udvidelser (Ny Metode) |
|---|---|---|
| Kodeændring | Ændrer direkte i Microsofts basiskode (SYS-laget). | Tilføjer funktionalitet i et separat, isoleret lag. |
| Opgraderingssikkerhed | Lav. Høj risiko for konflikter og ødelagte tilpasninger ved systemopdateringer. | Høj. Upåvirket af opdateringer til basiskoden. |
| Vedligeholdelse | Kompleks og tidskrævende. Svært at adskille standardkode fra tilpasset kode. | Nemmere at administrere, spore og fejlfinde i separate projekter. |
| Microsofts Anbefaling | Frarådes kraftigt og er ikke længere muligt for det meste af koden. | Den eneste anbefalede og understøttede metode. |
Bedste Praksis for Udvidelser
For at sikre, at dine tilpasninger er robuste og lette at vedligeholde, er det vigtigt at følge nogle grundlæggende principper:
- Følg navngivningskonventioner: Giv dine udvidelsesfiler og objekter et præfiks eller suffiks, der identificerer din organisation eller projektet. Dette forhindrer navnekonflikter. F.eks. MyPrefixCustTable.Extension.
- Undgå hårdkodning: Brug altid labels til tekst, der vises for brugeren, så systemet kan oversættes. Brug enums eller parametre i stedet for hårdkodede værdier i din logik.
- Hold det simpelt: Opret kun de udvidelser, du har brug for. Overkomplicer ikke ved at tilføje unødvendig funktionalitet.
- Test grundigt: Test altid dine ændringer i et dedikeret testmiljø, før de udrulles til produktion. Sørg for at teste både den nye funktionalitet og de omkringliggende standardprocesser for at sikre, at du ikke har introduceret utilsigtede bivirkninger.
Ofte Stillede Spørgsmål (FAQ)
Kan jeg ændre et felts datatype, efter det er oprettet?
Nej, når et felt er oprettet og databasen er synkroniseret, kan du ikke ændre dets grundlæggende datatype (f.eks. fra 'String' til 'Integer'). Du skal slette feltet og oprette det igen, hvilket kan medføre tab af data. Vælg derfor datatypen med omhu fra starten.
Hvad er forskellen på et 'Felt' og en 'Kolonne'?
I Dynamics 365-kontekst bruges disse termer ofte i flæng. Historisk har Microsoft brugt forskellige navne som 'Attribut', 'Felt' (Field) og nu 'Kolonne' (Column). Funktionelt set refererer de til det samme: en dataindgang i en tabel. I denne artikel har vi primært brugt 'felt'.

Er det altid nødvendigt at synkronisere databasen?
Ja, hver gang du foretager en ændring i en tabels struktur – såsom at tilføje, slette eller omdøbe et felt – skal du køre en databasesynkronisering. Dette sikrer, at den logiske definition af tabellen i AOT matcher den fysiske struktur i SQL-databasen.
Kan jeg tilføje flere felter i én tabeludvidelse?
Ja, du kan tilføje så mange felter, du har brug for, i den samme tabeludvidelsesfil. Det er god praksis at samle relaterede felter, der hører til den samme funktionalitet, i den samme udvidelse.
Konklusion
At tilpasse Dynamics 365 F&O ved hjælp af udvidelser er en kraftfuld og sikker metode. Ved at adskille dine tilpasninger fra Microsofts standardkode sikrer du en problemfri opgraderingsproces og en mere stabil og vedligeholdelsesvenlig løsning. Processen kan opdeles i to hovedtrin: Først oprettes en tabeludvidelse for at definere og gemme de nye data, og derefter oprettes en formularudvidelse for at præsentere dataene for brugeren. Ved at følge den trinvise vejledning og de bedste praksisser i denne artikel, kan du trygt forbedre og skræddersy din D365 F&O-implementering til at opfylde dine specifikke forretningsbehov.
Hvis du vil læse andre artikler, der ligner Tilføj nye felter i Dynamics 365: En guide, kan du besøge kategorien Teknologi.
