Overall timeout/deadline for CPI iflow

[juankinspain]

Hello.

I have a requirement to set an overall timeout or deadline for an integration flow that it is expected to run for a long time until a required entry is found in a datastore. The entry is expected at certain time of the day but it can be delayed for several reasons. If the deadline is reached, the processing has to stop and the message has to end in error.

Has anyone faced a similar challenge? If so, how can this be achieved?

I searched thoughout the community but haven't found anything useful. Maybe my searching criteria was poor.

I thought about encapsulating the main functionality in a looping local process, with a groovy that waits a little time, lets say 30 seconds, before let a datastore-get, look for the entry; then set the looping process max iterations dynamically with a property that has the calculation 'deadline-time-in-seconds' divided by 'waiting-time-by-the-groovy' (for example, if the dealine is 1 hour, then the property would be 3600/30 = 120 iterations) and let the loop end in error if the max iterations is reached. The condition expression would be initially false and switched to true if the entry is found in the datastore. Would this be okay?

Thanks in advance for any insight on this matter.

Thanks

[Ryan-Crosby]

Sounds like a good candidate for EDA.

[MAVR]

Hi @juankinspain 

Unfortunately, there is no functionality out of the box to achieve what you seek. As you described, any solution will need to be a combination of scripts so you can achieve it with code and loops until you find the correct condition.

I want to share some guidelines because I have been in a similar situation where iFlows have been running for some time (more than an hour), and in those cases, I reached out to product support (support.sap.com) because it was not working as I expected.

1. It is not recommended to have iFlows, which require hours to complete, especially if the iFlows are not restartable (that means if it fails, it can be restarted from the point of failure). Ideally, the logic should be split into multiple iFlows, which, all together, produce the required outcome. Ideally, these sub-flows should be designed to be restartable, so even if some flow fails, it gets eventually restarted and completed. The more time an iFlow takes, the bigger the probability that it fails. Reasons:

1. iFlow runs out of memory, and the iFlow gets killed
2. Any other iFlow on the node produces an out-of-memory situation, and all iFlows running at the same node get killed
3. During software updates or security patches, an iFlow takes 5 minutes to complete; afterward, it gets killed

I hope this helps you.
Best regards 🖖🏻
Ricardo

[juankinspain2]

Thanks Ricardo.

It sure helps, at list from the design perspective.

Happy new year!