Steeds meer bedrijfsprocessen zijn ingesloten in specifieke (cloud) applicaties ontworpen voor één of enkele taken. De gebruiker van deze applicaties is vaak de enige die informatie uit verschillende systemen synchroniseert, interpreteert en integreert. Applicatie integratie voorziet in het optimaliseren van bedrijfsprocessen met als doel tijdswinst, een kleinere foutmarge en/of kostenbesparing.

Applicatie integratie lijkt een kwestie van applicatie endpoints verbinden. In de praktijk is dit een van de laatste stappen en de meest technisch georiënteerde. Er gaan een flink aantal stappen aan vooraf. Recent hebben we in een aantal projecten alle stappen doorlopen en zetten nog eens op een rijtje hoe je tot aan de kern van de integratie ui komt.

De 1e laag – Wat is het gewenste eindresultaat?

In de case die voorligt, wil ProductFlow een integratie met Exact Online “bouwen”.

ProductFlow ontwikkelt software die je zou kunnen samenvatten als een combinatie van een PIM (Product Information Management) met een OMS (Order Management System) welke naadloos integreert met populaire marktplaatsen. ProductFlow zorgt voor het vastleggen van de juiste product content, de distributie daarvan naar marktplaatsen en voor de synchronisatie van de order met bijbehorende statussen.

Exact Online is een zeer uitgebreid financieel en logistiek systeem (en meer dan dat) waarin het volledige logistieke en financiële proces wordt ondersteund. Exact Online heeft een uitgebreide set aan API’s die volledige integratie ondersteunen.

Het gewenste eindresultaat is;

  • een aantal integratie bouwstenen rondom ProductFlow waarmee zij hun klanten sneller kunnen onboarden, zonder daarbij eigen ontwikkelcapaciteit in te zetten,
  • een standaard, voorspelbare integratie tussen ProductFlow en Exact Online Handel als optimale applicatieset voor hun doelgroep,
  • samenwerking met een integratiespecialist om zodoende eigen development capaciteit vrij te houden voor de kernactiviteiten en daarmee focus,
  • voorspelbare functionaliteit voor de gebruiker van de applicaties waarbij voldoende rekening is gehouden met de systemen, de processen en de mensen die het gebruiken

De 2e laag – Is er een API beschikbaar?

Een eenvoudige Google zoekopdracht zou antwoord moeten geven op de vraag of de te integreren applicaties beschikken over een API. Als dat antwoord niet direct duidelijk is dan zul je op zoek moeten naar de leverancier en daar het antwoord halen. Zonder API gaat het vaak over (verouderde?) on-premise applicaties waarmee integratie uitdagender wordt. Als fallback kun je nadenken of batchgewijze uitwisseling over (s)FTP een bruikbaar alternatief kan zijn.

De 3e laag – Is er API documentatie beschikbaar?

Een API zonder goede documentatie voelt als een puzzel van 3.000 stukjes zonder afbeelding van het eindresultaat. Zoek in de documentatie niet alleen naar mogelijkheden maar zeker ook naar beperkingen die er kunnen zijn. Besteed extra aandacht aan API limits omdat die je wellicht later beperken als er sprake is van grote hoeveelheden data of hoge frequenties die de API niet toestaat. Die documentatie is dus essentieel!

De 4e laag – Verzamel de credentials! 

Je krijgt (over het algemeen) niet zomaar toegang tot een API. Soms heb je alleen een API key nodig, soms zijn er complexere stappen nodig om toegang tot de API te verkrijgen (bijvoorbeeld Amazon Seller API). Om teleurstelling verderop in het proces te voorkomen, test altijd eerst of je met de credentials toegang hebt tot de API’s van de te integreren applicaties.

De 5e laag – Welke functionele gebieden worden geïntegreerd?

De combinatie van deze applicaties worden in deze case gebruikt door ondernemingen die actief zijn op een of meerdere marktplaatsen voor B2C verkoop. Ter ondersteuning van het proces zijn de volgende functionele gebieden geïdentificeerd;

  • Artikelbeheer
    • Artikelen “starten” in Exact en worden overgezet naar ProductFlow waar verdere verrijking van product informatie plaatsvindt
  • Voorraad- en prijs updates
    • De voorraad en de basis verkoopprijs in Exact is leidend, deze worden frequent in ProductFlow bijgewerkt, in ProductFlow kunnen prijzen per marktplaats worden aangepast
  • Verkooporders
    • De klantbestelling van de marktplaats komt in ProductFlow binnen van waaruit de status met de marktplaats wordt gesynchroniseerd
    • De klantbestelling wordt ingeladen in Exact Online zodat daar het logistieke proces kan starten. Onderdeel van de integratie is het aanmaken van debiteuren, contactpersonen en adressen
  • Leveringen
    • (Deel)leveringen worden vanuit Exact geadministreerd als onderdeel van het logistieke proces
    • De leveringen worden gesynchroniseerd met ProductFlow
    • De gewijzigde order(regel)status wordt gesynchroniseerd met ProductFlow
  • Track & Trace
    • In Exact worden de track & trace code en de vervoerder toegevoegd, deze worden gesynchroniseerd met ProductFlow
  • Betaling, facturatie en financiële boeking
    • De facturatie en boeking is onderdeel van het proces in Exact maar is geen onderdeel van het gewenste eindresultaat

De 6e laag – De functionaliteit van de applicaties?

Applicatie kennis is essentieel, enerzijds om de processtappen uit laag 2 te begrijpen, anderzijds om de niet zichtbare business rules (de 7e laag) te doorgronden. Het doorlopen van het volledige bijbehorende proces in de applicatie draagt bij aan een succesvolle integratie omdat resultaten beter kunnen worden gevalideerd en beter begrepen wordt waar rekening mee gehouden moet worden. Het komt ook regelmatig voor dat technische documentatie niet up to date is, data welke zichtbaar is in de interface, toch niet beschreven staat in de API, of dat de relatie tussen veldnamen in de interface niet of moeilijk te herleiden zijn naar de kenmerken in de resultaat output van de API.

  • Doorloop het proces in de interface van de applicatie(s) en maak printscreens voor latere referentie
  • Ter voorbereiding van de mapping (de 8e laag) kun je de velden op de printscreen voorzien van een identificatie en daar een “paper mapping” van maken. Welke velden van beide applicaties zijn nodig en hebben dezelfde betekenis
  • Het is erg handig om in de paper mapping de API output als voorbeeld / referentie data op te nemen. Zorg dat het record dat als referentie dient, volledig gevuld is met verschillende waardes zodat je de waarde kunt terug herleiden naar een identifier (op scherm / in dataset) 
  • Definieer welke velden geschikt kunnen zijn als unieke identifiers, soms zichtbaar in de interface, soms alleen als API output terug te vinden

Bij het invoeren van een order in Exact Online, kent Exact een order, aflever- en factuurdebiteur. De debiteur, de contactpersoon en het afleveradres moet bestaan, of wordt tijdens de invoer aangemaakt. 

Bij het middels API insturen van die gegevens moet je dus eerst controleren of de debiteur uit de ProductFlow order al bestaat, bijvoorbeeld door een check op de aanwezigheid van het emailadres. Indien deze bestaat kun je de unieke identifier van een debiteur (GUID) ophalen en bewaren voor verderop in het proces. Hetzelfde moet je doen voor de contactpersonen. Voor de adressen echter is het verstandig om het op de marktplaats opgegeven actuele afleveradres als nieuw adres aan te maken en te koppelen in de order.

Als bepaalde informatie niet beschikbaar is bij het integreren van een order zul je deze eerst moeten aanmaken, de debiteur staat nog niet in Exact Online bijvoorbeeld. Hier zie je al een conceptualisatie van het proces in verschillende integraties ontstaan, in Dovetail noemen we dit flows. Inzicht in hoe informatie binnen de applicaties flowt en welke informatie op ieder moment beschikbaar moet zijn is een voorwaarde voor een succesvolle integratie.

De 7e laag – Ken de business rules!

Het voorbeeld hierboven over het middels API aanmaken van een debiteur, contactpersoon en adres gaat over bij de applicatie horende business rules die je moet kennen om te voorkomen dat een oud afleveradres voor de actuele order wordt gebruikt.

Een ander voorbeeld zijn prijsberekeningen waar je onderscheid moet maken tussen prijs stamgegevens en een prijs die in de transactie wordt bepaald op basis van kortingen, staffels of mix/match regels. Een prijs die in een transactie wordt bepaald is niet beschikbaar anders dan in een berekening in combinatie met andere artikelen en andere variabelen.

De 8e laag – Data mapping

Niet alle hondjes heten Fikkie!

Dus, iedere applicatie heeft haar eigen naamgeving voor velden, zowel op de interface, in de database en binnen de API. Historie, voortschrijdend inzicht en (non)consistentie veroorzaakt dat logica niet altijd logisch is. Dus, de kans dat het artikelnummer in beide applicaties ItemID heet is niet zo groot… Daarom moeten we middels mapping de beide zijden van de integratie hetzelfde dialect laten spreken.

De 9e laag – Het configureren van de integratie flows

Met alle voorbereidingen bij de hand, kun je aan de slag met het configureren van de integratie flow. Binnen Dovetail heb je geen programmeerkennis nodig, je hoeft niet te kunnen coderen. De Dovetail gereedschapskist is goed gevuld met alles wat je nodig hebt om de integratie op te bouwen. 

Het is gebruikelijk om een aparte flow te bouwen voor de authenticatie en daarmee variabelen vast te leggen die je “geldig” kunt houden en verderop in het proces kunt blijven gebruiken.

Zo bouw je stap voor stap de flows op tot de volledige integratie tussen de systemen is bereikt.

De 10e laag – Foutafhandeling!

Minstens zo belangrijk, de afhandeling van fouten. Het configureren van de HAPPY flow is niet zo moeilijk, maar wat doen we als er iets niet gaat zoals verwacht? En weten we eigenlijk wat er fout zou kunnen gaan? Het probleem is dat we niet weten, wat we NIET weten. En het probleem daarvan is dat we een economische afweging moeten maken in de hoeveelheid tijd die we steken in het zoeken naar problemen. Dus maken we pragmatische afwegingen en regelen we de foutafhandeling voor alles dat we redelijkerwijs kunnen voorzien;

  • de API is niet bereikbaar of reageert niet
  • de authenticatie komt niet tot stand of wordt onderbroken
  • essentiële data ontbreekt
  • de flow doorloopt niet het gehele proces

Binnen Dovetail heeft iedere flow een zogenaamde error route. Als er iets in de flow mis gaat, wordt teruggevallen op deze error route waarin je vooraf hebt bepaald wat er dan moet gebeuren.

We zeggen ook wel, integratie is iteratie, iedere volgende versie is beter!

De 11e laag – Optimalisatie

Het kan altijd beter! Ongetwijfeld weten we inmiddels een aantal zaken die we eerder nog niet wisten. En hebben we waarschijnlijk een aantal fouten opgelost waardoor de kans op nieuwe fouten steeds kleiner wordt. Zoals gezegd, integratie is iteratie.

Wat dagelijks veel gebruikt wordt, kan altijd beter. Realiseer je dat een gebruiker fouten misschien niet meldt, maar ze “gewoon” zelf oplost. Zich niet realiserend dat niet alleen hij (of zij) dit voor zichzelf oplost maar dat collega’s dat waarschijnlijk ook doen. Dat was natuurlijk niet de bedoeling van integratie! Loop eens rond, vraag hoe het gaat en of de collega’s zonder handmatige aanpassingen hun proces kunnen doorlopen.

De 12e laag – Beheer

Onzichtbaar, maar iedere cloud applicatie wordt onderhouden op het gebied van infrastructuur, updates en upgrades van besturingssystemen, updates en upgrades van onderliggende frameworks, hotfixes en updates van de applicatie(s). Al met al werk voor een flink team van DevOps, back- en frontend developers, product managers, consultancy en support specialisten.

Soms is om die reden de applicatie even niet beschikbaar, we doen ons best om dat te doen op de momenten dat de gebruiker er zo weinig mogelijk last van heeft.

De 13e laag – Change management

Omdat het altijd beter kan, volgens ons of volgens de gebruiker, omdat het landschap van de gebruiker veranderd, omdat er nieuwe functionaliteit nodig is. Iedere verandering vraagt van onze mensen om even in te lezen, en het analyseren van de bestaande situatie.

Aanvragen voor wijziging worden opgepakt middels een RfC, een Request for Change waarbij onze consultant beoordeeld wat de mogelijkheden zijn, de consequenties in functionaliteit, tijd en geld.

De moraal van het verhaal!

Integreren van applicaties is meer dan het ontwikkelen van een technische integratie. Er gaan flink wat stappen aan vooraf, en er komen er een aantal achteraan. Om die reden zeggen wij “Integratie is complex, maar niet moeilijk”.

Bij het pellen van de ui, is de kans groot dat je een traantje moet laten…

Wij proberen dat te voorkomen door het HELE verhaal te vertellen en daarmee de verwachtingen duidelijk te maken. 

Dat noemen we Integration made easy

Contact

Neem contact met ons op!

We vertellen je graag meer over onze oplossing!

Contact