I would actually go for the repeat solution: repeat while there are still records found in the result set (or while you still have elements to append to the list):
REPEAT on Success
add a Label on REPEAT
set the “Repeat interval”
add inside REPEAT an EXIT step → set the “exit step from” by using the REPEAT Label
call the EXIT step if there are no other entries to be appended to the list
Using the label instead of Exit on ERROR is a better approach than EXIT and signal Error (actually there was no error).
This way, you will exit from the Repeat step only and the execution of your flow service will proceed with the next sequence of steps.
Plus - you’ll use the native delay mechanism provided with REPEAT, no need to reinvent or add an extra “wheel”
What do you think? Please let me know if you have any questions!
Ana, It is interesting to know that we can achieve this with repeat.
But I have a question about this.
We use the loop with input array to loop through the records. But how can we achieve this with repeat to loop through the records which are received with one database call? Is there any way for the repeat to specify something like input array ?
LOOP (the equivalent of “for” in Java) is indeed helpful and the first solution that comes to mind when iterating is involved.
You do not have this option with REPEAT (the equivalent of “do while” in Java). The workaround I suggest for this is to have a counter (‘pos’ for example) that is initialized before the REPEAT block which is incremented by 1 at the end of each REPEAT block.
In order to extract the record for the corresponding iteration:
Step1: branch on /…/element[pos] and check if it’s null.
IF element[pos] !=null - it means you found records in the database OR you did not reach the end of the list returned from the DB call; you can proceed by invoking the service that builds the webservice call and creates the file from the response to FTP it (avoid having long service, try keep these as granular as possible).
ELSE - it means that the DB call returned no entries or you reached to the end of the list.
This is just my recommendation based on my preference, it does not mean that using a Java solution for this where you invoke Thread.sleep(ms) would not work.
I hope this helps, let me know if you have any questions and/or the approach you decide to go for!
If I had to choose, I’d vote for the simple LOOP with a sleep step. In my humble opinion, it’s cleaner and it should perform better.
Now, why do you need to “reduce the number of webservice calls made in one second”? These types of requirements make me very curious. Is it a licensing issue with the target system? Or is it a capacity issue (i.e. the target system is unable to handle the volume)?
I’d push hard to eliminate this requirement altogether because having a sleeping thread, whether using REPEAT or the Thread.sleep, is a bit wasteful.
Is there absolutely no way to address the capacity issue on the target application itself?
As for the 503 error code, as long as the target application consistently returns that error code when it becomes overwhelmed, I imagine your logic should work. You need to remember to retry the current message after the sleep, of course.
Now, another thing you could consider is to decouple the retrieval of the data from the database and the sending of the data to the web service by publishing a message to the bus (e.g. Broker or UM). This would bring on a few benefits that I can elaborate on if needed. It would, of course, add a little bit of complexity so you’d have to weigh in the pros/cons.
I have a similar type of requirement ,where inside loop I need to delay for some time (say 25 sec) before iterating to second loop.For this I have kept one repeat step at the end of the loop (properties as repeat on success and repeat interval of 25 sec).Inside loop i have kept just two map step as a place holder.
What I am observing is that ,for some request it is working and for some it is not.Out 8 request I have make ,I can observer only 2-3 have waited for delay time and rest of the request have straight execution without any delay.
Don’t use a REPEAT step to add a “wait”. Either use a Java service that calls Thread.sleep() as already mentioned in this thread, or better yet, eliminate the “wait” altogether by redesigning your solution.