As a developer, to support a multi-tenant app, I must be able to instantiate different implementations of a workflow definition, via DI

Following up on issue #748, in addition to connecting to different database by changing the connection string by tenant, you might actually want to register a different implementation of a given workflow as per the requirements of the different tenants. Some of the scenarios that I think should be supported by the AddWorkflow() (link) method are the following:

• Generic method with a factory method which resolves the instance at runtime.
• A non-generic method which allows locating the type at runtime (maybe from an assembly configured by tenant) and then instantiates the workflow implementation which implements a given interface.

What do you think?

[kassemdarwish]

@craigfowler to answer your question as to why we would vary coded workflows per tenant, take the following example of managing a university program:

• Tenant A: Program starts out as a Draft > it is set to ready after all of its requirements are available > the institution manager sets it as Active to allow students to register > it can be closed if the institution manager chooses to do so
• Tenant B: Program starts out as a Draft > it is set to ready after all of its requirements are available > the institution manager sets it as Active to allow students to register which results in it being escalated to University Program Coordinator for approval > once approved, status changes to Active > it can be closed if the institution manager chooses to do so As you can see, it’s basically the same feature (Managing a program), but every tenant might have slight differences in how it manages its programs.

[sfmskywalker]

I think it all comes down to what model of multitenancy we think Elsa should implement. Initially, I wanted to try and keep the concept of multi-tenancy outside of the scope of Elsa, and if someone can offer any insights as to how we could make this possible, then I think we should take that into consideration. Barring such insights at the moment, it seems to me that the most flexible & straight-forward implementation is the “complete multi-tenant” model, allowing implementers of Elsa to share the same database tables but discriminated by tenant ID.

Should the implementer desire more isolation, one could take advantage of @craigfowler’s modifications to the EF Core provider’s service registration extensions that allows you to select a db context from your own context factory.

And if you wanted the ability to resolve certain service implementations per tenant, then you can take the same approach that Orchard Core does, which is instantiating a service container per tenant. This is something that could be done external to Elsa. You could even use Orchard Core’s framework libraries to implement this together with Elsa in your own app today.

But if all you want is to associate a certain set of workflows per tenant, then you can do so today with Elsa since workflow definitions have a TenantId field, as does IWorkflowBuilder (which allows you to set a tenant ID when using the workflow builder API). Which means that you totally could implement two different workflows that only execute for a given tenant.

Just keep in mind that the multi-tenant story in this area is far from complete as of this writing. For example, if you were to implement a workflow that starts with an HttpEndpoint trigger activity, it doesn’t currently know what tenant ID to select for.