Koppelen met IBM i en AS400

Wat we wel en niet doen

Hier zijn we graag duidelijk over, want het scheelt je een verkeerd gesprek.

Wij zijn geen RPG- of COBOL-ontwikkelaars. We programmeren niet op de IBM i en we beheren hem niet. Moet er iets op het systeem zelf gebeuren, dan doet jouw IBM i-partij of je eigen beheerder dat, en werken wij daarmee samen.

Wat we wel doen is alles aan de buitenkant. Lezen uit Db2 for i, aansluiten op wat er ontsloten is, de laag ertussen bouwen die vertaalt en cachet, en de webshop, het portaal of het dashboard dat er gebruik van maakt.

Dat is een bewuste afbakening en tegelijk een voordeel: een koppeling van ons levert nooit een change op je productiesysteem op.

Eerst even de naamgeving

IBM bracht de AS/400 uit in 1988, hernoemde het platform in 2000 naar iSeries, in 2006 naar System i en sinds 2008 heet het besturingssysteem IBM i, draaiend op IBM Power-hardware. In de praktijk zeggen mensen nog steeds AS400, ook als er een Power10 in het rek staat.

Wat wel uitmaakt is je release. IBM ondersteunt op dit moment 7.4, 7.5 en 7.6. Voor 7.4 loopt de standaardondersteuning af op 30 september 2026, daarna alleen nog tegen meerprijs. Draai je op Power8, dan is 7.4 het eindstation. Power9 komt tot 7.5, Power10 en Power11 draaien ook 7.6.

Voor een koppeling is dat vooral relevant vanwege TLS-ondersteuning op oudere releases. Blokkerend is het zelden, maar het bepaalt wel of er een proxy tussen moet.

Vier routes naar buiten

Db2 for i uitlezen via SQL

De snelste route en meestal de eerste stap. Db2 for i is een volwaardige SQL-database, ook al zijn de tabellen ooit met DDS aangemaakt als physical files. We benaderen hem met de ODBC-driver uit IBM i Access Client Solutions, met JTOpen (de opensource Java-toolbox), of vanuit PHP, Python en Node.js.

Voor lezen is dit ideaal. Voorraad, prijzen, artikelgegevens en orderstatus halen we op zonder dat er iets aan het systeem verandert. Nodig van jouw kant: netwerktoegang en een gebruikersprofiel met leesrechten op de juiste bibliotheken.

Rechtstreeks in tabellen schrijven doen we niet. Dan omzeil je de validatie en de bedrijfsregels die in de bestaande programma’s zitten, en dat gaat een keer mis.

Aanroepen wat er ontsloten is

Voor schrijven, en voor alles waar bedrijfslogica bij komt kijken, roepen we liever een programma aan dan dat we een tabel aanpassen. Dan blijven de regels op één plek staan.

Is er al een webservice, dan gebruiken we die. Is die er nog niet, dan is dat werk voor de IBM i-kant. Het systeem heeft daar Integrated Web Services voor aan boord, waarmee een bestaand RPG- of COBOL-programma als REST-service gepubliceerd wordt zonder dat de code herschreven hoeft te worden.

Zit de logica verweven met de schermafhandeling, dan is hij niet aanroepbaar en moet dat stuk eerst afgesplitst worden naar een service programma. Ook dat ligt bij de IBM i-kant. Wat wij wel doen is scherp maken welke functie we precies nodig hebben, met welke parameters en welk retourformaat. Dat maakt dat gesprek een stuk korter.

Data queues en de IFS

De klassieke manier om asynchroon te koppelen, en nog steeds uitstekend. Een data queue is razendsnel en ontkoppelt beide kanten volledig: het ene systeem zet er iets in, het andere haalt het eruit wanneer het uitkomt. Valt de verbinding weg, dan blijft de wachtrij staan.

Voor bestandsuitwisseling gebruiken we de IFS. Minder elegant, maar voor nachtelijke batches met leveranciers of vervoerders vaak precies goed genoeg.

De laag ertussen

Hier zit het meeste van ons werk. We zetten een aparte laag naast de IBM i, meestal in Laravel of Node. Die praat aan de ene kant met Db2 en met wat er ontsloten is, en biedt aan de andere kant een moderne API aan.

Vier redenen waarom die laag er hoort te zijn:

• Cachen. Een drukke webshop mag niet bij elke paginaweergave de Power-machine bevragen.
• Vertalen. Van cryptische veldnamen en packed decimals naar begrijpelijke JSON.
• Beveiligen. Tokens en rate limiting die je niet op de IBM i zelf wilt regelen.
• Doorontwikkelen. Een wijziging in de frontend leidt nooit tot een change op productie.

Voor het bouwwerk eromheen zetten we onze Laravel-specialisten in, of we werken vanuit Node als het landschap daarom vraagt.

Zo ziet dat er in de praktijk uit

Voor Drankdozijn draait de AS/400 ongewijzigd door als kern, met de webshop er volledig omheen gebouwd.

• Alle productinformatie wordt via een JSON-koppeling uit het bestaande systeem opgehaald
• Het productfilter toont realtime de actuele voorraad en data uit de AS/400
• De webshop is viertalig, waarbij elk land zijn eigen checkout-regels en prijsafspraken volgt
• Betalingen lopen via Adyen
• Transactionele e-mails gaan via Mailgun, automatisch getriggerd op het juiste moment

Waar het in de praktijk misgaat

Dit is het deel waar ervaring het verschil maakt. Een paar dingen komen in vrijwel elk IBM i-project terug.

Tekens die verminken. IBM i slaat data op in EBCDIC en de buitenwereld werkt in UTF-8. Die vertaling gaat vanzelf goed, behalve als een veld CCSID 65535 heeft. Dat betekent letterlijk “niet converteren” en het resultaat is een kolom vol vraagtekens of ruis. Wij inventariseren dit vooraf, op job-, bestands- en veldniveau, zodat het niet halverwege de bouw opduikt.

Datums die geen datums zijn. In legacy-bestanden staat een datum vaak als achtcijferig getal, of als zescijferig getal met een apart eeuwveld ernaast. Soms is 0 een geldige waarde die “onbekend” betekent. Dat moet je weten voordat je gaat rekenen of sorteren.

Getallen die geen getallen zijn. Packed en zoned decimal velden kunnen ongeldige inhoud bevatten die jarenlang onopgemerkt bleef, omdat het bestaande programma dat veld nooit las. Zodra je er een SQL-query op loslaat, krijg je een decimal data error.

Veldnamen van tien tekens. CUSNBR, ORDDAT, WHSLOC. Kort, cryptisch en soms hergebruikt voor iets anders dan de naam suggereert. Een mappingdocument is geen luxe maar het halve project, en dat maken we samen met degene die het systeem kent.

Autorisaties. Wij vragen om een eigen gebruikersprofiel met precies de rechten die nodig zijn op precies de objecten die nodig zijn. Het aanmaken ligt bij je beheerder, maar wij leveren de exacte lijst aan zodat er niets ruimer wordt ingesteld dan nodig.

Performance. Een query die op duizend testregels prima loopt, kan op veertig miljoen productieregels de machine op de knieën krijgen. Wij meten dat vooraf en signaleren waar een index ontbreekt. Het aanleggen gebeurt in overleg met de beheerder.

Wat we aan de andere kant koppelen

Zodra de data eruit komt, gaat hij meestal ergens anders naartoe. De koppelingen die we in combinatie met een IBM i het vaakst bouwen:

• Boekhouding: AFAS en Exact Online, soms Twinfield
• CRM: Salesforce
• Inloggen en identiteit: Microsoft 365
• Betalen: Mollie of rechtstreeks iDEAL
• Presentatie: mijn-omgevingen en portalen en data-dashboards

Zo beginnen we

We starten met een korte verkenning, samen met degene die het systeem kent. Welke release en hardware draait er, welke bestanden zijn relevant, hoe zit het met CCSID’s en autorisaties, en is beschikbaar wat we nodig hebben of moet er nog iets ontsloten worden.

Daaruit komt een concreet beeld van de route, de risico’s en de volgorde. Vervolgens bouwen we het kleinst mogelijke stuk dat echt werkt, bijvoorbeeld alleen de voorraadstand, en zetten dat in productie. Pas als dat stabiel draait, breiden we uit.

Op een systeem dat de hele bedrijfsvoering draagt voer je geen experimenten uit, ook niet vanaf de buitenkant.