Multi-tenancy refers to a single application instance that can serve multiple organizations and their user groups. For Activiti BPM, there are several approaches to implement multi-tenancy, including:
In this approach, a single Activiti database schema is used to store information (process instances, tasks, process instance variables, deployed processes, etc.) regarding multiple tenants. Though this looks promising, handling complex process deployments for each tenant is easier said than done. Because, all the DB queries and updates should be tenant specific.
For Example, to deploy a BPM for specific tenant, you have to use
Similarly, to deploy it for multiple tenants, you have to either loop it or deploy it multiple times for each tenant. To get all the tasks in a group, the API call should include tenant specific information as below:
To get all the tasks related to a user, the API call should include:
The idea here is to use a different schema for each tenant and segregate this information from the rest. This simplifies the deployment and management process for adding new tenants to the application. In this approach, a process engine is created for each DB schema, relating to the respective tenant. And for each tenant, respective process engine will perform the job.
To create a set of process engines, based on their specific tenants and DB URLs, we have to use
In the above code, the tenant specific DB URL is read from the properties file and a process engine specific to them is created and kept in a HashMap.
With the help of above code, a process engine specific to a tenant is picked up and returned for further use.
For process deployments, the only difference from the shared DB multi-tenancy is that the tenant ID is not required here, as the DB schema itself relates to a single tenant. Similarly for API calls, the tenant specific information is not required as the engine instance itself is tenant specific.