I’m a bit confused about what happens if we don’t use unique business keys within a process.
Specifically, we are modelling activities triggered by a patient at a consultation - we could have a mostly unique key of ${patientId}-${consultationId} - but it would not be totally guaranteed to be unique. A single consultation might trigger more than one instance of the same workflow - if a patient for some reason needed to have two different X-Rays, we might trigger the xray workflow twice, with the same business key.
Is this really a problem? Will something break? The docs state
“The business key uniquely identifies the process instance in the context of the given process definition.”
But it doesn’t seem that this is enforced, as far as I can tell.
More on that - would there be a problem with having the business key just be ${patientId}? That would definitely not be unique - but it’d be quite useful for us, especially as we might not have consultation IDs for all future workflows. What would be the limitations of this be?
The business key is more of a legacy / part of the BPMN spec thing. There have been a few discussions on the forum about its use. The key difference I have seen others mention is that the BK is indexed so seatching I’m very large databases would be more preforment.
A BK as the patient ID is a good idea because it gives you a easy way to find all instances related to that patient.
BUT
A BK can only be set when the process starts. So this can be a problem: such as starting the xray process but not adding the patient info until later on in the process. Or maybe there was a mistake and you need to switch the ID value.
You would not be able to ya fake this with a BK.
You can use process variables as well to solve the issue above. They are not indexed, but they will let you store multiple values and you can filter based on those values in the UI and API using the process variable filters that are part of the GET /process-instance Api.
That’s perfectly fine. I think the docs are just outdated, because the business key used to be unique.
Correct. For reference to other users: You can enforce the business key being unique by adding a database constraint.
The rest is pretty much as Stephen put it, aside from that the business key is a Camunda concept and completely unrelated to the BPMN spec as far as I know.