beautypg.com

IBM WEBSPHERE 6.1.X User Manual

Page 59

background image

5 4

W E B S P H E R E P O R T A L V 6 . 1 T U N I N G G U I D E

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.