If upgrading from the base 5.2.1 directly to 5.2.1-TF011, there are additional database schema updates required. All schema updates included with all patches on the 5.2.1 codeline including 5.2.1-TF011 must be applied. Please see the documentation included with those patches to ensure proper application of the required schema updates.

Note: Please refer to section 3.3 for instructions on when to apply database schema updates during the patch install if required.

2.3 Properties File changes

Following are the parameters added in common.properties file required for some of the features provided in this Test Fix.

# This is the maximum number of WSDL objects which will cached.

max_wsdls_in_cache=50

# Script Cache TimeOut is the time for which the system will not look

# for updates for a Script in the Cache from other JVMs

# Value is entered in MINUTES!

max_script_timeout=1

# Configure the size of the script cache

# Ideally, this value includes both docstore scripts and spec scripts

max_scripts_in_cache=1000

# This property decides whether the webservices would be session enabled or not. A true

# value will enable sessions for webservices.A webservice needs to be saved after changing

# the value of this property.

enable_webservice_session=true

# This property decides the session timeout period for the webservices session. The value is in seconds.

webservice_session_timeout=300

Please include them in your common.properties.

3 INSTALLATION

This section provides general guidelines to apply a patch to WebSphere Product Center. Some information may differ depending on the methods used for previous installations. Contact your support representative for WebSphere Product Center with any installation issues.

3.1 Preparation

Before attempting to apply the latest patch to WebSphere Product Center, the following preparation is recommended:

3.1.1 Stop the WPC application on the local machine

Complete the following steps to stop the WebSphere Product Center instance:

a) Check the scheduler to make sure there are no critical jobs that need to be completed. If the queue is clear, kill the scheduler manually by running the following script:

$TOP/bin/go/stop/stop_scheduler.sh

b) Check the workflow engine to make sure there are no critical workflow events in process that need to be completed by running the following script:

$TOP/bin/go/workflow_status.sh

If the queue is clear, shutdown the workflow engine manually by running the following script:

$TOP/bin/go/stop/stop_workflowengine.sh

c) Abort the entire application by running the following script:

$TOP/bin/go/abort_local.sh

All remaining WPC services running on the local machine will abort, including the RMI registry.

Note: Check to make sure all processes have stopped using the 'ps' command.

Kill off any rogue "java" or "rmiregistry" processes that remain after shutting down the instance. Occasionally, it may take several attempts to kill off all java processes. Continue killing all java processes until they are all dead.

3.1.2 Backup

a) Create a full backup of the current WebSphere Product Center directories before applying the patch. The patch will overwrite files that have changed. If any issues occur, the backup will allow a rollback to a previous version

b) Perform a full backup of the database before applying the patch to a production system

Note: Apply the patch to a test system to identify any issues before applying the patch to a production system. Do not delete the old WebSphere Product Center version until performing thorough testing with the new installation.

3.2 Patch application

To apply the patch to WebSphere Product Center, complete the following tasks:

3.2.1 Unpack tar file

Purpose: To extract and update any new installation files into the current working directory

Note: GNU tar is needed to untar the WebSphere Product Center files.

1. Copy the WebSphere Product Center tar file to the user or temporary directory.

Example:

{HOME_OF_WPC}/tarballs

2. CD to $TOP, the current working directory, and unpack the tar file:

Example:

Using GNU tar, the following command extracts and unzips the tar file using an absolute path:

tar zxvf /home/WPC/tarballs/5.2.1-WS-WPC-WS5_ORA-IF001.tgz

3.2.2 Run WebSphere Application Server script

After unpacking the tar file in the previous section, ensure that the default server (server1) is running and run the following WebSphere Application script:

$TOP/bin/websphere/install_war.sh

Note: Ensure that the default server (server1) is running, as it is required for the WebSphere Application Server script to work. If needed, start the WAS default server by issuing the following command as root:

${WAS_HOME}/bin/startServer.sh server1

3.2.3 Verify/Update configuration files

Verify all configuration files required by the new installation and make any updates as needed (refer to section 2.3 for details). Refer to the backup copy of the configuration files for the previous installation if needed.

* common.properties

* admin_properties.xml

* init_ccd_vars.sh

common.properties

On startup, the system will use this file to read in all system level parameters. This file includes settings for the database layer (connection parameters), directory settings, default character sets, thread-pooling parameters, and other settings, which are documented in the file.

File location: $TOP/etc/default

admin_properties.xml

This file is used by the administrative utilities to configure clusters of the application.

File location: $TOP/etc/default

init_ccd_vars.sh

The initialization file is the shell script that initializes the shell variables used by the system.

File location: $TOP/setup

3.3 Database Schema Modification

To apply the database schema modifications as outlined in section 2.2, run any included SQL instructions for your database. Make sure to create a backup of your database before running the SQL update in order to have a version of the database to revert to in case of any problems.

3.4 Verify Installation

3.4.1 Start WebSphere Product Center

To start the WebSphere Product Center, execute the following script:

$TOP/bin/go/start_local.sh

The script starts all the services needed to run WebSphere Product Center.

Note: This process should take approximately 30-40 seconds, depending on the speed of the processor.

3.4.2 Check status

Run the $TOP/bin/go/rmi_status.sh script that was provided by WebSphere Product Center and verify the following services have started correctly.

* admin_<machine name>

* appsvr_<machine name>

* eventprocessor

* queuemanager

* scheduler

* workflow

4 LIST OF INCLUDED CONTENT

4.1 Enhancements

Table 4‑1: Enhancements being delivered in 5.2.1-TF011

WSDL retrieval optimization (WSDL Caching)

WSDL validation switch

Script Caching

Webservice Splitting

Session Mangament in Webservice layer

4.1.1 Session Management – Portal Integration

WebService Session Management

Webservices invoked from portal are stateless. Session Management is implemented in portal by passing the Session ID in SOAP Header. WPC generates a new session ID for each portal user session. Portal user has to get and retain the session ID and send to WPC after each subsequent calls.

In the portal the Session ID is encapsulated in the user object. These user objects are contained in the WPSContext object. In order for the session management to work fine, the WPSContext object has to be cached either by the caching framework/portlet context, per user login.

WPC Request with SOAP Header

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

// without SOAP Header since it is the new user

WPC Response with SOAP Header

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header> <ns1:sessionIDsoapenv:mustUnderstand="0"xmlns:ns1="http://xml.apache.org/axis/session"/>4932478437954237555 </soapenv:Header>

Subsequent Call

WPC Request with SOAP Header

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header> <ns1:sessionIDsoapenv:mustUnderstand="0"mlns:ns1="http://xml.apache.org/axis/session"/>4932478437954237555 </soapenv:Header>

WPC Response with SOAP Header

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header> <ns1:sessionID soapenv:mustUnderstand="0" xmlns:ns1="http://xml.apache.org/axis/session"/>4932478437954237555 </soapenv:Header>

4.1.2 Portal Code changes

File : IWPCUser.java

Content:

public static final String WPC_AXIS_SESSIONID = "WPC_AXIS_SESSIONID";

Description:key variable name for the property in WPCUser to store the WPC generated SessionID.

File: SoapReponse.java

Content:

private String wpcAxisSessionID;

Description: Variable to store the WPC generated SessionID from the SOAP Response. This is used to check the request and response SessionID is same OR different in case of session timed out.

File: WSHelper.java

Method : public Element getCatalogs(WPCUser user) throws WPCMediatorException {

SoapResponse soapResponse = invokeSOAP(getSoapURL(

ISoapMessageKeys.REQ_GET_CATALOGS), requestXML,

(String)user.getProperty(WPCUser.WPC_AXIS_SESSIONID));

setWPCSessionID(soapResponse,user);

Description: Invoke webservice with sessionID which is stored in the User. Set the newly generated sessionID in user property only if it is new or timed out.

File: SoapInvoker

Method: private static SoapResponse invokeWithMOM(Call call, String requestMsg,Attachment attachment,String wpcSessionID) throws AxisFault {

//when the ResponseMessage contains SOAP session Header store it in soapResponse

SOAPHeaderElement resSessionID = call.getResponseMessage().getSOAPEnvelope().

getHeaderByName(SimpleSessionHandler.SESSION_NS,SimpleSessionHandler.SESSION_LOCALPART);

Long sid = null;

if(resSessionID != null) {

try {

sid = (Long) resSessionID.getValueAsType(Constants.XSD_LONG);

} catch (Exception e1) {

e1.printStackTrace();

}

return new SoapResponse(buff.toString(), attachmentList,sid.toString());

Get the generated SessionID from WPC Response and set the value in the SaapResponse Object.

Code to add the sessionID in SOAP Header if session exists

// when wpcSessionID is present create a SOAPHeader with Session ID

if(!UIUtils.isEmpty(wpcSessionID)) {

try {

//create a session element with session id

Document document = factory.newDocumentBuilder().newDocument();

Element sessionElement = document.createElementNS(SimpleSessionHandler.SESSION_NS,

SimpleSessionHandler.SESSION_LOCALPART);

sessionElement.appendChild(document.createTextNode(wpcSessionID+""));

SOAPHeaderElement sessionHeader= new SOAPHeaderElement(sessionElement);

sessionHeader.setActor(null);

//add Session ID to SOAP Header

call.addHeader(sessionHeader);

4.1.3 WPC Migration of WSDL definition Changes

The WSDL definition at the WPC needs to be changed to include SimpleSessionHandler in request and response flow of webservice processing.

To have this updated for the webservice definitions.

The following java class needs to be executed, which will update the server-config.wsdd according to common.properties values:

$JAVA_RT com.ibm.ccd.soap.common.WebServiceMigrationForSessionHandling

4.2 Bug Fixes

Table 4‑2: Bug fixes being delivered in 5.2.1-TF011

PMR	APAR	Bug Id	Synopsis
01314	JR25580	WPC00030917	Out of Memory issues in EntryNodes and Attribute values have been fixed. These problems were due to the fact that Garbage Collection finalizers were not consistently cleaning up the WPC objects. The "memory.log" files of the WPC services (e.g. $TOP/logs/scheduler_<appserver>/memory.log) should be retained, but include only the "memory used". This will be the natural consequence of the removal of finalize methods. Thus, instead of the current WPC business object counts at the tail of the lines: 2006-12-28 15:28:22,176 [memorymonitor_daemon1] INFO com.ibm.ccd.perf.common.MemoryMonitor - Memory Used: 9267k, 0, 0, 0, 0, 0, 4, 0, 0, 0, 2, 4, 1, 16, 12, the lines of memory.log would just look like this: 2006-12-28 15:28:22,176 [memorymonitor_daemon1] INFO com.ibm.ccd.perf.common.MemoryMonitor - Memory Used: 9267k
91976	JR24690	WPC00029232	Slow performance of rich search has been improved
57576	JR25190	WPC00030230	Problem using WPS mass edit portlet in order to remove values from attributes has been fixed.
28309	JR24742	WPC00030694	Problem in Commerce Integration kit with Merchandising Associations has been fixed
65033	JR25449	WPC00030715	Empty Soap envelop caused due to bad exception handling has been fixed
65368		WPC00031150	Scalabity of the WPC Web Services layer has been improved.
24678	JR25700	WPC00031203	Change in lookup table image display mode affecting usability has been fixed
65072	JR24827	WPC00029596	When using Realtime search, the link/result on the search did not work. Clicking on the link did not populate the field (For example, when creating items). This has been fixed
56953	JR25164	WPC00030206	In a WPC 5.2.1 installation, the sendFTP and getFTP operations didn't work. This has been fixed.
75890	JR25206	WPC00030371	Pop-up screen for "macro" didn’t close automatically.
21678	JR25114	WPC00030302	WORKFLOW PERFORMANCE improvement due to fixing Oracle session issues.
05554	JR24308	WPC00029078	The method getOriginalEntry() didn’t work as expected.
21678	JR25113	WPC00030300	WORKFLOW PERFORMANCE: Workflow code changes to improve performance were done
56041	JR25360	WPC00030696	saveUser script op truncated the user name after 20 characters
56936	JR24624	WPC00029428	LOOKUP("PORTAL_CONFIG","PATHSEPERATOR") CACHE was not used

5 LIST OF INCLUDED PREVIOUS PATCHES

This Test Fix includes all fixes from 5.2.1-TF010, 5.2.1-FP004 and all earlier 5.2.1 maintenance releases.

6 KNOWN LIMITATIONS

Table 6‑1: Known bugs on 5.2.1-TF011

Bug ID

Synopsis

YOU HAVE SUCCESSFULLY APPLIED THE TEST FIX FOR WEBSPHERE PRODUCT CENTER!