WebSphere Issues

20/06/2012

Limitations to consider when creating WebSphere Portal cluster

Filed under: WebSphere Portal — Ishtiaque @ 1:09 pm

Before clustering WebSphere Portal you should consider following limitations:

  • You must install WebSphere Portal as stand-alone node before creating the cluster, you can’t install it on an existing managed node.
  • WebSphere Portal is not supported on a managed node that is not part of the clustered environment.
  • It’s not possible to change the settings through Global Settings portlet or the XML configuration interface in a clustered environment. These changes must be made by changing respective properties in the the deployment manager console i.e Integrated Solutions Console (ISC) > Resources> Resource Environment> Resource environment.
  • In order to support the search in a clustered environment you must install and configure search as a remote search service on an application server node that’s not part of the cluster.
  • Do not use spaces in cluster or it’s member name when creating a cluster or adding a member into cluster.
  • When creating the cluster verify that system time clock of Deployment Manager node and each future WebSphere Portal cluster member node is synchronized. If the time difference would be more than 5 minutes then during federating the portal node to dmgr it will fail.
  • When creating dmgr profile for cluster make sure it’s cell and node name are different from portal profile cell and node name.

References:

14/06/2012

Find out module name of a portlet placed onto a WebSphere Portal page

Filed under: WebSphere Portal — Ishtiaque @ 9:31 am

Some times it’s required to find out the module of the portlet that’s deployed onto a page. Few of the possible scenarios can be that we want to remove or disable the module of that portlet from WebSphere Portal.

There can more than one ways to achieve this task, but we will discuss one of the possible way. Let us assume we want to find out the module name for Welcome (ibm.portal.WebSphere Portal.Welcome) page under portal Administration tab. The portlet title that’s placed onto this page is Information portlet.

  • Export the page and open it in a text editor.
  • Search the page definition in the xml file either by title or it’s uniquename in our case it’s Welcome page.
  • Note down the value of portletref attribute under portletinstance tag that’s child node of content-node tag of Welcome page.
  • Search the value of portletref attribute that you note down in previous step in the xml file. It should match with objectid of any portlet tag under web-app. Note down the uid of web-app in our case it’s ‘BlurbPortlet..’
  • Now login to WebSphere Portal and navigate to Administration>Web Module and search for the module as ‘Blurb’.

13/06/2012

Points to consider when planning for multiple realms in WebSphere Portal

Filed under: WebSphere Portal — Ishtiaque @ 8:29 am
  •  A realm is a defined subset of number of repositories defined in the federated repository configuration of the Virtual Member Manager (VMM).
  • Multiple realms are NOT supported when WebSphere Portal user registry is configured as stand-alone repository.
  • A group in one of the repositories cannot encompass members from another repository.
  • Names  must be unique across the entire federated repositories.
  • VMM users a database to federate and track its child repositories. The database does not contains the individual user membership but it contains the necessary information required to access the child repository.
  • A single realm can be applied to multiple virtual portals but you can’t assign multiple realms to a single virtual portal.
  • VMM stores it’s configuration settings in wimconfig.xml file which can be located at /wp_profile/conf/cell/<cellname>/wim/config directory.
  • The wimconfig.xml file defines: The participating repositories for databases and LDAPs, The full repository’s base distinguished names (DN) and search bases for user and groups, The realms configuration for all defined realms.

References:

08/06/2012

Delete Tags and Rating in Websphere Portal V7 and V8

Filed under: WCM, WebSphere Portal — Ishtiaque @ 1:18 pm

First of all export all the tags and ratings using the sample ‘ExportTagsAndRatings.xml’ which can be located at /PortalServer/doc/xml-samples. You can import it from portal  admin console using Import XML portlet or you can use XMLAccess admin tool also. The result would be shown in the popup window if using Import XML. Copy the resultant text from popup window and save it in a xml file. The tag and ratings would be as follows:

<tag action=”update” domain=”comm” locale=”en” objectid=”ZCI_JGMPEVV24MFS50ITJS6F5J0006″ owner=”uid=wpsadmin,o=defaultWIMFileBasedRealm” resourceref=”ZCH_JGMPEVV24EV080IT331TNK2097″><![CDATA[training]]></tag>

<rating action=”update” domain=”comm” objectid=”ZCJ_JGMPEVV24EV080IT331TNK20P5″ owner=”uid=Employee1,o=defaultWIMFileBasedRealm” resourceref=”ZCH_JGMPEVV24EV080IT331TNK2097″ value=”5“/>

Now change the ‘action’ attribute of the tags or ratings that your want to delete from update to ‘delete’. Save the file and import it back to the portal. I would suggest to remove all the xml tags from the file except the one that you want to delete.

My sample DeleteTagsAndRatings.xml look like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<request build=”wp7002_132_01″ type=”update” version=”7.0.0.2″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:noNamespaceSchemaLocation=”PortalConfig_7.0.0_2.xsd”>
<portal action=”locate”>
<tag action=”delete” domain=”comm” locale=”en” objectid=”ZCI_JGMPEVV24MFS50ITJS6F5J0006″ owner=”uid=wpsadmin,o=defaultWIMFileBasedRealm” resourceref=”ZCH_JGMPEVV24EV080IT331TNK2097″><![CDATA[training]]></tag>
<rating action=”update” domain=”comm” objectid=”ZCJ_JGMPEVV24EV080IT331TNK2093″ owner=”uid=wpsadmin,o=defaultWIMFileBasedRealm” resourceref=”ZCH_JGMPEVV24EV080IT331TNK2097″ value=”4″/>
</portal>
</request>

05/06/2012

Best practices for creating and securing a page and portlet hierarchy

Filed under: Security, WebSphere Portal — Ishtiaque @ 8:03 am

Follow these best practices for creating and securing a page and portlet hierarchy:

  • Organize the hierarchy to permit security through inheritance.
  • Assign roles NO higher than Privilege User role to average portal user.
  • Lock container content to prevent users from adding or deleting content.
  • Copy portlets to assign different level of access.
  • Assign user the same privileges on the page as the highest privilege of the portlet placed on the same page.
  • Assume that a user has the highest level of access granted to them by more than one group.

Reference: IBM Course WPL81 – Installation and Administration of IBM WebSphere Portal 7.0 on Windows

Create a free website or blog at WordPress.com.