Introductie
In integratieprojecten komt het regelmatig voor dat berichten worden ontvangen waarbij in een vervolgstap aanvullende data uit een ander bronsysteem moet worden opgehaald, maar deze data is nog niet beschikbaar op dat moment. In zo’n geval moet bijvoorbeeld na een dag opnieuw worden geprobeerd om deze data op te halen. Als de data nog steeds niet beschikbaar is, volgt na een dag opnieuw een poging, enzovoort.
Kortom: binnen SAP Integration Suite dient een procesflow te worden ontwikkeld die de volgende situatie kan afhandelen:
- De benodigde additionele data is nog niet beschikbaar op het moment dat het bericht binnenkomt.
- Wel willen we automatisch blijven proberen deze data op te halen, zonder handmatige interventie.
In deze blog beschrijf ik hoe ik dit scenario heb opgezet in SAP Integration Suite (Cloud Integration).
De uitdaging
Het te ontwikkelen integratieproces moet dus voldoen aan de volgende kenmerken:
- Via een subscription op een topic worden events ontvangen (event mesh oplossing).
- Op basis van een ID in het event moet aanvullende data uit een ander bron systeem gehaald worden
- Als deze data nog niet beschikbaar is, wacht dan één dag en probeer opnieuw
- Herhaal dit maximaal 3 – 4 keer
- Daarna:
- ✅ Succes → vervolgprocesstap uitvoeren
- ❌ Geen data → uitvaltaak in SAP task center (BPA)
De gekozen oplossing
Ik heb gekozen voor een asynchrone retry-architectuur bestaande uit:
- 2 (hoofd)iFlows waarvan 1 met een timer
- 1 datastore
- 1 verwerkingsiFlow
-
-
iFlow 1 – Intake (opslaan van de data van het event)
Deze iFlow ontvangt de berichten (via een event mesh oplossing), voegt metadata toe (zoals retry-teller) en schrijft het bericht naar een globale datastore. (In dit scenario uit de praktijk zal het aantal entries in de datastore nooit boven de 100.000 komen, dus gebruik van een datastore is mogelijk.)
-
iFlow 2 – Retry proces
Deze iFlow wordt één keer per dag (bijvoorbeeld ’s ochtends) gestart (via een timer) en leest alle records uit de datastore. De records (event data) worden vervolgens afzonderlijk verwerkt. Per record wordt een aparte verwerkingsflow gestart. Hiermee voorkom je schaalproblemen en voorkom je ook dat een proces (onnodig) lang draait.
-
iFlow 3 – Verwerking van de data
In de verwerkingsflow zelf wordt vervolgens de additionele data opgehaald voor één record.
Als de data wordt gevonden:
- wordt het record uit de datastore verwijderd
- en gaat het integratieproces verder (de ‘happy flow’)
Als de data niet wordt gevonden:
- wordt de retry-teller verhoogd
- en wordt het record opnieuw weggeschreven naar de datastore
Als het maximaal aantal retries is bereikt:
- wordt een uitvaltaak aangemaakt via SAP BPA, inclusief alle relevante data
- en wordt het record uit de datastore verwijderd
-
Waarom deze aanpak werkt
Het voordeel van deze aanpak is dat er geen langlopende, blokkerende processen optreden. SAP Cloud Integration is niet geschikt voor processen met lange wachttijden: een asynchrone integratie past veel beter binnen SAP Cloud Integration.
In dit scenario fungeert de datastore als wachtrij en status opslag. Daarnaast zorgt het verwerken per record ervoor dat je geen grote, monolithische flow krijgt die langdurig draait.
Wat je dus niet moet doen
- Het gebruik van sleep in een Groovy-script
- Een iFlow meerdere dagen laten draaien
- Retry-logica implementeren zonder persistente opslag
Conclusie
Met een combinatie van een globale datastore, een timer en een gescheiden verwerkingsiFlow is een overzichtelijk en beheersbaar retry-mechanisme gebouwd binnen SAP Cloud Integration.
Deze aanpak is breed toepasbaar voor vergelijkbare scenario’s waarbij data niet altijd direct beschikbaar is.
Heb je een vergelijkbaar vraagstuk? Dan kan dit patroon een goede basis zijn voor jouw integratie-oplossing.
