Caching Issue in WebSphere Portal version 6.1, 7.0 and 8.0

Currently Committed database setting - Applies to DB2 v9.7 or higher and WebSphere Portal version 6.1 and 7.0

 

DB2 V9.7 introduced a new default behaviour for isolation level cursor stability (CS) (see http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0053556.html).
In WebSphere Portal this has implications for the cache invalidation strategy related to transactions. The new DB2 default behaviour for isolation level cursor stability (CS) is to NOT block code that wants to read data which is still being worked on in an uncommitted transaction in another thread (DB2 returns the result, as if the other transaction would not exist). But WebSphere Portal version 6.1 and 7.0 cache invalidation and refill strategies rely on the blocking at database level. With the new 'currently committed' default setting, stale data in Portal caches can occur.

Starting with Portal version 8.0 the setting of CUR_COMMIT to ENABLED is supported.

Besides the fact that CUR_COMMIT must be set to DISABLED for WebSphere Portal version 6.1 and 7.0, WebSphere Portal development does not expect a performance degradation when changing the value of CUR_COMMIT from ENABLED to DISABLED. For some scenarios with long database transactions, it could be that response times increase due to additional waits for updated data.

The setting of CUR_COMMIT is applied at database level. Therefore it is required to set CUR_COMMIT to DISABLED for the Portal database(s), containing the Portal database domains release, community, customization, jcr, feedback, and likeminds.

Disabling CUR_COMMIT in DB2 Version 9.7:

Ask your DB2 administrator to ensure that CUR_COMMIT is disabled by carrying out the following steps (for each of the Portal databases):

1. Connect to the runtime database:
   $ db2 connect to
   where represents the name of the database.
   
2. List the CUR_COMMIT parameter:
   $ db2 get db cfg show detail | grep CUR_COMMIT
   The output should look like this:
   Currently Committed (CUR_COMMIT) = DISABLED DISABLED
   
3. If the values are anything other than two times DISABLED (one for the current setting used, the other for the delayed setting specified in the configuration), change the value to DISABLED:
   $ db2 update db cfg using CUR_COMMIT DISABLED
   
4. Close the database connection:
   $ db2 connect reset
   
5. Check that no other application is connected to the database,to make the change effective (This e.g. requires to stop the Websphere Portal Server that uses the database). List the connected applications like this:
   $ db2 list applications for db
   where represents the name of the database.
   The output should look like this:
   SQL1611W No data was returned by Database System Monitor.
   
6. Ensure that the settings are correct by repeating the steps 1. and 2.

Full technote and source : http://www-01.ibm.com/support/docview.wss?uid=swg27037929&myns=swgws&mynp=OCSSHRKX&mync=E#!

IBM WebSphere Portal ConfigEngine Tasks

action-deploy-portlets-prereq.pzn

If you install Portal or WCM using the administration option, or base install, the Personalization features, including the Personalization Navigator and Personalization Editor, are not installed. However, you can add these features manually after installation by deploying the Personalization portlets and adding the Personalization Navigator and Personalization Editor to a page. This task deploys the personalization portlets.
Examples:

UNIX:

./ConfigEngine.sh action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

Windows:

ConfigEngine.bat action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

i5/OS:

ConfigEngine.sh action-deploy-portlets-prereq.pzn -DPortalAdminPwd=password -DWasPassword=password

Note that if you want to follow a common structure that IBM uses when personalization is installed, you could use an XMLAccess export from the ContentRoot > Applications > Content > Personalization node taken from a portal instance that has those pages with the portlets deployed on them.

activate-portlets

Auto-synchronization of the Web modules to each node in the cluster might not happen immediately, or at all, depending on how the administrator has auto-synchronization configured in the deployment manager. For this reason, WebSphere Portal cannot guarantee that the portlet has been successfully synchronized to each node in the cluster and thus cannot automatically activate the portlet during deployment.
Perform the following steps to manage your portlets:
Deploy your portlets using either the WebSphere Portal Administration page or the XML configuration interface utility (xmlaccess command).

Run this task to activate the deployed portlets and to synchronize the changes across all cluster members.

Example:

ConfigEngine.bat activate-portlets -DWasPassword=password task from the wp_profile_rootConfigEngine directory

add-wcm-la-attributes

Adds the look-aside (property extension) database attributes necessary for WCM. You have to create the look-aside database first. See: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Configuring_a_property_extension_database_on_Windows_wp7. Example command:

ConfigEngine.bat add-wcm-la-attributes -DWasPassword=password -DparentProperties=full path to wp_profile_root\\ConfigEngine\\config\\helpers\\wp_add_LA.properties

checkin-wp-proxy-config

This task activates changes made to the WebSphere Portal Ajax proxy configuration (wp.proxy.config.xml) file.

Example:

ConfigEngine.sh|bat checkin-wp-proxy-config -DProxyConfigFileName=dir_path/your_updated_proxy_file.name

cluster-node-config-cluster-setup

Example:

ConfigEngine.bat cluster-node-config-cluster-setup -DWasPassword=wpsadmin

create-jcr-jms-resources-post-dbxfer

The Java Content Repository (JCR) TextSearch functions are used for searching for content in the Lotus Web Content Management (WCM) Authoring user interface.As part of the install of IBM WebSphere Portal V7.0, all environments should be running the JMS task, "create-jcr-jms-resources-post-dbxfer," to move the JCR TextSearch resources from an Apache Derby Datasource/database configuration to the Datasouce/database that is used for the JCR repository. Failure to run this task can leave the datasource definitions pointing to Derby or cause the JCR TextSearch to not function properly.

Example:

create-jcr-jms-resources-post-dbxfer -DWasPassword=replaceWithWasPassword

configure-wcm-authoring

Installs the Web Content Management Authoring Portlet, Local Rendering Portlet and Web Content Manager Portal pages. This task can be run, for example, to install WCM atop a base portal install if the licensed edition allows for use of WCM.

Example:

ConfigEngine.bat configure-wcm-authoring -DPortalAdminPwd=xxx -DWasPassword=xxx

Lesson Learned: If the WCM Authoring portlet is invisible after running this task, try going into Portal Admin > Web Modules and make sure the modules for WCM are started (if they have the lightning bolt icon, you need to start them).

create-virtual-portal

Use this task to create a virtual portal. Additional parameters can be passed to the task, so please refer to the Virtual portals reference for details.

create-jcr-jmstopics

Recreates the bus and bus member used for JCR text search functionality.

database-transfer

Transfers the portal database from one to another depending on the settings in your configuration files (typically from the default Derby database to another such as DB2). You typically want to run the validate-database-driver and validate-database-connection tasks before this one.

delete-virtual-portal

Use this task to delete a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals.

deploy-full-profile-7002-theme

This config task applies the full profile to the WebSphere Portal7.0.0.2 theme.

deploy-lightweight-profile-7002-theme

This config task applies the lightweight profile to the WebSphere Portal7.0.0.2 theme

deploy-deferred-profile-7002-theme

This config task applies the deferred profile to the WebSphere Portal7.0.0.2 theme.

enable-identityprovider-tai

Enables a Trust Association Interceptor (TAI) for allowing OpenID authentication with an identity provider such as Google, Yahoo, or Facebook.

AIX:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

IBM® i:

ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Linux:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Solaris:

./ConfigEngine.sh enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

Windows:

ConfigEngine.bat enable-identityprovider-tai -DWasUserId=username -DWasPassword=password

For the additional parameters that must be added to this command for proper function, please refer to the product documentation: Configuring OpenID authentication

enable-profiles

This command creates a configuration archive (CAR) file that is used to create additional WebSphere Portal profiles. The Portal.car file is saved to the PortalServer_root
profileTemplates
default.portal
configArchives directory. This is typically done as a step in the process of creating the WebSphere Portal profile template in a clustered environment.

enable-wcm

Installs Web Content Manager into an existing Server installation. In a clustered environment, this must be executed on each node.

See: Installing Web Content Manager into an existing Server installation on Windows

export-library-copy

Exports a copy of a web content library. See: Exporting and importing a web content library copy

export-wcm-data

Exports a web content library. Several things need to be in place for this task to be executed properly, so please refer to: Exporting and importing web content libraries

import-library-copy

Imports a copy of a web content library. See: Exporting and importing a web content library copy

import-wcm-data

Imports a web content library. Several things need to be in place for this task to be executed properly, so please refer to: Exporting and importing web content libraries

list-all-virtual-portals

This tasks lists all your virtual portals, together with the following information:

• The title of the virtual portal
• The description of the virtual portal
• The realm of the virtual portal
• The object ID of the virtual portal.

See: Virtual portals reference for details.

list-server-ports

Example:

ConfigEngine.bat list-server-ports -DWasPassword=password

list-server-ports-by-name

Examples:

ConfigEngine.bat list-server-ports-by-name -DServerName=server1 -DWasPassword=password

ConfigEngine.bat list-server-ports-by-name -DServerName=WebSphere_Portal -DWasPassword=password

modify-servlet-path

Changes the default portal Uniform Resource Identifier (URI) after installation.
Example:

./ConfigEngine.sh modify-servlet-path -DPortalAdminPwd=password -DWasPassword=password

Note that additional steps are typically required. See the topic, Changing the portal URI, in the appropriate product documentation for your software version.

modify-virtual-portal

Use this task to modify a virtual portal by using its object ID. To determine the correct object ID of the virtual portal, use the task list-all-virtual-portals .

package-profiles

Zips the profileTemplates directory and creates a profileTemplates.zip file in the PortalServer_root/profileTemplates directory. This is typically done after the enable-profiles task as a step in the process of creating the WebSphere Portal profile template in a clustered environment.

remove-wcm-authoring

Uninstalls the Web Content Management Authoring Portlet, Local Rendering Portlet and Web Content Manager Portal pages.

run-wcm-admin-task-member-fixer

Creates a report of users or groups referenced in Web Content Manager items that need fixing. See product documentation: Using the web content member fixer task

Example:

ConfigEngine.bat run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=password -DWasUserId=username -DWasPassword=password -Dlibrary="MyLibrary"

To actually run the module and make the fixes, add -Dfix=true as shown below:

ConfigEngine.bat run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=password -DWasUserId=username -DWasPassword=password -Dlibrary="MyLibrary" -Dfix=true

si-remove-setup

Removes the Solution Installer PAAs and their registrations as part of the uninstallation procedure for the IBM WebSphere Portal Solution Installer. For more information, refer to the official documentation for the Solution Installer, which is a PDF file contained within the application that can be obtained from the IBM Lotus and WebSphere Portal Business Solutions Catalog. See also: si-setup.

si-setup

This task is executed as a part of the installation procedure for the IBM WebSphere Portal Solution Installer. After the SolutionInstaller.zip has extracted on a node, and the install script has been run, this task is then executed to set up and register the PAA offering directory that the Solution Installer uses. For more information, refer to the official documentation for the Solution Installer, which is a PDF file contained within the application that can be obtained from the IBM Lotus and WebSphere Portal Business Solutions Catalog. See also: si-remove-setup.

start-portal-server

Starts the portal server. Note that the portal admin user id and password should be set in wkplc.properties before executing this task.
Example:

./ConfigEngine.sh start-portal-server

stop-portal-server

Stops the portal server. Note that the portal admin user id and password should be set in wkplc.properties before executing this task.
Example:

./ConfigEngine.sh stop-portal-server

validate-database-connection

Typically ran after the validate-database-driver task and before the database-transfer task to validate successful connection to database.
Example:

ConfigEngine.bat validate-database-connection -DTransferDomainList=release,customization,community,jcr,feedback,likeminds

validate-database-driver

Typically ran before the database-transfer task to validate your database driver configuration.
Example:

ConfigEngine.bat validate-database-driver -DTransferDomainList=release,customization,community, jcr,feedback,likeminds

validate-federated-ldapValidates your LDAP server settings. Typically run before the wp-create-ldap task.validate-standalone-ldapValidates configuration settings for stand-alone LDAP.
Example:

ConfigEngine.bat validate-standalone-ldap -DWasPassword=wpsadmin -DparentProperties=Z:\helpers\wp_security_ids.properties

webdav-deploy-zip-file

Use this configuration task to manage theme artifacts and to deploy iWidgets. This task uploads archive or compressed files to portal WebDAV folders.
This task has parameters; please see IBM documentation: Task webdav-deploy-zip-file

wp-node-prep-vmm-db-secured-environment

wp-prep-vmm-db-secured-environment

wp-query-attribute-config

Run the ConfigEngine.bat wp-query-attribute-config -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory, any time during the configuration process or at runtime to query an overview of the currently defined LDAP attributes. This task creates the availableAttributes.html report, located in the wp_profile_root/ConfigEngine/log directory. The report contains one table that lists the available attributes for Users (PersonAccount) and one table that lists the available attributes for Groups. For each configured repository there is a column that indicates if the attribute is flagged as unsupported or if the attribute is mapped to a different LDAP attribute.

wp-query-repository

Lists the names and types of configured user repositories.

wp-update-standalone-ldap-attribute-config

Applies the settings from wkplc.properties related to marking LDAP attributes as unsupported or mapping the portal attributes to attributes in your LDAP. For example, you might need to map the "ibm-primaryEmail" attribute that portal uses to the "mail" attribute in your own LDAP.
See: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Mapping_attributes_on_Windows_in_a_clustered_environment_wp7. This task may do more, but at the time I wrote this, it was documented in this particular context.

wp-validate-federated-ldap-attribute-config

Validates that all defined attributes are available in the configured LDAP user registry.

Source : https://wiki.base22.com/

---

WCM page and authoring portlet may not display after migration

Greetings Fellow WebSpherians

I am posting this one in response to a few queries that were mailed to me and here's to it being helpful :

After migrating to IBM WebSphere Portal V7.0, you may not be able to navigate to or display the Web Content Manager (WCM) out-of-box page or the authoring portlet. In addition, some related functions in the user interface might not work or might generate exceptions when accessed. Clicking buttons in the authoring portlet may generate the following error in the log:

IWKAP0009E: Servlet not enabled.

If this occurs, you must re-enable these features manually after migration.

Cause

The migration process can disable some new out-of-the-box features if the feature did not exist in the previous release or if it was updated. In particular, the Portal page required for the reserved authoring portlet is missing and the permissions on the AJAX proxy servlet are not set correctly.

Resolving the problem

To re-enable the affected features manually after migration, do the following:

1. Make sure that the page on which the WCM authoring portlet is installed uses a theme with client-side rendering such as the Page Builder theme.
2. Deploy the hidden Portal page on which the reserved authoring portlet is installed.

3. Run the following task from the wp_profile_root / Config Engine directory.

Cluster note: Run this task on the primary node in a V7 clustered environment.

Windows:
ConfigEngine.bat install-wcm-hidden-authoring-page -DWasPassword=password

UNIX:
./ConfigEngine.sh install-wcm-hidden-authoring-page -DWasPassword=password

i/System:
ConfigEngine.sh install-wcm-hidden-authoring-page -DWasPassword=password

z/OS (run from the UNIX shell) :
./ConfigEngine.sh install-wcm-hidden-authoring-page -DWasPassword=password

No restart of the Portal server is required. 

How to retrieve a file name stored in WCM library file resource component using the API ReferenceComponent

finds the document id of the content items that match by name 
DocumentIdIterator docIdIterator = ws.findByName(DocumentTypes.Content, "testcontent");
DocumentId docId;
Content currentContent; 


loops through the document id's found in the iterator
while(docIdIterator.hasNext()) 
{
docId = (DocumentId)docIdIterator.next();

get the current content item
currentContent = (Content)ws.getById(docId); 

standard out log message
System.out.println("Log: Testing WCM API: Retrieved content name = " 
+ (String)currentContent.getName());

get the content's component reference element by name
ContentComponent myCmpnt = 
(ContentComponent) currentContent.getComponent("MyComponent");

standard out log message
System.out.println("Log: Testing WCM API: My Component getName = " 
+ (String)myCmpnt.getName());

Typecast using ReferenceComponent in order to access the library component 
stored in the content's component reference element

ReferenceComponent myRefCmpnt;
myRefCmpnt = (ReferenceComponent)myCmpnt;

Get the LibraryComponent which your content is referencing 
LibraryComponent myLibCmpnt = myRefCmpnt.getComponentRef() ;

standard out log message
System.out.println("Log: Testing WCM API: My Library Component name = " 
+ myLibCmpnt.getName());

Use the instanceof method to confirm the library component type. 
For example, this checks if your component is a Library File Component.

if (myLibCmpnt instanceof LibraryFileComponent)
{

In this example, the component reference holds a LibraryFileComponent. 
This will get the file name of the file stored in the LibraryFileComponent.
LibraryFileComponent fileCmpnt;
fileCmpnt= (LibraryFileComponent)myLibCmpnt;

standard out log message
System.out.println("Log: Testing WCM API: My Library File Component: File name = " 
+ fileCmpnt.getFileName() );
} end if statement

ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

 So WCM 7 Post migration step fail Right?Complaining about access and credentials?

The command you were running:

ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=xxx 

-DWasPassword=xxx -DPreviousPortalVersion=6.1.0.0 -DtransferDomainList=jcr

The Core Error : 

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

The Full write-out in your migration log :

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
Registry could not be loaded from WAS using current connection information.
Please verify your WAS connection properties and retry the operation.  Current input:
WasUserId: xxxxxx


The Solution:

Add the -DWasUserid=user_id  -DWasPassword=password  parameters to the task, and then rerun the task. Verify that the task ran without any exceptions.

Happy Trails!!!

Yours in WebSphere
Jerome Slinger

IBM WCM 6 to 7 Migration - Commands - Unix

Hi Y'all

Please find attached the commands I used during migration form version 6.0.1.X  to 7.0.0.1

• ./ConfigEngine.sh validate-database-connection -DTransferDomainList=jcr -DWasPassword=XXXXXX -DPortalAdminPwd=XXXXXX

• ./ConfigEngine.sh connect-database-jcr-migration

• ./ConfigEngine.sh create-wcm-persistence-tables
• This is not part of the IBM listed steps...you will thank me later :-)

• ./ConfigEngine.sh upgrade-jcr-datastore-601x-to-6100-jcr

• ./ConfigEngine.sh configure-wcm-migration

• ./ConfigEngine.sh configure-wcm-remote-admin

• ./ConfigEngine.sh action-create-schema-applyMIG7000-wp.migration.jcr.db -DPreviousPortalVersion=XXX -DCurrentPortalVersion=7.0.0.x -DWasPassword=Password -DPortalAdminPwd=Password
• Please add your Portal versions where the xx's are.

• ./ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=Password-DWasPassword=Password-DPreviousPortalVersion=6.1.0.x -DtransferDomainList=jcr
• This step fails - Build Failed

The attached error can be found in your migration log.

Error: 

MigrationSQLExecutor: ERROR ->DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, 

SQLERRMC: JCR.ICMSTJCRNODELOCKSX

Migration Log :

/WebSphere/WP_PROFILE/ConfigEngine/log/Migration.log

The Fix:

You can resolve the issue by binding the JCRDB, executing the following commands from a DB2 command line window:

==db2 terminate 

==db2 connect to jcrDB (this is the newly copied database from 6.0.x to 7.0)

==db2 bind PATH\db2schema.bnd blocking all grant public sqlerror continue db2 terminate 

Substitute "PATH" with the install path for your DB2, and make sure you find the db2schema.bnd in the path before running the command.

Also, verify that all the Datasource passwords are correct before running the next task. You can verify this in the security.xml at cell scope:

\config\cells\\security.xml:

Find this entry for the JCR datasource and make sure the encrypted password is the same as the other datasources; if not, set it to the clear text password, and it will be encrypted at the next restart:

authDataEntries xmi:id="JAASAuthData_1296387511109"

alias="jcrdbDSJAASAuth" userId="db2admin" password="setPasswordHere”

description="JAAS Alias for DataSource jcrdbDS"

Happy Trails and Yours in WebSphere

Jerome Slinger

IBM WCM 7 : Migrating from WCM 6.0 to 7 - Release Not Found

Error received during migration: Release not found

Error Example String:

/WebSphere/PortalServer/base/wp.db.impl/config/templates/updatedb/6.0.1.6-7.0.0.1/db2/release

 not found.

Solution:

The issue is caused by missing files for migration from 6.1.0.6 to  7.0.0.1. This happened, because fixpack 6.1.0.6 is newer and so not  known by current 7.0.0.1. An APAR is requested.

As there are no database changes in the affected area between 6.1.0.5  and 6.1.0.6, you could duplicate the files in

/base/wp.db.impl/config/templates/updatedb/6.1.0.5-7.0.0.1

to the new directory

/base/wp.db.impl/config/templates/updatedb/6.1.0.6-7.0.0.1

as a workaround.

This is obviously not ideal but will resolve your problem.

...so how does one end up with this problem.IBM recommends that clients/customers need to be at the most recent fix pack level and as 6.0.1.7 is the most latest users are running into problems.

I hope that this has helped.

Yours in WebSphere

Jerome Slinger

Migration version 6.0 to & - Checking your Versions

Hello Everyone

I am currently busy with a migration from version 6.0 to 7.

Prior to your migration it is important to ensure that you are on the most recent Fixpacks for both your 6 and 7 environment.

Finding your current Portal Version:

On Windows : run %WPS_HOME%\bin\WPVersionInfo.bat (e.g) c:\WebSphere\PortalServer\bin\WPVersionInfo.bat

On Unix : run $WPS_HOME/bin/versionInfo.sh (e.g) /opt/WebSphere/PortalServer/bin/WPVersionInfo.sh

What your report looks like:

--------------------------------------------------------------------------------
IBM WebSphere Portal Product Installation Status Report
--------------------------------------------------------------------------------

Report at date and time 2011-10-06T10:55:59+02:00

Installation
--------------------------------------------------------------------------------
Product Directory /WebSphere/PortalServer
Version Directory /WebSphere/PortalServer/version
DTD Directory /WebSphere/PortalServer/version/dtd
Log Directory /WebSphere/PortalServer/version/log
Backup Directory /WebSphere/PortalServer/version/backup
TMP Directory /tmp

Installation Platform
--------------------------------------------------------------------------------
Name IBM WebSphere Portal
Version 6.0

Technology List
--------------------------------------------------------------------------------
MP installed
PDM installed
WCM installed
PZN installed

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal MultiPlatform
Version 6.0.1.5
ID MP
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Document Manager
Version 6.0.1.5
ID PDM
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Personalization
Version 6.0.1.5
ID PZN
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere WebSphere Portal Web Content Manager
Version 6.0.1.5
ID WCM
Build Level wp6015_008_02
Build Date 11/08/2008

--------------------------------------------------------------------------------
End Installation Status Report
--------------------------------------------------------------------------------

You will notice that my current fix pack level is 6.0.1.5 so it's installing more fixpacks for me :-)

Will add that process as well.

Yours in WebSphere
Jerome Slinger

Preparing to migrate - 6.0.x to 7

Before starting the migration, go through this checklist:

Apply the latest cumulative fixpack on the 7.0 server. Refer to the IBM Support document, “Recommended Updates for WebSphere Portal and Web Content Management V7.0,” for more details.

Both the 6.x and 7.x servers should be using IBM DB2®. We tested these steps using DB2, but you can try the same with other relational databases (CloudScape is not supported).

Back up the JavaTM Content Repository (JCR) database on the 6.x server, and back up all the databases on the 7.0 server. So, in case there is a problem, you can restore the 7.0 databases to their previous working state and start over.

Verify that database-related properties in the Wkplc properties files on the 7.0 server have the correct information on all current databases being used besides the JCR database (JCRDB).

Delete the subscriber and syndicator pairs from the 6.x server before attempting the migration.

Check for any duplicate entries in the JCRSTLINKS table using following query:

select WSID , SIID , TNSID , TNAME , TIX, count(*)
from .ICMSTJCRLINKS
group by WSID , SIID , TNSID , TNAME , TIX having count(*) > 1

If you get any results from the above query, find the content with the name in TNAME column and delete it from the Authoring UI before backing up the 6.x database.

Original Article

System event logging: WebSphere Portal 7

The system event logging facility of IBM® WebSphere® Portal enables the recording of information about the operation of WebSphere Portal.

Event logs provide administrators with information on important or abnormal events, especially errors that occur during the operation of the product. In addition, event logs gather debugging information that helps IBM support to resolve problems.

WebSphere Portal provides two types of logging: logging of messages and logging of debugging messages called traces.

For information about how to use log files and a list of trace logger strings refer to the topic about WebSphere Portal logs.

This topic has the following sections:

Message logging
WebSphere Portal provides the logging of messages that report errors and status information.

The following types of messages are provided:

Informational

A condition worth noting but does not require the user to perform an action.

Warning

An abnormal condition has been detected. The user may have to take action. However, WebSphere Portal code is able to handle the condition without failing.

Error

A serious failure in the execution of the application that requires further action.

Messages for WebSphere Portal are logged in the following files:

SystemOut.log

Contains information that is useful for monitor the health of the WebSphere Portal server and all running processes.

System.err

Contains exception stack trace information that is useful when performing problem analysis.

Locating the log files: Log files for WebSphere Portal, including SystemOut.log and System.err are located in the following directory: wp_profile_root/logs/WebSphere_Portal

Trace logging
WebSphere Portal provides the logging of debugging messages called traces. These traces are useful for fixing problems. However, to save system resources, they are switched off by default.

Traces can be set for different durations:

Temporary

Traces can be set for a temporary period by using the administration portlet Enable Tracing or the IBM WebSphere Application Server administrative console. To set traces by using the portlet, proceed by the following steps:
Log in as the administrator.
Click Administration -> Portal Analysis -> Enable Tracing. The Enable Tracing portlet appears.
Type the required trace string into the field Append these trace settings:. For example, this can be com.ibm.wps.command.credentialvault.*=finest
Click the Add icon. Enable Tracing updates the field Current trace settings:
Note: Restarting WebSphere Portal will remove traces that were set by using the Enable Tracing Administration portlet.

To disable tracing, do either of the following:
Select the current trace settings under Current trace settings: and click the Remove icon. By the example given above, the current setting can be com.ibm.wps.command.credentialvault.*=finest.
Type the trace string *=info into the field Append these trace settings: and click the Add icon. This trace string overwrites all settings listed under Current trace settings: and resets it to the default.

Extended

To enable trace settings for a longer period of time, that is, for more than one session, switch them on in the WebSphere Application Server configuration. Proceed by the following steps:
Access the WebSphere Application Server Administrative Console by using this URL: http://hostname:port_number/ibm/console
Click Servers -> Server Types -> WebSphere application servers.
Select the application server.
Click Troubleshooting -> Change Log Detail Levels.
Specify the required trace settings. For example, this can be com.ibm.wps.command.credentialvault.*=finest
Save your updates.
Restart WebSphere Portal.
To disable tracing, specify tracestring: *=info and restart WebSphere Portal.

Changing the log file name and location
You can change the locations of the log files by configuring them in the WebSphere Application Server administrative console. Select Troubleshooting -> Logs and Trace -> server_name and select the logger type that you want to change. In the configuration dialog change the path for the log file as required. For a description of the available types of log files refer to the WebSphere Application Server information center.

Changing the language used in the log file
By default, information in the log file is written in the language that was used for the WebSphere Portal installation. However, because WebSphere Portal supports a number of languages, you can choose to have the log file information written in a language other than that used during installation.

To change the language used for the log file, edit the file log.properties. This file is located in the following WebSphere Portal directory:

UNIX: wp_profile_root/PortalServer/config/config
i: wp_profile_root/PortalServer/config/config
Windows: wp_profile_root\\PortalServer\\config\\config

Add the following line:

locale=xx

where xxis the two-letter abbreviation for the locale. For a list of the locale abbreviations used with WebSphere Portal, refer to Directories for languages. For example, to have log information generated in English, you would add the following line:

locale=en

Reference: Log file format
If the logs are written to the log file of WebSphere Portal and not redirected to the logging facility WebSphere Application Server, the log file consists of a sequence log records that are separated by blank lines.

The log records have the following format:

timestamp classification classname method threadID

messagecode: logmessage



Where:

timestamp is the time (to the millisecond) when the log record was created.
classification is one of the following letters:
E for error messages
W for warning messages
I for informational messages
l for traces (low details)
m for traces (medium details)
h for traces (high details)
classname is the Java class containing the code that triggered the log event.
method is the name of the Java method containing the code that triggered the log event.
messagecode is a unique identifier for this message, to uniquely identify the specific message and refer to it when consulting documentation or support. The message code is only available for error, warning, or informational messages, and not for traces. It consists of:
a four-character identifier for the component that defines the message.
a four-digit number identifying the message in the component.
a one-letter classification code, which can be E, W or I , as defined above.
logmessage is the actual log message describing the logged event. Error, warning, and informational messages are translated into the system locale. Trace messages are not translated.
threadID is the identification of the thread that triggered the log event.

Note:

Traces are written only if the specific tracing facility is enabled; all other messages are written unconditionally.
The system locale is part of the general internationalization features of WebSphere Portal and can be configured via LocalizerService. For more information refer to the topics about Setting service configuration properties and about the Portal configuration services.

The following is an example of a log record:

2003.05.16 13:36:14.449 W com.ibm.wps.services.datastore.DataStoreServiceImpl init 0000003a

DSTO0063W: The transaction isolation level is not set to READ_COMMITTED.
The current value is TRANSACTION_REPEATABLE_READ.

Source: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/System_event_logging_wp7