Currently, we are using Self-deployed Camunda and while integrating with our backend system I’ve encountered one issue with Operate API.
I found that there 2 APIs: public(operate/v1). and internal(operate/api). I see that Operate Java library is built for public API. Is there any library to integrate with internal API? If no, do you have any plans to build one in the future?
Hi @Ali_Akiltayev - no, because it is an internal API and subject to changes even between minor versions, which is the reason that it is kept internal. Of course, due to the nature of the web, you can call those endpoints from your application, but they should not be considered stable for external production use.
If there are features in the internal API that you need or would like to see brought to the public API, definitely let us know and we can raise a feature request!
What is missing in Public API for me is to search Process Instances by Variable name and value. This feature is present in Internal API. Could you please suggest any workaround?
I saw in Java client Filter interface and it would be nice if I could instantiate VariableFilter, set it in SearchQuery and search process instances using that filter.
Hi @Ali_Akiltayev - I believe this endpoint is exactly that: Search variables for process instances | Camunda 8 Docs
The endpoint you provided searches for variables and gets only processInstanceKey, but I need processInstance objects. In other words, I need to filter processInstances by variable(name, value).
@Ali_Akiltayev - yes, and then you can use that key to query for the process instance. I don’t know if it’s strictly RESTful to return all of the process instance data when searching for variables, which I think was at least part of the reason for this separation in the API’s.
Can you share a bit more about your particular use case? Why are you searching for PIs by variable, and what are you then doing with all the PI information? This will help formulate the feedback for the product team.
In our case, when user runs the process, our backend system writes into variables {initiator: userEmail}. And then when user wants to see all his/her completed processInstances, I wanted to search for all process instances with state Completed and variable {initiator: userEmail}.
Hi @Ali_Akiltayev - how are your users starting the processes? Most API calls to start a process return the process instance ID/key, which you can save in your database. This may be a more efficient way of handling it. Your processes can also be modeled to “push” updates back to your system at key points (for instance, using a job worker or Connector).
Either way, this is still good feedback that I’ll take to the team!
The user sends API request to our backend system, then using client credentials flow authorization our backend system runs the process on behalf of user and returns process instance key, as you suggested. We do save this key in our database, but we want to avoid making N time calls to Operate API to retrieve all N user process instances from Camunda. However, by making 1 call and retreiving all process instances by initiator:userEmail would really simplify communication with Camunda and significantly increase performance of our service. Please, find attached what I meant that Internal API has and Public API not.
@Ali_Akiltayev - personally, I think a bulk GET operation for PIs would make more sense than returning all the PI data with a variable search. Both would achieve what you’re looking for I think. I’ll take this feedback to the product team!
And you can certainly try to use that internal API, but we don’t guarantee backward compatibility between versions or that breaking changes won’t happen during patch releases, etc.