All persistent entities managed by the process engine (Process Instances, Tasks, …) have unique Ids. These Ids uniquely identify an individual task, process instance, etc. When these entities are persisted to the database, the ids are used as primary keys in the corresponding database tables.

Out of the box, the process engine provides two Id generator implementations.

The Database Id Generator

The Database Id Generator is implemented using a sequence Generator on top of the ACT_GE_PROPERTY table.

This id generator is good for debugging and testing since it generates human readable ids.

The UUID Generator

The StrongUuidGenerator generates identifiers using UUID v7 (time-based epoch, RFC 9562).

UUID v7 identifiers combine a millisecond-precision Unix timestamp with random bits. This makes them:

• monotonically ordered within a millisecond — beneficial for database B-tree index locality,
• globally unique without central coordination,
• free of MAC address — no node identifier is embedded, unlike UUID v1.

In the EximeeBPMS Full Distributions, the StrongUuidGenerator is preconfigured and the default Id Generator used by the process engine.

If you use an embedded process engine configuration and configure the process engine using Spring, you need to add the following lines to the Spring configuration to enable the StrongUuidGenerator:

<bean id="processEngineConfiguration" class="org.eximeebpms.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">

  [...]

  <property name="idGenerator">
    <bean class="org.eximeebpms.bpm.engine.impl.persistence.StrongUuidGenerator" />
  </property>

</bean>

Security Considerations

UUID v7 embeds a millisecond-precision timestamp but does not embed a MAC address or other node information. This means:

• creation time can be approximated from the identifier,
• identifiers are partially predictable within a millisecond window,
• no hardware or network information is exposed.

For most use cases this is an acceptable trade-off: the time-ordering improves database write performance significantly, while the random bits appended within each millisecond still make enumeration or brute-force infeasible in practice.

Note that identifiers generated by the engine should not be relied upon as a security mechanism. Proper authorization checks must always be enforced.

Legacy UUID v1 Generator (Deprecated)

The UuidV1Generator class is available as a migration aid for environments that require UUID v1 identifiers for compatibility reasons. It embeds a timestamp and the MAC address of the network interface, which may leak system metadata.

To activate the legacy generator, set the id-generator property to uuid-v1 in your distribution configuration:

Spring Boot (application.yaml):

eximeebpms.bpm:
  id-generator: uuid-v1

Quarkus (application.properties):

quarkus.camunda.id-generator=uuid-v1

bpm-platform.xml (WildFly / Tomcat shared engine):

<property name="id-generator">uuid-v1</property>

Migration Note

Upgrading from version 1.2.x or earlier:

• does not affect existing data — IDs already stored in the database remain valid,
• is backward compatible — IDs remain standard UUID strings,
• improves INSERT throughput on indexed columns due to monotonic ordering of UUID v7.

If you temporarily need UUID v1 for compatibility, configure id-generator=uuid-v1 (see above). That option itself is deprecated and will be removed in 1.4.0.