The idMatching query is a special case. The LDAP search filter can only search for entries based on their attribute values. However, the LDAP repository uses the entry’s DN, rather than any attribute value, as its ID. Thus, ID matching queries cannot be constructed with search filters, unless the LDAP entry’s DN is also an LDAP attribute.

To implement ID matching queries, add an ID attribute to the LDAP entries, as described earlier in Id and ObjectClasses Properties. In this example, all user LDAP entries have an attribute called dpsid, which is mapped to the repository item’s id attribute. The value of dpsid is automatically set to the DN when the item is first added to the repository. Because the ID can now be accessed as an attribute of an LDAP entry, full support for the ID matching query is provided in this case. Note, however, that directory entries that were not created by the repository must be manually modified to include a dpsid attribute, or they are not returned by the queries on the view.

If no ID attribute exists in the LDAP entries, the ID matching query is only supported as the top level query. That is, you can have a targeting rule that matches only items with specified IDs, but you cannot have a rule that matches items with specified IDs and satisfies some other criteria. The top level query is implemented by simply calling Repository.getItems with the specified IDs. No checking is done to verify that the resulting items are actually contained by the view. Oracle ATG Web Commerce does not check that they have the correct object classes, and are located inside one of the search roots.