Runtime multi-tenancy

Introduction

The Blueriq Runtime can be configured to run in a multi-tenant environment. This allows you to run your Blueriq application on a single Runtime instance which can be used by multiple user groups. 

Overview

The overview below shows which parts of the Runtime support multi-tenancy at the moment.  

For more information on configuring the Runtime, please refer to Multi-tenant setup.

Details

As stated in the overview, the current list of Blueriq components are supporting multi-tenancy:

1. Runtime. The Runtime receives the tenant via the X-TENANT-ID HTTP header and places it on the Blueriq context (System attributes) which can be used in the model. Additionally, it will listen to a separate RabbitMQ for each tenant, if the dcm-lists-client profile in enabled.
2. Customerdata client. This component sends the tenant via the X-TENANT-ID HTTP header to the customerdata service.
3. Customerdata service. This component receives the X-TENANT-ID header and determines which datasource to use.
4. Process engine.This component uses the Blueriq context to retrieve the tenant and determines which datasource to use.
5. Scheduler. This component uses the Blueriq context to retrieve the tenant and uses the tenant when registering jobs in the Quartz database.
6. Trace engine. This component uses the Blueriq context to retrieve the tenant and determines which datasource to use.
7. Comments. This component uses the Blueriq context to retrieve the tenant and determines which datasource to use.
8. DCM Lists Client. This component sends the tenant via the X-TENANT-ID HTTP header to the DCM Lists Service. Additionally, it publishes events to a separate RabbitMQ for each tenant.
9. DCM Lists Service. This component receives the X-TENANT-ID header and determines which datasource to use. Additionally, it listens to a separate RabbitMQ for each tenant.
10. DCM Intake (DCM_CaseCreate). This component publishes events to a separate RabbitMQ for each tenant.
11. DCM Case Engine. This component listens to a separate RabbitMQ for each tenant.

The Blueriq Runtime makes sure the tenant is used in its own components. When the tenant information needs to be transfered to another (external) component like a webservice, you as a modeller are responsible for passing the tenant information. The tenant is stored in system.user.tenant attribute.

The following components do not support multi-tenancy at this moment:

1. CMIS client. The tenant information is not send to the configured DMS.
2. Reporting. The tenant information is not used to determine a datasource.
3. The queue attached to the customerdata service. The received X-TENANT-ID header is not used either as part of the aggregate event or to determine which queue to use.
4. The queue attached to the trace engine. The received tenant on the Blueriq context is not used either as part of the process event or to determine which queue to use.