Here is a summary of a common deployment scenario with Sun Directory Proxy Server:
LDAP entries are grouped by location in the DIT, e.g user entries are located under
ou=north,ou=people,dc=company, dc=com or
ou=south,ou=people,dc=company, dc=com or ou=east,ou=people,dc=company, dc=com or ou=west,ou=people,dc=company, dc=com based on user physical location.
Later, for sake of simplicity, the DIT is flatten so that every user entry is stored immediatly under ou=people, dc=company, dc=com
New applications are aware of the DIT structure change but DPS is used so that legacy applications expecting the location container node can operate w/o problem.
The dn mapping needed can be achieved by using virtual data transformations as described in http://docs.sun.com/app/docs/doc/820-2765/virtual_transformations?a=view
Let's assume that
- you have a data view DV1 with viewBase (suffix) set to dc=company,dc=com.
- entry location (north, east,...) is always available in each entry in attribute 'location'
- entry uid=*,ou=(north|south|east|west),ou=people,dc=company,dc=com mapped to uid=*,ou=people,dc=company,dc=com
You have to create a virtual data transformation on the 'dn' for data view DV1. For inbound traffic (requests), the proxy must get rid of the ou=(north|south|east|west) node. For outbound traffic (responses), the proxy gerenates a (fake) ou=(north|south|east|west) from the content of the 'location' attribute of each entry.
Here is the dpconf command to do that:
dpconf add-virtual-transformation -h <host> -p <port> -d <proxy manager> DV1 mapping attr-value-mapping dn internal-value:uid=\${uid},ou=people view-value:uid=\${uid},ou=\${location},ou=people
Note: you might have to escape some characters (e.g $) in the command
below depending on the command interpreter you are using. In the
example above, I used \$ instead of plain $.
Note2: dn patterns used in virtual transformations must not contain the
data view viewBase (dc=company,dc=com in this case) as it is implicit.