WEBVTT

00:00:01.000 --> 00:00:04.890
Deze uitleg hoort bij ons artikel over API-integratie.

00:00:04.960 --> 00:00:08.010
Wat gebeurt er wanneer een systeem hetzelfde bericht opnieuw

00:00:08.040 --> 00:00:11.450
verstuurt, terwijl de eerste opdracht misschien al is aangemaakt?

00:00:11.720 --> 00:00:15.850
Een fictieve, goedgekeurde CRM-aanvraag gaat naar de administratie.

00:00:16.040 --> 00:00:18.170
Het bericht wordt tweemaal aangeboden.

00:00:18.360 --> 00:00:22.010
Zonder herkenbare referentie kunnen twee conceptopdrachten ontstaan

00:00:22.120 --> 00:00:24.090
voor precies dezelfde aanvraag.

00:00:24.280 --> 00:00:27.855
Geef de aanvraag een onveranderlijke bronreferentie die ook in de

00:00:27.880 --> 00:00:29.410
bestemming wordt opgeslagen.

00:00:29.640 --> 00:00:33.690
Een relatietabel koppelt de klantreferentie aan het juiste bestaande

00:00:33.720 --> 00:00:35.130
administratieve klantnummer.

00:00:35.480 --> 00:00:37.690
Alleen goedgekeurde aanvragen mogen door.

00:00:38.040 --> 00:00:42.090
Verplichte tekst, klantkoppeling en datumformaat worden gecontroleerd.

00:00:42.440 --> 00:00:46.615
Een ontbrekende klantmatch of ongeldige datum stopt de verwerking en

00:00:46.640 --> 00:00:48.410
krijgt een duidelijke foutreden.

00:00:48.600 --> 00:00:52.170
Alleen eerst zoeken voorkomt geen dubbele opdracht bij gelijktijdige

00:00:52.200 --> 00:00:52.890
berichten.

00:00:53.080 --> 00:00:56.775
De bestemming moet de externe referentie uniek houden, ook wanneer

00:00:56.800 --> 00:00:59.210
twee verwerkingen op hetzelfde moment starten.

00:00:59.400 --> 00:01:01.610
Na een time-out kan de opdracht al bestaan.

00:01:01.880 --> 00:01:05.130
Controleer daarom eerst de bestemming op dezelfde referentie.

00:01:05.320 --> 00:01:10.210
Blijft de uitkomst onbekend, laat een medewerker beoordelen voordat je opnieuw aanmaakt.

00:01:10.440 --> 00:01:14.490
Registreer bronreferentie, verwerkingsstatus en foutreden.

00:01:14.680 --> 00:01:17.495
Een beheerder moet kunnen zien wat wel is verwerkt en wat

00:01:17.520 --> 00:01:21.130
nog aandacht vraagt, zonder de hele keten blind te herhalen.

00:01:21.320 --> 00:01:25.530
Test dubbele en gelijktijdige berichten, ontbrekende velden en een

00:01:25.560 --> 00:01:26.650
onbekende uitkomst.

00:01:26.920 --> 00:01:31.015
Controleer ook actuele bronstatus: een oud bericht mag een nieuwere

00:01:31.040 --> 00:01:32.570
toestand niet terugdraaien.

00:01:32.920 --> 00:01:35.930
Een betrouwbare koppeling heeft dus meer nodig dan een geslaagde

00:01:35.960 --> 00:01:36.770
overdracht.

00:01:36.920 --> 00:01:41.050
Het bronartikel over API-integratie werkt gegevensafspraken,

00:01:41.160 --> 00:01:44.650
foutreacties en gecontroleerde herverwerking verder uit.