How to get the JobKey or ActivatedJob Using BpmnProcessId and service type

Hi All,

I have a circumstance in which I need to manage some stage or workflow using the Rest API.

If I have a context of either JobKey or ActivatedJob during the research, we can complete the step and move on to the next stage. However, I am unable to identify the best way to extract this information from Camunda by providing the BpmnprocessId (which was created during the workflow instance setup) and the service type.

Could someone please propose a solution?

Please see the environment specifics below.

  • Spring Boot Version : 2.7.5
  • Camunda Version : 8.2.1
  • spring-zeebe-starter : 8.2.1

Hey @GRajaMca :wave:
Can you be a little more explicit about what you want to achieve? Maybe there is another solution to your problem. :slight_smile:


Hi @Hafflgav,

Please see the following use case, which I am attempting to resolve.

I have a case in which the workflow instance is started by the user in one of the stages, however during the succeeding stage, I require the user’s input, such as some input/file and so on.

To some extent, I agree that we have user tasks that we can utilise to manage all sorts of things, but in this case, the client does not want to browse via operate and do; instead, they want it to be part of their application itself via some rest api that the team will expose.

We will be able to achieve this if there is a way to extract the JobKey by providing the BpmnProcessId and service type, but I am unable to discover a reliable solution for this scenario.

Thanks & Regards,
Raja Gandharaw.

What about using the GraphQL or REST API the Camunda Tasklist provides. To me it seems that you want to rebuild similar functionality as provided already through there.
If you rely on the provided mechanisms of this component things should be a little easier.

Here is the API specification:

Could that possibly solve your problem?

Hi @Hafflgav ,

Yes, you are correct if we wish to use the complete functionality of the Tasklist API. We only have one instance when this feature is required, thus we’re looking for a different approach.

Thanks & Regards,
Raja Gandharaw.