Health Checker tool for WebSphere Portal V7.0

The Health Checker tool allows you to run a verification of your WebSphere Portal settings before applying the Fix Pack or Combined Cumulative Fx itself to better plan your upgrade.

You can find more details at IBM Support site (Clicke Here)

<wp_profile>/ConfigEngine >  ConfigEngine.bat -DRequiredWAS=7.0.0.13 action-health-check-validation

URL Generation Tag: Generate URL to portlet edit defaults mode directly

You can find complete options available for <portal-navigation:urlGeneration> tag in IBM wiki, but it does miss mentioning about the "edit_defaults" portlet mode

Following sample helps to generate URL from theme to portlet edit_defaults mode directly

<portal-navigation:urlGeneration contentNode="yourPageUniquename" layoutNode="yourPortletUniquename" portletMode="edit_defaults" portletParameterType="render">

     <portal-navigation:urlParam name="param" value="Value"/>

      <a href="<%wpsURL.write(out);%>">Portlet_Edit_SharedSettings</a>

</portal-navigation:urlGeneration>

Property extension(formaly LookAside) – Adding custom attributes to file based repository

There may scenarios where security teams doesn’t allow you provide the write access to LDAP from portal to store any additional attributes. To overcome this issue you can use the property extension to store those additional attributes.

Following link explain steps to setup or configure the property extension database

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

Above wiki talks about the setting up the property extension on separate DB. But for testing it on the local portal installation you can add custom attributes to file based repository that comes out of the box websphere portal installation.

Perform the following steps to add new attributes to your user registry:

1. Install the required Enterprise Archive (.ear) file on WebSphere Application Server. Select the appropriate task to install the .ear file:

run the ./ConfigEngine.sh wp-la-install-ear -DWasPassword=password task from the wp_profile_root/ConfigEngine directory

2. Stop and restart the appropriate servers to propagate the changes.
3. Use a text editor to open the wkplc.properties file, located in the wp_profile_root/ConfigEngine/properties directory.
4. Enter a values for the following required parameters in the wkplc.properties file and save the changes

• la.providerURL = corbaloc:iiop:localhost:10035
• la.propertyName = yourOwnProperty
• la.entityTypes  = PersonAccount
• la.dataType   = String
• la.multiValued  = false

5. Run the ./ConfigEngine.sh wp-add-property -DWasPassword=password task to add the attribute to the user registry.
6. Stop and restart the appropriate servers to propagate the changes.

Troubleshooting:

1. “la.providerURL = corbaloc:iiop:localhost:10035” , Here 10035 bootstrap port number.
2. If “wp-add-property” fails because of the authentication , you can try changing following unders “sas.client.props”

# RMI/IIOP user identity

com.ibm.CORBA.loginUserid=wasadmin

com.ibm.CORBA.loginPassword=wasadminPassword

3. If you have multiple properties to add then change the “la.propertyName” and run the wp-add-property task for each custom property.
4. If everything is successful , then you can see the following xml element for each additional property added in <wp-profile>/config/cells/<cell>/wim/model/wimxmlextension.xml

    <wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="STRING"

        multiValued="false" propertyName=" yourOwnProperty ">

      <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>

    </wim:propertySchema>

5. To test whether additional attributes can store values for each user successfully or not

a). Click on the Edit profile from theme or edit the user from the “manage users and groups”

b). Click the portlet menu and click on “configure” portlet

c). check the  “yourOwnProperty” in that.
d). Add a value for the “yourOwnProperty”.

6. Open “fileregistry.xml” under <wp-profile>/config/cells/<cell>/ and check whether the value you have selected is available or not.

    <wim:entities xsi:type="wim:PersonAccount">

      <wim:identifier externalId="8690e35e-9d79" externalName="uid=wpsadmin,o=defaultWIMFileBasedRealm"

          uniqueId="8690e-9d79-4c397" uniqueName="uid=wpsadmin,o=defaultWIMFileBasedRealm"/>

      <wim:parent>

        <wim:identifier uniqueName="o=defaultWIMFileBasedRealm"/>

      </wim:parent>

      <wim:createTimestamp>2010-06-02T18:35:52.402Z</wim:createTimestamp>

      <wim:modifyTimestamp>2011-09-28T23:26:22.071-05:00</wim:modifyTimestamp>

      <wim:password>W51YTlldnA0Ok5iNkFmaGNVbis3dWRCcVN5t0KzFNdz0NCg==</wim:password>

      <wim:uid>wpsadmin</wim:uid>

      <wim:cn>wpsadmin</wim:cn>

      <wim:sn>wpsadmin</wim:sn>

      <wim:yourOwnProperty>Hello</wim:yourOwnProperty>

    </wim:entities>

Note: “fileregistry.xml” is your local user repository so be careful and suggests not to edit manually.


Additional Info: 
http://www-01.ibm.com/support/docview.wss?uid=swg21608856

Question

How can I verify the attribute mappings configured in a WebSphere Portal or Quickr server?

Answer

There are two methods to verify or review the Virtual Member Manager (VMM) attribute mappings in a WebSphere Portal environment.
1. Run the ConfigEngine task wp-query-attribute-config from the <wp_profile_root>/ConfigEngine directory.

AIX example:

ConfigEngine.sh wp-query-attribute-config -DWasPassword=password

The output of this task is a file called availableAttributes.html that is written to the directory <wp_profile_root>/ConfigEngine/log.

The HTML file will list the properties and corresponding mapping (if any) in table format for the VMM entities PersonAccount (users) and Group.

2. If wp-query-attribute-config fails or the HTML file does not contain the expected output, you can review the mappings manually by visual inspection of the VMM XML configuration files.

Standard Attributes

a. Open the file <wp_profile_root>/config/cells/<cell>/wim/config/wimconfig.xml

b. Look for the XML that begins with <config:attributeConfiguration>. Under this block or stanza all of the attribute mappings will be listed.

For each attribute entry, "name" refers to the attribute in the repository (usually an LDAP) and "propertyName" refers to the "VMM name" for the property or attribute.

For example:

<config:attributes name="userPassword" propertyName="password"/>
<config:attributes name="krbPrincipalName" propertyName="kerberosId">
   <config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

password is mapped to userPassword and kerberosId is mapped to krbPrincipalName for PersonAccount (users).

<config:attributes name="postalAddress" propertyName="homePostalAddress">
  <config:entityTypes>PersonAccount</config:entityTypes>
  <config:entityTypes>Group</config:entityTypes>
</config:attributes>

homePostalAddress is mapped to repository property postalAddress for both users and groups.

<config:attributes name="mail" propertyName="ibm-primaryEmail">
  <config:entityTypes>PersonAccount</config:entityTypes>
</config:attributes>

ibm-primaryEmail is mapped to mail in the repository.

Unsupported attributes 

If any property has been marked or set as "not supported" the property will appear at the end of the attributeConfiguration section. An property that is not supported will not be used by VMM and no query should be sent by VMM to the repository to fetch a non-supported attribute or its value.

All of the properties in the list below are marked as not supported.

<config:propertiesNotSupported name="homeAddress"/>
<config:propertiesNotSupported name="businessAddress"/>
<config:propertiesNotSupported name="countryName"/>
<config:propertiesNotSupported name="c"/>
<config:propertiesNotSupported name="viewIdentifiers"/>
<config:propertiesNotSupported name="identifier"/>
<config:propertiesNotSupported name="localityName"/>
<config:propertiesNotSupported name="stateOrProvinceName"/>
<config:propertiesNotSupported name="createTimestamp"/>
<config:propertiesNotSupported name="entitlementInfo"/>
<config:propertiesNotSupported name="modifyTimestamp"/>
<config:propertiesNotSupported name="displayName"/>
<config:propertiesNotSupported name="principalName"/>

Custom attributes

If you have installed the LA ("lookaside") enterprise application WIMSYSTEM.ear by running the ConfigEngine task wp-la-install-ear and have added custom attributes to the configuration, these attributes are written to file wimxmlextension.xml in<wp_profile_root>/config/cells/<cell>/wim/model.

Sample entries for custom properties are shown below:

<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String" multiValued="false" propertyName="EmployeeID">
<wim:applicableEntityTypeNames>PersonAccount
</wim:applicableEntityTypeNames>
</wim:propertySchema>

<wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String" multiValued="false" propertyName="region">
<wim:applicableEntityTypeNames>PersonAccount
</wim:applicableEntityTypeNames>
</wim:propertySchema>

Troubleshooting

Follow the Portal User Management Architecture (PUMA) Collecting Data document for the version of Portal in use. Refer to the links below in the Related URLs section.

Notes

1. Custom properties do not have to be mapped in VMM provided they are referred to by the attribute name as it appears in wimxmlextension.xml and an entry for the attribute exists in the file.

2, In some configurations, VMM may send a query for properties marked as NotSupported if a Property Extension database is configured.

3. If the property is known to VMM by default (the list of attributes VMM uses by default depends on the repository type) and the property is referenced by its actual name in the Portal (such as in custom code that you have written), then there is no need to map the property to another name in VMM.

For example, if you use IBM Directory Server you do not need to create a mapping for uid in VMM unless you intend to use uid under a different name. This means that uid does not need to be mapped "to itself", however, it is not an error to do so.

4. See the WebSphere Application Server documentation for more information about the default attribute set for each repository type.

Pagebuilder Theme Pros and Cons

While developing custom theme in portal 7 most of the people choose either the Portal Theme (standard) and Pagebuilder theme and we realized the following are pros and cons of page builder theme

Pros

1. You can create a page with a single click by using the Page Builder theme , from the “actions” link at top
2. Use the Customize button to add content or change the style and layout of the current page
3. WYSIWYG-style page editing tools
4. Pagebuilder Theme supports tagging and rating by default.
5. You can integrate the portlets with iwidgets like website displayer ..etc

Cons

1. The Page Builder theme does not use side navigation by default . But we can write our own ofcourse.
2. The “Show layout tools/hide layout tools” will not be shown in pages using the default Page Builder Theme.  In order to utilize the layout tools, users should switch the theme of the page to the Portal Theme. 
3. “Edit page layout” portlet structure is different from what end user sees because page layout is depends on the static layout HTML files attached as page metadata.
4. You can’t create the layout containers inside the another layout container.
5. The Page Builder theme does not support the portal color palette for themes.
6. Uses lot javascript code (DOJO widgets)
7. Troubleshooting is pain.
8. Need theme developer with lot of DOJO and javascript knowledge to edit any of the existing widgets.
9. Can’t find complete documentation, lot of hidden things like TLD’s, widgets …etc

To create custom page builder theme you need to touch multiple places like need EAR or WAR for the dynamic components , webDAV for storing the static or layout files. This is has both advantage and disadvantage.