Manually populate the Profiles database - IBM Lotus Connections 2.5

Home

Manually populate the Profiles database

+
Search Tips | Advanced Search

To populate the Profiles database manually...

Map fields manually
Update...
TDI_HOME/profiles_tdi.properties

..to specify values for at least the following properties...

source_ldap_url Universal resource locator of the LDAP which enables programs to access the LDAP
source_ldap_url=ldap://myldap.enterprise.example.com:389

source_ldap_user_login A user login name is required if you cannot use Anonymous search.
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 A user password is required (along with user login name) if you cannot use anonymous search.
{protect}-source_ldap_user_password=wpsbind

TDI will automatically encrypt any properties which have the {protect} prefix. If you don't want to encrypt these properties, remove the {protect} prefix.
source_ldap_search_base A portion of the LDAP DN that should be part of all entries processed. Typically this contains the expected organization (o) value, such as...
source_ldap_search_base=o=ibm.com

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=*

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. This should specify the peopledb database, and should include the port number.
For DB2:
jdbc:db2://localhost:50000/peopledb

For Oracle:
jdbc:oracle:thin:@localhost:1521:PEOPLEDB

For SQL Server:
jdbc:sqlserver://enterprise.example.com:1433;DatabaseName=PEOPLEDB

dbrepos_username The user name used to authenticate to the database.
dbrepos_username=<db_admin_id>

dbrepos_password Password used to authenticate to the database
{protect}-dbrepos_password=act1vities

You can provide values for additional properties if necessary.
Optional: If you are setting the isManager field using a 1:1 mapping, ensure that you specified how to set the field in the map_dbrepos_from_source.properties file. For example, if your LDAP has an "ismanager" field that is set to a value of Y or N, your map_dbrespos_from_source.properties file could specify the following:
PROF_IS_MANAGER=ismanager

Notes

If your source LDAP system uses a value other than Y or N to indicate whether the person is a manager, write a JavaScript™ function to map the value into a Y or N, and then provide a reference to that function here.
If you are setting the PROF_IS_MANAGER field based on PROF_MANAGER_UID references in other employees' records, perform Step 5 instead of this step.

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

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 file created is named collect.dns by default. After the script runs, it creates a log file called ibmdi.log in the /logs subdirectory of the TDI Check this file to find out how many entries were populated and whether there were any errors encountered during the process.
Before starting this step, complete the steps in the Mapping fields manually task.
Populate the database repository from the source LDAP by running the following script:
./populate_from_dn_file.sh

Depending on how many records you are processing, this step could take many hours. For example, 5,000 records might take a few minutes, while half a million records could take over 12 hours. Tivoli Database Integrator prints a message to the screen after every 1,000 iterations to inform you of its progress.
Notes

If a failure occurs during processing, such as loss of the network connection to the LDAP server, start processing the names from where it left off. Check the PopulateDBFromDNFile.log file in the logs subdirectory to find out which distinguished name was last successfully processed. (The ibmdi.log file also keeps track of the tasks that you run.) Edit the DNS file generated in the previous step, which is named collect.dns by default, to remove all entries up to and including the last successfully processed entry. Start the task again. This can be repeated as many times as necessary until all of the distinguished names are processed.
The script populates only those entries where the value for surname is not null.

Optional: If you are setting the PROF_IS_MANAGER field based on PROF_MANAGER_UID references in other employees' records, run the following script:
./mark_managers.sh

The acceptable values for the PROF_IS_MANAGER field are Y or N. Y indicated that the person is a manager. Manager identification is not done 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 may not complete in a single pass for large organizations.
Run the following script file to populate the Country table from the isocc.csv file:
./fill_country.sh

Optional: Create any of the following tables that are relevant for your organization, and then populate the local database repository with that information:

Department codes If your organization uses department codes, create a table that contains one line per entry. In each entry, include a department code, followed by a separator (such as a semicolon), and then a department description. Name the table deptinfo.csv and store it in the solution After building the table, run the following script file:
./fill_department.sh

Employee type codes If your organization uses employee type codes, create a table that contains one line per entry. In each entry, include an employee type code, followed by a separator, such as a semicolon, and then an employee type description. Name the table emptype.csv and store it in the solution After building the table, run the following script file:
./fill_emp_type.sh

Organization codes If you use organization codes, create a table that contains one line per entry. In each entry, include an organization code, followed by a separator, such as a semicolon, and then an organization description. Name the table orginfo.csv and store it in the solution After building the table, run the following script file:
./fill_organization.sh

Work location codes If your organization uses work location codes, create a table that contains one line per entry. In each entry, include a work location code, followed by a separator, such as a semicolon, and then a location description. Name the table workloc.csv and store it in the solution After building the table, run the following script file:
./fill_workloc.sh

Related tasks
Map fields manually
Tivoli Directory Integrator properties
Add LDAP data to the Profiles database
Administer Profiles
Use the Profiles population wizard
Use the Profiles population wizard in silent mode
Populate the Profiles database
Attribute mapping for Profiles
Population functions for populating ID into PROF_GUID
Profiles attributes

source_ldap_url	Universal resource locator of the LDAP which enables programs to access the LDAP source_ldap_url=ldap://myldap.enterprise.example.com:389
source_ldap_user_login	A user login name is required if you cannot use Anonymous search. 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	A user password is required (along with user login name) if you cannot use anonymous search. {protect}-source_ldap_user_password=wpsbind TDI will automatically encrypt any properties which have the {protect} prefix. If you don't want to encrypt these properties, remove the {protect} prefix.
source_ldap_search_base	A portion of the LDAP DN that should be part of all entries processed. Typically this contains the expected organization (o) value, such as... source_ldap_search_base=o=ibm.com 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=* 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. This should specify the peopledb database, and should include the port number. For DB2: jdbc:db2://localhost:50000/peopledb For Oracle: jdbc:oracle:thin:@localhost:1521:PEOPLEDB For SQL Server: jdbc:sqlserver://enterprise.example.com:1433;DatabaseName=PEOPLEDB
dbrepos_username	The user name used to authenticate to the database. dbrepos_username=<db_admin_id>
dbrepos_password	Password used to authenticate to the database {protect}-dbrepos_password=act1vities

Department codes	If your organization uses department codes, create a table that contains one line per entry. In each entry, include a department code, followed by a separator (such as a semicolon), and then a department description. Name the table deptinfo.csv and store it in the solution After building the table, run the following script file: ./fill_department.sh
Employee type codes	If your organization uses employee type codes, create a table that contains one line per entry. In each entry, include an employee type code, followed by a separator, such as a semicolon, and then an employee type description. Name the table emptype.csv and store it in the solution After building the table, run the following script file: ./fill_emp_type.sh
Organization codes	If you use organization codes, create a table that contains one line per entry. In each entry, include an organization code, followed by a separator, such as a semicolon, and then an organization description. Name the table orginfo.csv and store it in the solution After building the table, run the following script file: ./fill_organization.sh
Work location codes	If your organization uses work location codes, create a table that contains one line per entry. In each entry, include a work location code, followed by a separator, such as a semicolon, and then a location description. Name the table workloc.csv and store it in the solution After building the table, run the following script file: ./fill_workloc.sh