Advanced Customization > Business Logic Customization > Packages Customization > Identifying Users in Context Replication and Activating Replicated Users
  
Identifying Users in Context Replication and Activating Replicated Users
You can change the default behavior of how Windchill identifies matching users in the target system during a context replication package import, determining when replication of users is necessary. You can also change how the system identifies such replicated users if converting them to active users becomes necessary.
Background
This information details configuration and customization hooks for the following two scenarios:
Identifying matching users in the target system during context replication package import and determining when replicated users are created.
During a context replication package import, user data may be included for object attributes such as “creator” in the delivery ZIP files. By default, user names are used to identify users on the target system if there is not an exact match to the user’s distinguished name. If a matching user is not found in the target system, it may result in the creation of a replicated user, if that is the chosen resolution. You can change how users are identified in context replication package import, and instead of user name, the user’s email address can be used to identify users on the target system. It is also possible to change this to use custom logic based on other attributes of the user.
Identifying a replicated user when it comes time to activate/convert to an active user.
Replicated users created during the Context Replication Package Import represent inactive users that are known to the Windchill installation but who cannot log into Windchill or interact with its business objects. Replicated users can become regular users on activation. Activation occurs automatically when in the process of creating a new “active” user, the system locates a matching Replicated user entry for that user and converts that instead. By default, the user name of the user being created is used to identify a matching Replicated user to activate.
Sites can change how a Replicated user is identified during activation, and instead of the user name of the user that is being created, the email address of that user can be used to identify an existing Replicated user. It is also possible to change this to use custom logic based on other attributes of the user being created.
Scope/Applicability/Assumptions
The two configuration scenarios described in this information must be applied in consideration to each other. For example, if you change the behavior to use email addresses to identify users during context replication package import, it is recommended that you change how replicated users are identified during user activation to use email addresses as well. This will ensure that the processes leading to the generation of replicated users and their transformation to active users happens based on similar characteristics of the users.
The preference User Email in Context Replication Deliveries is relevant to the information in this section. This preference determines if user email addresses are included in the delivery ZIP files created as part of context replication. When certain objects are included in the delivery ZIP files, user data is included for object attributes such as “Creator”.
If the preference is set to “Yes”, user email addresses are included with the object information during delivery creation.
If the preference is set to “No”, user email addresses are not included.
By default user names are used to identify users on the target system from the information included in the delivery ZIP files, if there is not an exact match to the user's distinguished name. You can also configure your system to use email addresses to identify users, rather than user names. If you set this preference to No, you should not configure your system to match users by email addresses because it will not be able to identify the users.
Intended Outcome
By using the configuration or customization strategies described in this section, you are able to change the behavior of:
How matching users in the target system are identified during Context Replication Package Import
How replicated users are identified when it comes time to activate/convert to an active user
Prerequisite knowledge
To achieve the intended outcome, you need to have an understanding of the following:
Basic development involving JAVA, XML
Basic understanding of the Service Delegate infrastructure