1.7 eDirectory Event System

The eDirectory Event System provides a way for applications to monitor the activity of eDirectory on an individual server over LDAP. LDAP Event Services are available on eDirectory 8.7.

For additional information on the eDirectory Event System and for a complete listing of LDAP events, see LDAP Event Services in the "LDAP and eDirectory Integration Guide."

1.7.1 Registering to Monitor an Event

The LDAP Libraries for C provide functions to simplify registering to recieve event data. To register to monitor an event, you call the ldap_monitor_events or ldap_monitor_events_filtered function passing an array of EVT_EventSpecifier or EVT_FilteredEventSpecifier structures specifying the events you wish to monitor, and an event filter if calling ldap_monitor_events_filtered.

These functions send a MonitorEventRequest or FilteredMonitorEventRequest extended operation to the server. The request is sent asynchronously; it does not wait for a response from the server. The functions return the constant LDAP_SUCCESS if the request was successfully sent, or another LDAP result code if not.

After a successful call to ldap_monitor_events or ldap_monitor_events_filtered, server responses to the EventMonitorRequest are retrieved by calling the ldap_result function. If the return value of ldap_result is equal to LDAP_RES_EXTENDED, it indicates than an error or exceptional situation occured and events are not monitored. The result is parsed by calling the ldap_parse_monitor_events_response. If the return value of ldap_result is equal to LDAP_RES_INTERMEDIATE it indicates that an event has occured. The result should be parsed by calling ldap_parse_ds_event.

Memory allocated by the ldap_parse_monitor_events_response and the ldap_parse_ds_event functions must be freed by the application by calling the ldap_event_free.

For an example, see monitorevents.c

Filtered Event Monitoring

Filtered event monitoring enables you to limit the events returned to your application by the server, possibly reducing network traffic and processing in your application.

See ldap_monitor_events_filtered for additional information.

1.7.2 LBURP

The LDAP Bulk Update/Replication Protocol (LBURP) is used to send asynchronous requests to an LDAP server. This guarantees that the requests are processed in the order specified by the protocol and not in an arbitrary order influenced by multiprocessor interactions or the operating system’s scheduler. LBURP also lets the client send several update operations in a single request and receive the response for all of those update operations in a single response. This adds to the network efficiency of the protocol.

LBURP works as follows:

  1. The client to an LDAP server.

  2. The server sends a bind response to the client.

  3. The client sends a start LBURP extended request to the server.

  4. The server sends a start LBURP extended response to the client.

  5. The client sends zero or more LBURP operation extended requests to the server.

    These requests can be sent asynchronously. Each request contains a sequence number identifying the order of this request relative to other requests sent by the client over the same connection. Each request also contains at least one LDAP update operation.

  6. The server processes each of the LBURP operation extended requests in the order specified by the sequence number and sends an LBURP operation extended response for each request.

  7. After all of the updates have been sent to the server, the client sends an end LBURP extended request to the server.

  8. The server sends an end LBURP extended response to the client.

The LBURP processor in eDirectory also commits update operations to the database in groups to gain further efficiency in processing the update operations. LBURP can greatly improve the efficiency of your LDIF imports over a traditional synchronous approach.