Home

Map fields manually

 

+

Search Tips   |   Advanced Search

 

Overview

To populate the Profiles database, map fields in the Profiles database to fields in the LDAP.

When you run the Profiles population wizard in interactive mode, it generates two property files...

If the -mappingFile command parameter is not specified when mapping fields manually, the population wizard uses mappings.properties to create LDAP values.

The Profiles population wizard also creates...

..and updates this file with data from mappings.properties when you run the Profiles population wizard in silent mood.

Both map_dbrepos_from_source.properties and mapping.properties have similar content. Only use map_dbrepos_from_source.properties as the value of the -mappingFile command parameter if you cannot use the mappings.properties file.

To map fields between the Profiles database and the LDAP

Edit profiles_functions.js to see the options for the different mapping functions. You can add your own functions if necessary.

Consider using LDAP viewer software such as Apache Directory Server to help you map the fields.


Define mappings used when populating the Profiles database from the LDAP

  1. Edit...

      TDI_HOME/map_dbrepos_from_source.properties

  2. Add or modify the field values.

    Any values you omit or set to null will not be 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, for example, the content of the property in the LDAP must be split into multiple fields in the Profiles database, use a Javascript function to define the relationship. Define the function in profiles_functions.js and wrap the name of the Javascript function in curly brackets {}. Begin function names with "func_" so you can more easily identify them. For example:

        bldgId={func_map_to_db_bldgId}

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

  1. Edit...

      TDI/map_dbrepos_to_source.properties

  2. 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 LDAP, 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, for example, 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 profiles_functions.js and wrap the name of the Javascript function in curly brackets {}.

      Begin function names with "func_" so you can more easily identify them. For example:

        buildingname={func_map_from_db_PROF_BUILDING_IDENTIFIER}

  3. Add a line at the bottom of the file and type the name of the LDAP file that you want to map to the extension field. For example:

      PROF_VALUE.property1=carLicense

  4. After the Tivoli Directory Integrator Solution files are extracted, edit...

      TDI/conf/LotusConnections-config/tdi-profile-config.xml...

  5. Modify the file to indicate the property to extend, the property's name, data type, and key. Use the following parameters:

      Parameter Description
      extensionId The ID of the extension attribute.

      Required.

      sourceKey The name of the LDAP attribute that maps to 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.

      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.

      Optional

    For example, to add a simple attribute called spokenLangs, the configuration would look similar to the configuration in the profiles-config.xml file: 

      <simpleAttribute extensionId="spokenLangs"
  length="64" 
  userLabel="Spoken Languages"
  userTypeString="String"
  sourceKey="spokenLang"/>

    The formatting is compatible between tdi-profile-config.xml and profiles-config.xml, allowing you to copy and paste configuration information between the files.

  6. Save your changes to tdi-profile-config.xml and then close the file.

The properties in map_dbrepos_from_source.properties have the default values defined in the table below. 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 you omit or set to null will not be populated in the database.

The guid property identifies the global unique ID of a user. This property's value is created by the LDAP and is unique, complex, and never changes. It is essential in that it maps each user's Lotus 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 ofLDAP that you are using:

If you edited wimconfig.xml 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. The uid is a critical field in the Profiles database. The value in it is used to link together entries for a given person across multiple tables. The value you map to uid must meet the following requirements:

In Microsoft Active Directory, although there often is a UID field available, this 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