Skip to content

Manually populating the Profiles database

Instead of using the Profiles population wizard, you can manually populate the database.

You can populate the Profiles database manually, as described here, or with the help of the population wizard as described in the Using the Profiles population wizard topic. You might choose to manually populate the database to take advantage of functionality not provided by the wizard, such as anonymous LDAP access, large data sets, and property configuration other than what is provided by the wizard, for example alternate source options.

Note: Additional and related information about configuration and mapping properties may be available in the Using the Profiles population wizard topic.

Important: If your database uses a database driver that requires Java 8, or you otherwise require Java 8 when running the IBM Security Directory Integrator, see this article for instructions: Using IBM Security Directory Integrator with Java 8 and HCL Connections. Note that you must use the manual population method when using Java 8, not the population wizards.

Before starting this task,

  1. In order to manually populate the Profiles database, ensure you have Set up the Security Directory Integrator Solutions directory (tdisol).
  2. Complete the steps in the Mapping fields manually topic. You must set up the mapping file before starting this task.

After installing the Profiles database, and setting up the SDI Solutions Directory, and defining mapping and validation, complete the following steps to populate the Profiles database:

  1. Update the profiles_tdi.properties file to specify values for the following properties. To locate this file, change to the SDI solution directory that you created in the topic Setting up the Security Directory Integrator Solutions directory (tdisol). The profiles_tdi.properties file is located in the tdisol/TDI directory. For example: /opt/IBM/TDI/V7.2/tdisol/TDI.

    The following list contains properties that you must review. Edit any property values that require editing for your configuration.

    source_ldap_url : Universal resource locator of the LDAP directory. Enables programs to access the LDAP directory. Use the following syntax to specify the value:

    ```
 source_ldap_url=ldap://myldap.enterprise.example.com:389 
```

    source_ldap_user_login : If you cannot use Anonymous search, a user login name is required . Use the following syntax to specify the value:

    ```
source_ldap_user_login=uid=wpsbind,cn=users,l=Bedford Falls,
st=New York,c=US,ou=Enterprise,o=Sales Division,dc=example,dc=com
```

    source_ldap_user_password : If you cannot use anonymous search, a user password is required, along with user login name. Use the following syntax to specify the value:

    ```
{protect}-source_ldap_user_password=wpsbind  
```

**Note:** Tivoli® Directory Integrator automatically encrypts any properties which have the \{protect\} prefix. If you do not want to encrypt these properties, remove the \{protect\} prefix.

    source_ldap_search_base : A portion of the LDAP DN that must be part of all entries processed. This base usually contains the expected organization (o) value, such as source_ldap_search_base=o=ibm.com. Use the following syntax to specify the value:

    ```
source_ldap_search_base=l=Bedford Falls,st=New York,c=US,
ou=Enterprise,o=Sales Division,dc=example,dc=com   
```

    source_ldap_search_filter : A search filter to further refine the entries used. A typical value might be source_ldap_search_filter=cn=*. Use the following syntax to specify the value:

    ```
source_ldap_search_filter=(&(uid=*)(objectclass=inetOrgPerson))   
```

    source_ldap_use_ssl : Required only if you are using SSL to authenticate. Specifies whether to use Secure Sockets Layer for the connection. Options are true or false.

    dbrepos_jdbc_driver : JDBC driver used to access the Profiles database repository. The default value of the properties file references the DB2® database provided with Profiles as follows:

    ```
dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver

```

If you are using DB2, you do not need to modify this value. If you are using an Oracle database, change the value to reference an Oracle database. The following values are examples:

```
dbrepos_jdbc_driver=oracle.jdbc.driver.OracleDriver
```

```
dbrepos_jdbc_driver=oracle.jdbc.pool.OracleConnectionPoolDataSource
```

If you are using SQL Server, change the value to reference the SQL Server database. The following value is an example:

```
com.microsoft.sqlserver.jdbc.SQLServerDriver
```

    dbrepos_jdbc_url : Universal resource locator of the database that you created. This value specifies the peopledb database, and must include the port number. For example:

    -   DB2:

    ```
     jdbc:db2://localhost:50000/peopledb
    ```

-   Oracle:

    ```
    jdbc:oracle:thin:@//dbHostname:dbPort/PEOPLEDB_Name
    ```

-   SQL Server:

    ```
    jdbc:sqlserver://enterprise.example.com:1433;DatabaseName=PEOPLEDB
    ```

.

    dbrepos_username : The user name used to authenticate to the database that you created. Use the following syntax to specify the value:

    ```
dbrepos_username=<db\_admin\_id>   
```

    dbrepos_password : The password used to authenticate to the database that you created. Use the following syntax to specify the value:

    ```
{protect}-dbrepos_password=act1vities   
```

    You can provide values for additional properties if necessary, see the topic IBM® Tivoli Directory Integrator solution properties for Profiles for details.

  2. Ensure that you have completed the steps in the Mapping fields manually task. You must complete the mapping task before continuing.

  3. Run the ./collect_dns.sh or collect_dns.bat script to create a file containing the distinguished names (DNs) to be processed from the source LDAP directory.

    Note: Before starting the script, ensure that you have completed the steps in the Mapping fields manually task.

    Note: If the script does not run, you might need to enable its Executable attribute by running the chmod command first. The Executable attribute of a script can become disabled after the script is copied from a read-only medium such as DVD.

    The new file is named collect.dns by default but you can rename it if necessary. If you change the file name, update the source_ldap_collect_dns_file parameter in the profiles_tdi.propertiesfile.

    After the script runs, it creates a log file called ibmdi.log in the /tdisol/TDI directory. Examine this file to find out whether any errors occurred during the process.

  4. Populate the database repository from the source LDAP directory by running the ./populate_from_dn_file.sh or populate_from_dn_file.bat script.

    Depending on how many records you are processing, this step could take many hours. For example, 5,000 records might take a few minutes, but half a million records might take a few hours, depending on the speed of your system. Tivoli Directory Integrator prints a message to the screen after every 1,000 iterations to inform you of its progress.

    Note: If a failure occurs during processing, such as loss of the network connection to the LDAP directory server, you can run the populate_from_dn_file script again with no harm. If you want to save time though, you can start processing the names from where it was interrupted. Examine the PopulateDBFromDNFile.log file in the logs subdirectory to find out which distinguished name was last successfully processed. The ibmdi.log file also tracks the tasks that you run. Edit the collect.dns file to remove all entries up to and including the last successfully processed entry. Start the task again. You can repeat this step as many times as necessary until all the distinguished names are processed.

  5. If you are setting the PROF_IS_MANAGER field based on PROF_MANAGER_UID references in other employee records, run the ./mark_managers.sh or mark_managers.bat script.

    For more information, see Configuring the Manager designation in user profiles for details.

    Note: Manager identification is not performed as part of the previous record population step because it must run across all the records and it is possible that the initial record population step does not complete in a single pass for large organizations.

    Note: If the manager designation was not part of the source records for your data set, you can run this task to analyze all the records after population. This task will take each user record and see if it is referenced as the manager for any other users. If yes, the user will be marked as a manager. If not, the user will be marked as not a manager. If you need to use this process to set this profile attribute, you will also need to run it periodically to perform updates. For more information, see Synchronizing user data between Profiles and the LDAP directory.

  6. Run additional and optional scripts to populate additional fields. For example, run the Country code script ./fill_country.sh or fill_country.bat to populate the Country table from the isocc.csv file. Other scripts include the following:

    • Work location code script ./fill_workloc.sh or fill_workloc.bat
    • Organization codes script ./fill_organization.sh or fill_organization.bat
    • Employee type code script ./fill_emp_type.sh or fill_emp_type.bat
    • Department code script ./fill_department.sh or fill_department.bat For more information, see Supplemental user data for Profiles.

Perform the remaining tasks under Populating the Profiles database.

Parent topic: Adding source data to the Profiles database