If you are using the OVD Shadow Joiner feature then you will need to add the vdeShadowObject object class to the directory hosting the shadow objects. Here is a little LDIF file for just such a need...

# Description: contains vdeshadowobject vdeprimaryref for use with shadow joiners
#
dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.17119.1.0.1 NAME 'vdeprimaryref' DESC 'This attribute contains an MD5 hash of a primary adapter' EQUALITY 'caseIgnoreMatch' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' X-ORIGIN 'user defined' )
-

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: vdeprimaryref
-

# ObjectClass Definitions
dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.17119.1.1.1 NAME 'vdeShadowObject' DESC 'This object is used by VDE Shadow Joiner to store a shadow object to a primary entry in another directory. This objectclass normally used in conjunction with the extensibleObject object class to hold local attributes. vdeprimaryref is a hash of a DN that points to a primary object in an alternate adapter.' SUP top AUXILIARY MUST ( vdeprimaryref ) MAY ( description ) )
-

Labels: OVD, Shadow Join

What if you want to include a virtual attribute in your search results that is derived form another attribute? Just create the attribute in an outbound mapper flow and add it to the search results and it should show up as expected - right? Well, maybe it will and maybe it won't; if the attribute(s) the derived value is based on is/are in the search results too then it will show up as anticipated. However, if they are not there then it won't show up as expected.

The solution is to use the OVD addReturnAttribute delivered mapper function on the reciprocal inbound request with the required source attributes. This will allow the outbound mapper to have the required data to complete the derived attribute and enable the OAM search result configuration to exist without the source attributes.

Labels: Mapper, OAM Search Results, OVD

Creating a mapping file for OVD to use on inbound and/or outbound LDAP transactions can sometimes be tricky to get absolutely correct the first time. Invariably, the message

Could not complete mapping

is bound to show up at least once when you are trying something new.

When a mapping file is broken it can cause a variety of problems, but most notably if your adapters for authentication are using other unrelated mappers it can cause them to fail, resulting in failed authentication. So for instance if you are working on a mapper for one object you could prevent other users from authenticating. This pitfall can be easily avoided, however, using the OVD Filters to Exclude and Filters to Include fields on the routing tab of the adapters tab in OVD Manager. For instance by exluding (objectclass=inetorgperson) from an adapter that presents site data you can prevent an authentication search request from even attempting the adapter, thus insulating you and other development users from such a problem.

However, what if you cannot authenticate to the OVD Manager console to correct a broken mapper or add a routing filter to an adapter? I had one case where I could not authenticate even as cn=admin do the OVD Manager becuase of a broken adapter. The solution to this is simple; just remove the compiled mapper jar file from the OVD Server directory. You can do so by following these steps:

1. stop ovd
2. remove bad mapper ($VDE_DIR/mappings/jars/offendingMappingFile.jar)
3. start ovd
4. log into the OVD Manager and fix the source of the problem
   

Labels: Mapper, OAM, OVD