Implications of a no session timeout configuration in Portal

Problem(Abstract) Configuring IBM WebSphere Portal with no session timeout can cause memory growth problems because of the accumulation of HTTP sessions that live forever in the Java heap.

Resolving the problem

It is better to configure a finite session timeout in order to control memory usage of session management. For example, set the session timeout to 30 minutes (the default). After testing this value, you may increase or decrease it in order to better customize the user experience on Portal.

Update strategy for Workplace Web Content Management version 6.0

Preventive Service Planning Abstract Announcing a strategy for delivering maintenance updates for IBM® Workplace Web Content Management™ (WCM). By implementing a consistent and timely update strategy, customers can avoid rediscovering the problems we have already fixed and maintain a more stable and robust environment.

Content

Beginning with version 6.0.1.4 and continuing forward, IBM® Workplace Web Content Management™ Support is delivering this strategy to provide a clear upgrade path for our customers that reduces the risk of installing multiple individual interim fixes for their portal-based content management system. Following these guidelines provides a consistent maintenance approach you can follow as you manage your environment. Installing preventative maintenance as soon as it becomes available can avoid problems that could result in a service call and lost productivity. This will also save you time. Recommended Update Path Fresh installations begin with the most recent installation media. Update to latest refresh pack and fix pack in order to proactively avoid problems already resolved within WebSphere Portal and WorkplaceWeb Content Management. Plan appropriate testing prior to installing any update solution in production. Ensure testing or staging environments closely match the production environment (same hardware, topology, operating system and software maintenance levels) to avoid compatibility issues. Delivering Updates Fix pack deliveries will be scheduled every 3 to 6 months Cumulative fixes will be scheduled every 2 to 6 weeks There is a single list of all internal defects and APARs fixed for each release that is updated for each new fix pack. Install on top of either a specific refresh pack with no fix pack applied or a refresh pack with any previous fix pack installed Newer maintenance levels of underlying software are tested with the latest fix pack, but delivered separately. It is your responsibility to retrieve and install these updates, if necessary. These updates are explained in the following table*: Solutions Characteristics of Each Solution Release A new WebSphere Portal that includes major new function, such as V6.0 This is a separate installation that can coexist with other WebSphere Portal releases Full testing of all applications with new release is recommended Requires migration to upgrade, distribution via Passport Advantage Refresh pack A package that may include new features and fixes, such as V6.0.1 Refresh packs are cumulative, so for example a V6.0.2 would include features and fixes contained in V6.0.1, as well as any subsequent fix packs and interim fixes published for V6.0.1 Refresh packs uninstall all fix packs and interim fixes previously applied to the release. So, it is necessary to check the list of delivered fixes to determine if an interim fix must be reinstalled. Regression testing of critical functions with new refresh pack is strongly recommended to ensure your custom applications continue to function as expected. Fix pack This is the standard delivery for updates - it has been fully regression tested by IBM prior to release. A fix pack is a cumulative package of only fixes, such as V6.0.1.1, unless otherwise noted Fix packs install on top of a specific refresh pack, such as applying V6.0.0.1 to V6.0.0.0 Fix packs also install on top of a previous fix pack, such as applying V6.0.1.3 to V6.0.1.1 Fix packs are cumulative, so V6.0.1.3 includes all fixes in V6.0.1.1 Fix packs uninstall all interim fixes applied to the release since the last refresh pack or fix pack was installed. Therefore, it is necessary to check the list of delivered fixes to determine if an interim fix needs to be reinstalled. Brief testing of critical functions with the new fix pack is recommended to ensure your custom applications continue to function as expected. Cumulative Fix This is the standard delivery for necessary updates between fix pack releases - it has been well tested by IBM Quality Engineering prior to release. This is a cumulative package of only fixes as explained in each CF's readme file Provides a collection of APAR fixes that were available for previous Web Content Management CFs (WebSphere Portal fixes are not included, these are specific for the WCM component) Inclusive of all APAR fixes since the base release (for example. CF1 includes APARs since the initial release, and CF2 includes APARs since WCM 6.0.1.4 (in addition to the APARs corrected in CF1) Since the CF includes multiple APARs, there is a risk of someone installing an individual interim fix on top on a CF and thus causing corruption. Hence any subsequent APAR installation process must be clear about the existing CF it will require for installation Interim Fix A single published emergency fix, such as for an individual APAR PK77777 A fix is an interim fix or test fix that resolves one or more product defects. A fix can be applied to a release, refresh pack, fix pack or cumulative fix level where applicable Interim fixes are created when a stand-alone fix is required between fix packs and cumulative fixes. They are validated by at least one customer and verified by IBM before publishing. Test fixes are not generally released but might be provided by IBM support during the course of a service call (PMR). Given the frequent release schedule planned for Cumulative Fixes, customers are encouraged to wait and install a cumulative fix integrating any required fixes instead of using an interim fix when possible. It is recommended that you test functions affected by the component fixed *Some of the service releases mentioned in the above table are for example purposes only and may not reflect any specific planned releases or updates.

Portal Upgrades: Best Practices

Question
IBM® WebSphere® Portal upgrades can be a very combersome undertaking. This document is meant to provide a basic set of what to do and what not to do when performing Portal upgrades.

Failure to observe these points, particularly in the 'What NOT to do' section can result in an unusable system and often results in complete reinstalls.

Answer
What to do:

* Ensure you have a working backup of your environment. This includes a full file structure backup AND a full database backup. Having only one or the other is no better than having no backup at all. Portal upgrades cannot be uninstalled if they fail.

Customers using DB2 on z/OS: When taking the database backup starting 6.0.1.4 and higher fix packs it is sufficient to only take a backup of the data but not the DB2 catalog as separate SQL files are provided to revert changes applied to the database schema during fixpack installation.
* Ensure file permissions are set correctly for UNIX environments. If you are using a non-root user, ensure that the user owns the AppServer directory, the PortalServer directory and the profile directory. Ensure that the non-root user has full access to the /tmp directory.
* If the upgrade fails, fix the problem with the upgrade and finish it before attempting anything else with the system (unless you decide to restore a backup).
* Ensure you have followed all of the 'Before You Begin' steps from the upgrade instructions.



What NOT to do:

* If upgrading a clustered environment, upgrade the primary node first. DO NOT upgrade a secondary first.
* If upgrading a clustered environment, DO NOT upgrade cluster nodes simultaneously.
* If an upgrade fails, DO NOT attempt to apply a different fixpack on top of a fixpack failure. This is the most common action that results in a complete reinstall.
* Do NOT upgrade a node that is federated but not clustered. Create a cluster first, even if it is just one node.
* If an upgrade fails, DO NOT attempt to further configure the Portal server (reconfigure secuirty, transfer the database, etc) until you have resolved the upgrade failure.
* When restoring a backup, DO NOT simply overwrite the existing WebSphere directory with a backed up one. You run the risk of corrupting the environment since overwriting the directory might not remove new files that had been laid down by the failed upgrade.

Some good look and feel websphere portal examples

The message is clear. When you deploy a portal, you have to be careful in choosing your provider. Here I put a list of nice websites based on WebSphere Portal. There are portals from different countries, USA, Mexico, Colombia, Chile, Spain... Look at the "look and feel". Look at the changes. The "painter" is important !!


http://www.aeat.es

http://www.damm.es

http://www.tenerife.es

http://www.huelva.es

http://www.fundacioncyd.org

http://ww3.achs.cl/ws/wps/portal/

http://www.trafikoa.net

http://contrataciondelestado.es

http://www2.itesm.edu

http://www.cancilleria.gov.co/

http://wps.portalbita.net/wps/portal/!ut/p/.cmd/cl/.l/es

http://www.fundacionexe.org.co

http://www.geoportal.gov.co

http://www.ncaa.org

http://www.alcatel-lucent.com/wps/portal/BellLabs

http://www.ncaa.org

http://solutions.productos3M.es/wps/portal/3M/es_ES/EU/Country/

http://www.realinstitutoelcano.org/

http://corporate.homedepot.com/wps/portal/Grants

http://miamidade.gov/wps/portal/spanish

http://oneshpe.shpe.org/wps/portal/shpe2008

7 Steps to Portal Information Architecture Bliss

In the book "Intranets for Info Pros" (Information Today), there is a list of seven elements to consider when considering a portal implementation, and I think they bear repeating here for anyone looking to either build or enhance an intranet portal:

1. Limit technical customization of the portal to items planned for by the software supplier or easily accommodated in the software.
2. Fully understand the logic of how the individual portal software approaches content publishing, information architecture, and collaboration spaces before designing the portal--in other words, do not try to radically adapt the portal to your preconceived notion of how it all should work; use the software's design to achieve your goals.
3. Do not underestimate the time and effort of content migration.
4. Avoid duplicating the problems of the old intranet in the new portal by working with content owners to migrate content item-by-item rather than page-by-page (try to break content into distinct individual content items rather than relying on the old page structure).
5. Map the individual content items to individual portlets or content modules (use a content inventory listed on a spreadsheet), and then assign content modules to pages--fully understand and take advantage of the distributed nature of portal content publishing.
6. Be sure content owners and their organizations are prepared to take on content maintenance before beginning the migration process. Emphasize that starting with a simple set of content is a good thing--complexity witll come soon enough.
7. Recognize that content migration is a golden opportunity rather than a necessary chore; you will never have a better chance to clean up out-of-date content and navigation again.

Using Model SPI to get Page title

IBM WebSphere Portal uses a concept of Models for content aggregation, to track user's pages etc. The Model SPI provides access to these models. The attached code provides an example to illustrate on how to get a title of a page using model SPI in JSR 286 portlet. Here is the code snippet to get title of page

public String getTitle(PortletRequest request, PortletResponse response)
{
Context context=null;
PortletServiceHome homeObject =null;
NavigationSelectionModelProvider provider=null;
NavigationSelectionModel navSelectionModel = null;

try
{
context = new InitialContext();
homeObject = (PortletServiceHome) context.lookup("portletservice/com.ibm.portal.portlet.service.model.NavigationSelectionModelProvider");
provider = (NavigationSelectionModelProvider) homeObject.getPortletService (NavigationSelectionModelProvider.class);
navSelectionModel = provider.getNavigationSelectionModel(request, response);
}
catch (Exception exception)
{
exception.printStackTrace();
}
NavigationNode selectedNode = (NavigationNode) navSelectionModel.getSelectedNode();
//Following is commented since there is no title for page if user's locale is US English
//String pageTitle = selectedNode.getTitle(request.getLocale());
String pageTitle = selectedNode.getTitle(Locale.ENGLISH);
return pageTitle;

}

Portlet shows English title of page. For locale of US English there is no title for page and you will see null value. You may comment this line of code and uncomment previous line of code to get title of page in your locale. Please login to the site to download war file.

Sharing Data Among Portlets

There are number of ways to share data among portlets. This article introduces all these techniques.

Using PortletSession: Any portlets that are located in a same WAR file can share data using PortletSession. The setAttribute and getAttribute methods needs to be called with scope argument set to PortletSession.APPLICATION_SCOPE in order to share data.

Public Render Parameters: The render parameters set from either in processAction method or in render URL are only accessible from the same portlet. JSR 286 introduces public render parameters to share navigational state across portlets even located in different WAR files. Using this parameters to share data avoids event phase as needed using event technique. The render parameters can be shared by just defining XML elements in portlet.xml.

* The public-render-parameter tag should declare the parameter at portlet application level.
* Each portlet must reference the defined parameter using supported-public-render-parameter tag.

Using Events: In addition to public render parameters, JSR 286 introduces events to share data. Unlike public render parameters, events allows to send payload as an object. In order to share data using events, an action phase should occur by user's action of either clicking on a link that is created with action URL or submitting a form whose action is created as action URL. Here are the key points to understand the flow.

* Both sender and receiver portlets should declare same event using event-definition element at application level in portlet.xml.
* The sender portlet should refer the event using supported-publishing-event at portlet level in portlet.xml.
* The receiver portlet should refer the event using supported-processing-event at portlet level in portlet.xml
* The action invocation should occur to sender portlet. During processAction method, it should create pay load object and call ActionResponse.setEvent method to publish event.
* The receiver portlet should define processEvent. In this method it can get event object from EventRequest object. This event object carries payload.

Using Resource URL for Ajax

This below sample code illustrates how to use Resource URL for initiating Ajax requests. This allows to update portions of page without refreshing whole page.

<span style="font-weight: bold;">Introduction</span>
This portlet displays a drop-down list to select country. Upon selecting, an Ajax request is sent to portlet. This will invoke serveResource method of portlet which sends a text message containing major cities part of selected country. These cities are shown in hidden division in the portlet window.

<span style="font-weight: bold;">Analysis of portlet project</span>

1. The following is sample JSP shown in portlet. The highlighted code shows creating resource URL, and hidden division. This JSP also shows Javascript code used to send Ajax request.

<%@page session="false" contentType="text/html" pageEncoding="ISO-8859-1" import="java.util.*,javax.portlet.*" %>
<%@ taglib uri="http://java.sun.com/portlet_2_0" prefix="portlet"%>
<portlet:defineobjects>

<script type="text/javascript">
var xmlRequest;
/* send request to backend server */

function updatePortlet(url)
{
getXMLHttpRequest();
var params= getFormDataParams();
if(xmlRequest != null) { xmlRequest.onreadystatechange=stateHandler; xmlRequest.open("POST",url,true); xmlRequest.setRequestHeader ("Content-Type", "application/x-www-form-urlencoded"); xmlRequest.send(params); } }/* callback function called to check the request status and retrieve the resposne */function stateHandler(){ if (xmlRequest.readyState==4) { if (xmlRequest.status==200) { var responseDiv = document.getElementById("div_resource_response"); responseDiv.innerHTML= xmlRequest.responseText; } else { alert("Problem retrieving XML data"); } }}

/* get XMLHttpRequest object */
function getXMLHttpRequest(){ if (window.XMLHttpRequest) {

xmlRequest = new XMLHttpRequest(); // Mozilla/Safari
}

else if ( typeof ActiveXObject != "undefined" ) {

xmlRequest = new ActiveXObject("MicroSoft.XMLHTTP"); // IE
}}/* Prepares Post data */

function getFormDataParams(){
var params = "country=" + encodeURIComponent(document.resourceForm.country.value) + "&NOCACHE=" + new Date().getTime();
return params;
}
</script>


<h3 style="margin-bottom: 3px;">Select a country to display major cities</h3>
<form name="resourceForm" class="cssform">
<p>
<label>Country</label>
<select name="country" onchange=""><option value="" selected="selected"></option> <option value="usa">USA</option> <option value="canada">Canada</option> <option value="india">India</option> </select>
</p>

</form>
<div id="div_resource_response">

</div>

2. The following is the method invoked by submitting to resource URL.

@Override
public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
String country= request.getParameter("country");
if(country.equals("usa"))
response.getWriter().println("Major cities in USA are <b>New york, Chicago, Houston, Los Angeles</b>");
else if(country.equals("canada"))
response.getWriter().println("Major cities in Canda are <b>Toronto, Vancouer, Ottawa</b>");
else if(country.equals("india"))
response.getWriter().println("Major cities in India are <b>Delhi, Bombay, Bangalore, Madras</b>");

}
</portlet:defineobjects>

How to implement LDAP referrals for WebSphere Portal 6.1

Question
How can you implement referrals for WebSphere Portal 6.1? You have configured WebSphere Portal to an LDAP server that may return a referral in order to locate a specific user or group.

Answer

WebSphere Application Server 6.1 does not support referrals in standalone LDAP environments. However, referrals can be leveraged in a federated repository environment by using one of the following two methods for updating the Virtual Member Manager (VMM) configuration:

Method 1.
1. Login to the Integrated Solutions Console.
2. Navigate to Secure administration, applications, and infrastructure --> Federated repositories --> Manage repositories --> repository name.
3. In the drop-down list for "Support referrals to other LDAP servers", select Follow.
4. Save the changes and restart the servers.

Method 2.
1. Open the /config/cells//wim/config/wimconfig.xml file.
2. Search for referal="ignore".
3. Change this to referal="follow".
4. Save the changes and restart the servers.

How to export a subset of users using the XML Configuration Interface

Question
How do you export a single user or a subset of users from an IBM WebSphere Portal configuration using XMLAccess?

Answer

Take a copy of the sample XML file, "ExportAllUsers.xml", located in the /doc/xml-samples directory and make the following changes:

1. Near the top of the file set export-users to false or remove export-users="true" from the file entirely.

2. Delete the following lines that serve to export all users and groups:





3. To export a single user by uid, add a line similar to the following:




This example exports the user, "wpsadmin", using the xmlaccess parameter, "name", that corresponds to uid. You may also export users using other attributes such as "common name" if uid is not defined in your repository. Review the WebSphere Portal Information Center XML Configuration reference page for 6.0 or 6.1 for more information.

How to export a single group or subset of groups using the XML configuration

Question
How do you export a single group or subset of groups from an IBM WebSphere Portal configuration using XMLAccess?

Answer

Make a copy of the sample XML file, "ExportAllUsers.xml", located in the /doc/xml-samples directory and make the following changes:

1. Near the top of the file, set export-users to false or remove export-users="true" from the file entirely.

2. Delete the following lines that serve to export all users and groups in the file as installed:





3. To export a single group by uid, add a line similar to the following:



This example exports the group, "wpsadmins", using the xmlaccess parameter, "name", which corresponds to the uid.

Exporting a group in this way will also export the members of the group. Each group member will appear on a separate line in the output. The output XML file will look as follows:






You may also export groups using other attributes such as "common name" if the uid is not defined in your repository. Review the WebSphere Portal Information Center page XML Configuration reference for 6.0 or 6.1 for more information.

Using ldapsearch to debug LDAP configuration problems

Problem(Abstract)
How to using ldapsearch to debug LDAP configuration problems with IBM® WebSphere® Application Server?



Resolving the problem
There are many things which may prevent your LDAP configuration from working properly.
DN = Distinguished Name
ACL = Access Control List

· DN not in ACL and therefore cannot perform certain ldap queries
· DN was locked out of ldap due to too may failed login attempts
· DN password may have been changed
· LDAP server may not allow anonymous queries
· Default filter defined in Application Server may not fit customers' settings.(i.e. no objectclass=someObjectClass defined)
· Firewall not allowing communication on port
· LDAP set to use nonstandard port of 389
· LDAP administrator ID used for Server ID but the administrator's ID is not defined as a regular user

For these and numerous other possible configuration problems the best way to quickly debug the problem is to do an ldapsearch. Ldapsearch is a utility similar to what Application Server uses to query the ldap server but is used on the command line. This removes Application Server from the picture and allows you to see what is being returned from the query, normally hidden by Application Server.

The idea is use the same configuration settings, on the command line, as you have defined in Application Server’s Administrative console > Security > user Registries > LDAP settings.

Security Server ID Short name of the ID which is queried from LDAP.
Security Server Password ID’s password in LDAP
Directory Type Predefined list of supported LDAP servers. Selecting the proper Directory updates the filters defined under the Advanced properties. These can be changed.
Host Hostname of LDAP server. Can be short name, long name, or IP address.
Port 389 is the default LDAP port
Base Distinguished Name
(BaseDN) Query starting location in your LDAP tree
Bind Distinguished Name
(BindDN) Fully qualified DN which has the authority to “bind” to your LDAP server and preform the requested queries. Some LDAP servers allow for anonymous queries so no bind DN and bind password may be required
Bind Password Bind DN’s password.

LDAP advanced properties User Filter The string used to query the LDAP server.
User ID Map Defines what gets displayed in WebSphere from resulting query.

ldapsearch –h -p -b “” –D -w “”

Note: The “%v” in the gets replaced by the
For example, instead of "(&(cn=%v)(objectclass=ePerson))" use "(&(cn=bob)(objectclass=ePerson))"

Example ldapsearch queries
C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

Ldapsearch queries which would cause an exception for Application Server:

The following would fail in Application Server because the search filter is looking for an objectclass of “XYZ” but there is no “XYZ” objectclass defined LDAP. This results in an empty return string.

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=XYZ))"

The following search would fail in Application Server because 2 DN’s are returned instead of 1. Application Server will only authenticate using a single DN. If the query was uid=test instead of cn=test, then only one DN would have been returned.

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(cn=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

cn=test,ou=Larry's Group,ou=Austin,o=ibm,c=us
sn=User
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
cn=Test

How to generate a complete XMLAccess export of a Portal configuration

Question
How do you generate a full XMLAccess export of an IBM WebSphere® Portal configuration?



Answer
To assist in troubleshooting a WebSphere Portal issue, you may be asked by IBM Support to take a "full" or complete export of your Portal configuration using the XML Configuration Interface, commonly known as XMLAccess.
To generate a full export of your Portal's configuration, do the following:

1. Copy the file, /doc/xml-samples/Export.xml to /bin.

2. Open a terminal or command window. Change directories (cd) to /bin.

-- Execute (run) the script, /bin/setupCmdLine.
-- SetupCmdLine sets certain environment variables in the current window (such as JAVA_HOME).

3. From the directory, /bin, run the following xmlaccess command all on one line:

xmlaccess -user -password
-url :/wps/config -in Export.xml -out result.xml
Substitute Portal_admin_user, Portal_admin_password, myhost, and port with the correct values for your environment.
The file name specified after "-out" will contain the Portal configuration as XML. The file can have any name.
The protocol can be omitted after the -url parameter except in the case of SSL. SSL is only supported using Portal Version 6.0 and later.

If the file Export.xml is missing from your installation, contact Portal Support for the file or take a copy from another Portal host.

--------------------------------------------------------------------------------

Examples (using the default ports):

Version 5.0.x
xmlaccess -user wpsadmin -pwd Mypassword -url http://host.raleigh.ibm.com:9081/wps/config -in Export.xml -out result.xml

Version 5.1.x
xmlaccess -user wpsadmin -password Mypassword -url http://host.raleigh.ibm.com:9081/wps/config -in Export.xml -out result.xml

Version 6.0.x
xmlaccess -user wpsadmin -password Mypassword -url http://host.raleigh.ibm.com:10038/wps/config -in Export.xml -out result.xml

Version 6.0.x using SSL and the default port
xmlaccess -user wpsadmin -password Mypassword -url https://appserver_host_name:10035/wps/config -in Export.xml -out result.xml

Version 6.1.x
xmlaccess -user wpsadmin -password Mypassword -url http://host.raleigh.ibm.com:10038/wps/config -in Export.xml -out result.xml

Application Groups in WebSphere Member Manager

Abstract:
The main reason for using Application Groups is for read-only LDAP repositories. Many corporate directory systems do not allow application systems to add application-specific groups. To have better access control, however, Portal administrators may have to create these specific groups. IBM® WebSphere® Member Manager (WMM) provides a convenient way to set these groups in its database tables.

This technote contains some commonly asked questions and answers regarding Application Groups.



Resolving the problem

1. Where are Application Groups stored?
WMM stores the group information in database tables:
-- WMMDBMBR stores the group names.
-- WMMGRPMBR stores the name of the group members for Application Groups.
-- WMMMBR adds an entry for users or groups registered through the Portal no matter if they were added to the LDAP or Application Groups.
-- An entry is added to USER_DESC for every group.

2. Is "LookAside" required for this configuration?
No, LookAside and Application Groups are independent of each other. LookAside is used only in the Portal environment and is used for storing user attributes which are not standard LDAP server object classes. Application Groups reside in different sets of WMM tables and are used for creating Portal-specific groups.

3. Is there any performance benchmark for Application Groups?
No, there are no benchmark tests for the performance of Application Groups.

4. Do Application Groups support nested groups? For example, User A is in Group C which in turn is in Group F.
Yes. You can use nested groups as well as LDAP groups within Application Groups. However, in general, the use of nested groups is discouraged for performance reasons.

5. Is "groupCache" still supported when Application Groups are configured?
Yes, the "groupCache" configuration in WMM is for LDAP repository only. There is no conflict between "groupCache" and Application Groups, but Application Groups are not cached.

6. Can you change the suffix of Application Groups from "o=default organization" to something similar to "o=example.com"?
No. However, you can use node maps. For example, 'o=default organization' is the default root organization of the database. If you want to change the name in the database, you must modify the schema/bootstrap file which is not supported. But you can map it to others in wmm.xml and then use something similar to 'o=example.com' in the application. For example, between
... ,
you can add




7. Are there differences between realm support (WMMUR) and non-realm support (non-WMMUR) configurations with regards to Application Groups?
No. There is no difference for Application Groups regarding realm.

8. When configuring the group search filter, what group ObjectClass will be used for Application Groups?
Example: "groupOfNames," "groupOfUniqueNames," or something else?
Application Groups is stored in the database and ObjectClass is for LDAP only. You do not have to specify ObjectClass for Application Groups.

9. Can you still use groups in the LDAP server after configuring Application Groups?
After configuring Application Groups, both LDAP and database will be searched during group membership search. The Portal administrators group (wpsadmins) and all groups in LDAP will be searched and all the groups within the search base and search filter defined in LDAP repository stanza of wmm.xml, will be found correctly.

10. Is there a mechanism in WMM to prevent naming conflicts? Can you have groups of the same names within the LDAP and Application Groups?
Since the configuration for LDAP and Application Groups is in separate naming spaces, groups in LDAP and Application Groups are not in the same parent so there would be no conflict. However, a naming convention is recommended in practice for easy identification.
Example: Make all groups prefixed with "ag_," such as "ag_Managers."

11. What would the impact be should you decide to remove the Application Groups? Will the system stop working?
All the group membership information would be lost for Application Groups. The impact depends on how Portal Access Control (PAC) is configured. The recommendation is that before taking Application Groups away, you should create corresponding groups in LDAP to reflect all the configurations associated with Application Groups. A full XMLAccess export should give a complete picture of the ACLs.

12. Can Application Groups be used for admin groups in virtual portals?
Yes. Application Groups can be used just like other groups that participate in a multi-realm configuration. Therefore, the groups in Application Groups can be configured as admin groups in virtual portals.

13. Can you use Application Groups with External Security Managers (ESM), such as Tivoli® Access Manager?
No. The ESM must share an LDAP User profile repository with WebSphere Application and Portal servers. Application Groups are known only to the Portal.

14. Where can you find more information about Application Groups?
For more information, refer to the topic, "Enabling Application Groups", in the WebSphere Portal Information Center for V6.0 or the WebSphere Portal Information Center for V5.1.

How to get user ID of logged-in user from LDAP

How do you retrieve the user ID of a logged-in user from the LDAP instead of the user name which may not be unique?

There are two ways to achieve this :
1. Setting the "api.use.dn" parameter in WCMConfigService.properties to True gives you the distinguished name (DN) of the user instead of the display name when calling the getUserName() method.

2. You can dynamically set this by calling

"workspace.useDistinguishedNames(true)" before calling "workspace.getUserProfile()".
Essentially this would be similar to the following:

Workspace workspace = p_contextProcessorParams.getWorkspace();
workspace.useDistinguishedNames(true);
String currentCust = CustContextProcessorUtils.getCustomer(workspace.getUserProfile().getUsername());