Usecase
I don’t want to hardcode the retry interval. I want to dynamically set the retry interval as it is decided by the end system.
I think you should use retries for when your activity actually fails, for example accessing the End System service. Retries are performed on an interval, and if the “come back in…” time is very long you could have lots of retries happen for no reason. Workflow.sleep on the other hand does not utilize any resources on your system while you are waiting. If you use very long retry intervals, you might run into issues if the activity actually is failing so mixing the two is maybe not best idea.
So you could call your activity in a loop and after activity produces a result, sleep for the duration of the result provided by your activity. Break out of the loop when the result of your activity is for example an actual result and not a wait duration.
Another idea, if the sleep updates are dynamic you can use updatable timer, which can get the time result of the end system and update (add to) the timer per its instructions. Here is a sample for updatable timer.
Let us know if that would work for you.
1 Like