Keep track of users data as they transition from part-time to full-time or from one country to another


Before starting

To strengthen Tivoli Directory Integrator scripts using the steps detailed below, your organization must maintain a piece of data in the LDAP directory that allows you to connect the old employee record with the new employee record. The data does not need to be present for all user records, just for the user records that you are dealing with.


About this task

Certain HR-related actions can result in orphaned user data by causing the value in the uid field in the LDAP directory to change. TDI uses the uid field to synchronize data so any action that changes the value of the field will cause the user to appear as a completely new user to the Tivoli Directory Integrator scripts. Examples of HR actions that can have this effect include when users move from part-time to full-time, or from one country to another country.

To strengthen your TDI solution, define and use a custom assembly line that specifies the delete logic to use to identify when a user needs to be deleted from the Profiles database.


Procedure

  1. Configure your development environment for creating a delete logic script by following the steps in the topic, Setting up your development environment.

  2. Define an assembly line that contains your delete logic in the file.

      Your assembly line must return one of the following checking result values:

      • remove. The current entry should be added to the delete list.

      • updated. The current entry should be updated, not deleted.

      These values are case-sensitive so type them with care.

      Return the value as follows:

      1. Retrieve the checkResult attribute field from the work object into your assembly line. The attribute name is case-sensitive so type it with care.

      2. Set your checking result to the value of the checkResult attribute.

      For example:

        checkingResult = work.getAttribute("checkResult");
        checkingResult.setValue("updated");


  3. Use the publish feature to export the assembly line as a TDI adapter.

    1. Right-click the assembly line in the left panel of the Navigator and select Publish.

    2. Enter the name of the adapter in the Package ID field.

    3. Specify the following directory in the File Path field, and then click Finish.

        <profiles_tdisoln>/packages

  4. Add a reference to the profiles property store to your adapter files...

    • IBM AIX or Linux: 

        fixup_tdi_adapters.sh

    • Microsoft Windows: 

        fixup_tdi_adapters.bat

      Note: This reference is required in order to use the Profiles TDI adapter. Even if you do not believe that your adapter file requires access to the profiles property store, there is no penalty for adding the reference so it is strongly advised that you run this command regardless.

  5. Open the profiles_tdi.properties file from the following location:

      <tdisol.tar|zip>/tdisol/TDI

  6. Set the following properties in the file:

      sync_updates_double_check

        Specifies whether your checking assembly line is used. When set to true, your deletion-checking assembly line is used. When set to false, the checking operation is not performed. The default value is false.
        For example: 

        sync_updates_double_check=true

      sync_check_if_remove

        Specifies the name of your checking assembly line as follows:
        sync_check_if_remove=<name_of_your_adapter_xml_file>:/AssemblyLines/<name_of_your_assemblyline>

        By default, the assembly line's name is set to sync_all_dns_check_if_remove.
        For example, if you publish the assembly line with the file name deleteCheckRoutines and the assembly line is called example_check_if_user_really_deleted, then you set this property as follows: 

        sync_check_if_remove=deleteCheckRoutines:/AssemblyLines/example_check_if_user_really_deleted

      sync_delete_or_inactivate

        Controls what happens to a user record when the delete action is performed. This property can be set to one of the following values:

        • delete. The user record is deleted.

        • inactivate. The user record is inactivated.

            The inactive status is propagated to the member and login tables for all the applications. An event is generated for each of the following: Activities, Blogs, Bookmarks, Communities, Files, Forums, Profiles, Wikis, and News (which includes both Home page and Search). These events inactivate the user in every application by removing the user from the login tables and setting the user's status to 1 in all member tables.

        These values are case-sensitive so type them with care. The default value is inactivate.

        For example:

          sync_delete_or_inactivate=inactivate


  7. Save your changes to the profiles_tdi.properties file, and then close it.


Parent topic

Sample user management scenarios


Related tasks


Setting up your development environment

+

Search Tips   |   Advanced Search