Van door AI geschreven code naar een werkende SAP-orderdesk

Een AI-codeassistent bouwt een applicatie snel. Die applicatie in de dagelijkse praktijk krijgen, vraagt meer dan werkende code.

Hij heeft toegang nodig tot bedrijfsdata. Medewerkers moeten kunnen inloggen. Hij moet ergens kunnen draaien, er moeten tools zijn om problemen te onderzoeken, en er moet een duidelijke route zijn waarlangs iemand anders hem kan overnemen.

Vijf eisen naast werkende code: bedrijfsdata, inloggen met een werkaccount, hosting, support en overdracht.

Deze walkthrough volgt dat hele proces, met een bekend voorbeeld: een orderdesk die de klantenservice helpt vragen over leveringen te beantwoorden met informatie uit SAP.

Wat we bouwen

Een klant vraagt: "Waar is mijn bestelling?"

Het antwoord staat in SAP S/4HANA, maar om het te vinden heb je soms meerdere schermen of de hulp van een collega nodig. Ondertussen wacht de klant.

Onze orderdesk brengt de relevante informatie samen in één applicatie:

Zoek op klant of ordernummer.
Bekijk openstaande verkooporders en de bevestigde leverdatum per regel.
Leg een datum vast die aan de klant is beloofd, met een notitie.
Mail een bevestiging en stuur een melding naar een Teams-kanaal als een belofte in gevaar komt.

De applicatie leest ordergegevens uit SAP via OData, een interface waarmee andere applicaties SAP-data kunnen opvragen. Beloftes en notities bewaart hij in zijn eigen database.

Die grens is belangrijk: SAP blijft de bron voor orders. De orderdesk is eigenaar van de extra informatie die de klantenservice vastlegt.

SAP levert orders, orderregels en leverschema's met alleen leestoegang. De orderdesk is eigenaar van beloftes aan klanten, notities en de activiteitengeschiedenis.

De eerste versie schrijft niets terug naar SAP. Dat maakt de integratie kleiner en het gesprek over toegang eenvoudiger. SAP bijwerken kan later, met de juiste rechten en controles.

Voor technische lezers: de applicatie heeft vier onderdelen, een frontend, een API die verzoeken afhandelt, een PostgreSQL-database en een onderdeel om met een werkaccount in te loggen. Een docker-compose.yml-bestand beschrijft hoe die onderdelen samen draaien.

Een docker-compose.yml-bestand beschrijft vier onderdelen van de applicatie: frontend, API, PostgreSQL en inloggen met een werkaccount.

1. Bepaal de taak voordat je AI laat bouwen

Drie beslissingen geven de codeassistent een bruikbaar startpunt.

Wat is de ene taak?

"Een medewerker van de klantenservice kan in de browser een vraag over een leverdatum beantwoorden zonder een collega te vragen."

Dat is specifiek genoeg om de eerste versie te sturen. Functies die daar niet aan bijdragen, kunnen wachten.

Wat leest de applicatie, en wat bewaart hij?

Orders, orderregels en leverschema's komen uit SAP. Beloftes, notities en de geschiedenis van wie ze vastlegde horen in de database van de applicatie.

Schrijf dit op. Anders doet de codeassistent misschien aannames over waar informatie hoort.

Wie probeert het als eerste?

Kies één medewerker van de klantenservice die het test en feedback geeft. Diens betrokkenheid beantwoordt vragen die een specificatie alleen zou missen.

2. Koppel je codeassistent aan Syntica

Syntica geeft je codeassistent tools om de applicatie te maken, te deployen en te beheren.

Begin met:

npx @syntica/mcp setup

Dit installeert de koppeling tussen je codeassistent en Syntica, met instructies om hem te gebruiken. Herstart de assistent na de installatie.

Begin in Claude Code in een lege projectmap met:

/syntica:onboard

Vraag in andere ondersteunde assistenten in gewone taal om het project bij Syntica te onboarden.

Onboarden logt je in, maakt de applicatie aan en koppelt de Git-repository, de plek met versiebeheer waar de code staat. Het bewaart ook de projectinstellingen die je assistent nodig heeft voor het verdere werk.

3. Brief de AI zoals je een developer zou briefen

Een goede briefing legt de taak, de data, de gebruikers en eventuele technische grenzen uit.

Bijvoorbeeld:

Bouw een orderdesk voor de klantenservice.
De taak: Medewerkers kunnen zoeken op klant of ordernummer, openstaande verkooporders zien met de bevestigde leverdatum per regel, en een beloofde datum met een notitie vastleggen.
De data: Lees verkooporders, orderregels en leverschema's uit SAP via OData. Schrijf nooit naar SAP. Bewaar beloftes en notities apart in PostgreSQL.
De gebruikers: Interne medewerkers van de klantenservice, ingelogd met hun werkaccount. Controleer welke gebruikers toegang moeten hebben en welke informatie ze mogen zien.
De applicatie: Gebruik een frontend, een API en PostgreSQL, met een docker-compose.yml-bestand dat de services beschrijft.
Stel me vragen over alles wat onduidelijk is voordat je de code schrijft.

Verwacht vragen. Wat telt als een openstaande order? Mag een belofte worden aangepast? Wat moet er gebeuren als SAP een bevestigde datum wijzigt?

Dat zijn bedrijfsregels. De AI kan helpen ze te bouwen, maar iemand die het proces begrijpt moet ze bepalen.

4. Geef de applicatie toegang tot SAP

De applicatie heeft een goedgekeurde SAP-koppeling nodig. Daarvoor hoort geen wachtwoord in het AI-gesprek te worden geplakt of in de repository te worden gecommit.

Vraag je assistent:

Welke koppelingen heeft deze app voor de dev-omgeving?

Syntica geeft de beschikbare koppelingen terug, en de namen van de instellingen die de applicatie krijgt als hij draait. Voor de SAP OData-connector zijn dat onder meer:

SAP_ODATA_URL
SAP_CLIENT
SAP_USER
SAP_PASSWORD

Dit zijn omgevingsvariabelen: instellingen met een naam die de draaiende applicatie krijgt. De tool die koppelingen opzoekt geeft hun namen terug, niet hun geheime waarden.

Een beheerder geeft via Syntica toegang tot een koppeling. De applicatie krijgt de inloggegevens als hij draait. De AI-assistent ziet bij het opzoeken alleen de namen van de instellingen.

Is er geen geschikte koppeling, dan kan de assistent er een aanvragen. Een beheerder geeft de applicatie dan toegang tot een passende SAP-koppeling.

Voor deze orderdesk heeft het SAP-account alleen leesrechten nodig op de benodigde orderservice.

Gebruik tijdens de ontwikkeling een test-SAP-systeem en geef apart toegang tot productie. De code kan in beide omgevingen dezelfde variabelenamen gebruiken.

Controleer de verbinding vroeg: de connector ondersteunt nu SAP-endpoints die publiek bereikbaar zijn. Een systeem dat alleen achter een bedrijfsfirewall bereikbaar is, kan hij niet bereiken.

5. Laat SAP zijn eigen data beschrijven

De codeassistent heeft de echte veldnamen en structuren nodig die je SAP-service gebruikt.

OData beschrijft die via een endpoint met de naam $metadata. Vraag de assistent om dat te gebruiken:

Lees de metadata van de OData-service en bouw de integratie
tegen de entiteiten en velden die daarin staan. Raad geen veldnamen.

De service kan bijvoorbeeld entiteiten aanbieden zoals A_SalesOrder en eigenschappen zoals ConfirmedDeliveryDate. Met de echte definities voorkom je dat je bouwt tegen namen die aannemelijk klinken maar niet kloppen.

Nog twee instructies die het waard zijn om mee te geven:

Vraag alleen de data op die nodig is. Filter en beperk resultaten in het verzoek aan SAP in plaats van elke order te downloaden en lokaal te zoeken.
Leg ontbrekende configuratie duidelijk uit. Is er geen SAP-koppeling beschikbaar, dan moet de applicatie dat zeggen in plaats van te falen met een onverklaarde fout.

Die details maken de applicatie efficiënt en makkelijker te ondersteunen.

6. Review en deploy een testversie

Vraag de assistent vóór de deploy om de code te controleren tegen de validatieregels van je organisatie.

Syntica stelt die regels beschikbaar aan de assistent, die problemen en voorgestelde oplossingen kan melden. Dit is een adviserende review: nuttig om problemen te vinden, maar geen vervanging voor testen of verplichte goedkeuringen.

Een verstandige regel is dat wachtwoorden, tokens en connection strings nooit in de repository mogen worden gecommit.

De assistent moet ook de deployconfiguratie controleren. Syntica gebruikt docker-compose.yml om de onderdelen van de applicatie te bouwen en te draaien. Een van de eisen is dat de applicatie antwoordt op zijn hoofd-URL, zodat het platform kan controleren of hij goed is opgestart.

Deploy in Claude Code met:

/syntica:deploy

De assistent pusht de code, start de build en meldt een live URL of details over wat er misging. Bij de eerste deploy kies je een instance-grootte, en die bepaalt de kosten.

Een eerste deploy kan een ontbrekende instelling of een opstartprobleem aan het licht brengen. Los het op en deploy opnieuw.

Het doel is een werkende testapplicatie die een geautoriseerde gebruiker in de browser kan openen.

7. Test de werkwijze met een echte gebruiker

Leg de applicatie voor aan de medewerker van de klantenservice die je eerder koos.

Zorg dat de juiste inlog- en toegangscontroles er zijn voordat je echte klantgegevens gebruikt. Begin met testdata of een geschikte SAP-testomgeving.

Loop daarna realistische vragen door:

Kunnen ze een order vinden met de informatie die een klant geeft?
Staat de leverdatum op het juiste niveau?
Is het verschil tussen een bevestigde en een beloofde datum duidelijk?
Begrijpen ze wat er gebeurde als SAP niet bereikbaar is?

Hier worden kleine details zichtbaar. Zoeken op een deel van de klantnaam kan belangrijker zijn dan een extra dashboard. De beloftes van gisteren laten zien kan nuttiger zijn dan nog een filter.

Gebruik die feedback als de volgende briefing voor de assistent.

8. Bereid productie voor

Productie is de omgeving waar mensen in hun dagelijkse werk op vertrouwen. Die heeft een eigen database, goedgekeurde koppelingen en iemand die het beheer op zich neemt.

Voor inloggen met een werkaccount levert de Microsoft Entra ID-connector van Syntica de benodigde identiteitsinstellingen. De applicatie heeft nog steeds een onderdeel nodig dat die instellingen gebruikt om het inloggen af te handelen.

Een optie is oauth2-proxy, een standaardonderdeel dat vóór de applicatie wordt gezet om te controleren of gebruikers zijn ingelogd. Je IT-team moet ook de nodige Microsoft-app-registratie en goedkeuringen regelen.

Voeg de mailkoppeling toe, zodat bevestigingen aan klanten via een goedgekeurde mailbox kunnen worden verstuurd.

Spreek vóór de lancering af wie de applicatie ondersteunt en welke afspraken over back-ups, herstel en beschikbaarheid het bedrijf nodig heeft.

9. Onderzoek problemen via je assistent

Draait de applicatie eenmaal, dan kan de assistent de tools van Syntica gebruiken om operationele vragen te helpen beantwoorden.

Vraag	Tool
Reageert de applicatie?	`app_health`
Welke fouten waren er onlangs?	`app_recent_errors`
Wat gebeurde er op een bepaald moment?	`app_search_logs`
Wat staat er in de database van de applicatie?	`app_db_query`

Databasequery's zijn standaard alleen-lezen en worden vastgelegd in een audittrail. Zo zijn onderzoeken makkelijker na te gaan.

Met deze tools heeft degene die de applicatie ondersteunt een praktisch startpunt als iemand een probleem meldt.

10. Een overdracht nodig?

Als de applicatie door een andere developer of een ander team onderhoudbaar moet zijn.

De overdracht bevat de broncode, de docker-compose.yml-configuratie en documentatie van de koppelingen die de applicatie verwacht.

Broncode, deployconfiguratie en documentatie van de koppelingen gaan naar het volgende team, dat de applicatie onderhoudt, host en uitbreidt.

Een nieuwe hostingomgeving moet die koppelingen leveren en de onderdelen van de applicatie ondersteunen. Standaard code en standaard deployformaten maken die overstap makkelijker.

Leg onderweg de bedrijfsregels en operationele stappen vast. De volgende beheerder moet begrijpen hoe de applicatie draait en waarom hij zich gedraagt zoals hij doet.

Klaar om het te proberen? Begin met de handleiding om met Syntica te starten.

Geschreven door Mees Rootjes