Zeebe timer event doesn't support variables

Currently I use zeebe for publishing.
My task is pretty straightforward. I do some preprocessing and then want to publish only when
$.publicationDate in payload > now()

It is possible to implement in camunda, but I can’t afford it because of performance reason.
Therefore my questions are:

  1. Does Zeebe support embedded functions(variables) like now()
  2. Does Timer Event support using variables from payload

Workflow:

I have startPublicationDate and endPublicationDate as variables in payload

If answer on all/any question is ‘no’. Please tell me do you have at least some plan to implement those functionality in next releases. Thank you

Any workarounds appreciated

Hi @AlexFaster, thanks for the questions and detail about your use case.

Unfortunately, the answer to both of your questions is “no”, and we also haven’t discussed implementing functionality like this in upcoming releases. We’ll put our heads together to see if we can think of any workarounds.

Quick question: how specific are your startPublicationDate and endPublicationDate variables? Just the date, or date + hour + minute…?

Best,
Mike

Thanks for your reply, I can represent it in millis, just long value

It is my current workaround
I setup 10 min const timer, after that my ‘now’ variable is updated by task, after that I compare one more time the publicationDate and now. And either loop again or go to exit.

2 Likes

Unfortunately it is a very dirty hack, over 50% of my system resources now handling update now external task.
It would be nice to have either now() embedded function (i will use it in conditional step) or directly support this thing: see attached image,

as implemented in camunda

I am really looking forward for your reply, thank you

Hi @AlexFaster, thanks for the detail. One idea for a workaround, also hacky, is to use messages instead of timers.

A few quick notes:

  • The way I’m thinking about it, the correlationKey would be the startPublicationDate and endPublicationDate.
  • You’d need to create a separate client to publish these messages…
  • But you could use Zeebe’s message time-to-live features to publish the messages in advance; they’d be “buffered” in Zeebe until the TTL was reached.
  • A single message can be correlated to multiple workflow instances, and so if stories shared the same publication date, you wouldn’t need to publish one message per story.

I don’t know if having this separate message publishing client would work for your use case. Curious to hear what you think.

I’ll also keep you updated if/when we plan to add timer-related features, specifically around this “dynamic timer” case.

Best,
Mike

1 Like

@wints
Thanks for your reply.
We also considered this idea, but I am quite confusing that now 2 units (zeebe and external service) control the workflow.
I think message is a nice feature to support exceptional cases, not the regular flow.

BTW
Could you please answer what is the difference between const timer value (1m, 5h, etc) comparing with dynamic timer value, I think from technical point of view the implementation of “time out” moment is the same, isn’t it?

Hi @AlexFaster, agree that it’s not the way messages are intended to be used. I understand why you’d want to avoid the potential confusion.

Regarding your question: yes, that’s correct that once you’ve calculated the point in time (probably based on a workflow instance variable), the triggering code for the Timer would be the same. The bigger challenge here is around the expression / scripting implementation.

Best,
Mike

Hello @wints I came across this thread looking for the same functionality as OP was asking for, “dynamic timers”. Is there any updates on this?

No change, and nothing on the roadmap in the near future.

“dynamic timer” is a very useful feature. Otherwise I need to create different workflows simply because their starting time is different if I don’t want to use message hack. Initially you can just support the unix epoch time format and assume that the dynamic time variable value is passed when at the the time the workflow instance is created. I think this is a low hang fruit but create great value for Zeebe user

Thanks
Qing

Plus one for this feature.

1 Like

The best place to add +1 feature request feedback is in GitHub. Look here, and the related issues: https://github.com/zeebe-io/zeebe/issues/3079

1 Like