1
00:00:01,000 --> 00:00:04,890
Deze uitleg hoort bij ons artikel over API-integratie.

2
00:00:04,960 --> 00:00:08,010
Wat gebeurt er wanneer een systeem hetzelfde bericht opnieuw

3
00:00:08,040 --> 00:00:11,450
verstuurt, terwijl de eerste opdracht misschien al is aangemaakt?

4
00:00:11,720 --> 00:00:15,850
Een fictieve, goedgekeurde CRM-aanvraag gaat naar de administratie.

5
00:00:16,040 --> 00:00:18,170
Het bericht wordt tweemaal aangeboden.

6
00:00:18,360 --> 00:00:22,010
Zonder herkenbare referentie kunnen twee conceptopdrachten ontstaan

7
00:00:22,120 --> 00:00:24,090
voor precies dezelfde aanvraag.

8
00:00:24,280 --> 00:00:27,855
Geef de aanvraag een onveranderlijke bronreferentie die ook in de

9
00:00:27,880 --> 00:00:29,410
bestemming wordt opgeslagen.

10
00:00:29,640 --> 00:00:33,690
Een relatietabel koppelt de klantreferentie aan het juiste bestaande

11
00:00:33,720 --> 00:00:35,130
administratieve klantnummer.

12
00:00:35,480 --> 00:00:37,690
Alleen goedgekeurde aanvragen mogen door.

13
00:00:38,040 --> 00:00:42,090
Verplichte tekst, klantkoppeling en datumformaat worden gecontroleerd.

14
00:00:42,440 --> 00:00:46,615
Een ontbrekende klantmatch of ongeldige datum stopt de verwerking en

15
00:00:46,640 --> 00:00:48,410
krijgt een duidelijke foutreden.

16
00:00:48,600 --> 00:00:52,170
Alleen eerst zoeken voorkomt geen dubbele opdracht bij gelijktijdige

17
00:00:52,200 --> 00:00:52,890
berichten.

18
00:00:53,080 --> 00:00:56,775
De bestemming moet de externe referentie uniek houden, ook wanneer

19
00:00:56,800 --> 00:00:59,210
twee verwerkingen op hetzelfde moment starten.

20
00:00:59,400 --> 00:01:01,610
Na een time-out kan de opdracht al bestaan.

21
00:01:01,880 --> 00:01:05,130
Controleer daarom eerst de bestemming op dezelfde referentie.

22
00:01:05,320 --> 00:01:10,210
Blijft de uitkomst onbekend, laat een medewerker beoordelen voordat je opnieuw aanmaakt.

23
00:01:10,440 --> 00:01:14,490
Registreer bronreferentie, verwerkingsstatus en foutreden.

24
00:01:14,680 --> 00:01:17,495
Een beheerder moet kunnen zien wat wel is verwerkt en wat

25
00:01:17,520 --> 00:01:21,130
nog aandacht vraagt, zonder de hele keten blind te herhalen.

26
00:01:21,320 --> 00:01:25,530
Test dubbele en gelijktijdige berichten, ontbrekende velden en een

27
00:01:25,560 --> 00:01:26,650
onbekende uitkomst.

28
00:01:26,920 --> 00:01:31,015
Controleer ook actuele bronstatus: een oud bericht mag een nieuwere

29
00:01:31,040 --> 00:01:32,570
toestand niet terugdraaien.

30
00:01:32,920 --> 00:01:35,930
Een betrouwbare koppeling heeft dus meer nodig dan een geslaagde

31
00:01:35,960 --> 00:01:36,770
overdracht.

32
00:01:36,920 --> 00:01:41,050
Het bronartikel over API-integratie werkt gegevensafspraken,

33
00:01:41,160 --> 00:01:44,650
foutreacties en gecontroleerde herverwerking verder uit.