About this task
Edit the map_dbrepos_from_source.properties
file to map fields between the Profiles database and the LDAP directory. Open the profiles_functions.js
file to see the options for the different mapping functions. You can add your own functions if necessary.
When you run the Profiles population wizard in interactive mode, it generates two property files in the Wizards\TDIPopulation
directory: a tdisetting.properties
file and a mappings.properties
file. The properties in mappings.properties
are very similar to those in map_dbrepos_from_source.properties
The internal name of the Profiles database is PEOPLEDB.
To map fields, complete the following steps:
- On the system hosting your Tivoli® Directory Integrator installation, create a subdirectory in which to store the Tivoli Directory Integrator solution directory. Make sure that the file path does not contain spaces. Do not, for example, create the subdirectory in the Program Files directory in Microsoft® Windows®.
- Copy the tdisol compressed file from the TDISOL directory of the IBM® Connections installation media to the system where you installed Tivoli Directory Integrator.
- Using appropriate tools, extract the tdisol file to the directory that you created in Step 1. This process creates a Tivoli Directory Integrator Solution directory called TDI.
- From the TDI solution directory, open the tdienv.bat or tdienv.sh file in a text editor. Ensure that the path to the Tivoli Directory Integrator installation directory is specified correctly in the TDIPATH variable. If the path is not correct, edit the TDIPATH environment variable.
- AIX® or Linux®:
The default value for TDIPATH
The default value for TDIPATH
SET TDIPATH=C:\Program Files\IBM\TDI\V7.1
Other scripts in the solution directory use this Tivoli Directory Integrator path or tdienv.bat or tdienv.sh file to find Tivoli Directory Integrator files.
Edit the properties files to define the mapping between the LDAP directory and the Profiles database. Consider using LDAP viewer software to help you map the fields. To define the mappings that are used when populating the Profiles database from the enterprise directory:
Open the tdi-profile-config.xml file.
- From the TDI directory, open the map_dbrepos_from_source.properties file in a text editor.
- Add or modify the field values. Any values that you omit or set to null are not populated in the database. You can modify the values in one of the following ways:
If one field in the Profiles database matches one field in the enterprise directory, type the name of the field in the Profiles database and set it equal to the associated source database LDAP property. For example:Complex mapping
See Example complex mapping of Profiles data
for an example of complex mapping.
- The uid, guid, dn, surname, and displayName attributes are always required.
- See Table 2 for a list of the default values for the fields.
After the IBM Tivoli Directory Integrator Solution files are extracted, the file is located in the following directory:
Modify the file to configure the extension attribute, specifying the property's name and mapping from the source. Use the following parameters:
Table 1. Custom extension attribute parameters
Save your changes to the tdi-profile-config.xml file.
|extensionId||The ID of the extension attribute.|
This parameter is required.
|sourceKey||The name of the attribute from the source.|
This parameter is required.
For example, to add a simple attribute called spokenLangs
, the configuration would look like the following extract from the tdi-profiles-config.xml
The formatting between the tdi-profile-config.xml
and the profiles-config.xml
files is compatible, so you can copy and paste configuration information between the files. For the extension to be displayed in the user interface, the modifications must be made in profiles-config.xml
. For more information, see Extension properties in the data model
in the Customizing Profiles
To leverage the custom attribute in the Profiles user interface or REST API, you must configure the application per the instructions in the Customizing Profiles
section. For a detailed example that uses custom attributes, see Creating a simple profile data model and template customization
- Add the extension attribute function definition in the map_dbrepos_from_source.properties file, using the following format:
Note: The extensionAttribute name must match the specified extensionId in the tdi-profiles-config.xml extension attribute definition.
What to do next
The properties in the map_dbrepos_from_source.properties
file have the default values defined in the following table. Many of them are null. You must determine which LDAP properties to map to your database fields and edit this file to specify values that apply to your configuration. Any values that you omit or set to null are not populated in the database.
See Attribute mapping for Profiles
for a table of additional attribute mapping field values.
Table 2. Default values for properties in the map_dbrepos_from_source.properties file
Mapping the guid, uid, and loginId:
|TDI property||Default LDAP attribute mapping|
|guid||See the note at the foot of this table about mapping the guid, uid, and loginId.|
|loginId||See the note at the foot of this table about mapping the guid, uid, and loginId.|
This property represents a lookup of the UID of the manager using the Distinguished Name in the manager field.
|prof_type||Common types are customer, employee, and contractor. See the Profile-types topic for details. |
See the note at the foot of this table about adding profile types.
The Search application expects to find this in the Profiles database.
|uid||See the note at the foot of this table about mapping the guid, uid, and loginId.|
property identifies the global unique ID of a user. This property's value is created by the LDAP directory and is unique, complex, and never changes. It is essential in that it maps each user's IBM
Connections data to their User ID when using the Profiles database as the user repository. The mapping of the guid
property must be handled differently depending on the type of LDAP directory that you are using:
- Microsoft Active Directory
- IBM Lotus® Domino®
- IBM Directory Server
- Sun Java™ System Directory Server
- Novell eDirectory
If you edited the wimconfig.xml
file to use a custom global unique ID, be sure to specify that custom ID here.
property, not to be confused with the guid
property, defines the unique ID of a user. This property differs from a guid
in that it is the organization-specific permanent identifier for a user – often a login ID or some value based on the user's employee code. The uid
is a critical field in the Profiles database. By default, this property links a given person's user record back to LDAP data. The value you map to uid
must meet the following requirements:
- It must be present in every entry that is to be added to the database.
- It must be unique.
- In a multi-LDAP environment, it must be unique across LDAP directories.
- It must be 256 characters or fewer in length.
In Active Directory, although there often is a UID field available, this field is not always the best choice for mapping to uid
because it is not guaranteed to be present for all entries. A better choice is sAMAccountName because it usually does exist for all entries. Other values are acceptable also, as long as they meet the requirements.
- If you are mapping the uid from an LDAP field, specify the name of the field. However, if you need to parse it from the distinguished name and it is in the DN in the form of uid=value, use the following mapping function:
- Use the isManager and managerUid properties to set up the organizational structure of the organization. The isManager field determines whether the current person is a manager or not. You must assign a Y (Yes) or N (No) value to this property for each entry. Y identifies the person as a manager. The managerUid identifies the UID of the current person's manager. By default, managerUid is mapped to $manager_uid, which represents a lookup of the UID of the manager (using the Distinguished Name contained in the LDAP manager field). If a user's manager information is not contained in the $manager_uid field, you should adjust the mapping accordingly. These two properties work together to identify manager/employee relationships and create a report-to chain out of individual user entries.
- If users intend to log into Profiles using a single-valued user name other than the value specified in the uid or email properties, you must map that user name value to the loginId property. To do so, complete the following step:
- Set the loginId property in the map_dbrepos_from_source.propeties file equal to the LDAP property that you want to use as the login ID. For example, if you want to use employeeNumber as the login property, edit the property value as follows:
If you have more than one additional login ID (such as with a long and short form user ID) and you want to allow users to login with either of their login IDs, you can populate multiple additional login IDs by using one of the following settings:
For more information, see the Tivoli Directory Integrator product documentation
Adding profile types:
IBM Connections supports the ability to classify a profile using a profile type. The profile type allows the application to provide the set of properties that are intended for a given profile object. For more information, see Profile-types
Parent topic: Adding source data to the Profiles database
Choosing login values
Using the Profiles population wizard
Using the Profiles population wizard in silent mode
Manually populating the Profiles database
Creating a simple profile data model and template customization
Synchronizing user data between Profiles and the LDAP directory
Specifying a custom ID attribute for users or groups
Updating Profiles when changing LDAP directory
Attribute mapping for Profiles
Batch files for processing Profiles data
Extension properties in the data model
Customizing the Profiles data model