Overview of installation types
Before putting your FileNet® P8 system into production, it is often a good idea to install it several times, with each installation fulfilling a different purpose.
- Proof of concept system
- A proof of concept system can be used to demonstrate basic functionality, such as document management and simple workflow, to a prospective customer, a development partner, or a set of users.
- Development system
- A development system is used by software developers to design and implement code for custom applications.
- Test system
- A test system is used to evaluate the quality of the applications during development and to assess all subsequent changes to the code after the product is released. A test system is also used to evaluate product upgrades and fix packs before applying them to other systems, such as production systems that are already rolled out across your enterprise.
- Preproduction system
- A preproduction system is used to try out changes before making those changes on a production environment.
- Disaster recovery system
- Because it is designed to provide business continuity after a natural or human-induced disaster, a disaster recovery system is often geographically remote from production. Such a system is not designed to be instantly enabled to replace a production system that is no longer available, because this is generally accomplished by implementing high availability and failover features into the production environment itself.
- Production system
- A production system is the full-featured, fully tested live system that has access to all content and workflows, on the full suite of platform hardware and software, configured to access your entire set of users and groups, that supports your application.
- Multiple domain scenario
-
This configuration is not recommended for new deployments. Consider segmenting by object store or managed realms as an alternative.
Service providers who build services or application that are built on FileNet P8 and need to service multiple customers or divisions within an organization can use the multiple domain 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.
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 configuration are primarily suited for services where the service provider has built in mechanisms that can monitor and restrict tenant resource usage, or where that resource usage is not a concern. For most customers with a need to support multiple business units, hosting multiple virtualized P8 domains on shared hardware is the preferred approach. This multiple virtualized P8 domain approach provides 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.
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.
A master domain has a property that, when it is set, distinguishes it from a stand-alone domain and allows it to have tenant domains.Important: 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. Because of this, multi-tenant domain configuration is primarily suited for situation where tenants use a common P8 application and therefore share a common patch and upgrade schedule.
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 multiple domain scenarios, the service 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.