Configuration

The following new configuration will be added:

# multi-tenancy support of the app
# if `db` is set it means support multi-tenancy via different `DbService`
# if `tenant_id` is set it means support multi-tenancy via `tenant_id` column
# otherwise it means multi-tenancy is not supported
# default value is `unsupported`
multi-tenancy=db|tenant_id|unsupported

# specify multi-tenancy common db service name
# only used when `multi-tenancy=db`
# default value is `default`
multi-tenancy.common-db=<db-name>

# specify how the framework get `tenant_id` when a user is engaged
# when `domain_name` is specified then the framework will get the `tenant_id` from the host of the current request. Optionally there needs a `DomainNameToTenantId` mapping mechanism to transform the domain name to `tenant_id`, otherwise the host(domain name) is the `tenant_id`
# when `user_table` is specified then the framework will only be able get `tenancy_id` when user logged in, by which time the `tenant_id` shall be get from the user table's column
# default value is `domain_name`
multi-tenancy.tenant_id.source=domain_name|user_table

# specify the user table name
# This configuration is only used when all of the following is `true`
# - multi-tenancy=db
# - there is not `User` model defined
# - an authentication mechanism is implemented and favor this setting
# default value: null
multi-tenancy.user_table.name=<user-table-name>

# specify the `tenant_id` column name
# This configuration is used when `multi-tenancy=tenant_id` or `multi-tenancy=db`. 
# In latter case, this configuration specifies the column name in the user table
# Default value: `tenant_id`
multi-tenancy.tenant_id.column_name=tenant_id

# specify the session key used to fetch/store tenant_id data into a user session
# Default value: `tenant_id`
multi-tenancy.tenant_id.session_key=tenant_id

Fetch `tenant_id`

There are two ways to allow the system fetch tenant_id when a user is engaged.

By domain name
By user table

Fetch `tenant_id` by domain name

This is the prefered approach to provide multi-tenancy service to customer:

It is able to get tenant_id before user logged in
It does not require store user authentication info into common database

By default the tenant_id will be the domain name. However it shall allow the app to define domain_name to tenant_id mapping logic. Here are a few possible approaches:

calculate tenant_id from domain_name, e.g. via String.hashCode() or cut a substring from the domain name string.
store domain_name to tenant_id mapping into a database table/collection in the common database.

Either way the app needs to implement DomainNameTenantIdLookup interface and bind the implementation to the interface via ActFramework's module mechanism.

Fetch `tenant_id` from user table

In case tenant_id cannot be derived from the domain name, then it can only be identified when user logged in.

The user table needs to be accessible through the common DbService which is configured via multi-tenancy.common-db.
There must be a tenant_id column in the user table. the column name can be configured through multi-tenancy.tenant_id.column_name

Communicate `tenant_id` info through user session

Once tenent_id has been fetched, then it can be communicated through user session in the following interactions. The session key is tenant_id which can be changed via multi-tenancy.tenant_id.session_key configuration.

Configuration

Fetch tenant_id

Fetch tenant_id by domain name

Fetch tenant_id from user table

Communicate tenant_id info through user session

Fetch `tenant_id`

Fetch `tenant_id` by domain name

Fetch `tenant_id` from user table

Communicate `tenant_id` info through user session

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

act-db2 - multi-tenancy support framework #1276

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions