My organization is currently using Camunda 7. Since Camunda 7 provides a Postgres schema, we were able to create an adjacent schema that provides additional data points via JOINs to the Camunda schema. We are looking to move to Camunda 8. However, since Camunda 8 no longer has an exposed RDBMS schema, those JOINs appear to no longer be possible. What is the recommended solution for being able to customize Camunda 8 similar to how we are doing for 7?
Hello @Davin ,
there is no RDBMS schema exposed as there is no more relational database in Camunda 8.
If are embedding the process engine that deep in your system, one possible solution would be to create an exporter that interacts with a schema that you provide and save state updates from the emitted events there.
Please keep in mind that a relational database can become a performance bottleneck.
We do not use an embedded process engine.
As an example, in Camunda 7, we would be able to (transactionally):
- Issue a REST call to Camunda to start a process instance, getting back the process instance ID as a response.
- Insert a row into our schema using the process instance ID as a foreign key, now allowing us to capture additional data tied to a process instance that Camunda doesn’t already capture.
- Execute a query to fetch all data for the above process instance, from both Camunda, and our schema at once.
It sounds like this is no longer possible in Camunda 8?
The issue we saw with Exporters is they do not appear to be real-time updates. So while we may be able to combine steps 1 and 2 above into an Exporter that reads IDs from the stream, and inserts rows to our schema, step 3 may fail due to the Exporter not having ran yet. Is this our only option?
Hello @Davin ,
if I has to implement this, I would do the following:
Create a process instance using gRPC, getting back the process instance id.
Save it to the database as foreign key, allowing all state updates to have it as constraint.
Capture the state of the process instance together with the business data.
In fact, the exporter is real-time. However, it should always export events to some kind of data storage (index, queue, cache, …).
From there, your application could capture the events, pop them and insert the db updates.
I hope this is something you can rely to.
I would not try to “migrate” to Camunda 8, but rather treat Camunda 8 as a completely new product. There is not much in common besides the name part and the company behind it. And the BPM area of course.
@jonathan.lukas, we will POC this, hopefully with positive results. Thank you.
@fml2, that’s precisely what we’re doing, which is why I was careful to not use the word “migrate.” The fundamental problem is “how do we attach extra data to Camunda records, keeping referential integrity?” which sounds like that is not possible in Camunda 8.