Naar de inhoud
WD Noord
Menu

Systemen koppelen

Eén keer invoeren, twee systemen bij.

Twee pakketten die allebei vinden dat zij de waarheid in huis hebben. Het gevolg is dubbel invoeren, twee lijsten die uit elkaar lopen, en iemand die aan het eind van de maand uitzoekt welke versie klopt.

Plan een doorlichting Terug naar diensten
FIG. 02 / KOPPELINGBRON → DOORGEVEN → DOEL
Twee systemen verbonden, met een logboek van elke overdracht Webshop BESTELLINGEN BRON VAN WAARHEID Boekhouding FACTUREN VOLGT DE BRON Koppeling CONTROLEREN DOORGEVEN Logboek WAT ER OVERGING WANNEER WAT NIET DOORKON Handwerk DE GEVALLEN DIE OVERBLIJVEN Melding ALS EEN RECORD NIET DOORKOMT

WAT ER OVERGAAT, STAAT IN EEN LOGBOEK.

Wat ik doe

  1. 01

    Bepalen welk systeem de bron is

    In welke richting lopen de gegevens, en welk pakket is de baas over welk veld. Zonder die keuze wordt elke koppeling een wedstrijd tussen twee systemen.

  2. 02

    De koppeling bouwen

    Inclusief de lijst met gevallen die niet automatisch gaan en dus handwerk blijven. Die lijst maakt het verschil tussen een koppeling die vertrouwd wordt en een die stilletjes fouten doorgeeft.

  3. 03

    Fouten afvangen

    Een logboek van wat er overging, en een melding als een record niet door kon. Stilte is het echte risico.

Hoe het blijft lopen

Dit is de dienst waar veroudering het hardst toeslaat. Een leverancier brengt zelf de functie uit, wijzigt zijn API, of gaat over op een andere manier van inloggen. Elke wijziging betekent werk.

Onderhoud is hier daarom geen bijzaak maar het hart van de afspraak: de koppeling heel houden, meelezen als een leverancier iets aankondigt, en zeggen wanneer een koppeling zijn nut verliest in plaats van hem door te laten lopen.

Vragen over deze dienst

Het is al eens geprobeerd en het werkt niet meer. Kan dat opnieuw?
Ja, en dat is een veelvoorkomende situatie. Vaak is de oorspronkelijke bouwer weg en werkt het script nog wel, zonder dat iemand weet waarom of hoe. Dan wordt eerst uitgezocht wat er staat, voordat er iets verandert. Dat uitzoeken is werk dat betaald wordt, ook als de conclusie is dat het beter is om opnieuw te beginnen.
Kunnen julllie garanderen dat een leverancier zijn API niet wijzigt?
Nee, dat kan niemand. Dat is precies de reden dat er een onderhoudsafspraak naast staat. Wat ik wel doe is de koppeling zo bouwen dat een wijziging aan één kant zichtbaar wordt als fout, in plaats van dat er stil verkeerde gegevens doorstromen.
Wat als koppelen duurder is dan het pakket vervangen?
Dan zeg ik dat. Soms is een koppeling bouwen duurder dan overstappen naar een pakket dat het zelf kan. Dat is dan een advies en een aparte klus, geen koppeling die ik er toch doorheen druk.
Blijven er gevallen over die handwerk zijn?
Bijna altijd wel een paar. Bijvoorbeeld records met gegevens die geen van beide systemen kan valideren, of een leveringsvorm die alleen handmatig kan worden aangemaakt. Die gevallen zet ik vooraf op een lijst, zodat je weet wat er overblijft en niet pas ontdekt dat er iets blijft liggen.

Welke twee systemen moeten praten?

Noem de pakketten en waar het nu misgaat. Dan hoor je snel of het te doen is.

Neem contact op