Mapping fields manually

Mapping fields manually
To populate the Profiles database with data from the enterprise LDAP directory, map the content of the fields in the database to the fields in the LDAP directory.

Before starting
Before starting this task...

About this task
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. If you do not specify the -mappingFile command parameter when you map fields manually, the population wizard uses the mappings.properties file to create LDAP values.
The Profiles population wizard also creates the map_dbrepos_from_source.properties file, located in the Wizards\TDIPopulation\TDI directory, and updates this file with data from the mappings.properties file when you run the Profiles population wizard in silent mode. Both the map_dbrepos_from_source.properties file and the mapping.properties file have similar content. You should only use the map_dbrepos_from_source.properties file as the value of the -mappingFile command parameter if you cannot use the mappings.properties file.
Edit the map_dbrepos_from_source.properties and map_dbrepos_to_source.properties files 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.
The internal name of the Profiles database is PEOPLEDB.
To map fields...

Procedure
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.
Use 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 is:
export TDIPATH=/opt/IBM/TDI/V7.0 
Windows:
The default value for TDIPATH is:
SET TDIPATH=C:\Program Files\IBM\TDI\V7.0
Other scripts in the solution directory use this Tivoli Directory Integrator path 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:

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:

1:1 mapping
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:
bldgId=buildingname

Complex mapping
If there is a more complex relationship between the fields in the Profiles database and enterprise directory, such as the content of the property in the enterprise LDAP directory must be split into multiple fields in the Profiles database, use a JavaScript™ function to define the relationship. Define the function in the profiles_functions.js file and wrap the name of the JavaScript function in braces {}. Begin function names with "func_" so that you can more easily identify them. For example:
bldgId={func_map_to_db_bldgId}

Notes:

The uid, guid, dn, surname, and displayName attributes are always required.
See Table 2 for a list of the default values for the fields.

To define mappings from the Profiles database to the enterprise directory:

From the TDI directory, open the map_dbrepos_to_source.properties file in a text editor.
Add or modify the field values in one of the following ways:

1:1 mapping
If one field in the Profiles database matches one field in the enterprise LDAP directory, type the name of the source LDAP property and set it equal to the field in the Profiles database. For example:
buildingname=PROF_BUILDING_IDENTIFIER

Complex mapping
If there is a more complex relationship between the fields in the Profiles database and the enterprise directory, such as the content of the property must be split into multiple fields in the Profiles database, use a JavaScript function to define the relationship. Define the function in the profiles_functions.js file and wrap the name of the JavaScript function in curly brackets {}. Begin function names with "func_" so that you can more easily identify them. For example:
buildingname={func_map_from_db_PROF_BUILDING_IDENTIFIER}

Open the tdi-profile-config.xml file.

After the IBM Tivoli Directory Integrator Solution files are extracted, the file is located in the following directory:
TDI/conf/LotusConnections-config
Modify the file to indicate the property to extend, the property's name, data type, and key.
Table 1. Custom extension attribute parameters

Parameter Description
extensionId The ID of the extension attribute. Required.
userLabel An administrator-defined label for the extension attribute that is populated into the database. This string does not display in the user interface or API.
This parameter is optional.
userTypeString An administrator-defined string defining the data type of the extension attribute. This string does not display in the user interface or API.
This parameter is optional.
sourceKey The name of the LDAP attribute that maps to the extension attribute. Required.

For example, to add a simple attribute called spokenLangs, the configuration would look like the following extract from the profiles-config.xml file:
<simpleAttribute extensionId="spokenLangs"
  length="64" 
  userLabel="Spoken Languages"
  userTypeString="String"
  sourceKey="spokenLang"/>
Note: 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.
Save your changes to the tdi-profile-config.xml file.
Optional: Write a JavaScript function that combines different attributes from your LDAP directory to map a customized extension attribute for the Profiles database:

Add the extension attribute to the map_dbrepos_from_source.properties file, using the following format:

extattr.extensionAttribute={func_map_to_db_extensionAttribute}

Add a new func_map_to_db_extensionAttribute JavaScript function in the TDISolution\TDI\profiles_functions.js file. Write logic for the function that specifies the new extension attribute mapping.
Open the map_dbrepos_from_source.properties file and add the following line:

extattr. <myExtensionAttribute>={func_map_to_db_extensionAttribute}
where <myExtensionAttribute> is the JavaScript function that you created.

Repeat these steps for each func_map_to_db_extensionAttribute JavaScript function that you want to add.
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.
Table 2. Default values for properties in the map_dbrepos_from_source.properties file

TDI property Default LDAP attribute mapping
alternateLastname null
blogUrl null
bldgId null
calendarUrl null
courtesyTitle null
deptNumber null
description null
displayName cn
employeeNumber employeenumber
employeeTypeCode employeetype
experience null
faxNumber facsimiletelephonenumber
freeBusyUrl null
floor null
givenName givenName
groupwareEmail null
guid See the note at the foot of this table about mapping the guid, uid, and loginId.
ipTelephoneNumber null
countryCode c
isManager null
jobResp null
loginId See the note at the foot of this table about mapping the guid, uid, and loginId.
email mail
managerUid $manager_uid
This property represents a lookup of the UID of the manager using the Distinguished Name in the manager field.
mobileNumber mobile
nativeFirstName null
nativeLastName null
orgId ou
pagerNumber null
pagerId null
pagerServiceProvider null
pagerType null
officeName physicaldeliveryofficename
preferredFirstName null
preferredLanguage preferredlanguage
preferredLastName null
secretaryUid null
shift null
distinguishedName $dn
surname sn
Provide this field because the Search application expects to find it in the Profiles database.
telephoneNumber telephonenumber
timezone null
title null
uid See the note at the foot of this table about mapping the guid, uid, and loginId.
workLocationCode postallocation
surnames sn
givenNames gn
logins null

Mapping the guid, uid, and loginId: The guid 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
guid={function_map_from_objectGUID}

You must use a JavaScript function to define the value for Active Directory because objectGUID is stored in Active Directory as a binary value, but is mapped to guid, which is stored as a string in the Profiles database. Also, the samAccountName property used by Active Directory has a 20-character limit, as opposed to the 256-character limit of the other IDs used by IBM Connections.
Active Directory Application Mode (ADAM)
guid={function_map_from_objectSID}

IBM Lotus Domino
guid={function_map_from_dominoUNID}

IBM Directory Server
guid=ibm-entryUuid

Sun Java™ System Directory Server
guid=nsUniqueID

Novell eDirectory
guid={function_map_from_GUID}

If you edited the wimconfig.xml file to use a custom global unique ID, be sure to specify that custom ID here.
The uid 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.
Notes:

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:
{func_map_to_db_UID}

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, 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:
loginId=employeeNumber

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:
logins=multiValuedLdapAttribute
or
logins={function_to_get_multiple_ldap_values}

For more information, see the Tivoli Directory Integrator product documentation.
Add profile types:
IBM Connections supports multiple attribute layouts based on different profile types. In addition to different attribute layouts, custom extension attributes are also supported for every profile type.
For more information about configuring profile types, see the Add profile types topic.

Parent topic
Add LDAP data to the Profiles database
Related concepts
Choosing login values
Add profile types

Related tasks

Use the Profiles population wizard
Use the Profiles population wizard in silent mode
Manually populating the Profiles database
Synchronize user data between Profiles and the LDAP directory
Specify a custom ID attribute for users or groups
Update Profiles when changing LDAP directory
Related reference
Attribute mapping for Profiles
Population functions for populating ID into PROF_GUID
Batch files for processing Profiles data
Profiles attributes

+
Search Tips | Advanced Search

Parameter	Description
extensionId	The ID of the extension attribute. Required.
userLabel	An administrator-defined label for the extension attribute that is populated into the database. This string does not display in the user interface or API. This parameter is optional.
userTypeString	An administrator-defined string defining the data type of the extension attribute. This string does not display in the user interface or API. This parameter is optional.
sourceKey	The name of the LDAP attribute that maps to the extension attribute. Required.

TDI property	Default LDAP attribute mapping
alternateLastname	null
blogUrl	null
bldgId	null
calendarUrl	null
courtesyTitle	null
deptNumber	null
description	null
displayName	cn
employeeNumber	employeenumber
employeeTypeCode	employeetype
experience	null
faxNumber	facsimiletelephonenumber
freeBusyUrl	null
floor	null
givenName	givenName
groupwareEmail	null
guid	See the note at the foot of this table about mapping the guid, uid, and loginId.
ipTelephoneNumber	null
countryCode	c
isManager	null
jobResp	null
loginId	See the note at the foot of this table about mapping the guid, uid, and loginId.
email	mail
managerUid	$manager_uid This property represents a lookup of the UID of the manager using the Distinguished Name in the manager field.
mobileNumber	mobile
nativeFirstName	null
nativeLastName	null
orgId	ou
pagerNumber	null
pagerId	null
pagerServiceProvider	null
pagerType	null
officeName	physicaldeliveryofficename
preferredFirstName	null
preferredLanguage	preferredlanguage
preferredLastName	null
secretaryUid	null
shift	null
distinguishedName	$dn
surname	sn Provide this field because the Search application expects to find it in the Profiles database.
telephoneNumber	telephonenumber
timezone	null
title	null
uid	See the note at the foot of this table about mapping the guid, uid, and loginId.
workLocationCode	postallocation
surnames	sn
givenNames	gn
logins	null