I can set cron expression for timer cycle

[lzgabel]

Is your feature request related to a problem? Please describe.
As a user, I want to be able to set the cron expression for timer cycle.

Describe the solution you'd like

Parse the given crontab expression string. The string has six single space-separated time and date fields:

   ┌───────────── second (0-59)
   │ ┌───────────── minute (0 - 59)
   │ │ ┌───────────── hour (0 - 23)
   │ │ │ ┌───────────── day of the month (1 - 31)
   │ │ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
   │ │ │ │ │ ┌───────────── day of the week (0 - 7)
   │ │ │ │ │ │          (0 or 7 is Sunday, or MON-SUN)
   │ │ │ │ │ │
   * * * * * *
   

Example expressions:

• "0 0 * * * *" = the top of every hour of every day.
• "*/10 * * * * *" = every ten seconds.
• "0 0 8-10 * * *" = 8, 9 and 10 o'clock of every day.
• "0 0 6,19 * * *" = 6:00 AM and 7:00 PM every day.
• "0 0/30 8-10 * * *" = 8:00, 8:30, 9:00, 9:30, 10:00 and 10:30 every day.
• "0 0 9-17 * * MON-FRI" = on the hour nine-to-five weekdays
• "0 0 0 25 12 ?" = every Christmas Day at midnight
• "0 0 0 L * *" = last day of the month at midnight
• "0 0 0 L-3 * *" = third-to-last day of the month at midnight
• "0 0 0 1W * *" = first weekday of the month at midnight
• "0 0 0 LW * *" = last weekday of the month at midnight
• "0 0 0 * * 5L" = last Friday of the month at midnight
• "0 0 0 * * THUL" = last Thursday of the month at midnight
• "0 0 0 ? * 5#2" = the second Friday in the month at midnight
• "0 0 0 ? * MON#1" = the first Monday in the month at midnight
  of the month at midnight
• "0 0 0 * * 5L" = last Friday of the month at midnight
• "0 0 0 * * THUL" = last Thursday of the month at midnight
• "0 0 0 ? * 5#2" = the second Friday in the month at midnight
• "0 0 0 ? * MON#1" = the first Monday in the month at midnight

Describe alternatives you've considered
We can refer to the existing implementation of Spring, see here

[korthout]

That is a great idea @lzgabel Thanks!

We should carefully consider how this feature should be supported by Zeebe. I see the following options:

1. the timer cycle could be defined directly with a CRON expression .startEvent().timerWithCycle("*/10 * * * * *"). This means native support in Zeebe.
2. the timer cycle could be defined using a cron() FEEL function .startEvent().timerWithCycle("= cron(*/10 * * * * *)"). This means native support in FEEL-scala, which opens up the functionality to more than just Zeebe.
3. alternatively, the timer cycle could be defined using a cron() FEEL extension function in Zeebe (same as option 2, but only supported in Zeebe).

@lzgabel I'd be interested to hear your thoughts.

@felix-mueller Please also share your thoughts on your preferred approach.

[lzgabel]

Hi @korthout . Thanks for a couple of solutions. ❤️
I think the second solution is probably the best option.

[korthout]

@lzgabel I've had some more time to discuss and think about these alternatives. I suggest we continue with your original plan: support it directly in the timer definition.

The idea to define a cron() FEEL function is very interesting and may come with a few benefits:

• the return type of the cron() function may be easily converted to common FEEL data type, e.g. date and time(cron(*/10 * * * *)) could provide the next date and time based on the current date and time.
• the cron function might take a cron expression as a parameter which itself is made up of feel expressions, e.g. cron(0 8 * month *) would mean every day at 08:00 in the month resulting from the FEEL expression month (i.e. evaluate the month variable to a value which is used in the cron expression).

This seems pretty powerful, but there are also some downsides to this:

• users of C7 were able to use CRON to define timer cycles directly in the timer cycle definition. They would expect the same cron support for timer cycles in C8. If they need to switch to FEEL then this is an additional migration hurdle. So we should support such static CRON definitions as well.
• the FEEL spec does not define a data type for timer cycles, so we would need to extend FEEL-scala with a new data type. This means users cannot easily migrate to other FEEL engines and if the OMG decides to add timer cycles in the future, the data types would conflict.
• the OMG might decide to support CRON functions in FEEL directly, at which point our cron() function conflicts with the spec.
• we would need to write our own parser for cron expressions inside the FEEL parser. This could be hard because CRON uses spaces as field separators, but FEEL expressions may also contain spaces. Potentially there exist examples that result in parsing ambiguity.

The downsides may be overcome or accepted, but at this time both @saig0 and I feel that it is best to simply support static CRON timer cycle definitions in Zeebe. We could always reconsider in the future to support both styles.

//cc @felix-mueller