Bij het selecteren van een nieuwe, best-of-breed automatiseringsoplossing voor het purchase-to-pay proces komt al redelijk snel het onderwerp interfacing op tafel, zeker met de komst van SaaS. Wat betekent een migratie naar de cloud voor de interface met het ERP-systeem? Welke afwegingen zijn belangrijk voor een IT-afdeling?
Bij ICreative krijgen we regelmatig vragen over welke methodieken van interfacing met ERP we hanteren. Helemaal met de komst van SaaS-applicaties vormen interfacing en veiligheid van data een belangrijk vraagstuk. Inzicht in de afwegingen die voor een IT-afdeling belangrijk zijn, kan helpen om het implementatieproces te versnellen.
On-premise versus Saas
In een on-premise situatie staan het ERP-systeem, het financiële systeem en de purchase-to-pay (P2P) applicatie namelijk allemaal in hetzelfde IT-landschap. Dat maakt het makkelijk om een interface op te zetten. Een directe koppeling is mogelijk en je hebt het zelf allemaal in de hand.
Met de komst van SaaS moeten dient het vraagstuk zich aan hoe een best-of-breed applicatie, zoals Basware, in de architectuur geplaatst wordt. We dienen ons nu ineens te conformeren aan de protocollen van leverancier van de cloudoplossing, die veelal gestandaardiseerd zijn. Dat geeft een stuk minder vrijheid. Daarnaast moet het transport ook nog eens over het internet. Bedrijven die geen kennis of tools in huis hebben, hebben nogal wat te regelen.
Synchroon versus a-synchroon
Als we praten over interfaces, waar hebben we het dan eigenlijk over? Interfacing houdt in: het integreren van data over meerdere systemen en applicaties. Om de verschillende systemen met elkaar te laten praten, stelt de zogenoemde leverende partij data beschikbaar aan de vragende partij die de data zogezegd consumeert.
De koppeling tussen twee applicaties kan direct of indirect zijn, oftewel synchroon of a-synchroon. In het laatste geval zijn er meerdere transacties nodig om de data van de ene naar de andere applicatie te sturen. Het transport van de data loopt bijvoorbeeld via een FTP-server of fileshare. Het nadeel daarvan is dat er minder controle is of de data ook daadwerkelijk op de plek van de bestemming (het ERP) is aangekomen. Als de koppeling synchroon is, dan heb je direct antwoord of de import gelukt is. We zien echter in de praktijk dat koppelingen tussen ERP-systemen en P2P-systemen heel vaak a-synchroon zijn.
Voorbeeld a-synchrone interface
In dit voorbeeld is de interface asynchroon en weet het ERP-systeem niet of de data ook daadwerkelijk geïmporteerd is. Bron: ICreative (2020)
Authenticatie
Een belangrijke factor bij integratie is authenticatie. Dit betekent dat de leverende partij toestemming moet geven aan de vragende partij om de interface te gebruiken. Dat kan op verschillende manieren. Zo kan verificatie plaatsvinden via een gebruikersnaam met wachtwoord of bijvoorbeeld via een afgesproken geheime sleutel (een zogenaamde API-KEY). Een verdergaande vorm is bijvoorbeeld een Active Directory-integratie of VPN-verbinding. Daarmee kan de vragende partij rechtstreeks communiceren met het netwerk van de leverende partij.
Legacy, API en webservice
Wanneer we naar de techniek achter de aan te leggen interface gaan kijken, valt er een onderscheid te maken tussen legacy interfacing en moderne interfacing. Legacy interfacing is op maat gemaakt voor elke applicatie en daardoor vaak niet herbruikbaar. Dit is meestal alleen mogelijk bij interfacing tussen on-premise applicaties.
Moderne interfaces werken met een zogenoemde API of webservice. Elke webservice is een API, maar niet elke API is een webservice. Hoe zit dat? API staat voor Application Programming Interface. Het omvat een set programmeerinstructies en protocollen waarmee data uitgewisseld kan worden. Vanuit een applicatie maak je dan gebruik van een stukje code van een andere applicatie. Een voorbeeld hiervan is als bij vanuit je mailprogramma Outlook een afspraak maakt met daarin een Microsoft Teams- of Skype-uitnodiging. Dit gaat rechtstreeks van het ene naar het andere programma en gaat dus niet over het internet.
Een webservice is dus een API die via het internet te benaderen is. Dat maakt een webservice uitermate geschikt voor cloudapplicaties. De koppeling is synchroon en dat is erg prettig voor bijvoorbeeld het exporteren van facturen. Bovendien zijn webservices vaak gedocumenteerd, hierdoor zijn ontwikkelaars sneller in staat om de programmatuur die de webservice aanroept hierop aan te passen.
Webservice API documentatie
Een veelgebruikte manier om webservices te documenteren is via een zogenaamde swagger definitie (methode om REST webservices te documenteren en te gebruiken). Deze definitie kan via een webpagina worden gepubliceerd zodat de ontwikkelaar direct aan de slag kan.
In het voorbeeld is een swagger webpagina van Basware te zien, waarbij twee verschillende webservice staan beschreven met de bijbehorende aanroepmethodes:
SOAP en REST
Binnen het domein van de Webservices zijn er grofweg twee protocollen te onderscheiden: SOAP en REST. Microsoft ontwikkelde SOAP (een afkorting van Simple Object Access Protocol) in 1998 als een manier om externe machines met elkaar te praten in een standaard, samenhangende manier via het web. REST (een afkorting van Represention State Transfer) wordt ook wel gezien als de opvolger SOAP. REST biedt meer vrijheid en flexibiliteit in het opzetten van de webservices ten opzichte van SOAP.
Het grote voordeel van SOAP is dat het niet gebonden is aan HTTP(s) als transportmiddel van de data. Zoals eerder aangegeven kan de vragende partij daardoor al direct valideren of de berichten die ze sturen ook correct zijn. Zeker als je werkt met enorm veel diverse (complexe) services die enkel intern gebruikt worden is SOAP handig.
De reden dat veel programmeurs de weg van REST bewandelen is omdat het logischer in elkaar steekt. Het werkt makkelijker en het scheelt tijd.
JSON en XML
Samenhangend met het gekozen webserviceprotocol is de datastructuur. SOAP kent als enige optie XML. Dit is makkelijk op te zetten en heeft als voordeel dat er metadata meegegeven kan worden in het bericht zelf. REST ondersteunt meerdere formaten en werkt heel goed samen met de ‘lichtere’ code JSON (JavaScript Object Notation). Dit resulteert in betere prestaties en hogere snelheid van data-uitwisseling. Het is ideaal voor websites die Javascript gebruiken, aangezien Javascript zelf opgebouwd is uit JSON.
Pas nadat duidelijk is welk protocol gebruikt gaat worden en wat de gewenste datastructuur is tussen de servers, kunnen de webservices onderling informatie uit gaan wisselen.
Wees voorbereid
Kortom, er zijn nogal wat zaken die geregeld moeten worden. Het is daarom raadzaam om in een vroegtijdig stadium de IT-afdeling te betrekken en na te denken over de interface. Dat zorgt ervoor dat interne systemen zo georganiseerd en gestructureerd worden dat nieuwe P2P-projecten op een uniforme manier ondersteund kunnen worden en een kortere doorlooptijd zullen hebben.
We zien dat bedrijven met een eigen IT-afdeling vaak zijn voorzien van interfacetools. Bij bedrijven die zelf geen domeinkennis of geschikte tools in huis hebben, kan dit de doorlooptijd van een P2P-implementatie schaden. In dit geval kan een goede implementatiepartner hulp bieden.
>>Bekijk hier hoe ICreative kan helpen