Test Infrastructure: Process Portal
in WebSphere Portal for z/OS V6.1
Abstract
The purpose of this document is to outline the steps by which the WebSphere
Portal System Verification Test (SVT) team installed, configured, and tested
the Process Portal integration feature provided by WebSphere Portal for
z/OS.
Process Portal Introduction
The Process Portal integration was tested with the WebSphere Portal Enable
for z/OS environment in two different ways. One test environment
was with WebSphere Portal node and WebSphere Process Server node configured
within a Single-cell. The second test environment was with WebSphere
Portal in one cell and the WebSphere Process Server configured in a second
cell (i.e., a Cross-cell configuration, each with their own Deployment
Manager).
Test Environment – Single-cell
The Process Portal, Single-cell environment included:
· IBM WebSphere
Portal for z/OS v.6.1 primary node + IBM WebSphere Process Server v6.1.2
client + IBM WebSphere Application Server Deployment Manager 6.1.0.19
· IBM WebSphere
Process Server v6.1.2 –- primary node -- + IBM WebSphere Application Server
Deployment Manager 6.1.0.19
· IBM DB2 9.1
PUT0803 DS2 (for WebSphere Portal databases only)
· IBM DB2 9.1
PUT0803 DS2 (for WebSphere Process Server database only)
· IBM HTTP
Server v.6.1
· IBM Tivoli
Directory Server v6.1 -- contains 100000 portal users
The following specifications detail the machines used to test Process Portal
integration feature:
Process Portal Single-cell Specifications
|
Machine
|
OS
|
# of CPUs
|
CPU Speed
|
CPU Type
|
RAM (GB)
|
Function
|
|
Portal v6.1.0.1 + WPS v6.1.2
client + WAS Deployment Manager
|
IBM z/OS V1 R9
|
LPAR
|
x GHz
|
zSeries (z-9)
|
10
|
Deployment Manager, Process
Server client, and Portal node
|
|
WebSphere Process Server v6.1.2
+ WAS Deployment Manager
|
IBM z/OS v1.9
|
LPAR
|
x GHz
|
zSeries (z-9)
|
6
|
Deployment Manager and
Process Server
|
|
IHS 6.1
|
Windows 2003 Ent. Ed SP2
|
1
|
1.0 GHz
|
Intel
|
1.5
|
Web server
|
|
IBM DB2 9.1 PUT 0803 DS2
|
IBM z/OS v1.9
|
LPAR CF
|
x GHz
|
zSeries (z-9)
|
2
|
DB2 Data Sharing for Portal
and Process Server Databases
|
|
IBM Tivoli DS v6.1
|
Windows 2003 Ent. Ed SP2
|
2
|
2.4 GHz
|
Intel Xeon
|
2
|
LDAP |
Test Environment – Cross-cell
The Process Portal, Cross-cell environment included:
· IBM WebSphere
Portal for z/OS v.6.1 primary node + IBM WebSphere Process Server v6.1.2
client + IBM WebSphere Application Server Deployment Manager 6.1.0.19 for
Portal only.
· IBM WebSphere
Process Server v6.1.2 primary node + IBM WebSphere Application Server Deployment
Manager 6.1.0.19 for Process Server only.
· DB2 9.1 PUT0803
DS2 (for WebSphere Portal databases only).
· DB2 9.1 PUT0803
DS2 (for WebSphere Process Server database only)
· IBM HTTP
Server v.6.1
· IBM Tivoli
Directory Server v6.1 -- contains 100,000 portal users
The following specifications detail the machines used to test the Process
Portal integration feature in horizontal clusters:
Process Portal Cross-cell Specifications
|
Machine
|
OS
|
# of CPUs
|
CPU Speed
|
CPU Type
|
RAM (GB)
|
Function
|
|
WebSphere Portal for z/OS v6.1+
WebSphere Process Server v6.1.2 client
+ WebSphere Deployment
Manager v6.1.0.19 +
DB2 9.1 PUT0803 DS2
|
z/OS V1 R9
|
LPAR
|
|
zSeries (z-10)
|
8
|
Deployment Manager, Process
Server client, and Portal node
|
|
WebSphere Process Server v6.1.2
+ WAS Deployment Manager v6.1.0.19 for Process Server +
DB2 9.1 PUT0803 DS2
|
z/OS V1 R9
|
|
|
zSeries (z-9)
|
6
|
Deployment Manager and Process
Server
|
|
IBM HTTP Server 6.1
|
Windows 2003 SE SP2
|
1
|
2.4 GHz
|
Intel
|
1
|
Provcess Server
Web Server
|
|
IBM HTTP Server 6.1
|
Windows 2008 EE
|
2
|
1.0 GHz
|
Intel
|
1.25
|
Portal
Web server
|
|
IBM Tivoli Directory Server
v6.1
|
Windows 2003 Enterprise Edition
|
2
|
2.8 MHz
|
Intel Xeon
|
2
|
LDAP |
Single-cell Installation and Configuration
The single-cell environment general steps are documented below. Before
configuring business process integration with Portal and WPS v6.1.2 in
a Single-cell configuration, you should review the information in the
“Planning
integration with WebSphere Process Server” followed by “
Integrating
with WebSphere Process Server” section. For the Single-cell
steps in particular, under the “
Enabling process integration” we
will follow the “
Understanding single-cell deployment scenarios”
section, and follow the steps in “
Enabling process integration in a
single-cell setup” section.
WebSphere
Portal for z/OS 6.1 Information Center
The steps to install and configure the Process Portal integration single-cell
test environment:
1.0
These steps assume the databases
for WebSphere Portal and WebSphere Process Server, the LDAP, and the web
server you are using are already installed and configured. For example
with the database, the DB2 on z/OS Data Sharing Coupling Facility has been
installed and configured. For the Windows machines, the IBM Tivoli
Directory Server v6.1 32-bit can be found on CD W-9, W-9A, and W-9B; and
the IBM HTTP Server v6.1 32-bit can be found on CD W-13.
2.0
Install WebSphere Deployment Manager
for z/OS on a single machine using the WebSphere Application Server
Customization dialogs (for install instructions, refer to the
WebSphere
Process Server for z/OS version 6.1.2 InfoCenter). Some notable
items are listed in this section. It is very important to record
the port values you are using for the Deployment Manager along with other
values. For security customization, we used WebSphere to manage
users, groups and the authorization policy. Generate the jobs after
you have saved the customization variables. Follow the instructions
in BBOCCINS -- remember to record the ports you assign – and run the jobs
defined. Make sure BBOWWPFD has TIME=NOLIMIT on the WPROFILE
EXEC statement to avoid a 522 ABEND. Next, you should make sure
RRS is active before starting the Deployment Manager. At this point
Deployment Manager is up and running – make sure you can log in to the
WebSphere Administrative console before continuing.
3.0
Create an empty managed node via
the WebSphere Application Server Customization dialog. Stop the Deployment
Manager first. Choose option 3 to “Create Network Deployment cells
and nodes”, and option 2 to “Create an empty managed node”. Note
that you will want to use a different procedure name for the Daemon definitions.
It is very important to record the port values you are using for the node
agent along with other values. Generate the jobs and run the jobs
to create the node agent. Make sure BBOWWPFM has TIME=NOLIMIT on
the WPROFILE EXEC statement to avoid a 522 ABEND. NOTE:
Do not
run the BBOWMNAN job to federate the node agent at this time since
we plan to install WebSphere Process Server (i.e., BBOWMNAN will be run
later). Update the SOAP port requestTimeout as instructed.
Stop and restart the node agent and deployment manager, and verify the
node agent appears in the Admin console. At this time, make a backup
of the file system so that you can restore if necessary.
4.0
Install the WebSphere Process Server
v6.1.2 on the deployment manager node on the same machine. Note
that process server has to be installed on the deployment manager node.
Refer to the
WebSphere Process Server for z/OS version 6.1.2
InfoCenter for the instructions for installing the process server.
After you run the zSMPInstall.sh script, you may have to create the
DB2JccConfiguration.properties file and customize the file with your DB2
sub-system information. You will also copy and update the response
file (DmgrDB2.rsp) to provide input for the configuration script zWPSConfig.sh.
After zWPSConfig.sh completes, verify the profile augmentation was
successful.
5.0
Install the WebSphere Process Server
on the empty node on the same machine. Note that you must run the installation
script zSMPInstall on each node that will belong to the Network Deployment
cell. You will copy and update the response file (ManagedDB2.rsp)
to provide input for the configuration script zWPSConfig.sh. NOTE:
This step is very similar to the same step you performed against
the Deployment Manager node, however, you use a different response file
called ManagedDB2.rsp to configure the Empty Node. Verify the profile
augmentation completed successfully.
6.0
Create the Process Server databases using
the createDB.sh script. Modify the values within the script for your
database, and make sure you change appropriate permissions before running
the createDB.sh script. Verify the database object was created along
with the table objects and indexes before continuing with the setup.
NOTE: if you are using a Distributed Data Facility (DDF), make sure you
have the correct DDF location specified or the objects will not be created.
Also note that at the time of this testing, the WebSphere Process Server
InfoCenter did not contain the createDB.sh.
7.0
Configure the empty node with WebSphere
Process Server by running the BBOWMAN job at this time. Make
sure the Deployment Manager has been started before running this job. Also
verify BBOWMAN has the correct username and password defined. After
the job completes, check the log file for errors before continuing.
Finally, check to see if the node agent has been started automatically
– if not, you will need to start it.
8.0
Create a cluster for WebSphere Process
Server by using the WebSphere administrative console. Make sure
you select the defaultProcessServerZOS as the application server template.
It is recommended that you use a prefix of BBO for the short name
of your cluster and cluster member to avoid configuration naming issues
(e.g., BB0C001 and BBOS001, respectively).
9.0
Create the messaging engine data store
using the sibDDLGenerator command. The sibDDLGenerator command
generates the DDL statements that the database administrator will need
to create the tables for the messaging engine data store. Note that
you will use “-version 8.1” for DB2 v9.1 databases as well.
10.0
Configure the Service Component Architecture
(SCA) support for the cluster by choosing one of the five different
configuration paths. For these tests, the production deployment environment
was chosen, and the method was via the WebSphere administrative console.
11.0
Configure the Business Process Choreographer
(BPC) configuration page using the WebSphere administrative console.
Make sure you complete each section’s input fields before pressing
OK button. When completed with setup, verify the Business Flow Manager
and Human Task Manager applications have started successfully. Also
verify the new buses have been defined under Service Integration buses,
and the new data sources have been defined. Finally, check that the
messaging engines have been started. If everything is in order, you
should be able to verify that BPC works, and can proceed to install the
BPC Explorer application as defined in the WebSphere Process Server Information
Center.
12.0
Optional: Configure the Common Event
Infrastructure resources, which was done for this test environment.
13.0
Configure the remote web server for
the environment. Assuming IBM HTTP Server v6.1 has been installed
already, verify the WebSphere plug-in with the BPC Explorer.
14.0
Install and configure business application
on the process server. For our tests, we installed the Travel
Request application example described in the WebSphere Portal for z/OS
6.1 Information Center. After completing the install, verify
the business process application has started and can be found in the BPC
Explorer under the My Process Templates link.
15.0
Create an empty managed node and install
WebSphere Portal for z/OS v6.1 by following the WebSphere Portal Information
Center steps. A few items to prepare before install are the DB2 bufferpool
sizes, record the port values being used at this point to avoid conflicts,
and make sure the config.hfs for the deployment manager and node agent
are large enough. Set the soap.client.props requestTimeout value.
Use WebSphere’s customization dialog to create an empty managed
node, generate the jobs, and run the jobs to create the node agent. Next
install Portal using the option 6 “WebSphere Application Server-based
add-on products. Using the Basic configuration tasks, select option 2 to
configure base portal into a federated WebSphere Application profile. Generate
the jobs and follow the instructions in EJPINDM.
16.0
Transfer WebSphere Portal from Derby
to DB2 database. This configuration example uses DB2, and follow
the steps to create databases, modify properties, and configure the DB2
databases for WebSphere Portal.
17.0
Create a new WebSphere Portal cluster
by federating an existing standalone Portal profile into a Network
Deployment cell. Save the variables and generate the jobs. Follow
the instructions in the data set member EJPINDS.
18.0
Configure the Portal cluster to use
a remote external web server by generating the latest plugin and copying
to the current remote web server. For this test environment, only
one web server was used in the single cell configuration since only the
portal users would actively use the web server during testing (i.e., BPC
Explorer was infrequently used during testing).
19.0
Prepare and configure the federated
user registry. For this configuration example the IBM Tivoli
Directory Server was added as the LDAP user registry. Modify the
wkplc.properties file for the environment, and add the federated user registry.
Note that this is done via option 6 (add-on products) for WebSphere
Application Server for z/OS Customization dialog. Run the jobs as
instructed in EJPISER.
20.0
Install the WebSphere Process Server
client on the WebSphere Portal primary node. Note that even though
WebSphere Process Server “server” had been installed on the same machine
and in the single cell, the process server client will still need to be
installed on the Portal node. Use the “-client” option to
install only the client. After the install, apply the steps in the
technote
- 1322547
.
21.0 The WebSphere Portal and WebSphere Process
Server environment was tuned using the specifications outlined by the
WPLC Performance Team. We used the Version
6.0 tuning guide v.1.2 as
a guide until the version 6.1.0.1 tuning guide becomes publicly available.
At this point, the business application task will appear in the task list
and you can begin to create instances.
Single-cell Test Methodology
A good example of a general-user scenario can be found Business process
scenario: Travel request and approval in the WebSphere Portal for z/OS
v6.1. Information Center.
The Travel request and approval scenario consists of the following three
user roles:
1.0 Sales
Representative: this group of users initiates/submits a travel request
instance. The Sales Representative fills out applicable fields and
submits the request. The Manager is notified of the request for travel.
2.0 Sales
Manager: this group of users approves the travel requests. When a
sales manager receives a request for travel in the Task List portlet, s/he
clicks on the Approve Travel task and fills in appropriate fields to approve
of the travel. After saving the work, the task is completed by the
sales manager.
3.0 Administrative
Assistant: this group of reviews flight schedules and purchases airline
tickets for the sales representatives. When an Administrative Assistant
receives a request to book a flight in the Task List portlet, s/he
clicks on the bookflight task and fills in appropriate fields to
purchase a ticket. After saving the work, the task is completed by the
Administrative Assistant.
Three groups were created in the LDAP user registry to contain a unique
set of authorized portal users for each role described above. Users
defined in one role did not belong to any other role. The user,
when accessing the Travel Request application only performed the
tasks permitted for that user group. Depending on the load of the
system, portal users logged on and processed Travel Request tasks
as they appeared in the application. The users continued to process
tasks for seven days.
Cross-cell Installation and Configuration
The cross-cell environment on z/OS was installed with similar steps as
described above for the single-cell configuration. However, there
were a few differences. One difference is the portal cluster and
the process server cluster each had their own Deployment Manager for administrative
control (that is, they did not share one Deployment Manager). Another
difference is both the portal and the process server had their own database
(DB2 data sharing and DB2 standalone, respectively). Finally, each
cell had its own web server. (NOTE: The Cross-cell diagram
in this document illustrates this configuration.)
Once the two cells were operational, the Process Portal Cross-cell configuration
followed the steps in the section “Understanding cross-cell deployment
scenarios” to configure business process scenarios.
Cross-cell Test Methodology
With the cross-cell configuration operational on the z/OS configuration,
the test methodology used was the same as the single cell Test Methodology
section. More details on a general-user scenario can be found Business
process scenario: Travel request and approval in the WebSphere Portal
for z/OS v6.1 Information Center.
Test User Configuration
The process portal environments were load tested using LoadRunner with
a total of 30 concurrent users: 10 users were Sales
Representatives creating tasks and deleting finished tasks, 10 users were
Sales Managers approving the travel request, 10 users were Administrative
Assistants booking the flights that have been approved. The test
was run for 5 continuous days.