Need to implement the recurring for a task, so that it will be auto triggered.
So, for that is there any way to implement the scheduling options as in the backend for input task from interface?
Discussion posts and replies are publicly visible
It sounds like you would like to setup a task that runs on a dynamic schedule based on some sort of admin configuration set through a separate interface?
This is certainly achievable, but you will most likely want to work outside of the direct task recurrence configurations. Such as, your admin interface controls a database table with scheduling, then you have a parent process which checks for this schedule and maybe waits at a timer node until the next task should fire. Then when updating the schedule, have the admin process cancel/re-trigger the parent timer process, etc.
Can you provide some more details on the use case? A task that runs daily at 10 AM, but you can change it to 11 AM via the admin interface, etc? Multiple tasks at once or a single task?
Do you have an update on how you achieved this? I have a similar use case where end users can setup sets of recurring tasks, for example, settings task A to run every Friday at 8 am and tasks B and C to run every quarter. I wouldn't want to have long-lived processes and also not have a parent process running (every hour for example) checking if any settings are met.
Any suggestions?
Store these recurring setup to database and start processes at the dates.
Do you mean having a process to regularly query the dates in the DB and if they match run it?
If so, what if I have a task that should run every Friday at 8 am and another task to run every Friday at 2 pm? Should the process model run every hour and check for the settings? I'd want to have flexibility but also think about volume in the future
Since process model start time configurations require a re-publish for the new setting to be realized, you will require a parent process to handle the timing check and start the desired process at that time. For this I will generally start one hourly, or once in the AM and wait until the desired time that day, depending on requirements.
What type of volume are you expecting for these scheduled tasks?
Note I have some processes that run every minute in my environment, they simply delete themselves after running and do not cause any negative overhead that I have noticed (over years).
We typically have around 250,000 processes sitting in memory at one time.
That makes sense. The requirement is to have all the flexibility as you have in the timer configuration so Daily, Weekly, Monthly and Yearly with all the specific configurations so that gives me a better idea, thanks!
Right now the volume is not crazy at all but the idea is that in the future more departments will use this feature too so it's better to design it to be bulletproof since the beginning.
That's helpful, thank you Chris!
That scheduler process should run at the minimum interval you plan to support. In my experience, an interval smaller than an hour does not make much sense, but it really depends.
Then, this process checks the database for triggers and starts the according processes. If you store process model ids in that table, you can make this very dynamic.