Direct to Server URL Loses Port Number (WebSphere Portal 6.1)

I recently encountered a situation that required direct-to-node testing of one server in my portal cluster, so I looked up the default port for this server and typed in my internal URL:  http://myserver:10048/wps/portal... It was immediately obvious that something was wrong when the IBM logo and the login button did not render correctly.

I attempted to log in anyway... 404.  I noticed that the URL was incorrect in that the server-specific port had been removed, so my URL looked like this:  http://myserver/wps/myportal/...

It took a little digging, but I was able to find and resolve the problem with the following steps.

In the Deployment Manager

1. Navigate to Resources -> Resource Environment Providers
2. Click WP_ConfigService
3. Click Custom Properties (on the right)
4. Clear the http.host.port property (mine was 80)
5. Clear https.host.port property to (mine was 443)
6. Sync the cluster and restart the portal servers

Blank values for http.port and https.port

Happy portalling!

Hiding Portal Pages from Navigation (WP 6.1)

Hiding portal pages (and other items) from Portal Navigation is a common requirement, but there is no obvious way to do this.  There are some suggestions that using the Manage Pages portlet works, though I have not had any success with it.  My personal approach requires xmlaccess, but has never let me down!  Here's how I do it:

First, use xmlaccess to export the page, label, or other item(s) that you need to hide from navigation.  For a brief tutorial about xmlaccess exporting, the following article may be helpful: http://www-01.ibm.com/support/docview.wss?uid=swg21260098

Following is a snippet from a Portal 6.1.0.3 xmlaccess export that I took - it has been mangled slightly to fit on the page.  The parameter in question is highlighted in red.  If your export does not contain this parameter, just copy / paste from this article and it should work fine.

        <content-node action="update" active="true" allportletsallowed="false" create-type="explicit" domain="rel".... >
            <supported-markup markup="html" update="set"/>
            <localedata locale="en">
                <title>Enterprise Search for classic collections</title>
            </localedata>
            <parameter name="colorPalette" type="string" update="set"><![CDATA[bcbstp2Theme/bcbstp2Theme]]></parameter>
            <parameter name="com.ibm.portal.Hidden" type="string" update="set"><![CDATA[true]]></parameter>
            <parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
            <parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[No]]></parameter>
            <parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[OmniFindSearch]]></parameter>
            <parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA[0]]></parameter>
            <parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>

If the parameter already exists, just change the value within the CDATA block to "true" (to hide the page) or "false" (to show the page), depending on what you need.

Once you're done, save the xmlaccess file (make sure you keep a back up of your original export!) and reimport to your server.  The changes should be visible to Portal Navigation on the next reload.

Happy Portalling!

Memory Analysis - Gathering Java Cores on Windows WebSphere Servers

After dealing with a few memory leak issues in a windows-based, production environment, I have found the following steps to be most useful for gathering java cores to analyze for potential memory leaks.  

Download the Microsoft Debug Diagnostic Tool v1.2 http://www.microsoft.com/download/en/details.aspx?id=26798

Download the tool appropriate to your environment (32b vs. 64b)

Install the tool with default settings.

Launch the tool.

Cancel the "Rules Wizard" (if it shows up)

Click the "Processes" tab.

Select the java.exe process to be monitored.

Right click and select "Monitor for Leaks".

Wait about 15 minutes after starting the server, then right click the monitored java.exe and select "Create Full Userdump

1.                Install and take the defaults

2.                Launch Debug Diagnostic Tool

3.                Cancel the "Rules" wizard if it pops up

4.                Go to processes tab

5.                Locate the java.exe that you suspect to be leaking memory

6.                Right click and select "monitor for leaks"

7.                After 15 minutes, right click on the same java.exe from step 5 and select "Create Full Userdump"

8.                Depending how log it takes for memory to grow (minutes, hours, days, weeks...) collect 2 more userdumps over time for comparison analysis

9.                Review dumps by clicking the Advanced Analysis tab

10.              Click the "Add Data Files" button

11.              Locate dumps (default: <Debug_Diag_Install_Dir>\Logs\Misc)

12.              Select  the dumps from the same PID that you created in step 7

13.              Select "MemoryAnalysis.asp"

14.              Click "Start Analysis"

Adding LDAP Attributes to WebSphere Portal 6.1

When using an external directory for security in WebSphere Portal 6.1, you may find that some of the attributes in your directory are not available to applications, even through direct PUMA calls.  This is because WP only has default access to a base set of default attributes and anything outside of this set has to be mapped manually.

Adding these attribute mappings for WebSphere Portal 6.1 can be a little tricky, but once you've done it a few times it gets easier.  The following article attempts to provide a concise list of the steps required to add custom LDAP Attributes to your IBM WebSphere Portal 6.1 cluster.

The full IBM InfoCenter document can be found here: http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1/index.jsp?topic=/com.ibm.wp.exp.doc_v6101/install/i5os_add_attributes.html

Special thanks to Gabriel Boie (http://theoreticaltechstuff.blogspot.com) for providing clarifying information regarding this task!

I will assume that you already have a valid LDAP configuration and that you know your primary node's profile path and can find both the ConfigEngine.sh/bat and wkplc.properties files.  

Install WIMSystem.ear
This config engine task installs the WIM application required to add and map the new LDAP attributes.

• Stand-Alone:

ConfigEngine.bat wp-la-install-ear -DWasPassword=password

• Clustered:  This must be run on the primary node, but the Server and Node name parameters are for the deployment manager.

ConfigEngine.bat wp-la-install-ear -DWasPassword=password –DServerName=server_name –DNodeName=node_name 

• Restart the Cluster.

Add the LDAP Attributes

• Backup the wkplc.properties file in your primary node, then open it in a text editor.
• Find and update the following properties with values that meet your needs - the following is an example specific to my environment.

la.providerURL=corbaloc:iiop:localhost:10031
la.propertyName=extendedAttribute01
la.entityTypes=PersonAccount
la.dataType=String
la.multiValued=true

• Save the wkplc.properties file and execute the following ConfigEngine command:

ConfigEngine.bat wp-add-property -DWasPassword=password

TIP: A connection refused error will occur if the providerURL address and/or port are incorrect.  Check your server settings for address and port. 

TIP: A NameNotFoundException following a message stating that the WIMServiceHome EJB could not be found will likely occur if you neglect to restart the cluster after installing or reinstalling WIMSystem (wp-la-install-ear). 

TIP: An error stating that the service must be run on the deployment manager (paraphrased, I don't have the exact message, sorry) most likely indicates that WIMSystem.ear was installed using an incorrect server and/or node name.  The following technote addresses this situation: http://www-01.ibm.com/support/docview.wss?uid=swg21383774 

TIP: Provide LDAP credentials at the prompt.  Your bind account should have write access, though these mappings are possible without them.

• REPEAT the steps under "Add the LDAP Attributes" once for each attribute you need to add. 

Map LDAP Attribute Names in Portal

For the final step, we have to map the LDAP attribute names to Portal attribute names.  This simple process is described in http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1/index.jsp?topic=/com.ibm.wp.exp.doc_v6101/install/i5os_add_attributes.html.  The following example applies to standalone LDAP only!  For federated LDAP, reference the aforementioned infocenter document.

• Update your wkplc.properties files with the appropriate LDAP names, desired portal names, and matching entity types.

standalone.ldap.attributes.mapping.ldapName= extensionAttribute2, extensionAttribute6, extensionAttribute8, extensionAttribute10, extensionAttribute11, extensionAttribute13

standalone.ldap.attributes.mapping.portalName= DepartmentCode, DivisionCode, ManagerCode, EmployeeGrade, BuildingName, BusinessUnit

standalone.ldap.attributes.mapping.entityTypes=PersonAccount, PersonAccount, PersonAccount, PersonAccount, PersonAccount, PersonAccount

Execute the following ConfigEngine task:

• ConfigEngine.bat|sh wp-update-standalone-ldap-attribute-config -DWasPassword=password