Skip to content

Conversation

sfmskywalker
Copy link
Member

@sfmskywalker sfmskywalker commented Mar 30, 2024

This PR adds "shared database, shared schema" multitenancy capabilities.


This change is Reviewable

jeanbaptistedalle and others added 30 commits March 11, 2024 18:34
* feat(multi-tenancy): add tenantId to entities and additionnal configuration to dbContext

* feat(multi-tenancy): split code in a Elsa.Tenants project, add some configuration to the DbContext for strategies

* feat(multi-tenancy): fix queryfilter to split data between tenants

* feat(multi-tenancy): add tenantId to entity, generate migrations and create a sample

* feat(multi-tenancy): add strategies to always have tenantId when saving

* feat(multi-tenancy): add external user provider support for tenant

* feat(multi-tenancy): fix dbcontext filter on tenantid

* feat(multi-tenancy): manage background execution of workflows

* feat(multi-tenancy): change tenant accessor and middlewares

* feat(multi-tenancy): fix tenantId missing in some cases

* feat(multitenancy): fix efcore store for multitenant

* feat(multi-tenancy): fix some comment of the pullrequest (naming, use Sqlite for example, etc.) and split efcore from tenant project

* Move Elsa.Samples.AspNet.Tenants and Elsa.Samples.AspNet.Tenants.External projects

* Refactor tenant middleware and enhance code documentation

Multiple files including middleware and entity classes related to tenants have been refactored for more straightforward implementation. Unnecessary code has been removed and constructor parameters have been directly utilized, increasing the code's readability and efficiency. Moreover, documentation for classes and interfaces has been enhanced providing better understanding of their role and function.

* Refactor tenant-related classes and move to Elsa.Tenants module

Moved ITenantAccessor and related classes from Elsa.Common to Elsa.Tenants module. Adjusted necessary references in files where these classes were used. Made corresponding changes to the various services where these classes were instantiated or used. Updated project references accordingly.

* Refactor DbContext strategies and streamline code

The DbContextStrategy interfaces were moved from Abstractions to Contracts for better semantics. Async methods in ElsaDbContextBase and IBeforeSavingDbContextStrategy were made synchronous to simplify usage. This included the alteration of methods in related classes to reflect the changes. Unnecessarily complex lines of code were also rewritten for better readability and standardization.

* Refactor multi-tenancy feature and rename workflow provider interfaces

The update refers to multi-tenancy and workflow providers. For the multi-tenancy feature, the 'ConfigurationTenantProvider' was refactored to 'ConfigurationTenantsProvider' and used in 'TenantsFeature'. It was consolidated into one function 'UseConfigurationBasedTenantsProvider'. Middleware to handle this scenario was also adjusted. Regarding workflow providers, the 'IWorkflowProvider' has been renamed to 'IWorkflowsProvider' and corresponding changes made in classes consuming this interface. Name adjustments also affected functions and configuration options. Various non-related code cleanups and removals have also been made.

* Replace initial migration files for various databases

The replacement ensures that TenantId columns will be added when users migrate to 3.1.

* Remove old migration files

This commit removes multiple old database migration files from the source. These files are related to the Elsa.EntityFrameworkCore module and they cover database alterations and management. They are no longer needed due to changes in the application's data structure and updates in the database schema.

* Update database model and migration snapshot

This commit updates the database model and migration snapshot in Elsa.EntityFrameworkCore.MySql. The "ProductVersion" annotation has been updated, and the "Status" property's type has been changed from int to string. Furthermore, a "TenantId" property has been added which is indexed for faster lookups.

* Add TenantId to app settings

This update modifies the appsettings.json file to include a "TenantId" for Administrators, Users, and Applications. Moreover, the key names are updated to follow the PascalCase convention consistently.

* Refactored workflow command handler and added indexes to entities

The DispatchWorkflowRequestHandler has been replaced with DispatchWorkflowCommandHandler in the WorkflowRuntimeFeature. Also removed the DispatchTenantWorkflowRequestHandler from the TenantsFeature. In the entity framework, added indexes to SerializedKeyValuePair's Key and TenantId in the Configurations. The SerializedKeyValuePair class now inherits from Entity.

* Reset migrations to Initial

* "Added TenantId column and altered status column type in AlterationPlans and AlterationJobs tables"

This commit introduces new TenantId columns to the AlterationPlans and AlterationJobs tables across different DB contexts (MySql, SqlServer, Sqlite, PostgreSql). The type of the Status column has also been changed from int to string in both tables. Indexes for the new TenantId column are also created as part of this change.

* Update authentication settings and improve code structure

Several modifications have been made to improve our code and update our authentication setup. Made changes to disable Dapper and utilize JWT Bearer for authentication in the Elsa.Server.Web program settings. Additionally, we've updated a method on IdentityTokenOptions to be internal and adjusted token option assignments in ModuleExtensions. Syntax improvements were also made in ApplicationProviderExtensions for better consistency with best practices.

* Remove V3_1 migration from different databases

The V3_1 migration from MySql, SqlServer, Sqlite, and PostgreSQL databases has been removed. This includes alterations such as the addition of the "TenantId" column and changes in the "Status" column type within Elsa's schema.

* Remove old and add new tenant handling components

Removed files related to the old way of handling tenants in the application and added new ones for improved management. This change introduces a tenant resolution strategy pipeline, allowing different strategies to be used in sequence to resolve the current tenant. Various schemes have been implemented, including resolving tenants based on route prefixes, the currently authenticated user, and the user's claims. The update also enhances the way entities are handled when working with SQLite and Oracle databases.

* Added SQLite setup to PersistenceFeatureBase

The code now adds a line to include SetupForSqlite in PersistenceFeatureBase's services list. The SetupForOracle class was removed from the SetupForSqlite file - it is possibly now dedicated to SQLite setup only.

* Add CommonPersistenceFeature, refactor related classes

Implemented a new class, CommonPersistenceFeature, which handles aspects previously managed in PersistenceFeatureBase. ServiceScope registrations were removed from PersistenceFeatureBase and added to the new CommonPersistenceFeature. In addition, the tenant filter in SetTenantIdFilter has been simplified for more direct accessibility. Changes were also made in WorkflowManagementPersistenceFeature to accommodate these implementations.

* Refactor multi-tenancy configuration and resolution

Updated the code to use "MultiTenancy" section instead of "Tenants" section in all configuration files. Also, refactored the Store class to use IServiceProvider instead of IDbContextFactory and added tenant resolution logic. Renamed classes and variables accordingly to better represent multi-tenancy.

* Add Tenant Dymanic Filter options for Workflow Definition

Tenant Dymanic Filter provides the ability to include or exclude tenant matching in the filter. The corresponding queries and method signatures were modified to account for this new feature. Added `HttpContextTenantExtensions` and `HttpContextTenantResolver` classes to enable tenant-based filtering of HTTP context.

---------

Co-authored-by: Jean-Baptiste Dalle <jean-baptiste.dalle@stereograph.fr>
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
The AuthenticatingMediator, GetPlacedCallHubSpotId activity, and IAuthenticatingMediator interface have been removed. Middleware for authorization context workflow execution and tenant providers have been added to enhance multi-tenancy support.
Introduce tenant resolution strategies in the Identity module and refactor namespaces across modules to align with the new multi-tenancy structure. This includes moving various tenant-related classes from the Tenants module to Common and Identity, adjusting references, and consolidating tenant constants and options.
Deleted `IdentityOptions` and moved `TenantIdClaimsType` to `IdentityTokenOptions`. Renamed `ClaimConstants` to `CustomClaimTypes` and updated references across multiple services and samples accordingly. Adjusted `ClaimsTenantResolver` to use `IdentityTokenOptions` and removed deprecated method `Deconstruct` from `IdentityTokenOptions`.
Changed the dependency injection scope for ISystemClock from scoped to singleton to ensure a single instance is used application-wide. This ensures consistent time references across different components and enhances performance by reducing the number of instances created.
The `IQueueProvider`, `ITopicProvider`, and `ISubscriptionProvider` are now registered as singletons to ensure single instances throughout the application. Additionally, dependency resolution for `ITriggerStore` and `IBookmarkStore` is moved to a scoped lifetime within `StartWorkers` to maintain correct scope per operation.
Simplify the extraction of tenant ID from claims by removing the fallback to a default type, given that it is non-nullable.
The import of Elsa.Identity.Constants was removed as it was not used in the ClaimsTenantResolver class. This cleanup helps maintain code clarity and reduces unnecessary dependencies.
Removed several deprecated workflow activities pertaining to lead and deal updates in preparation for new workflow structure implementation.
A default value was added to the WorkflowDefinitionModel constructor to align with the expected parameter count. Additionally, removed unused tenant-related code from ElsaDbContextBase and redundant entity configurations from DbContext specific to Oracle, simplifying the model setup.
Adjusted the type passed to the DefaultWorkflowDefinitionStorePopulator constructor to use the correct IWorkflowsProvider interface. This change aligns the type expectation with the implemented providers list, ensuring proper dependency resolution.
The model snapshots for various database providers have been updated to reflect the new product version 7.0.14. Additionally, new properties and indices for `IsSystem`, `TenantId`, and compression information have been introduced across entities such as `WorkflowDefinition`, `WorkflowInstance`, `Label`, and others to support multi-tenancy and system-level workflows.
Migration V3_1 adds a tenant ID column and indexes, and changes the status column's type to a string across all database providers. It also renames the SerializedWorkflowInstanceIds to SerializedWorkflowInstanceFilter.
Updated migration versions and internalized records to extend from a new base Record class with tenant ID property for multi-tenancy. Added TenantId across stores and migrations to support tenant-specific data isolation within the Dapper module.
Introduced TenantId to various tables and records to enable multi-tenancy. Migration scripts have been added across modules for managing TenantId columns effectively.
Optimized TenantResolver for caching current tenant, refactored MongoDB stores to include tenant resolution, and updated index creation to add tenant-specific indices. Enforced multi-tenancy across various Elsa modules ensuring tenant isolation and efficient data retrieval.
Changed usage of BookmarkId to Id across several files, ensuring consistent referencing of the bookmark identifier for clarity and future deprecation of obsolete properties.
Provide an option for tenant-agnostic operations across all MongoDB store methods, including Find, Count, Any, and Delete operations. Default behavior respects tenant boundaries, but adding a flag allows operations to ignore tenant constraints. Removed unnecessary using directive.
Added Dapper persistence stores for various entities and refactored existing stores for better maintainability.
Introduced an option to perform tenant-agnostic queries in Elsa Dapper, allowing retrieval of records without tenant filtering. Refactored query methods to include a tenantAgnostic parameter and applied tenant filters conditionally based on this flag. This supports scenarios where tenant-specific data isolation is not required.
Changed the code to asynchronously resolve the tenant and handle possible null values before assigning the tenant ID. This improvement ensures tenant resolution is done properly and enhances code reliability by checking for nulls.
Refactored Mongo collection references to use IMongoCollection interface across various modules. This change allows for more consistent and flexible database operations. Additionally, updated program configuration to enable MongoDB and disable Dapper.
The workflow file ac-call-ring-group.json has been deleted, as it is no longer needed in our project. This may be due to changes in requirements or workflow optimizations.
Removed outdated migration scripts (efcore-3.0.sh, efcore-3.1.sh, efcore-3.1-sql.sh) and added new versions (generate.sh, generate-sql.sh). Also optimized the dependency list in Elsa.Tenants.csproj - switched individual package references into a single reference to Microsoft.AspNetCore.App. This streamlined the project's dependencies and reduced redundancy.
Fixed typographical errors in comments of the "JobId" property in both BackgroundActivityStimulus and BackgroundActivityBookmark classes. This minor change ensures accuracy and clarity in the code documentation.
This commit modifies the import statements in various files under the Workflow API endpoints. Most changes involve replacing Elsa.Workflows.Management.Contracts import with Elsa.Workflows.Management. This refactoring ensures the correct classes and interfaces are used from the updated module path. Few methods have additional parameters added as well, enhancing their functionality.
@sfmskywalker
Copy link
Member Author

Response to Multi-Tenancy Configuration Questions

Scenario 1: Disabling Multi-Tenancy After Being Enabled

Technical Impact:

  • When multi-tenancy is disabled after being previously enabled, all records that were associated with specific tenants become invisible. This is because those records are linked to a tenant ID. Only records with a NULL tenant ID will be returned and visible in the system.

Scenario 2: Enabling Multi-Tenancy on an Existing Data System

Technical Impact:

  • When multi-tenancy is enabled on a system that initially did not use it, any existing data not associated with any tenants will not be visible because these records will have a NULL tenant ID.

This commit introduces a new DefaultTenantResolver class which always returns the default tenant. The previous TenantResolver is renamed to PipelinedTenantResolver. The ITenantResolver interface has also been moved to a more general namespace. All services using ITenantResolver are updated accordingly. Furthermore, TenantResolverFeature is now a dependency of WorkflowsFeature.
This was linked to issues May 28, 2024
@Itzalive
Copy link

Itzalive commented Jun 5, 2024

The mediator handler should have the same context as the code that fires the notification or command. If this is not the case, can you provide me with an example of a case where this context gets lost?

For example, the DispatchTriggerWorkflowsRequest and DispatchResumeWorkflowsRequest commands which execute on the mediator. They have a string of the bookmark/event name but no tenant awareness. If two tenants have a bookmark with the same name, they will both be fired. The mediator, as I understood it, processes ICommands which have been persisted for later execution and so when it loads an ICommand there is only the information within the ICommand to set the context.

The logger reference used in the catch block of the DefaultTriggerScheduler.cs file was incorrect. This commit corrects it by using the appropriate logger variable for logging any potential cron expression format errors.
Removed unnecessary using directives and modified the `ElsaDbContextBase` constructor. Introduced `IServiceProvider` dependency to the constructor and removed `SaveChangesAsync` method. Also, a set of `ModifiedEntityStates` was added.
An override for the SaveChangesAsync method has been added to the ElsaDbContextBase class. This method ensures OnBeforeSavingAsync is called prior to the base.SaveChangesAsync method, allowing for pre-save operations to be queued and executed asynchronously.
The Identity module from Elsa.EntityFrameworkCore is now added to the Workflow Server configurations in both Elsa.Workflows.ComponentTests and Elsa.AzureServiceBus.ComponentTests projects. This module is configured to use Entity Framework Core with PostgreSQL as a data provider.
The key identifier from various key-value pair references has been replaced with ID in several modules, as reflected in the recent code changes. The 'Key' field was removed in the SerializedKeyValuePair class, related entity configurations, and multiple store methods. It's expected to improve the consistency of data identification across different components in the application.
Deleted the obsolete DictionaryExtensions.cs file, and did extensive refactoring of namespace usage. Some classes have been moved to new namespaces while others have been removed. Also removed methods that were not used or duplicated elsewhere in the codebase.
The import in AzureServiceBusServiceCollectionExtensions test file was changed. Elsa.Extensions was used instead of Elsa.Workflows.ComponentTests, adjusting the dependencies for the test configuration.
This commit removes old migration files pertaining to different databases in the Elsa.EntityFrameworkCore module. These outdated migrations versioned as 'V3_2' are no longer necessary in the current context of the application. The removal helps to keep the codebase cleaner and easier to manage.
Deleted previous versions of migration scripts and created new versions for EFCore 3.0, 3.1, and 3.3. These scripts have been included in the Elsa.sln, to facilitate regular and consistent updates of database schemas across various provider types (MySQL, SqlServer, Sqlite, PostgreSQL).
The commit introduces a new TenantId column to several tables including WorkflowExecutionLogRecords, Triggers, KeyValuePairs, Bookmarks, and ActivityExecutionRecords in different database providers (MySql, PostgreSql, SqlServer, Sqlite). The changes will allow isolating data based on tenant ids. This commit also removes the WorkflowInboxMessages table which is not needed anymore.
@sfmskywalker sfmskywalker marked this pull request as ready for review June 10, 2024 19:21
The code includes additional extensions to Elsa workflow server configurations. The changes involve the alteration modules, enabling them to use EntityFrameworkCore with PostgreSQL. This was applied in two workflow servers for component testing, i.e., Elsa.Workflows.ComponentTests and Elsa.AzureServiceBus.ComponentTests.
@sfmskywalker sfmskywalker merged commit 2aa9140 into main Jun 10, 2024
@sfmskywalker sfmskywalker deleted the feature/multi-tenancy branch June 10, 2024 19:30
@Gryhyphen Gryhyphen mentioned this pull request Jul 30, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multitenancy [FEAT] Multitenancy
4 participants