Configuring the software
After you have installed WebSphere Process Server,
you must create at least one profile. There are three types of profiles: a
stand-alone server profile, a deployment manager profile, or a custom profile
(managed node). Each profile defines a separate runtime environment, with
separate files (commands, configuration files, and log files). Use the pointers
in this topic to find more detailed information on tasks you might have to
perform after you install WebSphere Process Server.
Pointers to conceptual topics supporting the tasks are provided
as well.
You can also review topics on creating servers within
a network deployed environment in the Administering section of this information center.
If you selected Complete in the Installation type
panel, a stand-alone server profile named default with a
server named server1 was created for you, and the First steps
console was started when the Installation wizard finished. A sample Business
Process Choreographer container was not configured. You can use the
Profile wizard to create additional profiles if needed.
If you selected Custom in the Installation type panel, you must
create at least one profile. The Profile wizard is started when the Installation
wizard finishes.
If you selected Client in the Installation type panel, you do not
need to create profiles.
You can also use the command line tool, manageprofiles,
to create a profile.
After a profile is created, you can get started with WebSphere Process Server from
the First Steps console.
This
section contains the following topics:
- Starting the First Steps console -- The First Steps console is a tool you can run after
product installation to start the Profile wizard, link to product documentation,
and direct WebSphere Process Server elements
related to an individual profile. You can start it in several ways.
- Creating profiles -- To use WebSphere Process Server,
you create one or more profiles. Each profile contains a set of files
that define a runtime environment. You can create a WebSphere Process Server runtime
environment within a single stand-alone server profile, or over multiple profiles
(one deployment manager profile and a number of federated managed profiles)
as part of a network deployment.
- Configuring a stand-alone server profile --
After installing WebSphere Process Server,
you can create and configure one or more stand-alone server profiles.
- Configuring a deployment manager --
A deployment manager provides a single administrative interface to a logical
group of servers on one or more machines. After installing WebSphere Process Server,
you can configure a deployment manager.
- Configuring a custom profile (managed node) –
A custom profile is an empty node that you must federate into a deployment
manager cell to make operational. Federating the custom profile changes it
into a managed node. After federation, a custom profile has a nodeagent process
but does not have a server process. You must use the administrative console
of the deployment manager to customize the empty node for production or other
uses. After you start the nodeagent, it responds to commands from the deployment
manager.
- Database specifications --
WebSphere Process Server uses a number of database tables to hold, store and
track information. Some of the components that comprise WebSphere Process
Server use their own database tables. You can create these database tables
during profile creation or you can choose to create them separately using
scripts.
- Scripts for configuring DB2 on a remote z/OS server – If you
plan to use DB2 on a remote z/OS machine for the Common Event Infrastructure,
Common, and Business Process Choreographer database repositories, you or the
database administrator (DBA) must create on the z/OS machine four databases
called event, eventcat, WPRCSDB,
and BPEDB, as well as the correct storage groups for each
(EVTSTO is the default). WebSphere Process Server provides
default scripts that can be used to create the databases and storage groups.
- Making Service Component Architecture services accessible across cells –
One of the benefits of Service Component Architecture (SCA) is the ability
for consumers to use services that already exist in other service modules.
The service provider and the service consumer can reside on different cells.
This distribution allows you to isolate and manage services better by placing
the services among the cells.
Also included in this section are instructions for configuring Business
Process Choreographer.
Last updated: Wed 01 Nov 2006 07:47:12
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)