Webservices zijn tegenwoordig niet meer weg te denken in de IT-wereld. Ze worden overal gebruikt, Ook waar je het niet verwacht en maken heet leven heel wat eenvoudiger.
Een webservice kan omschreven worden als een interface van een applicatiecomponent. Deze is toegankelijk via webprotocollen en maakt het mogelijk om via het internet vanaf een client (BV. Een app of webapplicatie) een service of dienst op te vragen aan een (web)service. Ze maken interactie tussen verschillende applicaties een heel stuk eenvoudiger. De communicatie van de webservice gebeurt door het doorsturen van machine leesbare file formats zoals XML en JSON. Dit zorgt ervoor dat deze communicatie conform is tussen verschillende applicaties en dat er niet voor elke connectie tussen twee applicaties aparte regels moeten worden afgesproken. Webservices worden beschikbaar gesteld over een netwerk, dus een netwerkconnectie is noodzakelijk.
Omdat webservices tegenwoordig niet meer weg te denken zijn kon ook IBM niet achterblijven. IBM ondersteunt webservices ook op hun IBM i-servers. Een IBM i-server kan zowel communiceren met webservices via het internet als zelf webservices aanbieden.
Webservices aanspreken kan op verschillende manieren op je IBM i-server. De eerste manier is om deze services op te roepen via SQL. Wanneer we deze manier willen gebruiken zal de webservice worden opgeroepen via een SQL-statement. De response zal dan teruggegeven worden in JSON of XML-formaat. Je kan dan allerlei SQL-functies gebruiken om deze data dan te verwerken.
Dit maakt het vrij gemakkelijk om te testen omdat je deze SQL-statement al eerst kan uitvoeren en je ze niet pas te zien krijgt als je het programma waarin je ze verwerkt hebt laat lopen.
Een tweede optie is om de Integrated webservices client te gebruiken. Je kan dan via verschillende C-procedures webservices aanspreken. Je kan de request string via een RPGLE-programma opvullen en de JSON of XML-response afhandelen in een SQL RPGLE-programma. Errorafhandeling kan hier ook gebeuren via C-procedures. Je hebt wel minstens vier verschillende C-procedures nodig om één webservice call te maken en dit kan wel eens een valkuil zijn als je niet heel vertrouwd bent met C-procedures.
De laatste methode is webservices oproepen via Javamethodes.
Je kan dit doen door je eigen Java-programma’s te schrijven. Dit framework zorgt dan voor de afhandeling van de XML of JSON-response. Voor gemakkelijke toegang kan je dan een RPG wrapper service program schrijven rond de Java code. Je kan dit doen voor elke soort webservice en het is vooral handig als een specifieke optie nog niet aanwezig is in de SQL-functies.
Je kan het beste kiezen welke techniek je gebruikt afhankelijk van wat je kennis is van de nodige programmeertaal en wat je persoonlijke voorkeur is. Het is wel een ‘best practice’ om het eerst via de SQL-functies te proberen. Deze werken snel en je krijgt je resultaat direct te zien zonder dat je veel code moet schrijven.
Je kan via je IBM I-server ook webservices aanbieden.
Je kan dit doen met de Integrated Web Services Server op de IBM I-server of met de CGI (Common Gateway Interface).
Je kan met de IWS Soap webservices en REST API’s opzetten. Dit gebeurt via een handige GUI wizard die je door alle stappen laat gaan om de service op te zetten en te deployen. De verwerking wordt dan uitgevoerd door een RPGLE-serviceprogramma of een SQL-statement. Je hebt geen JSON of XML nodig in RPGLE of SQL en de request parameters die nodig zijn kunnen direct gelinkt worden via de wizard aan RPGLE of SQL-parameters.
Via CGI kan je ook zowel soap webservices als rest apis configureren. Het verwerken gebeurt via een RPGLE-programma. Er is een wizard voor de HTTP-server setup (om een programma te linken aan een resource). De complete JSON of XML request is beschikbaar in het RPGLE-programma.
Je probeert best eerst de IWS te gebruiken en gebruikt enkel de CGI als limitaties IWS niet toelaten, de request/response te complex is of geen JSON/XML is, de WS-client beslist over de request/response of je gedetailleerde logging en error informatie nodig hebt.
Nu wil ik nog even vertellen over de nieuwe ontwikkelingen over de webservices op IBM i.
Vroegen werden alle aansprekingen gedaan via de Systools library. Sinds september 2021 zijn er hier nieuwe functies voor op de markt gebracht. Deze zitten in de Qsys2 Library. Deze functies gebruiken http-transport apis i.p.v Java calls. Ze zijn performanter en hebben een kleinere ‘footprint’.
Deze nieuwe functies handelen SSL-certificaten anders af en hebben system support voor TLS-encryptie.
Deze nieuwe functies gebruiken de systeemstandaard certificate store, en deze is standaard niet bestaand. Als je ervoor kiest om je applicatie de certificaten van de JVM te laten vertrouwen kan je een SQL-script dat je in de documentatie kan terugvinden gebruiken om de trust store van de JVM te kopiëren naar de systeemtrust store. Zonder deze nieuwe trust store is het niet mogelijk om HTTPS-functies uit te voeren omdat je de juiste certificaten niet hebt. Je moet deze trust store 1x configureren voor je IBM I-server en dan kan je zonder problemen HTTPS-functies gebruiken als je de nieuw gemaakte trust store meegeeft bij deze parameters.
Ook moet je goed uitkijken voor de volgorde van de verschillende parameters want deze verschilt van de systools functies. Je kan dit gemakkelijk oplossen door bij elke parameter te verduidelijken welke parameter dit is bv URL => ‘https://someurl.com’, OPTIONS => {JSON-options}, REQUEST_DATA => ‘data-in-JSON-format’. Als je deze notatie gebruikt zie je direct over welke parameter het gaat en maakt de volgorde niet uit.
Er zijn ook heel wat verschillende nieuwe opties als headers. De header moeten in tegenstelling tot de oude HTTP-functies altijd meegegeven worden in JSON-formaat, je kan dus geen header meer meegeven in XML-formaat.