Multi tenancy support

That's not supported out of the box.
It might be we look into this in the near future, but nothing is decided in that direction yet.

The alfresco-integration has some notion of multi-tennancy. It prefixes all process-definitions keys with a certain tennant domain. When fetching all possible workflows to start, these are filtered out, based on the domain of the logged in user. All other functionality is covered by alfresco (eg. user's, content, …), so nothing as Joram says, there is currently no out-of-the box support.

Related to multitenancy, how does Activiti run a process? Does a process only advance within a user transaction (submit start form or task data) on the current thread, or can processes advance asynchronously?

I'm asking this because we've implemented DB multitenancy using a DataSource wrapper that can route DB queries (including those executed by Activiti) to tenant-specific DataSources (DBs). Would such a DataSource wrapper work with Activiti? Simply put, we store tenant information in a thread local which is then inspected by the DataSource wrapper in order to decide which tenant DataSource to route queries to…

If asynchronous process execution is possible, we could probably also set tenancy (for the current thread) manually by calling Java methods via expressions #{tenancyResolver.setTenancy("tenant1")} in the particular asynchronous step in the process? Obviously this would require us to store tenant-information in process variables when it is first start up (within a user transaction).

Thanks,
Jukka

heymjo

I'm interested in this as well, see http://forums.activiti.org/en/viewtopic.php?f=6&t=1593

My conclusion then was that we cannot keep strictly separate different organizations on the same activiti database. Even if you have a routing or proxying datasource the underlying datasources would still need to be present in the app server and could still be looked up from jndi by the application AFAICT. And even if your appserver has policies where you secure and link a datasource to an application then consider that this datasource still has access to the complete schema and with simple SQL statements could peek in other workflows' data. In short, we went for the one-schema-per-application approach.

Jorg

Activiti's timers and jobs are executed asynchronously. If you have a datasource that is tenant-aware, you could always add an extra interceptor to the commandExecutor activiti uses internally, which get called before any request to the activiti DB is done.

As heymjo states, using a proxy still "exposes" your datasource somewhere in your app-server or spring-context, which gives you no guarantees. Off course, if you have full control of what runs on your server, imho this is perfectly acceptible.

Thanks for your responses.

Just for the record, we are building a multitenant application that would utilize Activiti BPMS (vs. sharing an Activiti instance by multiple unrelated applications).

@heymjo: We would have separate (Activiti) databases for each tenant. Activiti just happens to query the right one when a process is initiated or updated (via the DataSource wrapper/proxy). And we do have full control of the applications that utilize Activiti and which are run on our server. So we should not have any trouble there.

@frederikhermans: Thanks for the tip, using an interceptor (vs. explicit tenant-related expressions) sounds right to me. However, we would still need to know which tenant DB to forward the request to, so we would most likely need to put tenant information in process metadata anyways, and have the interceptor read that?

Cheers,
Jukka

Indeed, your interceptor should be aware of the current user (can do that using the Authentication object in activiti) and potentially inspect all commands it will execute, for tenant-specific data…

Further question,

If we use a routing DataSource wrapper to achieve multitenancy (as described above), will we run into any trouble with caching within the Activiti engine?

For instance, say, if user details were cached in-memory, we might run into trouble when two tenants had a user with the same username (in which case a cached lookup for that user might return invalid user information).

What does the Activiti engine cache (if anything)?

Thanks,
Jukka

The engine only caches process definitions. So if you make sure there are no clashes related to process ids/keys you're all safe.

Thanks for the information. In our case tenants do actually share the definitions, so this should not be a problem.

l_marinkov

I would like to ask if support for multi tenancy is planned to be implemented in future activiti versions? Thx

heymjo

i have created a jira issue with some initial thoughts in it

http://jira.codehaus.org/browse/ACT-872

feel free to add your requirements or ideas, and maybe if there are enough votes someone will step up and do this. I don't think it is that hard from a technical point of view, you just need to get it right and transparent to those that don't want multi-tenancy.

ingo_ri

My comment on this (here and in in JIRA http://jira.codehaus.org/browse/ACT-872😞

We also need support for multiple tenants in one database. In our application we have a column tenantId in every database table. And we set the tenantId from the application.

To support an optional multi-tenant-environment in Activiti I would suggest to add some new start methods with an additional parameter 'tenantId'.

The activiti engine propagates this optional value to every row that belongs to this processinstance in all ACT_RU- and ACT_HI-tables without database triggers. Every instantiated task and activity gets this value, too. Every table should get an additional nullable column tenant_id_ varchar(64).

When a transition gets fired, it propagates the tenantId to the following activities or jobs, if a deadline is reached.

The default process definitions are for all tenants and some tenants build their own definitions. There sould be a parameter tenantId in the deployment-service.

We use our own identity-management, so no need for improvement here.

But for Demos, there should be a tenantId in the user tables too. This tenantId should be used in the application to query for tasklists etc.

This approach allows restricted access to tasks and processinstances over the api.

Is it sufficient for an open source superdeluxe workflow engine?

inoko

the jira issue(http://jira.codehaus.org/browse/ACT-872) was resolved?
So, multi tenancy isn't planed to be implemented on Activiti?

trademak

Multi tenancy can be achieved in Activiti by setting a specific process variable that you can use in a query. Currently we don't have plans to support multi tenancy in another way, but if there's an interest in that in the community then we can rethink that of course.

Best regards,

inoko1

Thanks for your information, Tijs.

Do you mean that if I make Activiti(engine, rest, explorer) Multi tenancy, I have to change following implementation?
- starting process instance : RuntimeService#startProcessInstance**
- querying process variables : TaskService#createTaskQuery#**, RuntimeService#createProcessInstanceQuery#**
- user management
- db schema : ACT_HI**, ACT_ID** ACT_RE**

If I develop this feature, I want to commit to code base, but is there anyone who are interested in this?

kepkap

Hi Guys,

seems like an old thread comes to live again.

I am also very much interested in multitenant BPM… BUT, it must be truly multitenant support in single datasource, no workarounds like configuring datasource per tenant, multiple engine instances, etc. It's not going to scale. the target customer count we target at is not 10 or 100, but more than 1000. It's obvious that handling that much by dedicating separate engine instance or datasource is not practical.

IMHO, the best way to do that is seaparting tenant data by tenantId filter everywhere. Process Instances, Tasks, users, roles, pretty much all entities.

so, my message is:
1. I vote for multitenant support.
2. I can participate. (…well, I think I can.)

Regards,

trademak

Hi,

There are 2 approaches. One is an approach that you can already use today. You can write your own Parsehandler and insert an process start listener for every process definition deployed. In this start execution listener you can set the tenantId value as a process variable. Also in the ParseHandler you could make the process definition tenant aware by adding a tenant prefix or something similar.

The second approach is to change the Activiti tables and add a tenant id in every table where needed. What you are suggesting is to go for the second approach, right? I think that would be a good addition to Activiti so we would definitely welcome that. If you need our help let us know.

Best regards,

chrisc

I guess using Activiti like Alfresco uses it with smart choice of userIds and the business keys can mean you can use Activiti out of the box for many multi-tenant scenarios.

Alfresco does some "smart" things indeed. So no, no out of the box support for MT is in activiti right now, but we're thinking about this in future releases. Nothing concrete yet, though…

bgronek

I would like to also put in my $.02 for the addition of multi tenancy to Activiti.

trademak

Starting from the just released Activiti 5.15, Activiti contains multi tenancy support.

Best regards,

Hi,

Does Activiti multi-tenancy support multi-schema on different databases? I have clients who needs their schemas on Oracle and others on Postgres. Is that possible. In other words, is it possible for Activiti to change the database type dynamically according to tenant database type?

Is there an example that shows how to configure the engine to that effect?

Thanks!

Dan

martin_grofcik

Hi Dan,

Does Activiti multi-tenancy support multi-schema on different databases?

No.

Regards
Martin

Thank you!

In fact, what I am planning to to is have different engines per database type. All embedded within the same application server.

martin_grofcik

In that case you can have different DBs in your application.

Regards
Martin

Hi Martin,

Is multi-tenancy support available within a single database (physical) server? or it is available across two independent databases of the same type, say Oracle type? In other words, can my tenants be in different, independent, separate oracle databases?

I think the answer is no, the tenants' schemas must be within the same database? I just want to clarify this, since it is not clear from the example (see link below) whether the registered tenants' datasources are strictly for different schemas within the same database or not.

http://www.jorambarrez.be/blog/2015/10/06/multi-tenancy-separate-database-schemas-in-activiti/

Many thanks,

Dan

> Is multi-tenancy support available within a single database (physical) server?

Yes: http://activiti.org/userguide/index.html#advanced.tenancy

My blog post you link to is about a NEW feature that we added.

So to answer: both options are possible with Activiti.

Tanks Joram for confirming that tenants can be located in separate independent databases.

I read the doc, but I think it is not clearly stated or explicitly mentioned that Activiti supports multi-tenants in different databases of the same type. It would be beneficial for the users to see that clearly.

Dan