Is it doable to access ProcessDefinition in DbSqlSession?

What I would like to achieve is that overrides flush() method from DbSqlSession so that it performs different operations based on ProcessDefinition.
(i.e. bundle entities together and send to some MQ if current ProcessDefinition has some flag)

The method I took is looping through insert/update/delete objects to find processDefinitionId, then query ProcessDefinition by its Id.

code snippet like this

    public void flush() {

        for(Map<String, Entity> item: this.insertedObjects.values()) {
            for(Entity entity: item.values()) {
                if (entity instanceof ExecutionEntity) {
                   String procDefId = ((ExecutionEntity) entity).getProcessDefinitionId();
  // ...

It’s ugly but somehow works. Please enlighten me if there is a better way.

Hey @sanbaispeaking,

I would strongly advise against doing things like this. Messing with the DbSqlSession can lead to bugs that are really difficult to find. It is one of the lowest levels in Flowable and it is not meant to be overridden.

In your place I would take one step back and try to understand what kind of business use case you have. Then we can look into an alternative solution. You might be able to solve your problem with transaction level listeners when new entities are created. At this point you have access to the process instance / definition and you can send things to an MQ.


Hi, Filip, thanks for your reply.

I’m currently on a low-code platform project and searching for high throughtput automation solutions.
As far as I konw, flowable-engine persists process state to DB, so that the system throughput is bound to DB. A premium DB cluster with lots of partitions would yield that much throughput but the cost is too much.

My take is to utilize MQ for state persistence:

If has flag been set on process definition ( DB trx required), a process instance’s state(jobs, executions, variables .etc) would be send to MQ and later picked up by a consumer, so that the instance can continue. On this circumstance no DB writes required. And this approch leads me to the previous crux.
Is this possible to solve with transation level listeners? Any suggestions would be appreciated.

And thanks to you guys again for the gread framework.

Hey @sanbaispeaking,

This is some low level things. If you want to have custom persistence I would suggest looking into overriding the different DataManagers, doing this on the DbSqlSession level might be a bit too brittle.

Have you measured the performance and throughput? There are other mechanisms that you can use to reduce the load on the database.