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.
Note: 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.
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.
- Optional: Move the OS directory
that you copied earlier to jvm/jre/lib/ext subdirectory
of the Tivoli Directory Integrator
directory. Rename the directory to TDI. This
directory becomes the Tivoli Directory
Integrator solution directory.
- 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.1.1
- Windows:
The
default value for
TDIPATH is:
SET TDIPATH=C:\Program Files\IBM\TDI\V7.1.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:
- 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}
Note: See Example complex mapping of Profiles
data for an example of complex mapping.
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.
- 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 configure the extension attribute, specifying
the property's name and mapping from the source. Use the following
parameters:
Table 1. Custom extension attribute parametersParameter |
Description |
extensionId |
The ID of the extension attribute. This parameter is required.
|
sourceKey |
The name of the attribute from the source, which most often is LDAP. This
parameter is required.
|
length |
The maximum number of characters for the field. This parameter is
required.
|
For example, to add a simple attribute called spokenLangs, which is derived
from the spokenLang source attribute, the configuration would look like the following extract from
the tdi-profile-config.xml file:
<profileExtensionAttributes>
<simpleAttribute extensionId="spokenLangs" sourceKey="spokenLang" length="80"/>
</profileExtensionAttributes>
Note: The formatting between the tdi-profiles-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 section.
Note: 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.
- Save your changes to the tdi-profiles-config.xml file.
- Add the property to the types hierarchy, which is contained in the file
profiles-types.xml.
You must add the property to both instances of
profiles-types.xml. One
instance is in the TDI solution
conf/LotusConnections-config directory, and the
other instance is in the primary
LotusConnections-config directory. The
property must be the same in both places. Using the
spokenLangs example from
previous steps, the property might look like the following
example:
<property>
<ref>spokenLangs</ref>
<updatability>readwrite</updatability>
<hidden>false</hidden>
</property>
- If the value of the extension attribute does not appear directly in LDAP, but instead is a
function of one or more LDAP attributes, you must write a JavaScript function. The function must combine different attributes from your LDAP directory
to map a customized extension attribute for the Profiles database.
- Modify tdi-profiles-config.xml to make the sourceKey
the same value as the extensionId.
For example:
<profileExtensionAttributes>
<simpleAttribute extensionId="spokenLangs" sourceKey="spokenLangs" length="80"/>
</profileExtensionAttributes>
- Add the extension attribute function definition in the
map_dbrepos_from_source.properties file, using the following format:
extattr.spokenLangs={func_map_to_langs}
Note: In this example, the extension attribute is spokenLangs. The extension
attribute must match the specified extensionId in the
tdi-profiles-config.xml extension attribute definition.
- Add a new func_map_to_langs
JavaScript function in the
TDISolution\TDI\profiles_functions.js file. Write logic for the function that
specifies the new extension attribute mapping.
In the following example, work.getString("c") retrieves the country code from
the LDIF obtained from LDAP. All LDAP attributes are available. By default, the LDAP country code
attribute is named "c", but it might be different in your environment.
function func_map_to_langs(fieldName) {
var country = work.getString("c");
var retval = "Unknown";
if ( country == "us" )
retval = "English";
elseif ( country == "fr" )
retval = "French";
return retval;
}
- Repeat these steps for each JavaScript function.
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.
Note: 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 fileTDI 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 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.
|
email |
mail |
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 |
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.
- IBM Lotus® Domino®
guid={function_map_from_dominoUNID}
- IBM Directory Server
guid=ibm-entryUuid
- Sun Java System Directory
Server
guid=nsUniqueID
- Novelle Directory
guid={function_map_from_GUID}
If you edited the
wimconfig.xml or
LotusConnections-config.xml file
to use a custom global unique ID, be sure to specify that custom ID
here. If you specify an attribute here other than the default, you
must edit the federated directory configuration to match the
guid used
here. See also
Specifying the global ID attribute for users
and groups and
Specifying a custom ID attribute for users
or groups. If the custom ID is different for users and groups,
see
Configuring the custom ID attribute for
users or groups.
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,
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}
For more information, see theTivoli 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.