Hello guys, I have a question. I make an API call and need to store each returned item in my database. It turns out that there is no specific number of items that will be returned, it could be dozens, it could be hundreds.
I will need to run this periodically, what approach would I need to take to avoid a possible infinite loop here, as I will never know the exact number of entries returned, but will always need to store them all?
I appreciate any ideas or suggestions.
If I made an api call that returned a list of stuff, I’d pass the list of returned stuffs lists of fields as lists of primitive types thru a recursive backend workflow
Sorry for the delay.
Regarding your answer @jared.gibb , then I wouldn’t need to define a maximum limit of items on which the workflow would be executed, I could just let it run over the entire list and when there were no more items it would stop execution, correct?
Could I set a limit value just in case?
Yes you can always add a count parameter and increment the number every time the API call runs and add a conditional to run the API call only when count < max_value.
Sidepoint: Does the API response tell you there are no more items to retrieve? If so you can use that response to stop the recursive workflow…
Yea usually there’s a “next page” number or UR to end the workflow when that hits 0 or empty
Of course.
You could always start with a incremented value and work towards an end value or your “max” loops
I love everyone’s recommendations of max value, would work really well.
Personally I tend to opt for a time based option. Where the start time is passed and it can only run if time+10min < current time. Or something of that nature.
Both options are equally as good in my opinion and tend to have their place of being used.
If you know the count of items coming inbound you’d definitely use max option as you’ll incur less loops if it goes infinite.
If you don’t know max items inbound time based is preferred so you don’t cut yourself short by only getting part of the list.
I would add a couple of different stopblocks.
One of my favorites is to add a date parameter that gets set when the workflow is triggered. Then, every time the workflow reschedules itself, have it check to make sure that “current date/time” is less than “date + x minutes” as a condition. So if the workflow is running longer than X minutes, it will stop rescheduling.
@chris.williamson1996 you beat me to it. Posted while I was typing 
I think I understand this. Thanks everyone for the tips, @jared.gibb , @code-escapee , @tylerboodman , @chris.williamson1996 and @aj11 .
I would like this to be done twice a day, the time doesn’t matter. I’ll just get the data and save it to the DB. But I think I’m a bit lost between some options 
, I don’t know which one would be recommended in this case that could occur automatically.
Create a new recurring event as a Backend WF and set this recurring event in the Backend WF or Common WF actions.
Schedule API WF on a list in the Backend WF actions or Common WF actions.
But then how can I schedule something every 12 hours or something like that.
I’d appreciate any basic explanation on this.
Generally speaking they are similar with a recurring event easier to turn on and off thru an admin (while turning off a API WF would require its ID (so you’d have to store that) unless done in the logs). However for your purposes, the API WF is clearly the way to go as you want it to run 2x a day and recurring events can only be triggered daily, weekly, etc (and creating 2 recurring events would be a hassle to maintain).
