I’m using Camunda 8 with Zeebe Engine but have opted not to use Operate in my deployment—only Zeebe and the required components.
I have successfully deployed a BPMN file to Zeebe, and now I need to retrieve its BPMN XML content. I’m aware that Operate provides an API for this, but since I’m not using Operate, how can I get the XML in this setup?
Additionally, I’d like to understand where process instance data is stored. Does Zeebe handle it internally, or is it stored in Elasticsearch? If there are any articles or documentation covering this in detail, please share.
Hi @vishu899 - I don’t believe you can retrieve the XML from Zeebe. The XML is stored in Elasticsearch, so you can query Elasticsearch directly for the XML (here is how Operate does it).
PI data for running instances is stored in Zeebe in an internal RocksDB instance; data is exported to Elasticsearch based on your configuration, and only purged from Zeebe when the PI has completed. How long the data remains in Elasticsearch is based on your retention configuration. You can read more about Zeebe’s architecture here:
yeah i worked on it
let me share details, it is right that xmls can be fetched from elastic search , but if i want than i have to use indices for operate and as i mentioned we don;t want to use operate so if operate will be disabled in deployment , i assume operate indices will never be generated
@vishu899 - I admit, I am not certain how the model is exported to Elasticsearch. Is there a reason you don’t want to use Operate? And what is the use case for needing to fetch the XML back from Zeebe, as you already have the XML from your deployment?
Our system runs on Camunda 7, using only the Camunda engine with BPMN containing service tasks and message events. We retrieve data from a custom extension element in service tasks.
As we migrate to Camunda 8, custom elements are unsupported, so we’re switching to task headers. Since task headers only support key-value pairs, we store multiple values as a JSON string. However, this requires significant code changes. A better alternative would be manually parsing the XML file to extract data.
We avoid using Operate because:
From version 8.6, both Zeebe and Operate are paid. While we may pay for Zeebe, Operate adds extra costs.
In Camunda 7, we used engine APIs instead of an external tool. In Camunda 8,If we use operate it would require an additional container just for one API call. Fetching the XML from Zeebe or Elasticsearch would optimize deployment.
to call Operate API we need authentication method,If it is like we just add demo, demo in parameters of operate API and it allow api call than also it is fine but here it is via cookie or via token, but all these operate api call in our system will be internal call so we don’t want authentication and we didn’t find any option to remove authentication,
Additionally, I need help understanding how to delete a deployment definition.
I came across this forum post: Camunda 8 delete deployed process, where it was mentioned that deleting a deployment is not possible. However, Niall referenced a Camunda blog which is edited now and states that deployment deletion is now possible using Operate. see it here
If possible Could you please help me understand which internal API Operate calls to delete a deployment?
Hi @vishu899 - I am not one of the engineers, so I don’t know precisely how that functions inside the product. I’d recommend reviewing the source code; all the source code (for Zeebe, Operate, the exporters, everything except Modeler) is available at GitHub - camunda/camunda: Process Orchestration Framework. I thinkthis line is the start of the delete operation.
