Hi,
I’m new to Camunda. I’ve tested the embedded version of Camunda 7 with PostgreSQL and it fits our needs because we can integrate the workflow engine with our transactional context that do not just manipulate the workflow.
If I understand well, with the new version 8 we will not be able to use Camunda the same way. Because there is no embedded version (am i correct ?) and more, the persistence is no longer available for database such as PostgreSQL.
If I’m correct, how, you as version 7 user see this evolution ?
You correctly described how it is and will be. You won’t be able to use ACID transactions in Camunda 8 to provide data integrity. This is possible in Camunda 7, but is also not a good idea. Bernd Rücker had a blog post about it. The main idea is that there is no integrity in the sense of ACID but eventual intergrity which is achieved by the dedicated error handling and compensating actions in the process.
First thanks for your reply.
I’ve read this blog and unfortunately we’re not agree with this conclusion and the ACID property is important for us. The compensation is not always possible.
Also, the big problem is the infrastructure requirements when you use ElasticSearch it’s not so easy to install on our information system
Hi Erik - let’s try to separate things (requirement around elastic) and look at ACID fist. Could you describe your scenario briefly and why you cannot compensate?
Do you rely on XA transaction for ACID or is all logic you do completely in the same PostgreSQL instance?
Ok thanks for the following
I’ve a Document that needs to be validated. This validation requires to fill some properties of the document. This validation is done through an existing WebService that have to check some rules before beeing able to validate. Theses rules , if the check is true have to be stored into the database with the document itself. I also need to “complete” the task “Document validated” using the workflow.
The save of the document properties and the rules needs to be consistent with the modification of the workflow. An undo, without a classic DB rollback is complicated because some rules triggers other rules and so on at many levels.
Call Webservice to check rules (which is always a separate transaction - as I would no expect the Webservice being part of the ACID transaction!) returning some data
Make a decision based on that data in the workflow (XOR Gateway)
Add data and document to your PostgreSQL database (this could still be one atomic ACID step)
Complete task in workflow
Now (1) and (3) could be a service task in a BPMN model.
For (1) what could happen is, that if the webservice call returns and the connection to the workflow engine is lost, you might to retry the Webservice call. This is exactly the same behavior you would have in Camunda 7 - and no way around it without distributed transactions. And typically when checking rules, this is idempotent - so it does not matter.
For (2) the PostgreSQL stuff cann still be done in an ACID transaction that either completes or rolls back completly. What could happen is again that the connection to the workflow engine is lost after the PostgreSQL commit. In this case you have a temporary inconsistency. But you the workflow engine will retry the service task - and you have two options. First, the operation is also idempotent and retrying does no harm. Or you might need to check if the data is already written and skip writing it yourself. In any way, you can easily recover consistency in this case.
So I don’t see a hard problem here - WDYT? But maybe I misunderstood something in the situation?
Best
Bernd
Hi and thanks for your reply
But, if I’ve an embedded workflow engine I do not have to “find a solution” to a problem that I do not have. The transactional context is enough to do everything consistently.
I fact, I’m very surprised by the architecture of the version 8. It has a huge impact on someone who uses the embedded version 7…and sincerely, the embedded version is great when you’ve to add workflow capabilities to an existing application.