It would really be very interesting!

This is what we need for our apps! In some occasions we're using synchronous calls since we can't pass any parameters to timers. Which is a waste of the users time! What's the status of this idea?!

You can do this, however you must use a Site Property for Input

Action

Timer

Call Logic

Hey Heryck,

If you use site properties in that manner, you run the risk of missing one in case there are concurrent requests that would wake the timer.  You cannot guarantee that the site property will not be overwritten prior to the timer waking.

I would recommend using a table to keep the ids and then querying that in the timer to avoid this possible issue.

In my logic I did a check if the Timer is already running, and if so, it returns a message to the user, I also put a check to be able to call the functionality only after one minute of the last call.

But you can do this control with a table too, but it would not be passed by input, and if it were, you would probably have to do the same valuations above

Thanks for your comment.

Never, ever, ever use site properies like this! Site properties should be considered immutable as far as the application is concerned! Updating them like this may cause serious performance and synchronisation problems.

Hopefully this will be released soon as this will make batch processing with timeout management easier like passing the next starting index to process.

Absolutely needed. Wander why it is not implemented yet. It has been asked 10 year ago.

@Bad Code Guru the reason has been given by João Rosado, 14 years ago:

"I had the same feeling the other day when I had to use a WakeTimer, but since calling the WakeTimer multiple times does not mean it will run more than once (if its really fast) this is not really an option."

The thing is that unless you know whether the timer is running or not, and you have intimate knowledge on how timers are scheduled (as described in my artikel here), you can't be sure that there will be a timer run with that specific parameter that will actually run.

@Bad Code Guru part of this tread (the 14 years one that got merged into it and has my reply)  was before the platform had BPT's, currently what I said as the better alternative that would be a "feature request" is already implemented in the form of Processes and especially more recently with Light Processes.

So while this idea itself is not implemented (and will most likely never will), there are far better alternatives.

Hi @Kilian Hekhuis @João Rosado 

I some particular cases I need to use timers inside BPT.

BPT is triggered by db record created, where I can store any metadata information I need to do inside the process. In that sense you both absolutely right. But a BPT and timer are similar, but has different logical concept. 

Example: Let's say I have BPT "World creation". As a god I have static Entity {Animal} with Animals I want to create. Inside my divine BPT I loop thru {Animal} and call Action Animal_Create(AnimalId). 

But animal creation is an expensive action, and I decided to create a timer with this action that can handle timeouts and re-execute itself. 

I know you can argue (we all argue with gods) I can create sub-BPT to handle creation of an Animal with AnimalId, but I want to keep logical concept of BPT and timers, and moreover BPT amount is limited, and I want to create a lot.., not just Animals.

I hope now you understand why I bolded my wonder why it is not implemented.

Thanks.

Is there any alternative for it to download the data asynchronsally by passing parameteres ?

Hi Ajit,

Please don't ask questions in the Idea section. Create a question in the forum instead.