Timer Start Event change after process deployment

Camunda 7 Topics Discussion & Questions
1

We would like to automate some routine task which have to be started on predefined schedule. It seems that Timer Start Event fits best for this task. But as we can understand the schedule has to be defined at process design time and it is fixed. Is it possible to change the schedule of a Timer Start Event after the process has been deployed without full cycle model changed and process redeployment withing Camunda API?

1 Like
2

if you use spring or cdi, you can specify an expression for the timer cycle intead of a fixed value.

just use any bean in your context that returns a valid ISO cycle code.

Then, that bean can dynamically determine the required value, for exampel by accessing configuration properties or environment variables.

Note that this will not change an already created job, so changes will only apply to the next job in the cycle.

1 Like
3

It is correct as @jangalinski says that you can use an expression for the timer. However after the process instance has been created a change in the object bound to the timer will not be reflected in the timer itself.

To change it runtime you would need to do it like this:

/**
 * Sets a new value for a timer
 *
 * For use if there is only one timer in the process. Will fail if there is more than one timer with the given name waiting at runtime for the process
 * instance
 *
 * @param processInstanceId
 * @param timerName
 * @param newValue
 */
protected void setTimer(String processInstanceId, String timerName, Date newValue) {
	Job timerJob = getEngine().getManagementService().createJobQuery().processInstanceId(processInstanceId)
			.activityId(timerName).active().singleResult();
	getEngine().getManagementService().setJobDuedate(timerJob.getId(), newValue);
}
2 Likes
4

Thanks.

@jangalinski currently we do not use Spring or CDI but we will check the approach to get new ISO cycle code from the application via bean. Currently the whole

@egil, it seems that your proposal is similar to REST API PUT /job/{id}/duedate and the parameter has to be a valid date. This means that I can change the next fire time but not the schedule. Am I right?

In general our design is to have our application and Camunda as separate as possible and all the communication is done via REST API on both sides.

We currently have some ideas about the solution (not yet implemented / tested):

  • Introduce a process variable with the schedule set via process start REST service. In case we need a change we stop the process instance and start a new one with the new value. The application controls that the only one process is running at the same time.
  • Similar to the previous solution but some the variable is changed via REST service POST /process-instance/{id}/variables.
  • Similar options but the process has a step to control a single instance itself.
5

Hi, yes, that seems to be a correct assumption :slight_smile: We use the process engine as an embedded part of our solution, so java api is more convenient for us.

You can also just set the schedule just to be an input variable using an expression (typically ${activationDate}) where the variable is set at execution start afaik.

6

@jangalinski is this functionality documented anywhere?

if you use spring or cdi, you can specify an expression for the timer cycle intead of a fixed value.
just use any bean in your context that returns a valid ISO cycle code.
Then, that bean can dynamically determine the required value, for exampel by accessing configuration properties or environment variables.
Note that this will not change an already created job, so changes will only apply to the next job in the cycle.

7

Wow, this is an old thread … you can use expressions basically everywhere (candidate user, assignee, …), and, yes, (at least for timers) this is documented: https://docs.camunda.org/manual/7.11/reference/bpmn20/events/timer-events/#expressions

1 Like
8

I remember Start Events being “special”, such as the Form Key cannot be a expression because its retrieved outside of the execution, thus a expression did not work/are not evaluated. So was thinking a Start Event timer for a process would/could have the same limitation. The example in that timer event is for a Boundary event, so it makes sense; but a Start Event is a “weird” space because its outside of a execution.

9

I guess that camunda registers a timer job for the process on deployment and therefore evaluates the expression (which is based on singleton beans in your app context) … so this should work. But honestly: Its been a while … I would have to build a spike to verify.