Hello,
as this and this answers state, one has to use the file processes.xml to set the tenantId for the process models deployed with the Spring Boot based process application. But this is not the “native” way to do things in Spring Boot. In Spring Boot, one usually uses properties to set application parameters.
Is there a special reason why the creators of the Spring Boot integration didn’t expose the tenantId as a property?
Thank you for your insight!
As one of the creators, I can answer this: We assumed that due to the nature of spring boot micro services, there wont be a use case for multi-engine/multi-tenant setups as we expected that you would just deploy a dedicated micro service for that.
Retrospectively, I don’t know if I would still follow this argument as there where a lot of requests for this.
We are currently using this lib to configure multi tenant setups:
using the application.yml like this:
camunda:
bpm:
deployment:
archives:
- name: Default
path: tenants/default
- name: TenantOne
tenant: one
path: tenants/one
Maybe that could be an option for you as well.
Hello @jangalinski,
thank you for the info and the link. The lib actually does more than we’d need. We have multiple applications working with the same process DB. Each one belongs to at most one tenant which we’d like to specify via application.yml. There are no multiple tenants per application.
I’m now about to create a small engine plugin that would just set the deploymentTenantId property in the engine configuration. Everything else would not change, i.e. the presence and contents of processes.xml and the location of the resources (BPMN/DMN models).
Cheers!
I’m now about to create a small engine plugin
Hrm… It turns out that it’s not that simple. Setting the field “deploymentTenantId” in the engine configuration (in the plugin’s “preInit” method) does not have the desired effect.