In some situations, it may not be convenient to store all profile information in a SQL repository. For example, you may want to use already existing profile data from another application that is stored in an LDAP directory. If your profiles also contain data that is not LDAP specific, one solution is to split the profile information between a SQL and an LDAP repository, rather than using one or the other.
This chapter describes how to link a SQL repository and an LDAP repository so that you can use them both to store profile data. This configuration allows you to choose which data to store in which repository. It also allows you to choose the repository through which you authenticate users. You can split up your profile data and authenticate users through LDAP or through SQL.
Repository linking is accomplished by creating a property in the SQL profile template to refer to the profile in the LDAP repository. You can then access LDAP properties via the SQL profile repository item. For example, you can add an ldapUser property to the SQL repository’s user item descriptor. Then, if your LDAP profile has an email property, you can refer to it in a JHTML page as follows:
<valueof bean="/atg/userprofiling/Profile.ldapUser.email">
Furthermore, the SQL repository can be set up so that when a new SQL profile item is created, updated, or deleted, the corresponding LDAP item is created, updated, or deleted automatically. This technique essentially allows you to treat the profile data stored in both the SQL and LDAP repositories as a single profile object.
The Linking Repositories section of the SQL Repositories chapter in the ATG Repository Guide describes how repository linking can be accomplished by storing the repository ID of the linked repository item as the value of the linked property in the database. This kind of explicit linking relies on the fact that the ID of the linked item does not change over time. However, this may not always be the case in an LDAP repository, which uses a directory entry’s DN (Distinguished Name) as its repository ID. Furthermore, explicit linking does not provide for an easy way to authenticate users through the linked LDAP repository.
With implicit repository linking, the SQL repository item does not store the ID of the linked item in the database; instead, the linking is performed dynamically, through code. This is accomplished by requiring that the linked profile items share a property that uniquely identifies them in both repositories. Typically, you would use a property such as login or email. For example, if both the SQL and LDAP profiles have a login property, a SQL profile is linked to an LDAP profile whose login property value is the same as the SQL profile’s login value.
Implicit linking is managed by the package atg.repository.linked. The ldapUser property, which links the two repositories in the example above, is defined in the SQL profile template as a user-defined property type atg.repository.linked.RepositoryLinkPropertyDescriptor (see the User-Defined Property Types section of the SQL Repositories chapter in the ATG Repository Guide for an explanation of user-defined property types). The RepositoryLinkPropertyDescriptor class contains the logic that links the two items together; it performs a repository query to obtain the LDAP item corresponding to the given SQL item.
The main limitation of the repository linking approach to combining SQL and LDAP profiles is that the ldapUser property is not queryable. Thus, the queries you perform against the SQL repository cannot include any of the LDAP properties. For example, if the lastName property is stored in LDAP, you cannot execute a query against the SQL repository to find all users with last name Smith. If you are using the Scenarios module, one consequence is that you cannot have scenarios that perform queries against LDAP properties. For example, you cannot have a scenario that finds all users with the last name Smith and then sends email to them.
In addition, the HTML profile administration interface is not sophisticated enough to handle these kinds of composite profiles, so you cannot use it to create users or to search for or edit their LDAP properties. However, you can still use the Business Control Center or the ACC to accomplish these tasks.
