Scenario Two : How replicated users are identified when it comes time to activate/convert to an active user
The role of the configured PrincipalMatchDelegate service implementation in determining how a replicated user is found for activation, is as described in the following diagram.
The following diagram details the role of the configured PrincipalMatchDelegate in Replicated User Activation.
Solution Elements
These elements determine how replicated users are identified when it comes time to activate/convert to an active user
 | In the following, the selector value is a pre-determined designator of the usage context and is meant for identifying the service configuration appropriate for a specific usage. The selector value must not be modified – only the corresponding serviceClass value may be changed |
Element | Type | Description |
|---|---|---|
ReplicatedUserForActivationByUserNameMatchDelegate | OOTB delegate JAVA class | Location: <Windchill>\codebase/wt/org/ReplicatedUserForActivationByUserNameMatchDelegate.class This delegate implementation is for use with the selector “ReplicatedUserForActivation”. This is the delegate configured by default for this selector. This delegate is only for use in finding a matching replicated during user creation. It uses the source user’s name to find a matching replicated user that can be converted into an active user |
ReplicatedUserForActivationByEmailIdMatchDelegate | OOTB delegate JAVA class | Location: <Windchill>\codebase/wt/org/ReplicatedUserForActivationByEmailIdMatchDelegate This delegate implementation is for use with the selector “ReplicatedUserForActivation”. This is not the delegate configured by default for this selector. This delegate is only for use in finding a matching replicated user during user creation. It uses the source user’s email address to find a matching replicated user that can be converted into an active user |
service.properties.xconf | Service Delegate configuration file | Location: <Windchill>\ codebase/service.properties The following service configuration elements determine which serviceClass is applied for the selector ReplicatedUserForActivation. <Service context="default" name="wt.org.delegate.PrincipalMatchDelegate"> <Option cardinality="singleton" requestor="wt.org.WTUser" selector="ReplicatedUserForActivation" serviceClass="wt.org.delegate.ReplicatedUserForActivationByUserNameMatchDelegate"/> </Service> |
PrincipalMatchDelegate | Delegate JAVA interface for customizers | Location: <Windchill>\codebase/wt/org/PrincipalMatchDelegate.class All customized delegate implementations must adhere to the contract established by this interface |
Procedure
• To change the behavior so that user’s email addresses are used to identify replicated users during user activation, change the serviceClass associated with the selector ReplicatedUserForActivation to use the ReplicatedUserForActivationByEmailIdMatchDelegate implementation:
<Service context="default" name="wt.org.delegate.PrincipalMatchDelegate">
<Option cardinality="singleton" requestor="wt.org.WTUser"
selector="ReplicatedUserForActivation"
serviceClass="wt.org.delegate.
ReplicatedUserForActivationByEmailIdMatchDelegate"/>
</Service>
<Option cardinality="singleton" requestor="wt.org.WTUser"
selector="ReplicatedUserForActivation"
serviceClass="wt.org.delegate.
ReplicatedUserForActivationByEmailIdMatchDelegate"/>
</Service>
• To change the behavior to use more customized logic based on other attributes of the user, see Customization Points and Limitations.