How to get missing details from flow node instances via operate API?

Camunda 8 Topics Discussion & Questions
1

Hello,

I use Operate API to show the status of my ongoing and finished process instances in a table. Every ongoing or finished task of each process is also listed with their details.
Additionally, I display the diagram of each process definition with the help of bpmn.IO. The current state of each task of a process instance is shown with a coloured overlay on the different flow nodes in the diagram.

Sadly, I was not able to get all needed information from the flow node instances via Operate API to display them in my table or diagram. Following information are missing for my use case:

  1. Is it possible to get the name of the flow node instance?
  2. Is it possible to get the id of a process instance, which is called from a “call activity”- Flow Node, in the flow node instance?
  3. Is it possible to assign a flow node instance to the defined flow node of a process definition? So, to get a flow node definition id in flow node instance request. This feature is needed for the coloured overlay.

If the listed things are not possible, could they be features in the near future?

2

Hi @wahlalexandra!

Thanks for the question and highlight of your use case. Operate API was released with the 8.0 version and right now, the first iteration is available - it offers basic functionality and we’re working to iteratively extend the capacities of it to support most use cases.

Answering on your questions:

  1. You can’t get flow node name unambiguously.
    In flow node instance, we have processInstanceKey and type (e.g. service task)
    You can find out processDefinitionKey by processInstanceKey and then find the diagram XML. But type is not enough to find the correct node in the diagram. It can be dozens of service task defined and you can’t say which is the one we’re looking for.

  2. It’s not possible directly at the moment. The possible workaround could be to get processInstanceKey from the current flow node instance and then search for process instances filtered by parentKey=processInstanceKey and bpmnProcessId= - but this will work only in the case when there is exactly one flow node instance in current BPMN that can call this process (with given bpmnProcessId).

  3. See point no.1 - it’s not achievable at the moment.

We have an item on our Product Roadmap to enhance Operate API / History API, so we’ll take into consideration the use case that you’ve described.

Do you have a timeline till when you need these capabilities? Just to mention - if you’re a Camunda customer, you can also raise a Feature Request in Jira.

If you have any other questions, I will be happy to help.

Best,
Aleksander

3

Hi @aleksander-dytko,

thanks for the informative response. @wahlalexandra and me work on the same project.
Basically we want to be able to render the BPMN diagram and provide the status of running and finished process instances to our internal users in our own custom developed UI. This gives us the possibility to connect the processes with other data and provide a seamless user experience. We are working on this custom UI since half a year, initially with the intent to use Camunda Platform 7. Since the Camunda Platform 8 announcement we decided that it doesn’t make sense to further develop something related to Platform 7 as we would anyway need to migrate in a few years (and the effort of it will increase with every bigger step we do until then). This means we are currently in a blocking situation.
As you asked for our timeline - we planned to release the first MVP of our custom UI in Q3 2022. Any initiative in increasing the prio on the Operate API / History API enhancements is therefore much appreciated.

We are no Camunda customer yet, but have been in contact in the past to be one. As we plan to reach the productive stage within this year I will make sure that this process will speed up now.

Kind regards,
Patrik

4

Hi @pfriedl,

Thanks for the description of your use case, this helps me a lot to understand what needs to be supported. I agree that this is a very valid scenario and probably it will appear even more often in the following months.
Let me check what we can do to increase the prio on our product roadmap, taking into consideration other items. I’ll get back in this thread with information.
From your perspective, would it be ok to keep the same API version with added endpoints, or would you rather expect a new API version?

Regards,
Aleksander

5

Hi @aleksander-dytko,

thanks for your response and considering our use case. To answer your question, we would prefer the same API with added endpoints.

Looking forward to your feedback regarding a possible re-prioritization.

Regards,
Patrik

1 Like
6

Hi @wahlalexandra @pfriedl,

Some time ago, we have released additional endpoints to visualize the status of the running instances in the external system. Did you have a chance to check it?
The documentation is available here.

Best,
Aleksander

7

Hi @aleksander-dytko,

thanks for catching up on this. We tried it out and it solved all our problems - means we could finally complete our custom Operate-like UI.

Regards,
Patrik

1 Like
8

That’s great to hear! Thanks for confirmation @pfriedl!

Have a nice day,
Aleksander

9