Passing timer job dueDate to started process instance?

Camunda 7 Topics Discussion & Questions
1

Hi,

I want to use the “dueDate” value of the timer-start-event job inside the process instance to pass it to service tasks or for monitoring/statistical purposes.

In its simplest form, I would like to collect some KPI about job execution delay (dueDate as defined in the timer job vs. startTime of the process instance), which may then serve as a source for auto-scaling.

The only extension point I was able to see so far is the “customJobHandlers” in the engine configuration, but those do not get passed the data of the job that they should handle (of course, currently it’s not needed).

Is there another infrastructure for hooking into the job-to-start-process handling or some reliable way of getting access to the timer jobs’ data from inside the started process instance?

2

HI @ancoron,

The public API way would be: Query for the timer job in an execution listener, then access the due date. That should work if the job is not deleted concurrently.

The non-public API way: Use Context.getJobExecutorContext().getCurrentJob().getDueDate() in the execution listener.

Cheers,
Thorben

3

Hi @thorben ,

sorry for getting back to this topic this late but I just managed to get some time for trying this out. It works like a charm! Currently, I have it implemented in a process as an end listener of script type “javascript” as follows:

var jobContext = org.camunda.bpm.engine.impl.context.Context.getJobExecutorContext();
if (jobContext != null && jobContext.getCurrentJob().getDuedate() != null) {
    execution.setVariable("scheduleFireTime", jobContext.getCurrentJob().getDuedate().getTime() / 1000);
} else {
    execution.setVariable("scheduleFireTime", java.lang.System.currentTimeMillis() / 1000);
}

This way the process can still be started explicitly or by an asynchronous continuation (e.g. in the context of a call-activity) but uses the Timer Jobs’ due date if it was started by a timer job.

I am thinking of an additional column in the process-instance history table (e.g. something like “timer_fire_time_” or something, so that one can access this information without the need of a process instance variable.

What do you think?

4

Glad to hear it’s working for you.

Not sure. We already have ACT_HI_JOB_LOG that contains details on when which job is executed. In terms of history data, this column would be redundant.

5

Oh yes, forgot about that because I am using history only at level AUDIT. Sorry for my confusion. :slight_smile:

6