In a multiple domain installation scenario, a master domain maintains a set of self-contained tenant domains. Each tenant domain appears to its clients as a separate independent domain.
Cloud service providers can host services for multiple customers by using the multiple domain installation scenario. In this scenario, the service provider runs a master FileNet® P8 domain and one or more tenant domains within the same set of Content Platform Engine servers, thereby reducing the overhead of deploying separate application server instances of Content Platform Engine for each customer. Tenants are isolated from each other and operate independently of other tenants. For example, a tenant object store cannot be accessed from the master domain or from the other tenant domains.
The physical infrastructure and storage resources in this environment are controlled by the master domain, which allows the service provider to configure and manage the multi-tenant infrastructure. Examples include physical devices, servers, and sites. Tenant domains expose a read-only copy of these objects. Other tenant domain objects are controlled by the tenant. Examples include the directory configuration, add-ons, object stores, and isolated regions. Some of these objects are initially set to the value in the master, but can then be modified by the tenant. Tenant domain users cannot access or modify anything in the master domain or in other tenant domains.
Migration paths to or from a multi-domain
configuration are not supported. You cannot migrate existing stand-alone
domains into a multi-domain configuration or convert a multi-domain
configuration into a stand-alone domain.
To access the master domain in a multi-domain configuration, client applications would specify the same type of URL that would be used to access a normal stand-alone domain. To access a tenant domain, a ?tenantId=<tenant_identifier> parameter is appended to the server URL. This convention applies to both Content Engine and Process Engine client applications.
Applying a patch or an upgrade to Content Platform Engine server software affects all tenants simultaneously. In other words, you cannot patch or upgrade just a single tenant.
Each tenant has a single database connection. The tenant GCD database, and all object stores and isolated regions, use this shared database connection. The service provider designates what database each tenant uses. A tenant can be configured to use the same database as either the master domain or another tenant, but the recommended configuration is for each tenant to use a separate database.
In cloud-based scenarios, the cloud provider defines the authentication scheme, which typically is some type of federated identity management. The cloud provider sets the AuthenticationRealmName property of each tenant domain; Content Platform Engine then ensures that only users who have been authenticated against the tenant's WebSphere realm can access resources within that tenant domain. Each tenant could be configured to replicate its users and groups into a cloud-based directory for use by the tenant domain for authorization purposes.
It is recommended to use email address as the UserNameAttribute for the directory configuration in the master domain. Doing so avoids a conflict in which a user in a tenant domain might have the same user name as a user in the master domain; neither user would be able to log in.
In a multiple domain scenario, Content Platform Engine must use WebSphere® Application Server. Multiple domains are supported only for new installations and not for upgrades. In addition, support for a multiple domain configuration is currently limited to custom applications. At time of writing, IBM client applications that use Content Platform Engine as their foundation (such as IBM® Content Navigator and IBM Case Manager) do not support a multiple domain configuration. For custom applications, support for a multiple domain configuration is limited to applications that use the Content Engine and Process Engine Java APIs. Custom applications that were written using some other interface (such as IBM CMIS or Process Engine REST Service) are not supported in a multiple domain configuration.
Also note that, in the multiple domain model, there is no mechanism to partition processing resources (such as memory, CPU cycles, threads, and database connections) so as to prevent one tenant from using a disproportionate amount of resources. Because of this, multiple domain configurations are primarily suited for more narrow applications where the solution does not expose the full capabilities of the Content Engine and Process Engine APIs. For most customers with a need to support multiple business units, hosting multiple virtualized P8 domains on shared hardware is the preferred approach. This approach does provide the ability to limit the resources used by any tenant, and is therefore more appropriate for most customers who want to share hardware resources across multiple applications.