Restricting Signal Event to Specific Deployment

[jonathanlevis]

I’m running a Spring Boot web app which is deployed as a war, inside I’ve got flowable running as a service performing some of the business logic…

• When the server starts up, the bpmn files are deployed from the resources directory of the war and show up in the DB.
• When the business logic is run, it executes specific processes by signal… my code for executing the flowable business logic looks something like this:
  processEngine.getRuntimeService().signalEventReceived(signalName, processVariables);

My issue is when a second server running the same web app starts up, the war is deployed and also has a copy of the BPMN files which get deployed to the DB.

• The BPMN are assigned a different deployment id than the first server
• When starting the processes by the signal above, I can see that I’m querying against all processes (not just the ones belonging to my engine)

Looking at the documentation, I was considering implementing scope at the bpmn xml level:
https://www.flowable.org/docs/userguide/index.html#bpmnSignalEventDefinitionScope

Is this the best approach?
Maybe I could ensure my BPMN files are only deployed once to the database and read by all servers (i.e. if they have already been deployed, don’t re-deploy them under a different deployment id)
Not sure how to do this though

[filiphr]

Hey @jonathanlevis.

If you are really using the exact same war then your BPMN files are identitcal. Therefore the second server should not deploy the files again (if you are using the Flowable auto deployment).

Are you by any chance deploying the files manually by using the DeploymentBuilder? If that is the case then I would suggest that you use enableDuplicateFiltering(), this would ensure that if the same files are being deployed again the deployment would be skipped (i.e. you’ll get back the previous deployment)

[jonathanlevis]

I am using a the auto deployment based off of something like this: https://github.com/flowable/flowable-engine/blob/flowable-release-6.4.2/modules/flowable-rest/src/test/java/org/flowable/rest/conf/engine/EngineConfiguration.java
What about in local development, using the same branch?
Does the entire code base have to be identical? or only the BPMN files?

[joram]

@jonathanlevis

Does the entire code base have to be identical? or only the BPMN files?

The duplicate filtering only looks at the BPMN files.

@jonathanlevis

When starting the processes by the signal above, I can see that I’m querying against all processes (not just the ones belonging to my engine)

Not sure I’m following here. Even when you have multiple deployments of the same BPMN, the signal will only be fired for the latest version (on deployment signal event subscriptions of old versions are removed). So what kind of query are you seeing?

[jonathanlevis]

@joram

The duplicate filtering only looks at the BPMN files.

Got it, thanks

@joram

Not sure I’m following here. Even when you have multiple deployments of the same BPMN, the signal will only be fired for the latest version (on deployment signal event subscriptions of old versions are removed). So what kind of query are you seeing?

Before starting my process by signal with the following code:
processEngine.getRuntimeService().signalEventReceived(signalName, processVariables);

Query I’m using is below to see what’s loaded:
flowableService.getRepositoryService().createProcessDefinitionQuery().list()
I know .latestVersion() would probably give a more accurate picture…
However I see the same processes with different deployment ids in ACT_GE_BYTEARRAY

This is in our development environment though so it may be that another developer is deploying as well but mainly I’m the only one who is running the code that deploys the bpmn files…

[joram]

@jonathanlevis

Before starting my process by signal with the following code:
processEngine.getRuntimeService().signalEventReceived(signalName, processVariables);

Yes, that’s correct.

@jonathanlevis

However I see the same processes with different deployment ids in ACT_GE_BYTEARRAY

That probably means you have multiple deployed versions of the same process. In this case, only the latest version should receive the signal event.

@jonathanlevis

Query I’m using is below to see what’s loaded:
flowableService.getRepositoryService().createProcessDefinitionQuery().list()
I know .latestVersion() would probably give a more accurate picture…

What do you mean with ‘loaded’? Where are you executing this logic?

[jonathanlevis]

@joram

That probably means you have multiple deployed versions of the same process. In this case, only the latest version should receive the signal event.

Where is the version number maintained? I see a REV_ column in that table but it’s empty…

@joram

What do you mean with ‘loaded’? Where are you executing this logic?

Forgive my use of loose terminology, I assume this logic allows me to see what rules have been loaded into the engine…
This logic is executed directly before this line:
processEngine.getRuntimeService().signalEventReceived(signalName, processVariables);

[joram]

@jonathanlevis

Where is the version number maintained? I see a REV_ column in that table but it’s empty…

When querying the process definition, the version is in the VERSION_ column.

When you have multiple deployments of the same process definition (even with multiple engines on different nodes), there should always be one with the highest version. That one will have the event subscriptions (check the ACT_RU_EVENTSUBCR table).