Map LDAP Entries to Uniface Entities

You cannot use the database import facility with LDAP, so you must manually define a model that maps LDAP entries to Uniface entities.

All entries in an LDAP directory have at least one objectclass value. An objectclass declares that an entry contains a set of fields, and so corresponds to a table definition.

The LDAP protocol does not include table definitions, so entities cannot be mapped directly to data on an LDAP server. Instead, use search profiles that behave the same way as a table definition. A Uniface entity is directed to specific data on an LDAP server by using a u_where statement.

If you want to create new entries in the LDAP directory, you need to ensure that all mandatory attributes are defined as fields in your entity definition. For example, the attribute objectclass is always required because the LDAP server needs to know the type of entry you are creating.

Depending on the value of the objectclass attribute, other attributes may also become mandatory. The values stored for these attributes must correspond to what is expected of an entry belonging to the specified objectclass, otherwise the store will fail with the error: 

"Objectclass violation"

To map LDAP entries to Uniface entities:

  1. Define an entity in the application model with field definitions corresponding to field definitions in the target object class.

    All the data in LDAP is accessible as string data. You can only specify string fields because you cannot access binary data, such as images.

  2. Use the entry name as the primary key.
  3. Add a readu_where instruction to appropriate triggers the ProcScript, using an objectclass to restrict the search profile. 
    read u_where objectclass = "NameOfObjectclass"

    Always use an objectclass to restrict the search profile, bearing the following in mind:

    • objectclass definitions are maintained on the LDAP server, and can differ between servers.
    • The objectclass field can contain more than one value.
    • LDAP does not store table definitions, and cannot recognize relationships between entries. Thus any entry containing the primary key field is retrieved, including data from other objectclass types.
    • Only fields defined in the entity are retrieved. The entries on the LDAP server can contain many other fields that are not retrieved.
    • If the data is always retrieved from an LDAP source, it can be advantageous to include the u_where clause in the entity definition.

For example, the illustration shows the field definitions for UNIQUENAMES, an entity targeted at data with the objectclassgroupofuniquenames:

Field Definitions for the Entity UNIQUENAMES

Graphical content.

CN is the primary key, so by default the retrieve statement retrieves all entries in the LDAP database with a CN field.

To ensure that only groupofuniquenames data is retrieved, include a u_where clause as follows in all appropriate read triggers.

read u_where objectclass = "groupofuniquenames"

Related Topics