Business Central-ontwikkeling betekent tegenwoordig veel meer dan oude objectaanpassingen en schermen visueel wijzigen. In moderne Business Central-projecten leidt die klassieke aanpak snel tot upgradeproblemen; de dagelijkse ontwikkelpraktijk draait om AL-extensies, events, testen en gecontroleerde deployment vanuit Visual Studio Code.
Microsoft Dynamics 365 Business Central is een ERP-platform voor processen zoals finance, verkoop, inkoop, service, projecten en voorraadbeheer. Voor ontwikkelaars is vooral relevant dat aanpassingen niet rechtstreeks in de basisapplicatie worden aangebracht, maar als extensies boven op de Base Application worden gebouwd. Daardoor kunnen organisaties sneller upgraden, wijzigingen beter isoleren en maatwerk onderhouden zonder elke release opnieuw te moeten herwerken.
Wat moderne Business Central-ontwikkeling inhoudt
De kern van Business Central-ontwikkeling is AL, de taal waarmee ontwikkelaars tabellen uitbreiden, pagina’s aanpassen, bedrijfslogica toevoegen, rapporten bouwen en integraties realiseren. AL-code staat in .al-bestanden, wordt beheerd in Git en wordt gepubliceerd naar een sandbox of productieomgeving als app-package. Die manier van werken lijkt meer op moderne softwareontwikkeling dan op klassieke ERP-aanpassing.
Een belangrijk verschil voor overstappers vanuit C/AL is dat directe wijzigingen in standaardobjecten plaatsmaken voor extensieobjecten. Een tabel wordt uitgebreid met een tableextension, een bestaande pagina met een pageextension, en standaardprocessen worden bij voorkeur beïnvloed via events. De ontwikkelaar downloadt symbolen uit de omgeving, waardoor de code kan verwijzen naar objecten en events uit de Base Application zonder de basiscode te wijzigen.
De praktische workflow begint meestal met een project in Visual Studio Code. In app.json staan onder meer de app-id, naam, uitgever, versie, platform- en application-versie en eventuele dependencies. In launch.json staat hoe Visual Studio Code verbinding maakt met een Business Central-sandbox, bijvoorbeeld een cloud sandbox voor SaaS-ontwikkeling of een container/on-prem-omgeving voor lokale scenario’s. Daarna volgen symbolen downloaden, ontwikkelen, debuggen, publiceren en installeren.
De ontwikkelomgeving in Visual Studio Code
Een werkbare Business Central-ontwikkelomgeving bestaat uit Visual Studio Code, de AL Language-extensie, toegang tot een Business Central-sandbox en broncodebeheer met Git. In SaaS-scenario’s werkt de ontwikkelaar vaak tegen een cloud sandbox die de productierelease volgt. Bij on-premises projecten kan debugging dieper in de infrastructuur grijpen, maar dat vraagt ook meer beheer rond service tiers, licenties, databaseversies en runtimeconfiguratie.
Git is in deze workflow geen administratieve bijzaak. Feature branches maken het mogelijk om afzonderlijke wijzigingen te isoleren, pull requests helpen bij review, en versie-tags geven grip op releases. In veel teams ontstaat vertraging doordat AL-projecten wel in Git staan, maar zonder duidelijke branchingstrategie, zonder consistente object-id ranges of zonder afspraken over dependencies tussen apps. Die problemen worden zichtbaar zodra meerdere ontwikkelaars aan dezelfde klantoplossing werken.
Een eenvoudige lifecycle voor een AL-app bestaat uit projectconfiguratie, symbolen downloaden, objecten ontwikkelen, lokaal of in de sandbox testen, package bouwen en publiceren. Voor productie hoort daar releasebeheer bij: semantische versies, upgrade codeunits voor datamigratie, en een duidelijk onderscheid tussen hotfixes, functionele releases en technische refactoring. Zonder dat onderscheid worden Business Central-apps moeilijk te ondersteunen na meerdere maandelijkse platformupdates.
AL-objecten in de praktijk
Een eerste nuttige oefening is het uitbreiden van een standaardtabel en het zichtbaar maken van het veld op een bestaande pagina. Dit voorbeeld voegt een klantreferentie toe aan de klantkaart zonder de standaard Customer-tabel direct aan te passen.
Example — tableextension en pageextension voor klantgegevens
tableextension 50100 CustomerTrainingExt extends Customer
{
fields
{
field(50100; "Loyalty Reference"; Code[20])
{
Caption = 'Loyalty Reference';
DataClassification = CustomerContent;
}
}
}
pageextension 50101 CustomerCardTrainingExt extends "Customer Card"
{
layout
{
addlast(General)
{
field("Loyalty Reference"; Rec."Loyalty Reference")
{
ApplicationArea = All;
ToolTip = 'Specifies the customer loyalty reference.';
}
}
}
}
Dit laat zien hoe extensies standaardobjecten uitbreiden zonder de basisapplicatie te wijzigen. In een echt project hoort hier ook een permissieobject bij, zodat gebruikers het nieuwe veld mogen lezen of aanpassen. Een veelgemaakte fout is dat ontwikkelaars de functionaliteit bouwen en testen met ruime ontwikkelrechten, maar pas laat ontdekken dat eindgebruikers onvoldoende permissies hebben.
Business logic hoort in AL zo veel mogelijk aan te sluiten op bestaande events. Daarmee blijft de code losser gekoppeld aan de standaardapplicatie en wordt de kans kleiner dat een platformupdate maatwerk breekt. Events zijn geen vrijbrief om overal code aan te hangen; in performance-kritieke paden, zoals posting of bulkverwerking, kan een event subscriber merkbare vertraging veroorzaken als er onnodige databaseaanroepen in staan.
Example — event subscriber zonder basiscode aan te passen
codeunit 50102 CustomerValidationSubscriber
{
[EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterValidateEvent', 'Name', false, false)]
local procedure CustomerNameOnAfterValidate(var Rec: Record Customer; var xRec: Record Customer; CurrFieldNo: Integer)
begin
if Rec.Name = xRec.Name then
exit;
Rec."Loyalty Reference" := CopyStr(UpperCase(Rec.Name), 1, MaxStrLen(Rec."Loyalty Reference"));
end;
}
De subscriber reageert op een validatie-event van de Customer-tabel en vult een veld op basis van de klantnaam. In productie zou dezelfde techniek eerder worden gebruikt voor controles, aanvullende defaults of koppelingen met een integratieproces. De leerwaarde zit vooral in het patroon: aansluiten op een event, de standaardcode ongemoeid laten en de wijziging klein genoeg houden om te testen.
Rapporten blijven belangrijk, ook wanneer veel managementinformatie inmiddels via Power BI loopt. Business Central-rapportobjecten zijn geschikt voor documenten, exports en operationele overzichten dicht bij de transactiegegevens. Voor bredere analyse is Power BI vaak logischer, zeker wanneer Business Central-data gecombineerd worden met verkoop-, service- of magazijnbronnen; een gerelateerd startpunt is de bestaande uitleg over Microsoft-trainingen rond Dynamics en Power Platform.
Example — eenvoudig report-object op klantdata
report 50103 "Customer Loyalty Export"
{
UsageCategory = ReportsAndAnalysis;
ApplicationArea = All;
ProcessingOnly = true;
dataset
{
dataitem(Customer; Customer)
{
trigger OnAfterGetRecord()
begin
if "Loyalty Reference" = '' then
CurrReport.Skip();
end;
}
}
}
Dit report-object verwerkt alleen klanten met een ingevulde loyaliteitsreferentie. Het voorbeeld is bewust klein: in echte rapporten komt daar een RDLC- of Word-layout, filtering via request page en afspraken over performance bij. Wie rapportlogica te veel gebruikt voor datatransformatie, kan beter heroverwegen of een query-object, API-page of Power BI-model passender is.
Kwaliteit: analyzers, tests en regressie
Professionele AL-ontwikkeling stopt niet bij een app die compileert. Code analyzers zoals CodeCop, AppSourceCop en PerTenantExtensionCop helpen om naamgeving, verouderde patronen, AppSource-eisen en tenant-specifieke aandachtspunten vroeg te signaleren. AppSourceCop is vooral relevant voor apps die via AppSource verspreid worden, terwijl PerTenantExtensionCop beter past bij klantgerichte extensies.
Het AL-testframework maakt het mogelijk om test codeunits te schrijven voor bedrijfsregels, posting-scenario’s en regressies rond maatwerk. In praktijk worden tests vaak te laat toegevoegd, meestal nadat een upgrade al iets heeft gebroken. Een verstandiger patroon is om testcode mee te laten groeien met elke feature, vooral bij boekingslogica, integraties, prijsberekeningen en datamigraties.
Voor geautomatiseerde regressietests kan BCTest worden ingezet in build- of releaseprocessen. Dat vraagt wel discipline rond testdata: tests moeten herhaalbaar zijn, niet afhankelijk van handmatige sandboxinstellingen en duidelijk falen wanneer een businessregel verandert. De grootste winst zit niet in het aantal tests, maar in het afdekken van processen waar een klein defect direct financiële of operationele gevolgen heeft.
CI/CD en releasebeheer voor Business Central-apps
CI/CD brengt Business Central-ontwikkeling dichter bij reguliere softwaredelivery. Met AL-Go for GitHub of Azure DevOps pipelines kan een team automatisch builds uitvoeren, analyzers draaien, testsets starten, artifacts bewaren en packages naar een sandbox deployen. Daardoor worden compileerfouten en regressies zichtbaar voordat een consultant of klant ze in acceptatie vindt.
Versiebeheer is hierbij meer dan een nummer in app.json. Semantische versies geven aan of een release een kleine fix, nieuwe functionaliteit of een breaking change bevat. Wanneer tabellen veranderen, velden verdwijnen of data moet worden omgezet, zijn upgrade codeunits nodig om bestaande tenants veilig naar de nieuwe versie te brengen. Dit is vaak het punt waarop experimentele maatwerkapps volwassen moeten worden: zonder upgradepad wordt elke release risicovol.
Deployment verschilt per doel. Een Per-Tenant Extension past bij klantspecifiek maatwerk met directe governance binnen één tenant. Een AppSource-app past beter bij ISV-scenario’s en bredere distributie, maar vraagt extra aandacht voor Microsoft-validatie, versiebeleid, afhankelijkheden, entitlements en supportafspraken. Wie deze keuze te laat maakt, ontdekt vaak dat objectstructuur, permissies en dependency-keuzes opnieuw moeten worden ingericht.
Performance, permissies en integraties
Business Central-extensies draaien dicht op bedrijfsprocessen, waardoor performancekeuzes snel merkbaar zijn. Onnodig gebruik van SetAutoCalcFields, herhaalde reads in loops, zware event subscribers tijdens posting en brede filters op grote tabellen kunnen de gebruikerservaring verslechteren. Temporary records, query-objecten, efficiënte keys en achtergrondverwerking via Task Scheduler of background sessions kunnen helpen, mits ze bewust worden toegepast.
Permissies verdienen dezelfde aandacht als codekwaliteit. Een AL-app kan functioneel correct zijn en toch falen bij acceptatie omdat eindgebruikers geen toegang hebben tot nieuwe tabellen, pagina’s of acties. Daarom horen permission sets, entitlement-denken en security-review bij de ontwikkeltaak, vooral wanneer extensies gevoelige financiële of klantdata verwerken.
Integratie met Power Platform is inmiddels een normaal onderdeel van Business Central-projecten. Power Automate kan processen starten op basis van gebeurtenissen of API’s, Power BI kan rapportage buiten operationele schermen brengen, en Dataverse kan nuttig zijn wanneer Business Central onderdeel is van een breder Dynamics 365-proces. De technische keuze moet volgen uit het gebruiksscenario: real-time boekingslogica hoort meestal niet in een flow, terwijl goed afgebakende workflowstappen of notificaties daar vaak juist geschikt voor zijn.
Training en MB-820 in perspectief
Een goed leerpad voor Business Central-development begint niet met examenvoorbereiding, maar met het bouwen van kleine, werkende extensies. Eerst komt de basis: AL-syntax, objecttypes, symbolen, debugging en Git. Daarna volgen events, API’s, rapportage, permission sets, tests en deployment. Pas wanneer die onderdelen in samenhang worden begrepen, wordt MB-820 een nuttig ijkpunt in plaats van een losse examenoefening.
MB-820, Microsoft Dynamics 365 Business Central Developer, richt zich op het ontwikkelen, testen en onderhouden van Business Central-extensies. Een training zoals de Readynez MB-820 Business Central Developer training kan helpen om die onderwerpen gestructureerd te oefenen, vooral voor ontwikkelaars die van C/AL overstappen of technische consultants die hun AL-praktijk willen professionaliseren. Microsoft Learn blijft daarnaast een nuttige bron voor actuele examendetails, AL-taalreferentie, events en het testframework.
Veelgemaakte fouten bij de overstap naar AL
De overstap naar moderne AL-ontwikkeling gaat vaak mis wanneer oude ERP-gewoonten worden meegenomen naar een extensiemodel. De meest terugkerende problemen zijn directe aannames over standaardgedrag, te weinig testautomatisering en onvoldoende aandacht voor releasebeheer. Juist bij Business Central SaaS worden die fouten sneller zichtbaar omdat updates regelmatig binnenkomen.
- Standaardfunctionaliteit proberen te vervangen in plaats van uit te breiden via tableextensions, pageextensions en events.
- Permission sets, analyzers en test codeunits pas toevoegen nadat de functionaliteit al is gebouwd.
- Geen onderscheid maken tussen Per-Tenant Extensions en AppSource-apps bij dependencies, validatie en support.
- Performance pas onderzoeken wanneer gebruikers vertraging merken in posting, lijsten of rapporten.
Een praktisch leerritme is om elke nieuwe feature te behandelen als een kleine release. De ontwikkelaar maakt een branch, past objecten aan, schrijft minimaal één relevante test, draait analyzers, publiceert naar een sandbox en documenteert de functionele wijziging. Zo ontstaat training die direct aansluit op het werk in klantprojecten.
Waar deze vaardigheden samenkomen
Business Central-development vraagt om een combinatie van ERP-inzicht en softwarediscipline. AL-objecten, events en rapporten vormen de technische basis, maar de waarde ontstaat pas wanneer code veilig upgradebaar is, goed getest wordt en past bij de manier waarop gebruikers hun processen uitvoeren. Dat maakt moderne Business Central-ontwikkeling geschikt voor developers, technische consultants en ISV-teams die maatwerk willen leveren zonder de onderhoudbaarheid op te offeren.
Wie verder wil bouwen aan Microsoft-vaardigheden kan naast een gerichte MB-820-route ook kijken naar Unlimited Microsoft Training wanneer meerdere Microsoft-onderwerpen relevant zijn binnen hetzelfde ontwikkel- of consultantprofiel. Voor vragen over een passend leerpad of certificeringsroute is er ook de mogelijkheid om contact op te nemen.
FAQ
Wat moet een Business Central developer vandaag leren?
Een Business Central developer moet AL in Visual Studio Code leren, inclusief extensieobjecten, events, debugging, Git, permission sets, rapporten, API’s, test codeunits en deployment naar sandbox- en productieomgevingen. Voor professionele projecten horen analyzers, CI/CD en upgradebeheer daar ook bij.
Is C/AL-kennis nog nuttig voor Business Central-ontwikkeling?
C/AL-kennis kan helpen om oudere oplossingen en functionele patronen te begrijpen, maar moderne ontwikkeling gebeurt met AL-extensies. De belangrijkste omslag is dat standaardobjecten niet direct worden aangepast; maatwerk wordt geïsoleerd in extensies en sluit aan op events en beschikbare symbolen.
Wanneer is MB-820 relevant?
MB-820 is relevant voor ontwikkelaars en technische consultants die Business Central-extensies willen ontwikkelen, testen en onderhouden. Het examen is vooral zinvol nadat iemand ervaring heeft opgedaan met AL-projecten, Visual Studio Code, events, debugging en de basis van releasebeheer.
Wat is het verschil tussen een Per-Tenant Extension en een AppSource-app?
Een Per-Tenant Extension is bedoeld voor klantspecifiek maatwerk binnen één tenant. Een AppSource-app is bedoeld voor bredere distributie en vraagt aanvullende aandacht voor validatie, versiebeleid, dependencies, entitlements en ondersteuning over meerdere klanten heen.
Hoe kan een team Business Central-extensies betrouwbaarder opleveren?
Betrouwbaarder opleveren begint met Git, duidelijke branches, analyzers, test codeunits en publicatie naar een sandbox vóór productie. In volwassenere teams worden builds, tests en artifacts geautomatiseerd via AL-Go for GitHub of Azure DevOps pipelines.
