AL-udvidelser i Business Central bliver ofte vurderet på, om de virker her og nu. Det er en for snæver målestok. Den rigtige test er, om løsningen stadig er til at forstå, teste, opdatere og drifte om 12 eller 24 måneder, når nye krav, nye brugere og nye platformopdateringer rammer.
Det er netop derfor, best practice for AL-udvikling handler lige så meget om lifecycle som om selve koden. En hurtig tilpasning kan være dyr, hvis den gør næste release usikker. En lidt mere disciplineret løsning kan til gengæld spare mange timer i test, support og fejlretning.
Tænk i produkt, ikke i enkeltstående tilretninger
En AL-udvidelse bør behandles som et lille produkt med sit eget liv: krav, design, udvikling, test, release, overvågning og løbende forbedringer. Den tankegang ændrer måden, man prioriterer på. Fokus flytter sig fra “kan vi få det med i denne uge?” til “kan vi få det med uden at skabe teknisk gæld?”
Det gælder især i virksomheder, hvor Business Central er tæt koblet til økonomi, lager, salg og rapportering. Her kan en lille ændring i validering, bogføring eller datamodel få konsekvenser flere steder. Derfor skal udvikling hænge sammen med governance, test og klare beslutninger om scope.
En god AL-løsning er sjældent den med flest linjer kode.
Værktøjer og miljø, der giver færre overraskelser
Det mest stabile udgangspunkt er et standardiseret udviklingsmiljø. Dokumentationen på learn.microsoft.com peger på Visual Studio Code med AL Language-udvidelsen som det naturlige centrum for arbejdet. Det giver et ens setup på tværs af udviklere og gør build, publicering og fejlsøgning mere forudsigelig.
Til selve miljøet vælger mange mellem en cloud sandbox og en lokal container. En sandbox er enkel at dele med projektteam og brugere, mens en container ofte giver hurtigere arbejdsgange under ren udvikling. Valget behøver ikke være enten eller. Mange teams får mest ro ved at kode lokalt og validere i en fælles sandbox, før noget sendes videre til test.
Det vigtigste er konsistens. Hvis hvert projektmedlem arbejder i sit eget setup uden fælles regler, bliver fejl svære at genskabe.
Efter en kort afklaringsfase bør værktøjskassen være fastlagt:
- Visual Studio Code med AL Language
- Git til versionsstyring
- sandbox eller container til udvikling
- CodeCop og relevante analyzers
- fælles scripts til build og publicering
Struktur og navngivning skal holde til vækst
Mange AL-projekter starter pænt og ender rodet. Det sker sjældent på dag ét. Det sker, når nye objekter bliver lagt ind uden tydelig struktur, fordi projektet har travlt. Derfor betaler det sig at vælge en mappestruktur tidligt, gerne efter funktionelle områder frem for kun objekttyper. Salg, lager, finans og integrationer giver som regel mere mening end én mappe til alle pages og en anden til alle codeunits.
Filnavne og objektnavne bør være lige så konsekvente. Retningslinjer fra learn.microsoft.com anbefaler, at filnavnet afspejler objektets navn og type. Det gør søgning, code review og fejlfinding langt lettere. Når navne er tilfældige, stiger tiden brugt på orientering i koden hurtigt.
PascalCase til objekter, metoder og variabler er en enkel regel, men den er vigtig. Samme princip gælder præfikser, så egne objekter er lette at skelne fra standardobjekter og fra tredjepartsapps.
Nogle få faste regler gør en stor forskel i praksis:
- Feature-mapper: saml filer efter forretningsområde, ikke kun efter objekttype
- Filnavne: lad navn og type følge objektet, så relationen er tydelig
- Prefixer: brug et entydigt præfiks på egne objekter og felter
- Dokumentation: skriv korte kommentarer til globale procedurer og vigtig logik
Udvikl med events og udvidelser, ikke med tunge indgreb
Business Central er skabt til udvidelser. Derfor bør tilpasninger tage udgangspunkt i tableextension, pageextension og event subscribers frem for løsninger, der forsøger at efterligne ændringer i basen. Det giver bedre opgraderbarhed og mindre friktion ved nye versioner.
En klassisk fejl er at lægge for meget logik direkte i sidehændelser eller i lange valideringsrutiner. Det virker i første omgang, men det gør test og genbrug sværere. En mere robust tilgang er at samle forretningslogik i codeunits og lade events kalde ind i dem. Så bliver ansvaret tydeligere fordelt.
Små mønstre betyder mere, end de ser ud til. Tidlige exit-kald kan gøre validering nemmere at læse. case-strukturer kan være mere forståelige end lange kæder af if. foreach passer ofte godt til gennemløb af samlinger og hjælper på læsbarheden.
Når logikken bliver mere kompleks, bør hvert stykke kode kunne besvare et enkelt spørgsmål: Hvad er formålet, og hvem ejer ansvaret for det?
Praktisk huskeregel: Hvis en ændring kræver mange afhængigheder på tværs af moduler, er designet ofte for tæt koblet.
Kvalitet, sikkerhed og performance skal bygges ind fra starten
Kvalitet i AL-projekter opstår ikke som sidste aktivitet før go-live. Den bliver lagt ind i hverdagen gennem analyzer-regler, pull requests, faste reviewpunkter og realistiske testdata. CodeCop bør være standard, ikke en ekstra luksus. Det samme gælder AppSource-regler, selv når appen ikke skal på AppSource. De fanger mange mønstre, der senere giver driftspres.
Sikkerhed starter med data. Felter med personoplysninger eller andre følsomme data skal klassificeres korrekt. DataClassification er ikke bare et teknisk felt i objektet. Det er en del af virksomhedens styring af data og compliance. Samtidig skal permissions være præcise, så udvidelsen ikke åbner bredere adgang end nødvendigt.
Performance er ofte en stille synder. En løsning kan fungere fint på et lille datasæt og blive tung, når virksomheden vokser. Derfor bør opslag, loops og datahentning vurderes tidligt. Kig efter unødige gentagelser, store gennemløb i UI-triggere og logik, der kunne flyttes til mere egnede steder i processen.
Telemetri er et stærkt værktøj her. Med Application Insights for extensions kan fejl og performanceproblemer spores hurtigere, end hvis alt først opdages via supporthenvendelser.
Test, branches og pipelines gør release mere rolig
Versionsstyring er fundamentet under hele lifecycle. Git giver historik, sporbarhed og et praktisk flow for samarbejde. Det gælder både små rettelser og større features. En enkel branchestrategi er ofte nok: en stabil hovedgren, feature branches til udvikling og pull requests før sammensmeltning. Det vigtigste er, at reglerne er kendt og efterlevet.
Pipelines bør tage over, så snart et projekt er mere end helt enkelt. Build, code analysis, pakning af .app-fil, publicering af artefakter og deployment til sandbox kan automatiseres i Azure DevOps eller GitHub Actions. Det sparer tid, men vigtigst af alt giver det ens releases. Man undgår personafhængige klikforløb og fejl i manuelle trin.
En .gitignore, der holder binære artefakter ude af repoet, bør være på plads fra starten. Secrets til deployment skal ligge i sikre variablegrupper eller i en vault-løsning, ikke i YAML-filer eller lokale scripts.
Et enkelt og robust releaseflow kan se sådan ud:
- Udvikling sker i en feature branch med lokal test.
- Build og analyzers kører automatisk ved pull request.
- Appen deployes til sandbox eller UAT til funktionel test.
- Godkendt release sendes videre til produktion med dokumenterede trin.
Versionering, deployment og rollback kræver disciplin
Hver release bør have et klart versionsnummer i app.json, tydelige release notes og en entydig reference til den build, der er sat i drift. Det lyder basalt, men mange teams mister overblikket netop her. Hvis man ikke hurtigt kan se, hvilken kode der ligger i produktion, bliver support og fejlsøgning langsommere end nødvendigt.
Deployment bør være forberedt som en kontrolleret aktivitet, ikke som en improviseret handling. Det gælder især ved ændringer i datamodel, integrationer og processer med bogføring. Her er det vigtigt at kende afhængigheder, plan for schema sync, test af opgraderingssti og eventuelle cutover-opgaver.
Rollback uden forberedelse er sjældent en rigtig rollback.
Derfor bør tidligere .app-artefakter gemmes, databackup være planlagt før større releases, og ændringer i data eller struktur være designet med omtanke. Platformen giver mulighed for at genudgive tidligere versioner, men det er kun nyttigt, hvis hele releaseforløbet er dokumenteret og testet.
Governance og brugerforankring er en del af udviklingen
Selv den pæneste AL-kode skaber ikke værdi, hvis brugerne ikke tager den i brug korrekt. Derfor skal udvikling kobles med workshops, afklaring af procesændringer, UAT og træning af superbrugere. Mange fejl opstår ikke i koden, men i uklar forventning til arbejdsgangen.
Det gælder især ved modernisering af ældre NAV- eller BC-løsninger, hvor virksomheden har gamle rutiner, manuelle genveje og lokale tilpasninger, som ingen rigtig ejer. Her er governance afgørende. Hvem kan bestille ændringer? Hvordan godkendes scope? Hvornår er noget en fejl, og hvornår er det et nyt ønske? Uden de svar vokser løsningen skævt.
En struktureret tilgang med små leverancer fungerer ofte bedre end store pakker. Brugerne kan teste tidligere, projektet får hurtigere feedback, og risikoen pr. release falder mærkbart. Den model passer godt til virksomheder, der ønsker kontrol over både budget, adoption og fremtidig vedligeholdelse.
Det er ofte her, erfarne Business Central-konsulenter gør den største forskel: ikke kun i koden, men i styringen omkring den.
Før næste sprint
Hvis en virksomhed vil løfte kvaliteten i sine AL-udvidelser, behøver den ikke starte med et stort transformationsprojekt. Gevinsten kommer ofte fra nogle få faste vaner: ens navngivning, branches med pull requests, analyzers i pipeline, tydelig releasehistorik og en reel plan for test og rollback.
Et godt næste skridt er at gennemgå den nuværende portefølje af udvidelser og stille enkle spørgsmål. Er strukturen forståelig for andre end den oprindelige udvikler? Kan en release gentages uden manuelle specialtrin? Bliver fejl fanget via telemetri, eller først når brugerne ringer? Svarene siger som regel meget om, hvor modent setup’et er, og hvor det giver mest mening at sætte ind først.