Een bestaande koppeling vervangen zonder dat er iets stilvalt

Het korte antwoord

Een koppeling die draait, vervang je niet in één keer. De nieuwe koppeling loopt eerst mee naast de oude, krijgt dezelfde gegevens binnen en schrijft niets weg. Hij legt alleen vast wat hij zou hebben geschreven. Dat wordt vergeleken met wat de oude koppeling werkelijk schreef. Pas als die twee overeenkomen, of als elk verschil is verklaard, gaat er een stroom over.

De dagen in het diagram zijn een voorbeeld om mee te rekenen. Hoe lang het meedraaien duurt, volgt uit de vraag of elke soort order is langsgekomen, niet uit een kalender. De methode is dezelfde als een dry run voor een nieuwe koppeling, met één verschil: er is een oude koppeling om tegen te vergelijken.

Wat het meedraaien zichtbaar maakt

Een webshop met 30 orders per dag levert in 14 dagen 420 orders op. Voor elke order staan er twee uitkomsten naast elkaar: wat de oude koppeling in het ERP zette en wat de nieuwe zou hebben gezet. In het voorbeeld:

398 van de 420 is 94,8%. De andere 22 zijn geen fouten van de nieuwe koppeling. Het zijn 4 regels die het oude script toepaste en die nergens beschreven stonden.

De eerste is rekenwerk. Een order met 2 regels van 10,50 exclusief btw: per regel is 21% btw 2,205, afgerond 2,21, samen 4,42. Per order is het 21% van 21,00, dus 4,41. Het ERP heeft twee jaar facturen met de eerste methode. De nieuwe koppeling neemt die methode over, want een cent verschil met de betaling blokkeert het automatisch afletteren.

De derde is het soort regel waar een vervanging op stukloopt als hij niet eerst meedraait. Ergens in het script staat dit:

als land van de order niet NL is: order overslaan

Iemand op de administratie voert de Belgische orders al jaren met de hand in en weet niet beter. Zonder meedraaien had de nieuwe koppeling die 3 orders aangemaakt en had de administratie ze daarna nog een keer ingevoerd: 6 verkooporders voor 3 bestellingen.

Elk verschil eindigt als een besluit: het gedrag van de oude koppeling overnemen, of het verbeteren en de mensen inlichten die eromheen werken. Zo ziet het vergelijkingsrapport van één ronde eruit:

order   veld             oude koppeling     nieuwe koppeling     besluit
10391   btw-bedrag       4,42               4,41                 oud overnemen
10391   verzendkosten    regel VERZEND      veld verzendkosten   oud overnemen
10397   order (land BE)  niet aangemaakt    aangemaakt           nieuw, handwerk stopt
10402   bedrijfsnaam     35 tekens          48 tekens            nieuw, veld is 50 lang

Het meedraaien kost verzoeken aan dezelfde systemen. Bij Exact Online geldt de limiet van 60 verzoeken per minuut en 5.000 per dag per app en per administratie. Een nieuwe koppeling met een eigen app-registratie heeft een eigen budget en hindert de oude niet. Gebruiken beide dezelfde registratie, dan delen ze de 5.000: een oude koppeling die er 3.200 per dag gebruikt en een nieuwe die hetzelfde werk leest, komen samen op 6.400 verzoeken. Gelijk over de dag verdeeld is het budget dan om 18:45 op (5.000 gedeeld door 6.400 is 78% van 24 uur) en krijgen beide koppelingen een 429 tot het budget de volgende dag opnieuw begint. Meer hierover in rate limits en throttling.

Per stroom omschakelen, in een vaste volgorde

Alles in één nacht omzetten betekent dat een probleem in de voorraad en een probleem in de orders tegelijk zichtbaar worden. Per stroom omschakelen houdt elke oorzaak apart. De volgorde loopt van makkelijk terug te draaien naar moeilijk terug te draaien.

Voor elke stroom geldt één regel: er schrijft steeds één koppeling. Twee koppelingen die dezelfde voorraad naar de webshop schrijven, overschrijven elkaar bij elke ronde, en bij een verschil is niet meer vast te stellen wie het getal heeft gezet. Op de dag van de omschakeling gaat eerst de oude stroom uit en daarna de nieuwe aan, niet andersom.

Orders gaan als laatste van de schrijvende stromen. Een verkooporder die in het ERP is aangemaakt, heeft een nummer, een reservering en soms al een pakbon. Die haal je niet weg door een koppeling uit te zetten.

De orders tijdens de omschakeling

Tussen het moment dat de oude orderstroom uitgaat en de nieuwe aangaat, komen er orders binnen. De webshop stopt niet met verkopen. Wie die orders verwerkt, wordt vooraf vastgelegd.

Een voorbeeld. De oude koppeling haalt elke 15 minuten nieuwe orders op en loopt voor het laatst om 05:45. De nieuwe gaat om 06:00 aan. Order 10482 komt om 05:52 binnen: na de laatste ronde van de oude en voor de start van de nieuwe. Start de nieuwe koppeling met orders vanaf 06:00, dan verwerkt niemand order 10482.

Drie afspraken sluiten dat gat:

• De grens ligt op ordernummer. De oude koppeling verwerkt tot en met 10481, de nieuwe vanaf 10482. De klokken van een webshop en een server kunnen een paar minuten verschillen; een ordernummer niet.
• De wachtrij van de oude koppeling loopt eerst leeg. Orders die de oude koppeling al had opgehaald en nog opnieuw aan het proberen was, worden afgemaakt of met naam overgedragen. Het aantal staat in het draaiboek: bijvoorbeeld 2 orders in herhaling, allebei afgeleverd om 05:58.
• De nieuwe koppeling controleert of de order al bestaat. Hij zoekt het ordernummer van de webshop in het referentieveld van het ERP voordat hij iets aanmaakt. Een order die beide koppelingen hebben gezien, levert dan één verkooporder op. Hoe die controle werkt staat bij dubbele orders en debiteuren.

Orders van voor de grens die nog open staan, hebben later een trackcode en een statuswijziging nodig. Die lijst wordt op de dag zelf gemaakt, bijvoorbeeld 37 orders, en gaat als startbestand de nieuwe koppeling in.

De afspraak over terugdraaien

Terugdraaien is een besluit dat onder druk slecht wordt genomen. Daarom ligt het vast voordat de eerste stroom overgaat, op papier, met vier onderdelen:

De getallen zijn voorbeelden. De vorm is het punt: een drempel die te tellen is, een naam, en een einddatum waarna de oude route echt weg is. In de eerste dagen na elke omschakeling is er aan beide kanten iemand bereikbaar die in het systeem kan kijken, zowel in de webshop als in het ERP.

Loopt er een stroom één keer per maand, zoals een export bij de maandafsluiting, dan blijft de oude route beschikbaar tot die stroom één keer op de nieuwe koppeling heeft gedraaid.

Een koppeling overnemen die niemand meer begrijpt

Het lastigste geval is een script zonder documentatie, gebouwd door iemand die er niet meer is. Wat het doet, is op vier plekken terug te vinden:

• De code en de configuratie. Daar staan de regels zoals de landcontrole hierboven, en vaak ook een vertaaltabel die in de code is getypt: betaalmethode naar betalingsconditie, verzendmethode naar artikelnummer.
• De geplande taken op de server. Welke scripts lopen wanneer. Een taak die elke nacht om 03:00 een bestand verplaatst, hoort er ook bij.
• De logs van beide systemen. In het ERP is te zien welke records door de API-gebruiker zijn aangemaakt; in de webshop welke sleutel welke verzoeken doet.
• De mensen eromheen. Wie voert wat met de hand in, en sinds wanneer.

Wat daarna nog onbekend is, komt uit het meedraaien. Bij een ongedocumenteerd script is het meedraaien daarmee zelf de inventarisatie. Heeft het oude systeem geen API, dan loopt het lezen via een van de routes uit koppelen zonder API.

Wat betekent dit voor je koppeling?

Wij bouwen de nieuwe koppeling naast de bestaande, laten hem meedraaien zonder te schrijven en leveren per ronde het vergelijkingsrapport: welke records overeenkomen, welke afwijken en waarom. Jij keurt de verschillen goed voordat een stroom overgaat. Uitsluitingen en regels die het oude script stil toepaste, worden instellingen die je in het dashboard terugziet.

Na de omschakeling draaien en bewaken wij de koppeling, met een wachtrij en nieuwe pogingen zodat een order niet stil verdwijnt. De aanpak voor koppelingen buiten de standaardpakketten staat op maatwerk koppeling laten maken. Vertel wat er nu draait en tussen welke systemen, ook als er geen documentatie van is.