Receiving Administrative Notifications

When a user is deleted using the Participant Administration utility, the administrator receives a notification by email (or possibly through Windchill workflow). The administrator is notified that the participant has been disabled and that any additional manual actions should be taken, such as removing a user’s personal cabinet.

Similarly, Windchill will notify the administrator that a repair is needed when it detects that a user, user-defined group, or organization needs to be repaired because the object in the Windchill database no longer references an existing directory service entry, possibly because the entry has been removed from or relocated in the directory service.

These notifications are initiated by calling the Info*Engine tasks named NotifyDisabled.xml and NotifyRepair.xml in the <Windchill>/tasks/wt/ federation directory (where <Windchill> is the Windchill installation directory). You can customize these tasks to tailor the way in which notification is done.

Also, you can change the email address used for the notifications by setting the wt.org.principalAdministratorEmail property in the wt.properties file. The default email address used is the email address of the Administrator user (if one is set) or the postmaster@<server_hostname> email address, where <server_hostname> is the value of the wt.rmi.server.hostname property in the wt.properties file.

Managing the Participant Cache

To improve the access time required for users, user-defined groups, and organizations, Windchill maintains an in-memory cache of user, user-defined group, and organization information.

Note

If user, user-defined group, or organization attributes are changed using an administration tool other than the Participant Administration utility (for example, using a directory administration tool), then the cache containing those attributes must be purged in order for Windchill to display the changed attributes.

You can manage the participant cache in two ways:

•By setting the maximum time that the information about a participant can remain available in the cache. Cache entries are automatically purged when the system accesses stale entries.

•By selecting actions that purge information from the cache from within the Participant Administration utility.

Automatically Purging Entries from the Participant Cache

You can add the following properties to the wt.properties file to automatically purge cache entries:

•The wt..cache.timeToLive property defines the amount of time that any given participant cache entry is available from the cache. Specify the property value in seconds. If the property value is not set or is set to zero or less than zero, then cache entries are not automatically removed from the cache. Out of the box, this property is not set.

•The wt..cache.timeToLiveRandomizer property adds a random amount of time to the time stamp of each cache entry so that a large number of entries do not expire at the same time. Specify the property value in seconds. If the property is not set, the value defaults to 600 seconds (10 minutes). If the property is set to zero or set to less than zero, then no random value is added to the time stamp of each cache entry. Out of the box, this property is not set.

When a valid value is specified, the random amount added to the time stamp varies between 1 second and the property value. For example, if the property value is 600 seconds (10 minutes), a value between 1 second and 600 seconds is added to the time stamp of a cache entry when the entry is added to the cache.

Use the xconfmanager utility to add the properties. For example to add the wt.. cache.timeToLive property, specify the following xconfmanager command from a windchill shell:

xconfmanager -s wt..cache.timeToLive=600