Business Central-udvikling handler sjældent om at skrive meget kode. Det handler om at skrive den rigtige kode det rigtige sted, så jeres tilpasninger overlever, når Microsoft opdaterer systemet. Her er de valg, der afgør, om jeres udvidelser bliver en fordel eller en byrde.
Kernen i det
- Al tilpasning sker i udvidelser skrevet i AL. Standardapplikationen røres ikke.
- Vælg en per-tenant-udvidelse til det, der kun gælder jer, og en AppSource-app, når problemet er fælles for mange.
- Microsoft udgiver to store opdateringer om året. Jeres udvidelser skal testes mod den næste, før den rammer produktion.
- Integrationer bygges på API’er og Power Automate, ikke på direkte adgang til databasen.
- Gamle NAV-tilpasninger skal ikke flyttes én til én. Mange af dem findes i standarden i dag.
- Kildekoden skal ligge hos jer. Ellers ejer I ikke jeres system.
Business Central-udvikling sker i udvidelser
I NAV kunne en udvikler rette direkte i standardkoden. Det var hurtigt den dag, og dyrt ved hver opgradering, fordi hver rettelse skulle flettes ind i hånden. Efter nogle år lod mange virksomheder være med at opgradere.
Business Central online tillader det ikke. I stedet lægger man udvidelser ovenpå: nye felter via tabeludvidelser, ændrede skærmbilleder via sideudvidelser, og ny logik via hændelser, som standardkoden selv sender. Udvidelsen lytter og reagerer. Standarden forbliver uændret, og derfor kan Microsoft opdatere den.
Mangler der en hændelse dér, hvor I skal ind, så kopiér ikke standardlogikken over i jeres egen kode. Find en anden vej, eller bed Microsoft om hændelsen. Kopieret standardkode er en af de hyppigste årsager til fejl efter en opdatering.
Per-tenant-udvidelse eller AppSource-app
En per-tenant-udvidelse er bygget til én virksomhed og installeres kun hos jer. Det er det rigtige valg til jeres egne arbejdsgange, rapporter og regler.
En AppSource-app er et færdigt produkt, som mange bruger. Se efter en app, før I får noget udviklet. Til gengæld skal I acceptere leverandørens måde at gøre tingene på, og I er afhængige af, at den bliver holdt opdateret.
En god tommelfingerregel: køb det, der er standard i jeres branche, og byg det, der gør jer forskellige.
To store opdateringer om året
Microsoft udgiver en stor version af Business Central om foråret og en om efteråret, med mindre opdateringer imellem. I kan udskyde inden for et vindue, men ikke springe over. Det betyder, at Business Central-udvikling aldrig er færdig den dag, udvidelsen går i drift.
Tre ting holder udvidelserne opgraderingssikre. Brug kun de dele af standarden, som Microsoft har gjort tilgængelige. Hold øje med advarsler om forældede objekter i compileren, for de bliver til fejl i en senere version. Og test mod den kommende version i et sandkassemiljø, så snart den er tilgængelig som forhåndsversion. Det er rutinearbejde, og det hører til løbende vedligeholdelse, ikke til et nyt projekt hver gang.
Integrationer uden genveje
Business Central har standard-API’er til de mest brugte data, og egne API-sider kan bygges i en udvidelse. Power Automate dækker de enkle flows.
Skal data flyde til en webshop, et lager eller et CRM, er integrationen ofte den største opgave. Den kræver fejlhåndtering, logning og en aftale om, hvilket system der ejer hvilke data. Det er API-udvikling i egentlig forstand, og det skal planlægges som det. Bruger I også Dynamics 365 til salg, hjælper Dynamics 365-udviklere, der kender begge sider.
Fra NAV og C/AL til udvidelser
Står I med en ældre NAV-løsning, så lad være med at konvertere alt. Gennemgå tilpasningerne og spørg, om de stadig bruges, og om standarden kan det samme i dag. Ofte kan mange slettes.
Det, der er tilbage, skal skrives om som udvidelser, ikke bare oversættes. Værktøjer kan konvertere C/AL til AL, men resultatet er gammel logik i ny syntaks. Data skal også flyttes og kontrolleres, og det er ofte her, tidsplanen skrider. Planlæg det fra starten som databaseudvikling og datamigrering.
Test og ejerskab af koden
AL har sit eget testværktøj, og automatiske tests er den billigste forsikring mod fejl efter en opdatering. Kør dem ved hver ændring og ved hver ny version fra Microsoft.
Kildekoden skal ligge i et versionsstyret repository, som I har adgang til. Har en tidligere partner kun leveret app-filen, kan ingen andre videreudvikle den. Er I i tvivl om kvaliteten af det, I har, er en kodeaudit et godt første skridt.
Ofte stillede spørgsmål
Ikke i Business Central online. Al tilpasning sker i udvidelser, der bygger ovenpå standarden. Det er netop det, der gør opdateringerne mulige uden et stort opgraderingsprojekt.
Begge er skrevet i AL. En per-tenant-udvidelse er lavet til én virksomhed, en AppSource-app er et produkt, mange installerer.
Er de bygget på de tilgængelige hændelser og objekter, kører de typisk videre. Test dem alligevel i en sandkasse først.
Ikke direkte. De skal skrives om som udvidelser. Start med at finde ud af, hvilke I stadig bruger, og hvilke standarden allerede dækker.
Kort fortalt
Tilpas med udvidelser, rør aldrig standarden, test mod hver ny version, byg integrationer på API’er, og hold kildekoden hos jer selv. Så bliver Business Central-udvikling en investering, der holder, i stedet for en regning ved hver opdatering. Læs mere om vores Business Central-udviklingstjenester.
Vil I have et blik på jeres udvidelser eller en NAV-løsning, der skal videre? Skriv til os eller book et møde.
