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.

During your planning phase, you decide which of the installation scenarios, such as the single server, the standard distributed, or the high availability scenario, would be best to use for the following types of installations:
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.
This system might be a single-server configuration of just the core FileNet P8 components you want to demonstrate. Or it could be the core components plus one or more expansion products that are important to your intended development activities or your audience.
Before you install a proof of concept system, make the following decisions:
  • Decide whether a simple installation is sufficient to achieve your proof of concept, or whether you need a more complex system, with multiple servers and essential add-ons, or with different components.
  • Decide whether to keep your proof of concept system in place without major modifications, at least during the early stages, in order to have a working example of the original installation as a reference.
  • Decide whether you intend to use the proof of concept system as a development or test system.
Follow either the single server scenario or the standard distributed installation scenario, including high availability elements if appropriate, to install your proof of concept system.
Development system
A development system is used by software developers to design and implement code for custom applications.
A development system should be only large enough to accommodate your development team and to contain the components required by the system under design. In some cases, more than one development system might be required, for example, if developers are working on different subprojects that could conflict or require unique capacity. The development system might not need to be as carefully controlled as a test system. For example, you could install products or debugging tools on a development system, or make environmental changes that are not recommended for production or intended for final documentation. This flexibility might not be advisable for a test system that is meant to exercise the production configuration.
It is acceptable to use the same authentication realm for the proof of concept system as for the development and test systems, though you might want some special accounts to use for just testing purposes. The benefit of using the same authentication realm is that these systems can use the same directory server (LDAP) accounts and authentication realms, which makes the subsequent development and test systems easier to configure.
Before you install a development system, make the following decisions:
  • Decide whether to use an existing proof of concept system as the basis for the development system.
  • Decide whether to install one of the bundled FileNet P8 client applications even if your customized solution will not use these products. For example, you might want to compare your customized application with the FileNet P8 clients.
  • Decide which APIs are needed to code your custom application, and then include the components that are required to implement those APIs.
  • Decide whether you want to collocate FileNet P8 components on the same server. Collocation is not a best practice in a production environment but can be a good option for development systems, especially if server resources are scarce and underlying system performance is not a major concern. See the P8 Related Requirements document for information on collocation.
  • Decide what kind of content storage areas you want to configure. For your development system, you might want to use a database storage area, which is easier to configure than a file storage area that is based in a file system.
Unless your development system requirements can be met by using the single server scenario, follow the standard distributed installation scenario, including high availability elements if appropriate, to install your development system.
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.
An important usage of a test system is to make sure that you have the correct versions of each software component. The owners of the test system must therefore be careful to control all changes to it. Configure your test system exactly as described in the installation documentation and by the hardware and software requirements. Control, maintain, and track the elements of your test system as carefully as possible so that testing integrity can be assured. Typically, a test system is backed up so that it can be returned to a known state without reinstalling all the software components. In many cases, you can use the same authentication realm for the test and development systems, unless you have security restrictions within your organization.
Before you install a test system, make the following decisions to be able to validate the functionality, usability and performance of the customer's applications.
  • Decide how large your test system must be to provide an adequate testing environment for activities such as code assessment, installation and upgrade testing, functional testing, and performance monitoring.
  • If your production system is expected to be a high availability environment, you might decide not to configure high availability on test systems but rather to use the preproduction system for testing under high availability conditions before installing the software into production.
  • Decide whether you want to collocate FileNet P8 components on the same server. Collocation is not a best practice in a production environment but can be a good option for test systems, especially if server resources are scarce and you must increase or maintain system performance.
Unless your test system's requirements can be met using the single server scenario, follow the standard distributed installation scenario, including high availability elements if appropriate, to install your test system.
Preproduction system
A preproduction system is used to try out changes before making those changes on a production environment.
It should be as similar to the production system as you can reasonably implement. Do not assume that a version change or some new code that runs acceptably on the test system will run acceptably on a production system; it must be tested first on a system that closely approximates the production configuration. The greater the difference between the preproduction system and the production environment, the greater your risk when implementing new software. For example, if the production system has a cluster of 20 servers, the preproduction system would need a cluster of at least two servers, and ideally more. Final performance testing is often done on the preproduction systems, so the closer it is to the production system, the more reliable your performance test results will be. As a best practice, all changes that are successfully tested on a test system should first be implemented on the preproduction system before being added to the production system.
If a preproduction system includes IBM® Content Search Services, it must have access to at least some of the documents to be searched. This access might be accomplished by providing a complete synchronized replica of the data, or only a subset of the data.
Before you install a preproduction system, make the following decisions:
  • Decide whether you need to install fixed content devices in your preproduction system. Because of the difficulties implementing a fixed content device or other very large storage devices, you might decide to implement such devices only on the production system.
  • Decide how large a data set you need to approximate the production system stored content and workflow information for preproduction functional testing.
Follow the standard distributed installation scenario, including high availability elements if appropriate, to install your preproduction system.
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.
Follow the standard distributed installation scenario, including high availability elements if appropriate, to install your production system.
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.