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.
- The Composite Platform Installation Tool (CPIT) provides a quick
way to create a proof of concept system on one server. It automatically
configures the underlying required software and applies a baseline
set of default FileNet P8 configuration
settings. However, make sure that you are aware of the following factors:
- It does not install IBM® Content Search Services or
configure other add-ons or expansion products.
- It uses WebSphere® Application
Server, DB2® for Linux, UNIX and Windows, and Tivoli® Directory Server only. This is the only
configuration installed and configured by the Composite Platform Installation
Tool.
- After a Composite Platform Installation Tool installation, consider
upgrading the components to the latest supported fix pack levels.
You can also add more products to the installation or interface with
components and products that are installed on other computers.
- It installs onto one server only.
- The Installation and Upgrade Worksheet is
not needed when you use the Composite Platform Installation Tool.
- Before you install a proof of concept system, make
the following decisions:
- Decide whether using the Composite Platform Installation Tool
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. In this case, you would probably follow
the standard distributed scenario.
- 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.