174 WebSphere Portal on z/OS
5.3.4 The test cases
The main intention for the test is to verify that WebSphere Portal on z/OS in a
sysplex behaves like WebSphere Portal for Multiplatforms when the latter uses
horizontal or vertical scaling. The intent was not to exploit all possible scenarios
within the sysplex on z/OS, for example, session persistence and failover
scenarios were not tested.
One problem during these tests was to show in which server instance of the
portal a special scenario was executed. Two tools were used to solve this
problem: the Vertical Cloning Test Portlet and a modified Login class that writes
The Vertical Cloning Test Portlet that is used in the class IBM WebSphere Portal
Version 4 Administration (WebSphere Portal for Multiplatforms) was installed.
This portlet was deployed without change on the z/OS portal and displayed the
Clone identification, as shown in Figure 5-11 on page 175.
1 server instance X X X
2 server instances 1 system
(not tested because reasonable usage was not
Multiple server instances in multiple systems
(like vertical scaling in WebSphere Portal for
All scenarios were executed using session affinity and no session persistence.
Chapter 5. WebSphere Portal in a Sysplex 175
Figure 5-11 Vertical Cloning Test Portlet
The Vertical Cloning Test Portlet was helpful during browser tests. It was not
used during the automated test scenarios or during parallel scenarios 1 to 3,
because the Host Name, Host IP Address, and Application Server Name are
identical for all clones in these scenarios. To cover these cases, the Login class
was modified to print a trace statement (--->SYSPLEX_TEST:Login <userid>) in
the standard output each time a login was made. This modification produced
similar traces to those shown in Figure 5-12 on page 176.
176 WebSphere Portal on z/OS
Figure 5-12 Standard output showing the login trace
Manual test with a browser
Log in manually via a browser to each of the portal instances. In all cases, the
login can be done using the same or different user IDs. The user IDs must have
the necessary access rights to access the security portlet. The access rights of
some user IDs are changed on one system. The users logged in to the other
portal instances verified that the modified rights are visible in all other portal
An automated scenario is created with AK/Stress to log in, view some portlets,
and log out again.
One user ID only used by all clients
Logging in from four clients with one user ID resulted in a successful scenario,
but produced this exception in all scenarios (except scenario 1), as expected: