Ga naar inhoud

7.6: Chunking

7.6 Verwerkingsprotocol voor Deelberichten (Chunking)

Deze paragraaf beschrijft het protocol voor het opsplitsen (door de zender) en verwerken (door de ontvanger) van grote berichten. Het gebruik van deelberichten (chunks) is een optioneel mechanisme dat wordt toegepast wanneer de omvang van een bericht de afgesproken limieten overschrijdt.

7.6.1 Fundamentele Uitgangspunten van Chunking

Voordat we het opsplits- en samenvoegproces beschrijven, gelden de volgende fundamentele regels voor het chunking-mechanisme:

  • Validiteit per Chunk: Elke chunk moet een op zichzelf staand, volledig JSON-schema-conform bericht zijn. Dit betekent dat elke chunk alle verplichte "header"-blokken bevat, zoals commonTechnical en commonFunctional.

  • Gedeelde messageId: Alle chunks die deel uitmaken van één logisch bericht, delen exact dezelfde messageId in het commonTechnical-blok. Dit is de unieke identificatie van het overkoepelende, logische bericht.

  • Verplichte chunking-attributen: Indien de chunking.default-entiteit aanwezig is om aan te geven dat chunking wordt toegepast, zijn alle attributen binnen deze entiteit verplicht. Dit is essentieel voor een robuust en deterministisch reconstructieproces aan de kant van de ontvanger.

  • Integriteit van het logische bericht: Een fout in één enkele chunk (bijv. een validatiefout of het niet aankomen van de chunk) maakt het gehele logische bericht ongeldig. Het bericht moet dan in zijn geheel, met een nieuwe messageId, opnieuw worden aangeboden.

7.6.2 Opsplitsen van een groot bericht (Kant van de zender)

1. Bepalen van de Noodzaak
Opsplitsen is nodig wanneer een bericht de afgesproken maximale grootte (default: 4 MB) overschrijdt. De zender is verantwoordelijk voor het correct opdelen van de data.

2. Het Opsplitsproces
De zender creëert meerdere chunks door de data uit grote, herhalende arrays (zoals de lijst met cohorten) te verdelen. Elke chunk krijgt een chunking-blok met de juiste metadata (chunkSequenceNumber, totalNumberOfChunks, etc.) en de chunkFragmentPaths die de inhoud van die specifieke chunk beschrijven.

3. Gebruik van JMESPath in chunkFragmentPaths
Het chunkFragmentPaths-veld bevat de essentiële instructies voor de ontvanger om het oorspronkelijke bericht correct te kunnen reconstrueren. Het JMESPath kan een specifiek bereik (slice) aangeven (bv. pension[0:100]), wat garandeert dat de ontvanger de data in de exact juiste volgorde kan terugplaatsen, zelfs als de chunks in een andere volgorde worden ontvangen.

7.6.3 Verwerken van ontvangen chunks (Kant van de ontvanger)

1. Het Reconstructieproces

De ontvanger gebruikt de gedeelde messageId om chunks te verzamelen

  • Start met de Eerste Chunk: De chunk met chunkSequenceNumber: 1 dient als de basis of 'template' voor de reconstructie.

  • Plaats Datafragmenten: Voor alle volgende chunks worden de datafragmenten op de juiste positie in de template geplaatst, geleid door de chunkFragmentPaths.

  • Bepaal Compleetheid: Het bericht is compleet als het aantal ontvangen chunks gelijk is aan totalNumberOfChunks.

2. Verwerkingsstrategieën
Na conceptuele compleetheid kan de ontvanger kiezen voor:

  • Reconstructie-eerst (Batch-aanpak): Bouw het volledige bericht in het geheugen en valideer het daarna.

  • Streaming-verwerking (Directe verwerking): Sla datafragmenten per chunk direct op en voer overkoepelende validaties later uit op de database.

3. Foutafhandeling en incompleetheid

De integriteit van het volledige logische bericht is cruciaal.

  • Als één enkele chunk faalt (bijvoorbeeld door een technische validatiefout, of als deze niet binnen een bepaalde tijd wordt ontvangen), wordt het gehele logische bericht als mislukt en onverwerkbaar beschouwd.

  • In dat geval dient de verzender, na eventueel overleg, het volledige bericht opnieuw aan te bieden met een nieuwe messageId, opgesplitst in een nieuwe set chunks.