Dynamics 365: Vigtige Opdateringer i Version 8.0

Introduktionen af version 8.0 af Dynamics 365 for Finance and Operations markerede et afgørende vendepunkt for udviklere og virksomheder, der benytter platformen. Denne opdatering cementerede overgangen fra den traditionelle tilpasningsmetode med overlejring (overlayering) til en mere moderne og robust model baseret udelukkende på udvidelser (extensions). Denne ændring er ikke blot en teknisk detalje; den repræsenterer en fundamental ændring i filosofien bag, hvordan systemet skal tilpasses og vedligeholdes. Formålet er at skabe et mere stabilt, opdateringsvenligt og fremtidssikret ERP-system. I denne artikel dykker vi ned i de mest betydningsfulde ændringer, som version 8.0 introducerede, og hvad de betyder for dig, der arbejder med Dynamics 365.

Hard-Sealed Modeller: En Ny Æra for Tilpasning

Den mest markante ændring i version 8.0 er, at Microsoft har "hard-sealed" (hårdt forseglet) alle deres standard applikationsmodeller. Helt konkret betyder det, at det ikke længere er muligt at anvende overlejring på Microsofts standard kode. Ethvert forsøg på at gøre dette vil resultere i en kompileringsfejl. Denne beslutning tvinger udviklere til at omfavne udvidelsesmodellen fuldt ud.

Hvorfor denne drastiske ændring? Overlejring skabte betydelige udfordringer, især i forbindelse med opdateringer. Når Microsoft udgav en ny version af systemet, var virksomheder med omfattende overlejringer ofte nødt til at gennemgå en kompleks og tidskrævende proces med at flette deres tilpasninger med den nye standardkode. Dette øgede risikoen for fejl og forsinkede implementeringen af nye funktioner.

Med den nye model er tilpasninger adskilt fra standardkoden. De eksisterer som separate udvidelser, der "hægter sig på" standardfunktionaliteten. Dette gør opdateringsprocessen markant lettere og hurtigere. Hvis en udvidelse ikke er tilstrækkelig for en specifik tilpasning, er den eneste vej frem at indsende en anmodning til Microsoft om at gøre det pågældende område i standardapplikationen udvidelsesparat.

Nogle af de centrale modeller, der nu er forseglet, inkluderer:

• ApplicationSuite
• ApplicationCommon
• Directory
• GeneralLedger
• Ledger
• Tax
• SourceDocumentation
• Retail

Denne liste er ikke udtømmende, men den illustrerer bredden af de berørte områder. Den nye standard er klar: udvidelser er den eneste understøttede metode til tilpasning.

Forbedret Udvidelsesmulighed med Enumerations

For at understøtte den nye udvidelsesmodel har Microsoft gjort en lang række enumerations (opregningstyper) udvidelsesparate. En enumeration bruges ofte til at definere et fast sæt af værdier, f.eks. statusser på en ordre (Oprettet, Afsendt, Faktureret). Tidligere var det kompliceret at tilføje en ny, specialiseret status.

Nu kan en enumeration gøres udvidelsesparat ved at sætte to egenskaber:

1. IsExtensible sættes til Yes.
2. UseEnumValue sættes til No.

Dette gør det muligt for udviklere at tilføje nye værdier til en standard-enumeration gennem en udvidelse. Dette er en kæmpe fordel, da det giver større fleksibilitet uden at ændre i kernen af systemet. Mange steder i koden, hvor der tidligere blev kastet en undtagelse (throw exception) i default-casen af en switch-sætning, er dette blevet fjernet for at tillade, at ny logik kan tilføjes via hændelsesabonnementer (event subscriptions). Eksempler på enumerations, der er blevet gjort udvidelsesparate, er ProdFlushingPrincipBOM, SalesStatus og CustAccountStatement.

Refaktorering for Øget Fleksibilitet

En stor del af arbejdet i version 8.0 har været at refaktorere eksisterende kode for at gøre den mere åben for udvidelser. Et centralt fokusområde har været datametoder på tabeller som insert(), update() og delete().

I mange tilfælde kaldte disse metoder tidligere ikke super(), hvilket forhindrede udviklere i at bruge pre- og post-events til at tilføje logik før eller efter, at en post blev gemt i databasen. Dette er blevet rettet i et stort antal tabeller og klasser. Ved konsekvent at kalde super() er disse metoder nu blevet tilgængelige for udvidelser via Chain of Command (CoC), hvilket giver udviklere mulighed for at tilføje deres logik på en ren og understøttet måde.

Sammenligning af Tilpasningsmodeller

For at illustrere forskellen mellem den gamle og den nye metode, er her en sammenligningstabel:

Andre Væsentlige Ændringer

Ud over de ovennævnte hovedpunkter indeholder version 8.0 en lang række mindre, men stadig vigtige, forbedringer for at understøtte udvidelsesmodellen:

• Maps for udvidelse: Nye designmønstre er blevet introduceret for maps, hvilket gør det muligt at tilføje felter og metoder via udvidelser. Dette gælder for maps som CustVendSettlement og SalesPurchLine.
• Lagerdimensioner: Der er foretaget forbedringer i modellen for at tilføje nye lagerdimensioner, så flere scenarier nu kan håndteres via udvidelser. Mange formularer er blevet opdateret til at bruge feltgrupper til at vise dimensioner, hvilket gør det nemmere at tilføje nye.
• Klasser og metoder: Hundredvis af specifikke klasser og metoder er blevet refaktoreret for at understøtte udvidelsesmuligheder. Klasser som InventUpdate, SalesLineType, og PurchTableInteraction har fået tilføjet delegates eller er blevet ændret for at give adgang til medlemmer, hvilket åbner op for nye tilpasningsmuligheder.

Ofte Stillede Spørgsmål (FAQ)

Hvad betyder "hard-sealed" helt præcist?

Det betyder, at kildekoden for Microsofts standardmodeller er låst og ikke kan ændres direkte. Al tilpasning skal ske gennem udvidelser, der bygger oven på den forseglede kode.

Kan jeg stadig bruge overlejring på mine egne modeller?

Ja, du kan stadig anvende overlejring på dine egne modeller eller på modeller fra tredjepartsleverandører, hvis de ikke er forseglede. Det anbefales dog kraftigt at anvende udvidelsesmodellen overalt for at sikre konsistens og fremtidssikring.

Hvad gør jeg, hvis en udvidelse ikke er tilstrækkelig til min tilpasning?

I sådanne tilfælde skal du identificere det specifikke punkt i standardkoden, der blokerer for din tilpasning, og indsende en anmodning til Microsoft via de officielle kanaler om at gøre dette punkt udvidelsesparat (f.eks. ved at tilføje en delegate eller gøre en metode public/protected).

Hvorfor er disse ændringer vigtige for min virksomhed?

Disse ændringer fører til lavere samlede ejeromkostninger (TCO). Selvom det kan kræve en investering at omskrive gamle tilpasninger, resulterer det i et system, der er langt hurtigere og billigere at opdatere og vedligeholde. Det giver hurtigere adgang til nye funktioner og forbedrer systemets overordnede stabilitet.

Sammenfattende er Dynamics 365 for Finance and Operations version 8.0 en fundamental opdatering, der fuldender overgangen til en moderne, udvidelsesbaseret arkitektur. Selvom det kræver en tilpasning fra udviklere, er fordelene i form af stabilitet, vedligeholdelse og fremtidssikring indiskutable. Denne opdatering sikrer, at Dynamics 365 platformen forbliver robust og agil i en verden i konstant forandring.