I D E N T I F Y I N G A F U L L F E T C H O F U S E R A T T R I B U T E S

How can you identify a second request is made to the directory server to retrieve the full set of user attributes? This is best done in a test or staging environment, rather than a live production environment, as it requires turning on tracing in the portal server, and this can impose a significant performance overhead. There are two traces to enable to look for this condition. The first one will show if the all the needed user attributes have been retrieved. If this is false, then a full fetch of the user information will occur. The second trace shows which attributes are being requested, so you can tell which ones should be added to the base set.

The two trace strings are:

com.ibm.wps.um.PrincipalImpl=all=enabled

com.ibm.wps.um.PumaProfileImpl=all=enabled

Enable those traces, and then execute the use case you wish to test. Then, look for this message in the trace.log:

PrincipalImpl 3 com.ibm.wps.um.PrincipalImpl isCompletelyLoaded false

This message may be output multiple times for the same user, so check all occurrences of it. If the value after isCompletelyLoaded is always true, then all the needed attributes have already been loaded, and no changes are needed. In this example, the value after isCompletelyLoaded is false, showing that the needed user attributes haven’t all been loaded. This will result in reloading all the user information from the user directory.

In that case, the trace will then typically show a call to reload the information for that user; this will tell the full distinguished name of the user whose information is being loaded from the user directory:

PrincipalImpl > com.ibm.wps.um.PrincipalImpl reload ENTRY id: cn=Yin Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com

Next, search above that in the trace for the getAttributes call, which will show the attributes the user has requested. It will look like this:

PumaProfileIm > com.ibm.wps.um.PumaProfileImpl getAttributes ENTRY id: cn=Yin Yin_000_992, cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com

…more user details follow…

isExternal: false[preferredLanguage, ibm-primaryEmail, countryName, displayName, givenName, cn, sn, uid]

The last line of the log entry shows the attributes being requested. In this case, the attributes being requested are [preferredLanguage, ibm-primaryEmail, countryName, displayName, givenName, cn, sn, uid]. Comparing this against the list of base user attributes, we can see that countryName is not in the base user attributes. Depending on whether the action being executed is a common one or not, consider adding this to the base set of attributes.

5 4

W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E

Page 59
Image 59
IBM 6.1.X manual BS P HE R E P O R T AL V 6 T U N I N G G U I D E