Get Job for timerId

[Filip H]

Hi,

I posted a feature request to the Camuna Jira and was redirected to repost it here to discuss it. This is the request.

I also just realized that the text is not clear enough. From my observation the jobHandlerConfiguration field in JobEntity represents the Id of the timer if the job is for a timer. I think that this is not difficult to implement into Camunda and I should be able to do it without problems. However, I wanted to ask about the use case of it and whether you think that it is useful to have something like that. 

I would appreciate the feedback.

Here is also the text:

I have a proposal feature for the engine, I couldn't find if it has been already proposed or discussed. Let me know what you think. 

I think that this can be easily implemented with only adding a new function to the JobQuery interface, and adding another condition in the named query 'selectJobByQueryCriteriaSql' in Job.xml. 

There is still a way to get the Job for a timerId and it looks like this: 
ProcessInstance processInstance = processEngine.getRuntimeService().createProcessInstanceQuery().processInstanceId(processInstanceId).singleResult(); 

JobDefinition jobDefinition = managementService.createJobDefinitionQuery().processDefinitionId(processInstance.getProcessDefinitionId()).activityIdIn(timerId).singleResult(); 

Job job = managementService.createJobQuery().processInstanceId(processInstanceId).jobDefinitionId(jobDefinition.getId()).singleResult();

[Daniel Meyer]

Hi Filip,

interesting. What would the new API look like?

something like

managementService.createJobQuery().activityId(...).list()

I suppose?

Would the Query join to the JobDefinition table?

Regards,

Daniel

[Filip H]

Hi Daniel,

Yes, it would look like that if we want to be able to get a job for any activity and in that case we would have to join to the JobDefinition table in order to get the activityId. We will only need to join if the activityId is set, otherwise there is no need.

However, we can also have something like this:

managementService.createJobQuery().timerId(...).list();

For the timers we do not need to join the JobDefinition, the HANDLER_CFG_ is the timerId. However, I would understand if you do not want to rely on that.

Cheers

Filip

[thorben.lindhauer]

Hi Filip,

I would prefer the solution of joining the job definition. Firstly, it is a more general solution. Secondly, the fact that the job configuration matches the activity id is an implementation detail that might change in future releases if there is need. So far, this database field is not exposed anywhere in the public API and I think we should keep it that way.

Cheers,
Thorben

[Filip H]

Hi Thorben,

I agree with you. It is a more general solution and the database field is already used in the JobDefinitionQuery.

Should this also be added to the JSON API? Do you think that I should do this?

Cheers

Filip

[thorben.lindhauer]

Hi Filip,

If you are willing to add this also to the REST API, then absolutely, go ahead.

Thanks,
Thorben

[Filip H]

Hi, 

Thanks everyone for the input that you provided. I worked on the issue today and created a pull request with the changes. Have a look at it and tell me what you think. I couldn't execute the engine-rest tests to check. What about the documentation, should I add it there, or someone else should do it?

Cheers

Filip

[thorben.lindhauer]

Hi Filip,

Thanks for your pull request. We'll have a look at it in the next days. As tomorrow is the code freeze for 7.2.0 and we are quite busy, I cannot guarantee that it will make it into that release.

Regarding docs: feel free to submit a pull request to https://github.com/camunda/docs.camunda.org

Cheers,
Thorben

[Filip H]

Hi Thorben,

No problem it was my pleasure. I understand for the code freeze, there is a way to get the wanted job by using two queries, so if someone needs it they will find it here by searching.

I'll have a look at docs and submit a pull request during the weekend probably.

Cheers

Filip