Chapter 1   Meta-Directory Concepts


This chapter provides an overview of iPlanet^TM Meta-Directory and its components and describes why it is an essential application in today's directory environment.

The chapter contains the following top-level sections:

• The Importance of iPlanet Meta-Directory

• iPlanet Meta-Directory Components

• How iPlanet Meta-Directory Works

The Importance of iPlanet Meta-Directory

---

A typical business enterprise today uses a myriad of directory system types. Often, the different systems collect information on the same entries (for example, information about a company employee), but each system will host different types of information for the entries. Think of the difference between the information contained in a Human Resource database as opposed to the employee information compiled by the Information Technologies (IT) department. As each of the systems gather data about a particular entity, there is an acute need for one product to integrate the various systems and link together their pertinent, authoritative information.

iPlanet Meta-Directory joins dissimilar data repositories into a single LDAP database so you can effectively manage, modify, and search the information that is distributed among different directory and database systems. With Meta-Directory, you can create a "Corporate LDAP Directory" that you can use as the central point for directory access and administration.

Historically, it has been extremely difficult to manage the data contained in differing data repositories due to dissimilar formats. Directory information stored in systems such as e-mail applications, human resources databases, various relational databases, and online directories makes it difficult to update and maintain the information for any one particular entity. The authoritative data source for a particular user attribute may exist in any one of many different user directories.

In a frequently repeated scenario, the Windows NT security accounts manager (SAM) stores account information for Windows users, the Network Information Server (NIS) stores user account information for UNIX® users, a human resources database will likely store specific information for employees and contractors, the payroll database is maintained in SQL, the facilities database stores employee building information, and the PBX system is the definitive source for employee phone numbers.

The iPlanet Meta-Directory Solution

iPlanet Meta-Directory integrates the disparate directory systems within an enterprise so their joined information can be accessed and managed from a single location, the meta view. The meta view is contained in an LDAP directory that is hosted by an instance of iPlanet Directory Server.

Meta-Directory creates an enterprise LDAP directory that contains a concentrated "view" of the external data repositories that it links. Since the meta view is LDAPv3-compliant, the directory overcomes the limitations of system-specific directory name spaces. This integration provides functions and capabilities that give directory planners the flexibility they need to maintain and upgrade their existing enterprise directory structure.

The meta view is a fully-functional Directory Server database. Using using the API built into LDAP, you can create applications to access the information stored in the meta view. In fact, all features available in iPlanet Directory Server (access control, data back-ups, and so on) are available in the meta view.

The iPlanet Meta-Directory's meta view combines diverse details about a data entity into a single LDAP directory entry. This provides a centralized system of gathering information on an entity that may have different details scattered throughout multiple data repositories. iPlanet Meta-Directory can copy data from one data repository to another data repository. During this process, Meta-Directory controls information flow, including what to copy, and where and when to copy it. You can update all of the records for a single entity either through the Meta-Directory meta view or through the individual data repositories.

In addition to unifying systems, you can use Meta-Directory to restructure the architecture of your enterprise directory system by combining and integrating legacy systems into state-of-the-art LDAP directories. By integrating these systems, you have greater control, flexibility, and access to the information stored in each directory.

An Example Application

Suppose an organization has information for one of its employees, Micki Guzman, in a number of different data repositories (for example, a human resource database, an e-mail system, and IS directory system). Not only would there be a lot of duplicate information on Micki between the systems, but the job of managing the changes rests with multiple administrators across the organization. Changing the telephone number or job title of Micki Guzman would require administrators to change records in each system on which Micki is registered. On top of this, finding the authoritative value for one of Micki's attributes (an e-mail address, for example) can be time consuming and resource intensive.

With iPlanet Meta-Directory, the details for Micki Guzman are stored in a single entry in the meta view, which presents a single view of all her directory attributes. Using the meta view, you can view and manage all of Micki Guzman's attribute values from a single location. Modified details are propagated back to each of the data repositories. Likewise, changing attribute values in one system will propagate, through Meta-Directory, to all connected systems.

Synchronizing and Joining Entries

Through the process of synchronizing and joining, Meta-Directory integrates and unifies directory information maintained in the different directory systems implemented across an enterprise. With Meta-Directory, directory entries are unified into a single, common LDAP directory.

Figure 1-1 illustrates the difficulty of accessing data that is stored in several different data repositories. The figure is a simplified look at a problem that faces many organizations. In this simple scenario, there are three databases that store different information about a singe object, a person in the company. In this case, if a user wants to get the phone number, the location, and the email address of an employee, they must search though an assortment of different database systems.

Figure 1-1    Manual Data Synchronization Without Meta-Directory

Figure 1-2 shows the highly automated data flow implemented in the Meta-Directory join process. Meta-Directory serves as the central repository and propagation facility for commonly updated user attributes. Here, users are able to query a single LDAP database (the meta view) to obtain information associated with a user. With Meta-Directory, users are assured that the information they are retrieving is the "authoritative" information for that user. Without Meta-Directory, a user would have to query several different databases, possibly retrieving several pieces of conflicting information.

Figure 1-2    Automatic Data Synchronization Provided by Meta-Directory

Through the Meta-Directory synchronization process, a copy of the entries stored in an external database is provided in a LDAP format. Meta-Directory provides a "view" of the external data in what is known as a connector view. The connector view contains information from an external data source after it has been mapped into LDAP format.

The Meta-Directory join process completes the unification of synchronized user entries by joining the entries in the central LDAP repository (the meta view). The join process is managed by the Meta-Directory join engine which, through the join rules you write, synchronizes information from the authoritative data source for each of the joined attributes. The join engine is also able to propagate changes made in the meta view back to the external data sources.

The join engine accomplishes the synchronization and joining by linking entries in the meta view with those in the participating connector views.

The specific information contained in the meta view (the attribute values for each entry) is configured when you set up the join process. You control the information contained in the meta view by specifying which attributes to accept or reject from each external data source. In addition, you configure which external data sources can accept changes made in (or propagated through) the meta view.

A Meta-Directory Deployment

Successfully deployed, Meta-Directory provides a consistent view of all directory databases in the enterprise. As shown in Figure 1-3, Meta-Directory leverages the iPlanet Directory Server, which it uses to store component configuration data and the meta view itself. The Directory Server also provides user authentication, access control to directory data, and replication and referral services.

In this figure, the join engine and the Meta-Directory console configuration are stored in one directory information table (DIT), while the meta view (the unified LDAP directory) is stored in another DIT. Connector views (LDAP copies of foreign directory data) may be combined in one directory instance or maintained in separate instances, depending on the directory requirements. All Meta-Directory components, including the connector views that participate in the meta view, are administered as one server group through the iPlanet Console.

Figure 1-3    The Meta-Directory Solution

The following sections explain in more detail how the Meta-Directory components interact and work with each other. The iPlanet Meta-Directory configuration process (setting up the meta view, the join engine, the directory connectors, and connector views) is fully explained in the iPlanet Meta-Directory Configuration and Administration Guide.

iPlanet Meta-Directory Components

---

iPlanet Meta-Directory works in conjunction with iPlanet Console, iPlanet Administration Server, and iPlanet Directory Server. You use iPlanet Console to manage the different iPlanet server groups that you have installed in your Meta-Directory system. You use iPlanet Administration Server to administer instances of iPlanet Directory Server and any installed Meta-Directory components. You use iPlanet Directory Server to provide support for the Meta-Directory configuration files and to provide the directory instance for the populated meta view.

With the mixing and matching of these software products and components, it can be difficult to draw a distinct line where one product ends and another begins. However, simply put, iPlanet Meta-Directory consists of the following components:

• The Meta-Directory console

• The join engine (and its associated meta view)

• The supported connectors (and their associated connector views)

iPlanet Meta-Directory Console

The Meta-Directory console provides a graphical user interface (GUI) that you use to configure Meta-Directory components and manage the flow of information to and from the meta view and connector views.

The Meta-Directory console contains both left and right panes. The left pane displays a navigation tree, which uses icons to represent the components installed in your Meta-Directory system. When you select a particular Meta-Directory component in the navigation tree, an interface to a set of administration tasks displays in the right pane of the console. Refer to the iPlanet Meta-Directory Configuration and Administration Guide for detailed information on managing the Meta-Directory components through the Meta-Directory console.

iPlanet Console and iPlanet Directory Server Console

In addition to the Meta-Directory console, you will also be working with the iPlanet Console and the iPlanet Directory Server console.

The iPlanet Console
The iPlanet Console is used to administer the iPlanet server groups that you have installed. A server group is an installed set of iPlanet servers that are administered by a single iPlanet Administration Server. It is likely that you will have more than a single iPlanet server group, with each server group being installed into a separate directory structure. For example, if you install iPlanet Directory Server into one directory structure and iPlanet Meta-Directory into another, they will each be represented in the iPlanet Console as different server groups.

An iPlanet Administration Server is installed into each server group. iPlanet Administration Server allows remote administration through the iPlanet Console, including the ability to view and modify Meta-Directory component configurations, start and stop agents, and view component status. For more information on the iPlanet Console, refer to the iPlanet Console and Administration Server 5.0 Server Management Guide, which can be found at the following iPlanet web site:

http://docs.iplanet.com/docs/manuals/console.html

In addition to administering server groups, you also use the iPlanet Console to access both the Meta-Directory console and the Directory Server console. From the iPlanet Console, double-click the Directory Server icon or an icon for a Meta-Directory component to display the associated product console.

The Directory Server Console
Before you install Meta-Directory, you must first install iPlanet Directory Server. Directory Server has its own console, the iPlanet Directory Server console. Centralized LDAP directory administration services—including access control, authentication, database backup, and replication—are implemented using the iPlanet Directory Server console. For more information about the Directory Server, the Directory Server console, and LDAP, refer to the iPlanet Directory Server Administrator's Guide and the other documents located at the iPlanet Directory Server web site:

http://docs.iplanet.com/docs/manuals/directory.html

The Join Engine and the Meta View

The core service of iPlanet Meta-Directory is the join engine, responsible for managing and controlling the flow of information into and out of the meta view. Its job is to maintain the meta view by synchronizing its information with the external data repositories.

The Join Engine

The join engine uses a configurable sequence of searches to automatically join (or link) entries in external data repositories with corresponding entries in the meta view. These searches are called rule sets, which consist of ordered sets of rules that you configure. When information from an external data repository is propagated to the connector view, the join engine "links" that information with the corresponding entry that exists in the meta view, if it is configured to do so.

In addition to joining participating connector views into the meta view, the join engine is also responsible for controlling the flow of information from the unified meta view to external data sources.

Meta View Services

In addition to containing the joined data of the participating directories and databases, the meta view provides the following centralized directory services:

• Incremental updates. External directories and databases can be updated incrementally as they are modified in the meta view.

• Object modification. The meta view can reflect modifications made to an entry in an external directory or database.

• Object creation. Objects in external directories and databases can be created from the meta view.

• Object deletion. Objects can be deleted from the meta view and from the external directory or database, depending on entity ownership.

Connectors and Connector Views

Connectors provide to the join engine the data contained in an external data source. The data is provided in the form of a physical directory, called the connector view. Once a connector populates a connector view, the join engine can flow the data to the meta view. There are two types of connectors: indirect and direct.

Indirect Connectors

An indirect connector provides an LDAP-based copy of the entries that reside in an external data repository. The indirect connector presents the information in a corresponding connector view. The join engine communicates with a connector view over LDAP and consolidates this information into the meta view.

Using the Meta-Directory Universal connector, indirect connectors convert data contained in an external data repository into LDAP. The LDAP copy of this data is stored in a connector view that is hosted by iPlanet Directory Server. The join engine can then link the entries in the connector view with the entries contained in the meta view.

iPlanet Meta-Directory, version 5.0 provides the following indirect connectors:

• The Universal Text Parser (UTP) is a text-file processor that parses and generates ASCII text files. Using the Universal Text Parser, you can build indirect connectors that interface with text-based data sources, such as an application that outputs a comma-separated value text file.

• The NT Domain connector provides bidirectional synchronization of user and group data from a Windows NT SAM database into a connector view.

• The Active Directory connector provides bidirectional synchronization of user and group data from an Active Directory database into a connector view.

An indirect connector asynchronously copies entries between the external data repository and its corresponding indirect connector view, as shown in Figure 1-4.

Figure 1-4    Indirect Connector Views

Directory Change Notification System
The Directory Change Notification System (DCNS) is a service provided by Meta-Directory as a shared library. The join engine and Universal Connector use DCNS to detect changes in indirect connector views and in the meta view. The Meta-Directory components also uses this service to provide change notification to the connected data sources that can accept notifications.

DCNS relies on the change log files that are generated by the Directory Server instances that host your Meta-Directory views. Without the DCNS service, the join engine and your connectors would not be able to react to the changes made to any of the Meta-Directory views. If the change log is not enabled, the DCNS will be unable to function and the error message mds_controller_unavailable will be written to the Meta-Directory logs.

Direct Connectors

The join engine communicates directly with external data sources that format their data using the LDAP protocol (such as iPlanet Directory Server). Because of this, the join engine forms a direct connection with applications that provide data in LDAP format. In addition to LDAP, the join engine also "speaks" SQL. With this, the join engine can also form a direct connection with SQL-based data sources.

---

Note

iPlanet Meta-Directory version 5.0 does not support all LDAP and SQL directories and databases. Specifically, Meta-Directory provides for a direct connection support for LDAPv2 and LDAPv3 directories that implement the change log mechanism implemented in NetscapeTM Directory Server 4.1x. In addition, Meta-Directory can make SQL connections only through the Oracle Call Interface (OCI). Specifically, Meta-Directory supports connections to Oracle version 8.1.5 databases using the OCI programming interface.

---

The LDAP and SQL direct connectors are actually a part of the join engine. Because the join engine can directly connect to LDAP and SQL data repositories, Meta-Directory does not require a separate connector component to copy the data into an LDAP-based connector view. Instead, the join engine provides a direct "view" of the data that resides in the external data repository. With the LDAP and SQL direct connections, the join engine is able to synchronously access entries in both the meta view and the connector view that resides on the external data source.

The Meta-Directory direct connectors are shown in Figure 1-5.

Figure 1-5    Direct Connectors

How iPlanet Meta-Directory Works

---

Two types of services integrate information from different data repository systems into and out of iPlanet Meta-Directory:

• The connectors, which transfer entries to and from disparate external data repositories into the Meta-Directory views.

• The join engine, which unifies entries contained in connector views with those in the meta view.

These services act upon data created and stored within two types of Meta-Directory views: the meta view and the connector views.

How Connectors Work

While there are inherent differences between direct and indirect connectors, they both perform the same basic function: connectors allow the join engine to sychronize entries between the meta view and the disparate connector views. With direct connectors, the associated connector view is located on the external data source. On the contrary, indirect connectors must first flow data to an LDAP-based connector view before the join engine can synchronize data.

Figure 1-6 shows the process of transferring information between external data repositories, the connectors, and the meta view. Note that LDAP and SQL data repositories do not use a connector component to populate the associated connector view.

Figure 1-6    iPlanet Meta-Directory Component Overview

With direct connectors, the join process rules that you define are enough to synchronize data between the external data source and the meta view. However, with indirect connectors, you need to configure a separate set of indirect connector rules to define what attributes should flow between the external data source and the indirect connector view. Once the entries are in the connector view, the join engine can link them to the meta view.

Indirect Connector Rules

When you configure indirect connectors, you specify the entries and attributes that should flow between an external data source and its associated connector view using indirect connector rules. Indirect connector rules consist of the following rule sets:

• Attribute flow rules specify which attributes should be synchronized between the external data source and the connector view. With attribute flow rules, you specify attribute name mapping, attribute filtering, and modification propagation.

• Default value rules specify attribute values to use for a destination value when the value of the source attribute is empty or when the source attribute itself is not present.

• Filtering rules specify particular domains, containers, or user entries to include or exclude from the synchronization process.

Indirect connector rules are similar to the join process rules used by the join engine (which are described on page 31). However, while the join engine uses its rule sets to determine what flows between the meta view and the participating connector views, connectors use attribute flow rules to determine what should be synchronized between an external data source and the indirect connector view.

Attribute Flow Rules

With attribute flow rules, you specify the actual attributes that you want to synchronize between the external data source and the connector view. In addition, attribute flow rules specify how modifications flow between the views.

Attribute flow rules specify the following:

• Attribute name mapping specifies how attribute names are mapped between the external data source and the connector view. You control both how the names are mapped from the external data source to the connector view and how they are mapped from the connector view back to the external data source.

• Attribute filtering specifies which attributes will flow from the external data source into the connector view. Attribute filtering works one way in that Meta-Directory does not filter any attributes output by the connector view to the external data source; all attributes contained in the connector view will be flowed out to the external data source.

• Modification propagation specifies how modifications to attributes are handled. Depending on the attribute flow granularity, modifications to existing data can be restricted to the owner of the object or they can be allowed by either the external data source or the connector view.

Attribute Name Mapping
Attribute mappings specify attribute names and they specify how attributes should be matched between two different data repositories. When you define attribute flow rules, you map the attributes from one data repository to another. For example, you might specify that an external database field LastName will map into the indirect connector view attribute sn. If you are flowing data to an external data source, you can also specify how the attribute names will map from the connector view to the external data source.

Because an indirect connector view is an LDAP DIT, information stored in a connector view must conform to a declared LDAP schema. Because of this, all attribute names must be conform with the schema that is loaded into that view. In contrast, an external database will likely contain data fields that do not conform to an LDAP schema. Attribute name mapping ensures that the attribute names are correctly named between the two data sources.

For example, Table 1-1 shows possible external database field names and the names that they could be mapped to in the connector view, (the connector view attribute names are part of the LDAP schema inetOrgPerson):

Table 1-1    Sample Name Mapping

External Database Field Name	Mapped Connector View Attribute Name
LastName	sn
Firstname	givenname
FullName	cn
Position	title
PhoneNumber	telephoneNumber

In this example, when flowing entries between an external data source and the connector view, the attribute LastName in the external data source maps to the attribute name sn in the Meta-Directory connector view. Once mapped into an LDAP schema, the attribute sn can be propagated to the meta view, which is also stored in LDAP format.

Attribute Filtering
Attribute filtering controls the flow of object attributes from an external data source to its associated connector view. When you map the attribute names from the external data source to the connector view, you specify only those attributes whose values you want to flow to the connector view. External attributes whose names you do not specify will not be flowed to the connector view.

Attribute filtering is a one-way filter, it filters only the attributes that will be flowed to the connector view from the external data source. If you are flowing data out of the connector view back to the external data source, no filtering will take place; the connector view will flow all the data that it contains. You control the filtering at this stage through the import function of your external data source.

Modification Propagation
Modification propagation specifies how modifications to existing data will be propagated between the connector view and its associated external data source.

Modification propagation is determined by the attribute flow granularity, which is defined as follows:

• Entry-level granularity is the default. If you do not specify any attribute flow rules, Meta-Directory will use this level of granularity when if flows data that has been modified.

• Attribute-level granularity used if you define any attribute flow rules.

Meta-Directory uses the defined attribute flow granularity to determine how it will propagate entries that contain modified attribute values. If a connector view has entry-level granularity defined, then Meta-Directory will only flow the entries whose data was modified by the source that owns the entry (Meta-Directory will not flow a modified entry if the entry was modified by a data source other than the one that created it). However, if you have defined any attribute flow rules for the connector view, then attribute-level granularity prevails and Meta-Directory will flow all modified entries between the connector view and its associated external data source, regardless of who owns the entries.

Default Value Rules

A default attribute value is a pre-configured value that Meta-Directory will use in a connector view if an entry in the external data source has no value for the corresponding attribute, or if the attribute has no value.

When updating a connector view or external data source, Meta-Directory updates all attributes or fields in the external directory that have associated values. Normally, if an field has no value in the external directory, it is not added to the connector view, and vice versa. To make sure that the connector view or external directory contains appropriate attributes and values, you can define a default attribute value to use with a particular attribute or field.

For example, if the PhoneNumber field in an external data source has no value, but you want the telephoneNumber attribute in the connector view to contain a valid phone number, you can specify a default attribute value (such as the main office telephone number) to be used in the connector view whenever the field is empty or missing in the external data source.

Filtering Rules

By default, all entries in both the connector view and the external data source are included in the synchronization process. However, you can set up filters to designate that particular entries are to be included or excluded from the synchronization. With filtering rules, you have the control to specify which level of a directory tree you want to include (or exclude) from the synchronization process. Within that tree, you can then exclude (or include) specific groups of entries.

How the Join Engine Works

The iPlanet Meta-Directory join process, which the join engine performs, is the key to unifying directory and database entries into the meta view. The join process links entries that exist in each of the connector views with an entry in the meta view. A link between an entry in the meta view and the entries in one or more connector views allows attributes to flow between the views.

The outcome of the join process depends on the join engine applying the sets of join process rules that you define. After the join process occurs, entries between the views are either linked or not linked, depending on how well they match the criteria defined in your join process rules.

When creating the join process rules, you have a lot of flexibility in determining which entries become linked between the different views. In addition, many elements of the join engine configuration are shared between views, making it easy to administer the rules that are shared between connector views.

The Join Process Rules

When the join engine synchronizes one view with another, it uses a set configuration settings, or join process rules, to determine the correct join and data flow. The following join engine settings are configurable from the Meta-Directory console:

Join rules enable you to specify the rules for joining entries between a connector view and the meta view.

Attribute flow rules enable you to specify which attributes should be propagated between a connector view and the meta view.

Filters enable you to include or exclude entries from a connector view by a subtree or a specific entry in a subtree. With filters, you specify groups of entries that you want to include or exclude from the connector view.

Distinguished Name (DN) mapping rules let you specify where you will map entries between a connector view and a meta view. Using DN mapping rules, you create an RDN under a connector view or meta view which you can populate with data. You can also create a DN mapping rule to calculate the primary key of an Oracle table.

Constructed attributes enable you to create attributes in entries stored in the meta view or connector view by combining and manipulating entry information.

A general description of these items is given in the sections below; for complete information on how to configure these items, refer to the iPlanet Meta-Directory Configuration and Administration Guide.

Join Rules

Join rules specify which entries will be linked between the participating connector views and the meta view. When Meta-Directory applies the join rules, the result will be a one-to-one correspondence between the entries that are linked the respective views. If a join rule is applied against a view, and the rule results in more than one candidate entry being selected from a view, no entries will be joined (links between views cannot be one-to-many).

Filters can be built to select an entry, or set of entries, from the opposing view. A filter is an LDAP search rule (or an SQL query) that when applied against a meta or connector view, result in a set of entries being selected to flow to the opposing view.

Join rules are applied in sets. When creating your join rules, you will add individual rules in a particular sequence to form a join rule set. A join rule set specifies an ordered list of join rules that are sequentially tested until either an individual join rule identifies a single entry or until all rules fail.

Each rule in the join rule is fully evaluated, one rule at a time, until a rule returns one or more entry matches. If the evaluation of a join rule results in more than a single candidate match, then no entries will be joined by that rule. In addition, no entries will be joined if the evaluation of the entire join rule set fails to match any entry. In each of these cases, you can manually join specific entries using the Fix-It Tool. See "Manually Joining Entries" on page 35 for more information.

Attribute Flow Rules

Passing data from an external data source, through a connector to a connector view, and to the meta view is known as flowing data. You specify the authoritative attributes, those that flow to the meta view, using attribute flow rules. Attribute flow rules enable you to specify the specific data source for each of the attributes represented in the meta view. They also let you specify which external data repositories can be modified when an entry or attribute value changes.

Attribute flow defines the flow of attributes between connector view and meta view entries. An attribute flow rule lists the attributes that flow between two linked entries and provides pairs of source/target attribute names.

Multiple attribute flow rules may be grouped together into an attribute flow set. The join engine scans through the attribute flow set and selects the first attribute flow rule that matches the selection criteria. The join engine then applies all the attribute flow pairs from the selected rule.

Attribute flow sets provide ordered sets of rules that the join engine scans until it finds a match in the connector view or meta view it is searching. Each rule set is applied in order until a valid rule is found.

Types of Attribute Flow
The selection criteria for attribute flow is based on two types of attributes: entry attributes and context attributes. While entry attributes deal strictly with the source entry and the target entry, context attributes are involved with the context of the operation the join engine is performing. Context attributes are based on a selection of items from the following list:

• Ownership of entry

• Membership of entry

• Operation (add, update, or delete)

• Flow direction (connector view to meta view, or vice-versa)

Entry Ownership and Membership
The ownership and membership of entries are key concepts when working with the propagation of changes through iPlanet Meta-Directory. The join engine updates entries based on entry ownership. Entry membership allows the join engine to work with sets of entries.

Entry ownership dictates the way the join engine decides which data source has ultimate control over an entry. Entry ownership is configurable from the Meta-Directory console—using the console, you specify who will own the entry when the entry is created in one of the Meta-Directory views.

The ability to delete an entry from a view (either the meta view or a connector view) depends on who "owns" the entry. If a view does not "own" an entry, and you delete the entry from that view, the entry will be added back to the view during the next synchronization process.

---

Note

It's important to note that data contained in indirect connector views is an LDAP representation of the data contained in the corresponding external data source. In most cases, the owner of the data is the external data source. As such, you should always use the services of the external data repository to modify (add, delete, or modify) the objects that it owns; you should not modify the objects in the corresponding connector view. Making sure that modifications are made by the owner of the data ensures that the modifications will properly flow through the Meta-Directory system.

---

In Meta-Directory, it is possible to have a connector view that contains data from a variety of data sources. Membership identifies an entry within a connector view that is native to the data source represented by that connector view. Rules can then be configured and applied based on the attributes that are already present in the data source. Membership can be used to control the flow of attributes to and from a view. Membership can also be used when you create selection criteria rules. For example, you can specify that only members of a view can flow from that view to other views, or that a view will take modifications only if the object being modified is a member of that view.

Filters

Filters are used to explicitly include or exclude entries within specific directory subtrees during synchronization. Filters enable you to configure the meta view or connector view to exclude specific subtrees or entries from the unification process.

Distinguished Name (DN) Mapping Rules

Distinguished Name (DN) mapping rules identify where to create a new entry in the destination view (either the meta view or a connector view) given a source entry. The input into a DN mapping rule is the source entry, and the result is a partial DN, which the join engine concatenates with the view location DN to produce a fully qualified DN. The DN mapping rule actually creates an RDN for a specific entry, placing it in the appropriate place under the root of the associated meta view or connector view.

Multiple DN mapping rules may be grouped into a DN Mapping Rule Set to allow for an ordered testing of rules. These rules can be defined differently for entries originating from each different connector view connected to Meta-Directory.

Constructed Attributes

The term constructed attribute refers to the broader scope of any additional attribute that is not explicitly part of a source entry, but that may be derived in a target entry given source data. A simple example would be as follows: if a user has an attribute "state equals New York," a constructed country attribute of "country equals USA" can be created.

The real functionality of constructed attributes comes into play when you use them in the creation of attribute flow settings. You can use constructed attributes in the join rules you write, giving you flexibility when flowing data between two data sources.

Manually Joining Entries

When you add, delete, or modify an entry in a connector view, a search is performed on the meta view for a matching user entry using the configured join rules. If a match is found, a link is made between the two views and any changes made to the entry in either view will be reflected in the other view (of course, depending on the attribute flow configurations).

For example, if an entry for the user David Lewis appears in the Human Resource's database connector view and the join engine links the David Lewis entry in the meta view, user information for David Lewis may be modified in the meta view. Likewise, any Human Resource database attribute changes for David Lewis that are made in the meta view will flow to the Human Resource database.

However, if while evaluating a join rule, the join engine returns more than a single candidate entry, the join will fail (joins can only exist between a single entry in the meta view and an associated connector view). For example, if a join rule links entries based on the sn attribute, and there happens to be two entries in the connector view that have the same sn attribute, the join rule will return multiple candidate entries after processing the rule. Because of this, it is possible for an entry to be left out of the join process. Using the Query Fix-It Tool, you can manually link entries that your join rules miss.

It's good practice to examine the Meta-Directory logs after each synchronization cycle to ensure that no entries were left out of the synchronization cycle. If you find that the cycle missed an entry, you can use the Query Fix-It Tool. The Query Fix-It Tool enables you to manually control the joining process. With this tool, you can link, exclude, unlink, or create entries on an individual basis. For information on using the Query Fix-It Tool, refer to the iPlanet Meta-Directory Configuration and Administration Guide.