- Zorg voor toegang tot een Business Central-tenant met een sandboxomgeving.
- Installeer Visual Studio Code en de AL Language-extensie.
- Controleer of de gebruiker ontwikkel- en publicatierechten heeft in de sandbox.
- Leg Git-repository, object-ID-bereik en naamgevingsafspraken vast vóór de eerste extensie.
Een Business Central-ontwikkelaar is een specialist die standaardfunctionaliteit veilig uitbreidt zonder de basisapplicatie te wijzigen. De kern van moderne Business Central-development ligt in AL, extensies, events, bronbeheer, testen en een releaseproces dat rekening houdt met cloudupdates en tenant-specifieke eisen.
Dat maakt de opleiding anders dan klassieke ERP-ontwikkeling. Een ontwikkelaar schrijft niet zomaar code die lokaal werkt, maar bouwt een onderhoudbare app die door updates heen blijft functioneren, begrijpelijk is voor consultants en beheerders, en zonder verrassingen van sandbox naar productie kan gaan.
Wat een Business Central-ontwikkelaar echt moet kunnen
Microsoft Dynamics 365 Business Central ondersteunt processen zoals finance, verkoop, aankoop, voorraad, projecten en servicebeheer. Ontwikkelaars werken meestal aan uitbreidingen op die processen: extra velden, aangepaste pagina’s, rapporten, integraties, validaties of automatiseringen die aansluiten bij de manier waarop een organisatie werkt.
De praktische vaardigheid zit niet alleen in AL-syntaxis. Een goede ontwikkelaar begrijpt hoe data door Business Central stroomt, waar bedrijfslogica hoort te zitten, welke events beschikbaar zijn en hoe een extensie zich gedraagt wanneer Microsoft of een partnerapp een update krijgt. Daardoor verschuift de focus van “iets werkend krijgen” naar “iets maken dat beheerbaar blijft”.
Voor junior ontwikkelaars en technical consultants is dat vaak de grootste omslag. Wie uit C/AL of oudere NAV-omgevingen komt, moet wennen aan het feit dat base-object wijzigingen geen normaal ontwikkelpad meer zijn. In AL wordt functionaliteit toegevoegd via tableextension, pageextension, codeunits, events en permissiesets, met broncode in Git en publicatie naar een sandbox of tenant.
De ontwikkelomgeving: klein beginnen, correct opzetten
Een trainingsomgeving hoeft niet zwaar te zijn, maar ze moet wel lijken op de manier waarop Business Central in projecten wordt gebruikt. De basis bestaat uit Visual Studio Code, de AL Language-extensie, toegang tot een Business Central sandbox en rechten om extensies te publiceren. Ontwikkelaars hebben daarnaast baat bij een aparte Git-repository, zodat elke wijziging herleidbaar blijft.
Een veelvoorkomende fout is dat deelnemers meteen code beginnen schrijven zonder eerst runtime, target en dependency’s te controleren. In Business Central wordt veel bepaald door het bestand app.json. De waarden voor application, platform, runtime en target beïnvloeden of een project bouwt, publiceert en compatibel blijft met de tenant waarop het moet draaien.
Een mismatch tussen runtime en tenantversie kan leiden tot build- of publishfouten die weinig met de eigen code te maken hebben. Daarom hoort een opleiding niet alleen uit te leggen hoe men een project aanmaakt, maar ook hoe men versie-informatie leest, updatecycli opvolgt en bewust kiest tussen cloud- en on-premises-doelen.
Een eerste AL-extensie: van app.json tot event subscriber
Een concreet voorbeeld maakt duidelijk hoe Business Central-development verschilt van directe objectaanpassing. Stel dat een organisatie een extra klantclassificatie wil bewaren en bij het vrijgeven van een verkoopdocument een controle wil uitvoeren. De extensie voegt dan een veld toe aan de klantkaart en gebruikt een event subscriber om logica te koppelen aan een bestaand proces.
Onderstaand voorbeeld is bewust klein gehouden. Het toont drie onderdelen die in veel echte projecten terugkomen: metadata in app.json, een tableextension voor extra data en een pageextension om het veld zichtbaar te maken. Daarna volgt een event subscriber als patroon voor bedrijfslogica zonder base-object wijziging.
Example — eenvoudige klantclassificatie in AL
{
"id": "7f4c2c2a-2d51-4a9c-90b7-2f9d7a4d8101",
"name": "Customer Classification",
"publisher": "Contoso Belgium",
"version": "1.0.0.0",
"application": "24.0.0.0",
"platform": "24.0.0.0",
"runtime": "13.0",
"target": "Cloud"
}
Dit fragment toont de projectmetadata die Business Central gebruikt om de app te identificeren en te valideren. In teamprojecten wordt de versie doorgaans volgens semver-afspraken verhoogd, zodat releases, dependency’s en rollbackgesprekken minder ambigu worden.
Example — tableextension en pageextension
tableextension 50100 CustomerClassificationExt extends Customer
{
fields
{
field(50100; "Customer Classification"; Code[20])
{
Caption = 'Customer Classification';
DataClassification = CustomerContent;
}
}
}
pageextension 50101 CustomerCardClassificationExt extends "Customer Card"
{
layout
{
addlast(General)
{
field("Customer Classification"; Rec."Customer Classification")
{
ApplicationArea = All;
ToolTip = 'Specifies the internal customer classification used for reporting and validation.';
}
}
}
}
De extensie voegt data en gebruikersinterface toe zonder het standaardobject zelf aan te passen. In een opleiding is dit een belangrijk ontwerpprincipe: wijzigingen moeten bij voorkeur uitbreidbaar, testbaar en verwijderbaar blijven.
Example — bedrijfslogica via event subscriber
codeunit 50102 SalesReleaseSubscriber
{
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Release Sales Document", 'OnBeforeReleaseSalesDoc', '', false, false)]
local procedure CheckCustomerClassification(var SalesHeader: Record "Sales Header"; PreviewMode: Boolean)
var
Customer: Record Customer;
begin
if PreviewMode then
exit;
if SalesHeader."Sell-to Customer No." = '' then
exit;
if Customer.Get(SalesHeader."Sell-to Customer No.") then
if Customer."Customer Classification" = '' then
Error('Customer Classification must be filled before releasing the sales document.');
end;
}
Hier wordt logica gekoppeld aan een bestaand releaseproces via een event. Dat patroon is belangrijker dan de specifieke controle zelf, omdat events de onderhoudbaarheid verhogen en conflicten met platformupdates beperken.
Publiceren en debuggen gebeurt meestal vanuit Visual Studio Code met AL-opdrachten zoals package, publish en debug. In de praktijk hoort daar ook controle bij van launch-instellingen, tenantnaam, authenticatie en permissies. Een foutloos compileerbaar project is pas bruikbaar wanneer de app in een sandbox is gepubliceerd, functioneel getest en gecontroleerd door de gebruikers die het proces kennen.
PTE of AppSource-app: een keuze die vroeg moet vallen
Niet elke extensie heeft hetzelfde distributiemodel nodig. Een per-tenant extension past wanneer de oplossing voor één tenant wordt gebouwd, snel moet aansluiten op lokale processen en beheerd wordt binnen een specifieke klantcontext. Dat is gebruikelijk bij maatwerk voor kmo’s of interne IT-teams.
Een AppSource-app is logischer wanneer dezelfde oplossing voor meerdere tenants bedoeld is. Dan spelen extra eisen mee rond signing, validatie, dependencybeheer, supportafspraken, documentatie en releasecadans. Het technische verschil is dus ook een productbeslissing: wie later van PTE naar AppSource wil bewegen, moet vaak opnieuw nadenken over configuratie, object-ID’s, permissies, upgradecode en testdekking.
Een ontwikkeltraject zou deze keuze vroeg behandelen, omdat ze invloed heeft op architectuur en planning. Een snelle PTE kan verstandig zijn voor een duidelijk afgebakende klantbehoefte, terwijl een herbruikbare app vanaf het begin striktere ontwerpdiscipline vraagt.
Bronbeheer, naming en teamafspraken
Git is in Business Central-projecten meer dan een opslagplaats voor code. Het maakt zichtbaar waarom een wijziging is gedaan, wie ze heeft gereviewd en welke versie naar UAT of productie is gegaan. Feature branches en pull requests helpen vooral wanneer meerdere ontwikkelaars tegelijk aan objecten, events en tests werken.
Object-ID’s en naamgeving verdienen vroeg aandacht. Zonder afspraken ontstaan snel conflicten tussen extensies of verwarrende objectnamen die later moeilijk te refactoren zijn. In een professioneel project worden ID-reeksen, prefixen, dependency’s en versiebeleid vastgelegd voordat het team meerdere features tegelijk bouwt.
Ook permissies horen bij bronbeheer. Een extensie die lokaal werkt met brede ontwikkelrechten kan falen bij eindgebruikers als permissiesets ontbreken of te beperkt zijn. Daarom is het nuttig om permissies niet als nazorg te zien, maar als onderdeel van het ontwerp en de review.
Testbaarheid: sneller leveren door vroeger te controleren
Business Central ondersteunt geautomatiseerde tests met test codeunits en testlibraries. Voor ontwikkelaars is dat soms minder zichtbaar dan pagina’s of rapporten, maar het verschil wordt duidelijk zodra een extensie door meerdere releasegolven heen moet blijven werken.
Testbare AL-code gebruikt kleine procedures, voorspelbare data en zo weinig mogelijk verborgen afhankelijkheden. Temporary records helpen om testdata te isoleren, terwijl test codeunits scenario’s kunnen valideren zonder telkens handmatig door de interface te klikken. Dat versnelt CI/CD, omdat fouten eerder verschijnen dan tijdens UAT.
In projecten waar testen wordt uitgesteld, ontstaan vaak dezelfde problemen: regressies in verkoop- of boekingsprocessen, foutieve aannames over standaarddata en afhankelijkheden die pas na publicatie zichtbaar worden. Een opleiding die testen integreert in de eerste extensies bereidt ontwikkelaars beter voor op echte releasecycli dan een traject dat testen pas aan het einde noemt.
Van sandbox naar productie
De route naar productie begint meestal in een sandbox, gaat vervolgens naar een UAT-omgeving en eindigt pas daarna in productie. Elke stap heeft een andere vraag. In de sandbox draait het om technische validatie, in UAT om procesacceptatie en in productie om gecontroleerde uitrol met duidelijke rollback- en supportafspraken.
Versiebeheer in app.json speelt daarbij een praktische rol. Een nieuwe build moet herkenbaar zijn, dependency’s moeten kloppen en de productieomgeving moet weten of een upgradepad nodig is. Bij breaking changes of datamigraties hoort extra aandacht voor upgradecode en communicatie met functionele beheerders.
Prestatie en onderhoudbaarheid horen eveneens in deze fase. Ontwikkelaars vermijden zware berekeningen in interactieve processen wanneer achtergrondverwerking passender is, gebruiken query-objecten voor gerichte datavragen en passen technieken zoals SetAutoCalcFields bewust toe wanneer FlowFields nodig zijn. Het doel is niet alleen correcte functionaliteit, maar ook een oplossing die onder dagelijkse belasting voorspelbaar blijft.
Hoe MB-820 aansluit op de opleiding
MB-820, Microsoft Dynamics 365 Business Central Developer, richt zich op het bouwen, aanpassen en onderhouden van Business Central-oplossingen met AL. De exameninhoud is breder dan syntaxis: ontwikkelaars moeten ook kunnen omgaan met extensies, events, integraties, testen, troubleshooting en deploymentprincipes.
Een goede voorbereiding koppelt de examendomeinen aan praktische taken. Wie tableextensions, pageextensions, codeunits, interfaces, API’s en event subscribers alleen uit theorie kent, mist de projectcontext waarin keuzes echt tellen. Omgekeerd helpt praktijkervaring pas voor MB-820 wanneer ze wordt vertaald naar de concepten en terminologie die Microsoft in het examen gebruikt.
Een gestructureerde training kan daarom waardevol zijn voor ontwikkelaars die sneller verband willen leggen tussen AL-praktijk en examendoelen. Readynez behandelt dit onderwerp via de Microsoft Dynamics 365 Business Central Developer MB-820 course, terwijl bredere Microsoft-leerpaden te vinden zijn via Microsoft-trainingen en Unlimited Microsoft Training.
Voor wie deze leercurve het meest relevant is
De leercurve is geschikt voor ontwikkelaars die al basiskennis hebben van programmeren en bedrijfsapplicaties, maar nog moeten leren hoe Business Central zijn eigen regels, objectmodel en releasecadans hanteert. Ook technische consultants die functionele kennis hebben, kunnen doorgroeien wanneer ze voldoende aandacht besteden aan AL, Git en testbaarheid.
Voor projectleiders en solution owners ligt de waarde in betere inschattingen. Een kleine veldtoevoeging kan snel gaan, maar integraties, boekingslogica, performance-impact en AppSource-ambities veranderen de scope. Wie een ontwikkeltraject opzet, moet daarom niet alleen trainingsdagen plannen, maar ook sandboxtoegang, reviewmomenten, coding standards en een releaseproces voorzien.
Bij twijfel over instapniveau of de juiste opleidingsvorm is persoonlijk advies nuttig, zeker wanneer een team zowel junior developers als ervaren NAV- of Business Central-consultants bevat. Daarvoor kan contact worden opgenomen via contact met een opleidingsadviseur.
Veelgemaakte fouten bij AL-training
De meest hardnekkige fout is denken in oude aanpassingspatronen. Base-object wijzigingen, impliciete afhankelijkheden en handmatige fixes in een omgeving passen slecht bij moderne Business Central-development. Events, extensies en duidelijke dependency’s zijn niet alleen technische voorkeuren, maar voorwaarden voor onderhoudbaarheid.
Een tweede fout is dat permissies, runtime-instellingen en targetkeuze pas worden gecontroleerd wanneer publicatie mislukt. Dat kost tijd en verstoort het leerproces. Een korte startcontrole vóór de training voorkomt veel ruis: tenant en sandbox beschikbaar, VS Code correct ingericht, AL Language-extensie geïnstalleerd, rechten bevestigd en repository aangemaakt.
Een derde fout is dat functionele validatie te laat gebeurt. Business Central-code leeft dicht bij bedrijfsprocessen. Een wijziging die technisch juist is, kan toch verkeerd zijn als ze niet aansluit bij verkoop-, voorraad- of financeafspraken. Daarom werken goede oefeningen met herkenbare use-cases, bijvoorbeeld een extra klantclassificatie, een validatie in verkoopdocumenten of een rapportageveld dat door finance wordt gebruikt.
Een duurzaam leerpad kiezen
Business Central-development leren vraagt om herhaling in echte patronen: een extensie bouwen, publiceren, debuggen, testen, reviewen en gecontroleerd releasen. Wie dat proces meerdere keren doorloopt, ontwikkelt sneller oordeel over wat in AL thuishoort, wat functioneel moet worden opgelost en waar integratie of configuratie beter past.
De meest praktische volgende stap is het leerpad afstemmen op de rol. Een junior developer heeft vooral begeleiding nodig bij AL, objecten en debugging; een ervaren consultant moet vaak de sprong maken naar Git, tests en releasebeheer; een projectleider heeft inzicht nodig in afhankelijkheden, risico’s en acceptatie. Readynez kan daarbij helpen met een gericht gesprek over MB-820 en Business Central-development, zonder dat het leerpad losraakt van de projectrealiteit.
FAQ
Wat leert men in een Business Central Developer-training?
De training richt zich op AL-development voor Microsoft Dynamics 365 Business Central. Typische onderwerpen zijn extensies, tableextensions, pageextensions, codeunits, events, debugging, Git, testen, integraties en deployment naar sandbox- en productieomgevingen.
Welke voorkennis is nuttig vóór de start?
Basiskennis van programmeren, datamodellering en Business Central-processen helpt sterk. Deelnemers hoeven niet alles vooraf te beheersen, maar ze moeten wel toegang hebben tot een sandbox, Visual Studio Code kunnen gebruiken en begrijpen hoe bedrijfsprocessen zoals verkoop, aankoop of finance in grote lijnen werken.
Is C/AL-ervaring nog relevant?
C/AL-ervaring kan helpen om Business Central- en NAV-concepten te begrijpen, maar moderne ontwikkeling gebeurt met AL en extensies. Wie uit C/AL komt, moet vooral leren werken met events, app.json, Git, cloudcompatibiliteit en het vermijden van directe base-object wijzigingen.
Hoe verhoudt de training zich tot MB-820?
MB-820 toetst kennis en vaardigheden rond Business Central-development met AL. Training helpt door examendoelen te koppelen aan praktische taken zoals extensies bouwen, bedrijfslogica implementeren, integraties begrijpen, testen uitvoeren en deploymentproblemen analyseren.
Is er een certificering na de opleiding?
Een opleiding kan een bewijs van deelname of voltooiing geven, afhankelijk van de aanbieder. De Microsoft-certificering zelf wordt behaald via het officiële MB-820-examen en niet uitsluitend door een training te volgen.
