Updating business key of active process does not update history tables (scripting using private methods)

As of 7.10 we can modify the business key at runtime/in delegation code. But when using this feature it does not update the history tables.

Not updating the history tables ends up a bug issue because the history tables now are not a accurate picture of updates that occurred in the runtime (because the business key was only updated once the process completes).

The business key is supposed to be a business identifier. But now the same process instance can have two different business identifiers depending on which table you look at (runtime vs history)

Hi @StephenOTT,

Can you provide a test case or example that reproduces this?

Because I just wrote one where the business key is updated through a JavaDelegate, and the historical data was updated as well.

The historic update is invoked here: https://github.com/camunda/camunda-bpm-platform/blob/501464394f8963680628b8a74ab4010c4cfffd3d/engine/src/main/java/org/camunda/bpm/engine/impl/pvm/runtime/PvmExecutionImpl.java#L1137-L1145. Is it possible that you have a lower history level?


Is your process over when you checked the history table?

Yes, it’s a small process with a single ServiceTask. The JavaDelegate there updates the business key.

Okay, took some further testing to get the specifics:

With 7.10 it introduced the processBusinessKey property and related getters and setters in the ExecutionListener and JavaDelegate implementations

Prior to this there was the businessKey property, which continues to exist in 7.10+. So in 7.10+ there is the businessKey and the processBusinessKey properties.

There also continues to exist the getBusinessKey() method that is carried from CoreExecution.

This means someone can access getBusinessKey, getProcessBusinessKey, and setProcessBusinessKey.

The issue comes down to Scripting… If you use a script language such as Groovy or Javascript, you can access the properties directly, and/or use methods such as `setBusinessKey()’.

So in Groovy and Javascript, you can execute execution.setBusinessKey("myKey"), and the business key will be set in the runtime tables (but not in the history tables). When the process instance completes, the history table is updated with the business key that was previous set using the setBusinessKey(). This creates a weird problem for script writers, because it is an unintended behavior that does not generate a error, and “Eventually” resolves it self… But when someone does a history table lookup during the process being active, they would not get the expected result.

Additionally it increases confusion for script writers when they are writing “getBusinessKey” which functions as expected, but they have to write “setProcessBusinessKey()”. Which can create further confusion if script writers are accessing the properties directly rather than using the methods:

val myKey = execution.businessKey
execution.businessKey = "123"

Okay, so the issue is not actually a bug. This seems more like incorrect use of the engine since the properties are meant to be accesses through the appropriate getters/setters.

Do you think that making it clearer in the documentation that the only way to update the business key in runtime code, is through the setProcessBusinessKey method would help?


@nikola.koevski i hope updating docs makes clearer to the developers to use the setProcessBusinessKey method to update the business key, but still anyone can directly access the setBusinessKey() from scripting . I hope that we can reduce the visibility so that public api’s don’t have access to it, if it doesn’t lead to further complexity.

Hey @aravindhrs,

Actually, setBusinessKey() is not public API, it’s part of the internal CoreExecution class, and can’t be accessed unless you cast the provided DelegateExecution instance (which would cause incorrect behavior in the engine).

However, I’m not an expert in Scripting engines and I’m not aware if it’s possible to explicitly prevent them from violating the encapsulation policies set by Java. If you know of a possible way to do this, feel free to provide a PR or open a ticket on our issue tracker. Otherwise, I would create a ticket to make the docs clearer.


Agreed that this is not a “bug”.