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.
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.
To map fields, complete the following steps:
Procedure
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.
TDI property | Default LDAP attribute mapping |
---|---|
alternateLastname | null |
bldgId | null |
blogUrl | null |
calendarUrl | null |
countryCode | c |
courtesyTitle | null |
decorateVisitorDisplayName | - External User Used with the visitor model. The value applies to all languages supported by the IBM Connections™ user interface. The text is not translated, and it is displayed to all users exactly as entered by you. |
deptNumber | null |
description | null |
displayName | cn Required unless using the visitor model. |
displayNameLdapAttr | cn Optional unless using the visitor model. |
distinguishedName | $dn Required. Note: By default the TDI
Property distinguishedName is mapped to the $dn
function which executes a DN lookup based on the directory
type. |
employeeNumber | employeenumber |
employeeTypeCode | employeetype |
experience | null |
faxNumber | facsimiletelephonenumber |
floor | null |
freeBusyUrl | null |
givenName | givenName |
givenNames | gn |
groupwareEmail | null |
guid | See the note following this table for information
about mapping the guid, uid, and loginId properties. Required |
ipTelephoneNumber | null |
isManager | null |
jobResp | null |
loginId | See the note following this table for information about mapping the guid, uid, and loginId properties. |
logins | null |
managerUid | $manager_uid This property represents a lookup of the UID of the manager using the Distinguished Name in the manager field. |
mobileNumber | mobile |
mode | null |
nativeFirstName | null |
nativeLastName | null |
officeName | physicaldeliveryofficename |
orgId | ou |
pagerId | null |
pagerNumber | null |
pagerServiceProvider | null |
pagerType | null |
preferredFirstName | null |
preferredLanguage | preferredlanguage |
preferredLastName | null |
prof_type | Common types are customer, employee, and contractor. See the
Profile-types topic for details. See the note following this table for information about adding profile types. |
secretaryUid | null |
shift | null |
surname | sn The Search application expects to find this in the Profiles database. Required. |
surnames | sn |
telephoneNumber | telephonenumber |
timezone | null |
title | null |
uid | See the note following this table for information about mapping the guid, uid, and loginId properties. Required. |
workLocationCode | postallocation |
- 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. - IBM Lotus® Domino®
guid={function_map_from_dominoUNID}
- IBM Directory Server
guid=ibm-entryUuid
- Sun Java™ System Directory
Server
guid=nsUniqueID
- Novell Directory
guid={function_map_from_GUID}
- 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.
- 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,
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:
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}
- 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:
For more information, see the IBM Tivoli Directory Integrator documentation.
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.