I’d like to use multi tenancy with different schema, but I have no ideia how to start, what configuration I need to do to accomplish that? Or isn’t possible to use multi tenancy on embedded engine?
Please refer this https://docs.camunda.org/manual/latest/user-guide/process-engine/multi-tenancy/
and this https://github.com/camunda/camunda-bpm-examples/tree/master/multi-tenancy.
Also see: https://jira.camunda.com/browse/CAM-10859
Although this should be possible, it fails due to different class path scanning behavior depending on whether you run the app from IDE or console.
Creating another process Engine programmatically not solve the problem?
ProcessEngineConfigurationImpl configuration = new StandaloneProcessEngineConfiguration();
ProcessEngine processEngine = configuration.setIdGenerator(new StrongUuidGenerator())
.setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE)
.setJdbcDriver(“com.microsoft.sqlserver.jdbc.SQLServerDriver”)
.setJdbcUrl(“jdbc:sqlserver://localhost:1433;databaseName=camunda”)
.setJdbcUsername(“sa”)
.setJdbcPassword(“camunda”)
.setJobExecutorActivate(true)
.setAuthorizationEnabled(false)
.setProcessEngineName(“camunda”)
.setHistory(ProcessEngineConfiguration.HISTORY_FULL)
.buildProcessEngine();RuntimeContainerDelegate.INSTANCE.get().registerProcessEngine(processEngine);
hi @alanfosk, apparently it created another process engine, but when I call JavaDelegate as Java Class the @Autowired annotation is injecting null value when the process engine is not the ‘default’, and when I call JavaDelegate using Delegate Expression it returns a exception:
org.camunda.bpm.engine.ProcessEngineException: Unknown property used in expression: #{logger}. Cause: Cannot resolve identifier ‘logger’
Running two embedded engines would require the spring autowiring to distinguish between those engines … this is not supported in the starter, as we agreed that if you had the need of running multiple engines in a microservice environment, you would just set up another node for the other engine.
If this assumption turns out to be not sufficient for actual runtime problems, please file a feature request in the camunda jira.