Sun logo      Previous      Contents      Index      Next     

Sun ONE Meta-Directory 5.1.1 Administration Guide

Chapter 8
Configuring the Database Connector

This chapter discusses configuration factors specific to the Database Connector, which provides bi-directional synchronization between Oracle and the Meta View.

The topics in this chapter are:

Make sure you have completed the following tasks:

Configuring the Database Connector

There are two phases in configuring the database connector:

Note that special characters whitespace and hash(#) present in the oracle data are not escaped while constructing DN at the Meta View. If your data source contains these characters then you have to escape your data source by adding backslashes to these special characters.

Creating the Data Server

Creating the data server consists of the following tasks:

Configuring the Data Server

    To display the Data Servers window
  1. From the Sun ONE console, double-click Server Group.
  2. Double-click the Join Engine object. The Sun ONE Meta-Directory window displays.
  3. Click the Meta-Directory object. The ‘Join Rules’ window displays.
  4. Select the Data Servers tab. The ‘Data Servers’ window displays.
    To add a new database server
  1. From the ‘Data Servers’ window, click New. The ‘Select a Data Server Type’ dialog box displays.
  2. Select Oracle, and then click OK. The server type is displayed in the list box.

    To provide data server information
  1. Select the server to configure.
  2. From the General tab, provide information or change the defaults for the following fields:

    3. Table 8-1  Description of the options

    Field

    Do This

    Data Server Name

    Enter any legitimate string without spaces. This is a required field.

    Database Alias

    Enter a connection string to connect to the database. For Oracle, you typically create the alias by using the Net8 Easy Config utility in Oracle 8. This is a required field.

    New Oracle User Name

    Enter a user name that does not preexist in the Oracle database. After data server creation, a script is generated, which when executed, adds this user to the Oracle database. The Join Engine employs this user’s credentials to bind to Oracle to retrieve the data. This is a required field.

    Password

    Enter a password associated with the user name.

    Confirm Password

    Enter the same password as above.

    Oracle Home Environment Variable

    Enter the ORACLE_HOME path of this machine. The OCI client libraries must be installed on the machine where you have installed the Join Engine database connector. This is a required field.

    NLS Language Environment Variable

    Enter the NLS_LANG environment variable used to indicate the locale, territory, and character set to the Oracle Call Interface (OCI) client library. The NLS_LANG parameter is not being used for enabling UTF-8 support, currently. Instead set the NLS_CHARACTERSET parameter of your database.

    Description

    Enter a brief description to inform other users about the purpose of this data server. This is an optional field.

  3. Select the Columns tab. The ‘Database Credentials’ dialog box displays. After providing the Oracle user name and password, described in "Generating the Script", the Columns window displays. The credentials remain in effect until you leave this particular data server. Note that this is not the same user described in ‘New Oracle User Name’ above.
    Figure shows the ’Database Credentials’ dialog box.

    4. You can select columns or tables to participate in the flow to the Meta View. This process of selection and setting up triggers is called instrumentation. These triggers populate the changelog tables with the changes.

  4. Do the following to perform instrumentation:
    1. Select a column, table, or user from the Uninstrumented Columns list.

      2. ‘C’ precedes column names, T precedes table names, and U precedes user names. An ‘X’ is displayed for columns that cannot be instrumented.

      Selecting a table instruments all the columns that belong to the table, and selecting a user instruments all the tables that belong to the user.

    2. Click Add or double click the node. The selection is displayed in the Instrumented Columns list.

      3. One of the columns in the table you select for instrumentation must be a primary key, denoted with the letter ‘P’. If you have selected a table or column from a table for which there is no primary key, a ‘Nominate Primary Keys’ dialog box displays.

      1. Select one or more columns as the nominated keys. You can double click an un-nominated column to move it to the nominated column.

        2. The set of nominated columns for a table must be unique for the associated row. That is, if you select FirstName and LastName as your nominated keys, there may be more than one person with the same name. A better choice would be AreaCode and PhoneNumber.

      2. Click Add. The column or set of columns now is displayed in the list of nominated keys.
      3. Click OK to close and return to the Columns window. Note that ‘N’ is now precedes the column you have nominated.

        4. You can change any nominated key after clicking OK if the associated table is not currently instrumented, and there are no primary keys in the table. To do this, right click any node and select Change nominated keys.

  5. Optional: If you want to change the user credentials, click Change User, then provide a new Oracle user name and password. Meta-Directory rereads the database dictionary and rebuilds the schema. You need to change credentials whenever you instrument users, tables, or columns that a different user owns.
  6. Click the Oracle Changelog tab to display the Changelog window. You can provide input only for a new data server. For existing data servers, you can only change the Flush Interval field.
    Figure shows the ’Change Log’ window.

    7. Enter appropriate values or change the defaults for these fields:

    Table 8-2  List of options and the description of the action to perform

    Tablespace Name

    Enter the name of the tablespace used for changelog tables, triggers, and changes. The default is MDChangeLog.This is a required field.

    See your database administrator for information about the tablespace name.

    Tablespace Location

    Enter the path and name of the data file, such as:

    d:/oracle/changelogs/changelog.dat

    See your database administrator for information about the tablespace location.

    Although this is not a required field, if you leave it blank, your database administrator will need to edit the generated script and supply this information.

    Tablespace Size

    Enter the size of the table space. See your database administrator for information about the tablespace size.

    Although this is not a required field, if you leave it blank, your database administrator will need to edit the generated script and supply this information.

    Flush Interval

    Enter a time interval in minutes when the server is requested to flush (trim) its changelog. This is a required field.

    Reserved Name for Action Column

    Enter a reserved column name that is not assigned to any column. The name must be unique for all columns and tables you want to instrument. The default is nsmdAction. This is a required field.

    Note that you cannot change the name after defining it.

    Reserved Name for SynchPoint Column

    Enter a reserved column name that is not assigned to any other instrumented column. The name must be unique for all columns and tables you want to instrument. The default is nsmdSynchPoint. This is a required field.

  7. Select the Tuning tab to display the ‘Tuning’ window.
    Figure shows the ’Tuning’ window.

    8. Enter appropriate values or change the defaults for these fields:

    Table 8-3  List of options and the description of the action to perform

    Field

    Do This

    Maximum Operation Result Time

    Enter the maximum amount of time allowed before time-out for an SQL search to receive its results. The suggested minimum value is 3600.

    Maximum Number of Retries

    Enter the number of times you want the server to attempt to connect after it initially fails to connect. This field is associated with the Retry Intervals field.

    Retry Intervals

    Enter the number of seconds to wait before the next retry should begin. There should be one interval for each retry. For example, if you specify 10 retries in the field above, you need 10 retry intervals. The syntax is shown in the window example above.

    Idle Timeout

    Enter the time, in seconds, that should pass before retries are abandoned if the server is idle.

  8. Select the DCNS Schedule tab to display the ‘DCNS Schedule’ window.
    Figure shows the ’DCNS Schedule’ window.

    9. Provide values for the following fields:

    Table 8-4  List of options and the description of the action to perform

    Field

    Value

    Example

    Second Specifier

    Accepts data in x/y format. x represents the ‘second’ at which schedule should start.

    x is interpreted as ‘start x seconds past minute’.

    y represents the repeat frequency of schedule in seconds.

    • ’*’ is allowed as a valid value for either x or y.
    • ’*’ in x is interpreted as ‘start at 0 seconds past minute’.
    • ’*’ in y is interpreted as repeat every second.
      Value of x should be between 0 and 59.
    • y can have any numeric value.

    2/15 means start 2 seconds past the minute and run every 15 seconds.

    */15 means start 0 seconds past the minute and run every 15 seconds.

    2/* means start 2 seconds past the minute and run every second.

    Minute Specifier

    Accepts data in x/y format. x represents the’ minute’ at which schedule should start. x is interpreted as ‘start x minutes past the hour.

    y represents the repeat frequency of schedule in minutes.

    • ‘*’ is allowed as a valid value for either x or y.
    • ‘*’ in x is interpreted as ‘start at 0 minutes past the hour.
    • ‘*’ in y is interpreted as repeat every minute.
    • Value of x should be between 0 and 59.
    • y can have any numeric value.

    Frequency of the schedule should be specified either in second specifier or minute specifier. If frequency is entered in both seconds and minute specifier, seconds frequency takes precedence over minutes frequency and minutes frequency is ignored.

    2/15 means start 2 minutes past the hour and run every 15 minutes.

    */15 means start 0 minute past the hour and run every 15 minutes.

    2/* means start 2 minutes past the hour and run every minute.

    Hour Specifier

    Accepts data in a regular expression format.
    Valid numeric values that can be entered are 0 to 23.
    Valid data formats are

    • x
    • x-y
    • x-y/z
    • a-b, x-y
    • x,y,z

    Interpretation of data in various formats:

    x: Is interpreted as run at x hour.

    ‘*’ in x is interpreted as 0-23.

    x-y: Is interpreted as begin at x hours and end at y hours.

    • ‘*’ is not a valid value in a range.
    • If x > y in hour range then the effective range is considered as x-23:59.
      that is, start at x hour and run till 23 hour 59 minutes.

    x-y/z: Is interpreted as begin at x hours and end at y hours at z step.
    This means valid hours to run are x, x+z, x+(2*z), x+(3*z).... till x+(n*z) < y.

    a-b, x-y: Is interpreted as multiple ranges.
    Multiple hour ranges can be specified in the hour specifier. Ranges specified should be in ascending order.

    x,y,z: Is interpreted as run at x, y, and z hours.

    Any of the above combinations can be used in hour specifier.

    Sample:

    9-4 is interpreted as 19-23:59

    Sample:

    10-16/2 is interpreted as run at 10, 12, 14 hours.

    Sample:

    8-10, 12-18, 20-22 is a valid schedule.
    8-10, 2-3, 12-18 is invalid as the ranges are not in ascending order.

    Sample:

    2,10-12,16-22/3 is a valid value in hour specifier.

    Day Specifier

    Accepts data in a regular expression format.
    Valid numeric values that can be entered are 1 to 31.

    Valid data formats are

    • x
    • x-y
    • x-y/z
    • a-b, x-y
    • x,y,z

    Interpretation of data in various formats:

    x: Is interpreted as run on x day.

    ’*’ in x is interpreted as 1-31.

    x-y: Is interpreted as run between x and y days.

    • ‘*’ is not a valid value in a range.
    • x should be less than y in the range.
      x-y/z: Is interpreted as begin on x day and end on y day every z days.
      This means valid days to run are x, x+z, x+(2*z), x+(3*z).... till x+(n*z) < y.

    a-b, x-y: Is interpreted as multiple ranges.
    Multiple day ranges can be specified in the day specifier. Ranges specified
    should be in ascending order.

    x,y,z: Is interpreted as run on x, y, and z days.

    Any of the above combinations can be used in day specifier.

    10-16/2 means run on 10th, 12th, 14th, 16th day of the month.

    Sample:

    8-10, 12-18, 20-22 is a valid schedule.

    8-10, 2-3, 12-18 is invalid as the ranges are not in ascending order.

    Sample:

    2,10-12,16-22/3 is a valid value in day specifier.

    Month Specifier

    Accepts data in a regular expression format.

    Valid numeric values that can be entered are 1 to 12.

    Valid data formats are

    • x
    • x-y
    • x-y/z
    • a-b, x-y
    • x,y,z

    Interpretation of data in various formats:

    x: Is interpreted as run in x month.

    ’*’ in x is interpreted as 1-12.

    x-y: Is interpreted as run between x and y months.

    • ‘*’ is not a valid value in a range.
      x should be less than y in the range.
    • x-y/z: Is interpreted as begin in x month and end in y month every z months.
      This means valid months to run are x, x+z, x+(2*z), x+(3*z).... till x+(n*z) < y.

    a-b, x-y: Is interpreted as multiple ranges.
    Multiple month ranges can be specified in the month specifier.
    Ranges specified should be in ascending order.

    x,y,z: Is interpreted as run in x, y and z months.

    Any of the above combinations can be used in day specifier.

    Sample:

    1-8/2 means run in 1,3,5,7 months. (Run in Jan, Mar, May, and Jul)

    Sample:

    1-2,6-9 is a valid schedule.
    6-9, 1-2 is invalid as the ranges are not in ascending order.

    Day of the Week Specifier

    Accepts data in a regular expression format. Valid numeric values that can be entered are 0 to 6. 0 stands for sunday. 6 stands for saturday.

    Valid data formats are:

    • x
    • x-y
    • x-y/z
    • a-b, x-y
    • x, y, z

    Interpretation of data in various formats:

    x: Is interpreted as run on x weekday.
    ’*’ in x is interpreted as 0-6.

    x-y: Is interpreted as run between x and y weekdays.

    • ’*’ is not a valid value in a range.
    • x should be less than y in the range.

    x-y/z: Is interpreted as begin on x weekday and end on y weekday every z days.
    This means valid weekdays to run are x, x+z, x+(2*z), x+(3*z).... till x+(n*z) < y.

    a-b, x-y: Is interpreted as multiple ranges.
    Multiple weekday ranges can be specified in the day of week specifier. Ranges specified should be in ascending order.

    x, y, z: Is interpreted as run on x, y, and z weekdays.

    Any of the above combinations can be used in weekday specifier.

    Sample:

    0-5/2 means run on 0,2,4 weekdays. (Run on sunday, tuesday, thursday)

    Sample:

    0-2,4-6 is a valid schedule.

    4-6, 1-2 is invalid as the ranges are not in ascending order.

    Sample data in different fields and their interpretation:

    Example 1:

    second specifier:12/30
    minute specifier:5/15
    hour specifier :7-9
    day specifier:*
    month specifier:*
    day of week specifier:0-6

    Schedule starts at 5 minutes 12 seconds past 7 and runs every 30 seconds. Schedule ends at 9. This schedule runs every day. As both seconds and minute frequency were specified minute frequency was ignored.

    Example 2:

    second specifier:*
    minute specifier:*/45
    hour specifier :7-10
    day specifier:*
    month specifier:*
    day of week specifier:0-6

    Schedule starts at 0 minutes past 7 and runs every 45 minutes till 10 every day. Schedule runs at 7:00, 7:45, 8:30, 9:15

    Example 3:

    second specifier:*
    minute specifier:*/30
    hour specifier :7-9, 15-17
    day specifier:*
    month specifier:*
    day of week specifier:0

    Schedule runs at 7:00, 7:30, 8:00, 8:30,15:00,15:30,16:00,16:30 every sunday.

    Example 4:

    second specifier: *
    minute specifier:10/15
    hour specifier :22-3
    day specifier:*
    month specifier:*
    day of week specifier:0-6

    Schedule runs at 22:10, 22:25,22:40,22:55,23:10,23:25,23:40,23:55 every day. 22-3 in hour range was rounded off to 22-23:59 as x > y in the hour range.

  9. Click Save to save the configuration. This generates a script that must be applied to the database. Privileges are required for generating and executing scripts. For more information, see "Issuing Privileges".
  10. Optional: Test the connection:
    1. Execute inst_orcl.sql.
    2. Select the new server, then click Test.

      3. The ‘Test Connect Succeeded’ message displays if successful.

    To delete a data server
  1. Select the data server to delete.
  2. Click Delete. The data server and its associated configuration is removed from the list box. A message displays the location of script.
  3. Execute the script to completely uninstrument the tables. When applied, the script deletes the changelog schema, changelog tablespace, and all triggers from the instrumented tables.

    4. Note

    You should not uninstrument an Oracle data server if a user is connected. If the Join Engine is running when you try to uninstrument your Oracle data server, the SQL scripts will fail, stating that the user could not be removed.

Running the Configuration Script

  1. Run the following:

    2. inst_dataservername.sql

    The script is stored in the $NETSITE_ROOT directory.

  2. Check the script and replace any tokens with information (that is, $TABLE_SPACE_LOCATION$). You must run the script as the system database administrator. After the script is generated, you must confirm that all fields are present and are correct.

    3. After running the script, the tables become instrumented and the changelog tablespace is created.

Adding a Connector View Instance

    To add the instance
  1. Select Connector Views from the Meta-Directory tree, and then right-click.
  2. Click New View. The ‘New Instance Creation’ dialog box displays.
    Figure shows the ’New Instance Creation’ dialog box.
  3. Select the newly created data server URL from the list box. The ‘New Instance Creation’ dialog box displays.

    4. Provide information for the following fields:

    Table 8-5  List of options and the description of the action to perform

    Field

    Do This

    View Name

    Enter a name that more fully describes the View ID. The default is the View ID.

    View ID

    Enter up to five characters to represent the view ID. The default is CVn, where n is the next available view number.

    View Table

    Select the table you want to assign to the Connector View.

  4. Click OK. A confirmation message ‘Instance Creation Succeeded’ displays.
    To delete the instance
  1. Select the instance to delete, and then right-click.
  2. Click Delete View. The instance is deleted.

    3. The Oracle Connector View is also deleted if you delete the Oracle data server.

Adding the Instance as a Participating View

Each participating Connector View has its own settings. In addition to these settings (or in place of them), each view also has settings that specify how the Join Engine handles the view within the Meta View.

    To add a participating Connector View
  1. Right-click the Participating Views object.
  2. Click Add Participating View. The ‘Select View’ dialog box displays.
  3. Select the Connector View to add or participate in a join/synchronization with the Meta View.
  4. Click OK. The view is added to the Meta-Directory tree.
    Figure show the tree structure of the ’view’.
    To remove a participating Connector View
  1. Select the view to remove, and then right-click.
  2. Select Delete View. The view is deleted.

Configuring a Connector View

Configuring the Connector View consists of the following tasks:

You can create join rules and filters, however you must create the following types of rules too:

After you create the rules, you can add them to the Connector View and flow data. The data should flow according to these rules from the Connector View (Oracle) to the Meta View and vice versa.

Creating Constructed Attribute Rules

See "Constructed Attributes" for procedures on creating constructed attribute rules.

Creating Attribute Flow Rules

See "Attribute Flow Rules" for procedures on creating attribute flow rules.

Creating DN Mapping Rules

You need to carefully write the DN mapping rules for flowing data from the Meta View to the Connector View. You might expect these to look like rules for flowing data from the Connector View to the Meta View with elements of the rule reversed, but this may not be the case.

The Meta View to Connector View DN mapping rules typically look like the following example:

<PK col name>=%mv.<mapped attribute>

Consider an employee table EMP with FIRSTNAME, LASTNAME, EMPNO and DEPT as columns in which EMPNO is the primary key. The Connector View to Meta View DN mapping rules for an inetorgperson entry would typically look like:

cn=%cv.FIRSTNAME%

However, the Meta View to Connector View DN mapping rule would need to be:

EMPNO=%mv.employeenumber%

assuming that you have mapped employeenumber to the EMPNO column.

Therefore, you need to map primary key columns to an attribute in the directory in order to correctly map a row in the database to a single entry in the directory and vice versa.

See "Distinguished Name Mapping Rules" for procedures on creating DN mapping rules.

Creating Join Filters

In case of database connector, a join filter typically replaces the ‘WHERE CLAUSE’ in the query statement. For instance

ID='%mv.uid%' and if mv.uid is say user1 the filter gets translated as ‘where ID=user1’.

Note that while creating join filters, the SQL datatype of the attribute has to be taken into consideration and accordingly the attribute value has to be enclosed within the SQL datatype specific enclosures. For instance if ID is of type SQL VARCHAR, then the filter should be created as ID='%mv.uid%' and if ID is of type NCHAR then the filter should be ID=n'%mv.uid%' and so on.

Configuring a Participating Connector View

See "Configuring a Participating View" for procedures on configuring a participating Connector View. Note that the Group Filters window is only available for UTC-based connectors or for Sun ONE Professional Services.

Starting the Join Engine

Before you start the Join Engine, ensure that you have already enabled the changelog in the Directory Server configuration.

    To start the Join Engine
  1. Select the Join Engine object from the navigation tree and right-click. A context menu appears.
  2. Select Start Server. A message appears stating that the server has been started.

You can also start the server from the Sun ONE Console. To do this, select the Join Engine object and right-click. Select Start Server from the context menu.

Enabling the Connector View

  1. From the Sun ONE Meta-Directory software window, click on the Status tab.
  2. Click on the Join Engine object. The Operations tab window appears.
  3. Select the Participating View you want to enable.
  4. Select Enable from the Operation list menu, then click Start.

    5. This option disables the Traverse drop-down menu. You can only enable the Participating View if the configuration for setting up the view is valid. Any error in the configuration automatically changes the view to a disable status.

  5. Select Refresh from the Operation List Window, then select either Meta View or Connector View from the Traverse menu list.
  6. Click Submit Request. The status changes to up.

If you are having trouble enabling the Connector View, you should check whether the proper privileges have been issued. See "Issuing Privileges" for more information.

Monitoring the Connector View

You should monitor the Connector View status while restarting the database on which you created the Connector View. When the Oracle server is restarted while the Oracle Connector View is enabled, the Join Engine requires about one to two minutes for rebinding to the Oracle server. You can adjust the DataAccess logs to level 1 to determine that the rebind has occurred; the logs would show SQLs being executed on the Oracle changelog. Subsequent to the rebind, all refresh/changelog operations would become effective.

It takes about a minute for Oracle to shut down. You can expect the Join Engine to disable the Oracle Connector View if you attempt an operation, such as add, on the database during the database shutdown. In that case, you would need to explicitly enable the Connector View after the database is up and running.

Configuration Example

The following example is intended as a quick reference you can use as a checklist. For complete configuration information, refer back to the earlier portions of this chapter.

    Create the data server
  1. Configure the data server.
    1. Click the Meta-Directory object, then click on the Data Servers tab. The Data Servers window appears.
    2. Click New. The Data Server Type dialog box appears.
    3. Select Oracle and click OK.
    4. From the General tab, provide information for the fields.
      • The New Oracle User Name should not currently exist in the Oracle database.
      • The Oracle Home Environment Variable is the OCI root directory.
      • Use the default for the NLS Language Environment Variable.
    5. Click the Columns tab. The Database Credentials dialog box appears. After providing the Oracle user name and password, the Columns window appears.
      • Select the columns you want to synchronize.
      • Select the primary key of the column to be instrumented. If no primary key exists in the column, you need to nominate a primary key.
    6. For the remaining tabs, use the defaults.
    7. Click Save to save the configuration.
  2. Run the following configuration script:

    3. inst_dataservername.sql

    The script is stored in the $server_root\bin\meta50\bin directory. This script grants privileges. For more information on privileges granted, see "Issuing Privileges".

  3. Add the Connector View instance.
    1. Select Connector Views from the Meta-Directory tree, then right-click. A context menu appears.
    2. Select New View. The New Instance Creation dialog box appears.
    3. Select the newly created data server URL from the drop-down list. An altered New Instance Creation dialog box appears.
    4. Provide the view name, view ID, and select the table you want to synchronize.
    5. Click OK. The message “Instance Creation Succeeded” appears after the instance has been created. The main console navigation tree will redisplay.
  4. Add the instance as a Participating View.
    1. Right-click the Participating Views object. A context menu appears.
    2. Select Add Participating View. The Select View dialog box appears.
    3. Select the newly created Connector View and click OK. The view is added to the Meta-Directory tree.
    Configure the participating Connector View
  1. Create constructed attribute rules.
    1. Select Configuration > Meta-Directory > Attribute Construction.
    2. Click New Attribute, then provide a name, such as dbobjectclass, in the New Constructed Attribute dialog box.
    3. Click OK. The new attribute appears in the Attributes list.
    4. Select the attribute, then click New Rule. The New Constructed Attribute Rule dialog box appears.
    5. Configure the rule, using dbobjectclass as the name. For the Attribute Construction field, enter the following string:

      6. top;person;organizationalperson;inetorgperson

    6. Click OK, then click Save from the Attribute Construction tab.
  2. Create attribute flow rules.
    1. Select Configuration > Meta-Directory > Attribute Flow.
    2. Click New Rule. The New Attribute Flow Configuration dialog box appears.
      1. Provide a name of ora2mvattrflowrule.
      2. For Direction, select To Meta View.
      3. For Selection Criteria, click “...” to go to the Compose Condition Criteria dialog box. For Type, select Attribute. For Source, select the Oracle Connector View. For Attribute, select the primary key or nominated key. For Expression, select Present. Click Insert, then OK.
    3. Click Add. The Add Attribute Mappings dialog box appears.
    4. Map attributes by doing the following:
      1. For Source View, select the Oracle Connector View.
      2. For Source Objectclass, select the Oracle table.
      3. For Destination View, select Meta View.
      4. For Destination Objectclass, select inetorgperson.
      5. Select one attribute from the left column, one from the right column, then click Insert. You do not need to map all attributes.

      Repeat the process with these variations:

      1. For Source Objectclass, select Constructed Attributes.
      2. For Destination Objectclass, select inetorgperson.
      3. Select the constructed attribute (dbobjectclass) and map it to objectclass in the right column.
      4. Click Insert, then Close.
    1. Click OK from the New Attribute Flow Configuration dialog box. The new rule appears in the Rules section of the Attribute Flow window.
    2. From the Attribute Flow window, click New Set, and provide a name of ora2mvattrflowruleset in the New Set dialog box.
    3. Select ora2mvattrflowrule and ora2mvattrflowruleset, then click Add Member. The rule appears in the Members list box.
    4. Click Save, then select View > Refresh from the menubar.
  3. Create DN mapping rules.
    1. Select Configuration > Meta-Directory > DN Rules.
    2. Click New Rule. The New DN Mapping Rule dialog box appears.
      1. Provide a name of ora2mvdnmap.
      2. For Selection Criteria, click “...” to go to the Compose Condition Criteria dialog box. For Type, select Attribute. For Source, select the Oracle Connector View. For Attribute, select the column mapped to the RDN. For Expression, select Present. Click Insert, then OK.
      3. For Distinguished Name Construction, enter the RDN:

        4. cn=%cv.ENAME%

        where ENAME is a column name in the Connector View (primary key or unique column). Do not repeat the RDN mapping in the attribute flow rule.

    3. Click OK. The new rule for this DN mapping appears in the Rules list box.
    4. Click New Set and provide a name of ora2mvdnmapset in the New Set dialog box.
    5. Select ora2mvdnmap and ora2mvdnmapset, then click Add Member. The rule appears in the Members list box.
    6. Click Save, then select View > Refresh from the menubar.
  4. Configure the participating Connector View.
    1. Select the participating Oracle Connector View for the Meta View. The Configuration tab appears.
    2. For Attribute Flow, select None for To Connector, and select ora2mvattrflowruleset for To Meta View.
    3. For Join Rules, select None for both drop-down lists.
    4. For DN Mapping Rules, select None for To Connector, and select ora2mvdnmapset for To Meta View.
    5. For the remaining tabs, see "Configuring a Participating View".
    6. Click Save.
  5. Start the Join Engine.
    1. Select the Join Engine object from the navigation tree and right-click. A context menu appears.
    2. Select Start Server. A message appears stating that the server has been started.
  6. Enable the Connector View.
    1. Select Status > Join Engine > Operations.
    2. For View, select the Oracle Connector View, for Operation, select Enable, and then click Start.
    3. Repeat the step above, except select Refresh instead of Enable.

Changing Instrumentation

You can add or remove instrumentation any time after you have followed all of the procedures in this chapter to this point in the order presented.

    To add instrumentation
  1. Click the Columns tab. The Database Credentials dialog box appears. After providing the Oracle user name and password, the Columns window appears. The credentials remain in effect until you leave this particular data server.
  2. Select one or more columns, tables, or users from the Uninstrumented Columns list.
  3. Click Add. If you selected a column, the column now appears in the Instrumented Columns list. If you selected a table, the table and its associated column(s) now appear in the Instrumented Columns list. If you selected a user, the user and its associated table(s) now appear in the Instrumented Columns list.
  4. Click Save.
  5. Run the script. The changes are now instrumented.
    To remove instrumentation
  1. Click the Columns tab. The Database Credentials dialog box appears. After providing the Oracle user name and password, the Columns window appears. The credentials remain in effect until you leave this particular data server.
  2. Select one or more columns, tables, or users from the Instrumented Columns list. Note that if you select a primary key column or nominated column, the entire table will be uninstrumented.
  3. Click Remove.
    • If you selected a column, the column now appears in the Uninstrumented Columns list.
    • If you selected a table, the table and its associated column(s) now appear in the Uninstrumented Columns list.
    • If you selected a user, the user and its associated table(s) now appear in the Uninstrumented Columns list.
  4. Click Save. After running the script, the uninstrumented columns, tables, or users are removed and the remaining columns, tables, and users become instrumented.

    5. Note: After changing instrumentation and running the scripts, use the “Refresh” button present in the same panel, in order to refresh the console with the latest changes in the data server. If the console is not refreshed, and further changes are made to the instrumentation, the scripts generated might be incorrect. Refreshing the console is required, if the user continues to use the same session to make multiple changes to the instrumentation (i.e he has not left the particular data server).

Issuing Privileges

Oracle privileges are required for performing the following tasks:

Typically, different individuals would perform each of these tasks, but one person could perform all of the tasks if preferred. The following sections explain these tasks and the associated privileges required. Contact your database administrator or refer to your Oracle server documentation set for specific questions about privileges.

Generating the Script

The console reads the database dictionary to gather information about the database schema. The user can select tables and columns from this schema for instrumentation.

The user for which the console connects to Oracle must be given sufficient privileges to read the database dictionary tables. The associated user name and password are supplied to the Meta-Directory Console, which the console uses to read the data dictionary. The user name and password are not stored in Meta-Directory configuration.

Executing the Script

To instrument the database, a user executes the script and has privileges to do the following:

This user name and password are supplied to the tool that executes the script; they are not stored in Meta-Directory configuration, nor handled by Meta-Directory software.

Table 8-6 provides reference information for the user roles discussed above.

Table 8-6  Database Privileges 

Task

Required Privileges

Appropriate User

Script Generation

CREATE SESSION

To instrument tables that other users own, SELECT privileges for these tables should be granted to this user before attempting to instrument them.

Any existing database user with these privileges. (Known as the console user.)

Script Execution

CREATE ANY TRIGGER
DROP ANY TRIGGER
CREATE TABLESPACE
DROP TABLESPACE
CREATE USER
DROP USER
CREATE ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT
CREATE ANY TABLE
DROP ANY TABLE
INSERT ANY TABLE
DELETE ANY TABLE
CREATE SESSION
CREATE ANY PROCEDURE
EXECUTE ANY PROCEDURE

Any user with these privileges.

Synchronization

CREATE SESSION SELECT/INSERT/UPDATE/DELETE

Also, privileges are required to synchronize all instrumented source tables. These privileges are granted to the changelog user by the script Meta-Directory generates.

The changelog user the Meta-Directory creates.

Synchronizing the Instrumented Tables

The Meta-Directory console generates a script to instrument the tables and columns you select. The set of tables you can select for instrumentation consists of the tables you own, and those for which you have SELECT privileges. The database schema is built by querying the data dictionary, which is accessed through public synonyms (defined in data dictionary views).

For synchronization, each data server has one user (whose user name and password are in its mdsAuthenticationDetails attribute). The Meta-Directory Database Connector authenticates this user to synchronize any associated Connector View. The generated script grants privileges to the changelog user to:



Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.