Transformation Models

The transformation model is determined by the direction of a transformation, in other words, whether the transformation is applied during the request, during the response, or both.

In this sense, transformations can be categorized into the following types:

• Mapping transformations (bidirectional transformations)

• Write transformations (inbound transformations)

• Read transformations (outbound transformations)

Mapping Transformations

The most common transformation is a bidirectional (mapping) transformation. A mapping transformation is applied during the request, and its inverse is applied during the response. These transformations are called mappings because in effect, an attribute or entry in the physical data view maps to an attribute or entry in the virtual data view. Mapping transformations enable you to process existing values before assigning them to a DN component, an attribute type or value, or an object class.

The following diagram illustrates the principals of a mapping transformation.

Figure 18–2 Mapping Transformation

A mapping transformation is defined on a data view, by running the dpconf command as follows:

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name mapping action attr-name [parameters]

Example 18–1 When Would You Use a Mapping Transformation?

Imagine, for example, an organization has a physical data source that contains entries with the attributes surname and givename. The organization has a client application that requires entries to have a cn (common name) attribute of the form givenname surname.

The client application sends a search request for an entry of the form cn=Carlos Fuentes. A transformation is defined that extracts the name and surname during this request and transforms the request to one of the form surname=Fuentes, givenname=Carlos. The corresponding entry is located in the data source. Before returning this entry to the client application, the inverse transformation is performed. The client application receives the entry as cn=Carlos Fuentes, which it understands.

This request is transformed to be of the form surname=Fuentes, givenname=Carlos. Similarly, the client application sends a modify request to change the cn attribute of an entry to Lisa Davis. The request is transformed so that the givenname attribute of the physical entry is modified to Lisa and the surname attribute is modified to Davis.

Write Transformations

A write transformation is applied during the request, but not during the response. A write transformation changes the physical data in storage.

The following diagram illustrates the principals of a write transformation.

Figure 18–3 Write Transformation

A write transformation is defined on a data view, by using the dpconf command as follows:

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name write action attr-name [parameters]

Example 18–2 When Would You Use a Write Transformation

Imagine an organization has a legacy application whose function is to add person entries to a data source. The application adds the entries without the telephoneNumber attribute. The physical data source has been upgraded and the telephoneNumber is now a mandatory attribute for person entries. The transformation required here is to add the telephoneNumber attribute during the add request. This transformation changes the entry that is written to the database. No reverse transformation is required.

Read Transformations

A read transformation is applied only during the response to a request. No transformation is applied during the request and the physical data is not changed.

The following diagram illustrates the principals of a read transformation.

Figure 18–4 Read Transformation

A read transformation is defined on a data view, by using the dpconf command as follows:

$ dpconf add-virtual-transformation -h host -p port -D bindDN /
view-name read action attr-name parameters

Example 18–3 When Would You Use a Read Transformation

Imagine an organization has a legacy application whose function is to display person entries. The application does not support entries that do not contain a mail attribute. The physical data source has been upgraded and the email attribute no longer exists for person entries (e-mail addresses are constructed using other attributes).

The transformation required here is to add the mail attribute during the search response. This transformation changes the entry that is read from the database and adds a mail attribute whose value is givenname.surname@example.com. No reverse transformation is required and the physical data is not changed.

Note that with the above transformation, the mail attribute makes no sense in a search request filter. Search request filters must contain physical attributes.