This section is not applicable to this feature.

The notifications feature works on a Distribution Entry (DE) basis to provide information about changes in the attribute data stored in entries below the DEs in the Lightweight Directory Access Protocol (LDAP) tree. In other words, it reports modifications of data stored in the Data Store (DS) layer of a certain DE or set of DEs.

Figure 1 shows the notifications module, its components, and relationships with other CUDB modules and external FEs.

The notifications module subscribes to the database events to monitor attribute changes, check for certain attribute values, and retrieve attribute contents to build the notifications.

Notifications to applications are sent as Simple Object Access Protocol (SOAP) messages over Hypertext Transfer Protocol (HTTP). CUDB acts as the SOAP client and the applications FEs act as the SOAP servers (referred to as endpoints from now on). For more information on the CUDB SOAP interface, refer to CUDB SOAP Interwork Description.

Use of Transport Layer Security (TLS) key and certificate is also possible in the SOAP interface. For more information on security in CUDB, refer to CUDB Security and Privacy Management.

The notifications feature has the following configuration options:

• It is possible to configure the data to be monitored for change, the data whose value must be checked before sending notifications, as well as the data sent into a notification.

• It is possible to configure several different notification types in parallel for the same or different applications FEs.

• It is possible to configure some feature behavior parameters, such as the destination of each notification message to be sent.

The parameters above are configured through the CUDB configuration Command Line Interface (CLI).

The notifications module is deployed in all payloads. However, only two instances run in active-standby model. The rest of the instances are waiting to enter in standby mode in case one of the active-standby instances fail. The active entity monitors the database events to be notified by subscribing to the master replicas of the DSGs hosted by the CUDB node. When the active entity fails, the standby entity becomes active and monitors the events instead of the active. For more information on high availability, refer to CUDB High Availability.

The module gathers internal statistics on failed and successful operations. These statistics are downloaded to counters, which are managed by the Ericsson Simple Network Management Protocol (SNMP) Agent (ESA). Additionally, the module produces logging information about the performed operations and the operation errors.

The notifications feature has the following three types of attributes:

• Monitored: triggers the processing of a notification when changes are made in tracked data in the database.

  A notification will be sent in the following cases:

  1. There is a change in the value of at least one monitored attribute in an entry that matches the specified dn/rdn in the Notification Event configuration.

  2. After the Checked and Related configuration is evaluated successfully.

  The way rdn/dn information is specified in the configuration allows monitoring single entries (fixed rdn) or a group of entries that matches a dn pattern regular expression (full dn with Portable Operating System Interface (POSIX) regular expressions).

  Note:

  To trigger the processing of the notification, all of the configured monitored attributes must refer to the same LDAP entry or set of LDAP entries matching the regular expression which was specified in the CUDB Notification Event configuration. Moreover, it is possible to monitor the creation or deletion of whole entries by using the monitorAll option (see Notifications Parameters for further information).

  The following database events are considered as attribute changes:

  • Changing an attribute value to other than the previous one.

  • In non-multi-valued attributes, changing from no-value (null in the database) to a specific value.

  • In non-multi-valued attributes not using the monitorAll option, changing from a specific value to no-value (null in the database), except if the object class containing the attribute is not removed. If the object class was deleted, this event is not considered as an attribute change.

  • In non-multi-valued attributes using the monitorAll option, changing from a specific value to no-value (null in the database).

  • In multi-valued attributes, when at least one value is added to or deleted from the attribute, or when all the values from the attribute are replaced with a new value.

• Checked: A notification is sent if at least one of the attributes has a certain and configured value, which must be different from no-value. Multi-valued attributes are not allowed to be checked.

• Related: The attributes to be included in the notification message. The notification is sent if the attributes are defined in the database and have a value (that is, if they are not null). When a multi-valued attribute is included in a notification, all the values currently held in the attribute are sent in it.

It is possible to define as many notifications as needed, but each one of them must have at least one monitored attribute. A notification is triggered if a monitored attribute changes and if the checked attributes (if defined) fulfills the comparison condition. All the attributes included in the notification are related to the same DE, as the feature is DE-based. Preconfigured Notifications shows an example of a notification definition.

A list of notification endpoints is also defined per notification. Each endpoint is characterized by a certain weight, which determines how often it receives notifications. Endpoints having a weight different from zero are included in a Weighted Round Robin (WRR) algorithm. This means, for example, if three endpoints (EP1, EP2 and EP3) are defined, each having weights 4, 2 and 1 respectively, then EP1 receives twice the number of notifications than EP2, and four times the number of notifications than EP3. On the other hand, if an endpoint has weight=0 set, it is excluded from the WRR algorithm and receives all of the notifications. Therefore, all the endpoints with weight=0 receive notifications in a broadcast. The order of WRR endpoints where notifications are being sent to is equal with the configuration order of the WRR endpoints in the configuration model.

The notifications module works in an autonomous way in the CUDB system and does not interfere with the LDAP traffic operations performed by the system up to the characterized performance limits. However, the following limitations in the feature and interactions with other features must be considered:

• In general, only binary content up to 4 KB is supported. Only string and integer attributes are supported in notifications (for more information about mapping LDAP to internal database types, refer to the related table in CUDB Application Integration Guide). OctetString attributes are supported with the following limitations:

  • For monitor and related attributes, OctetString binary attributes up to 4 KB are supported.

  • For check attributes, OctetString binary attributes up to 1530 bytes are supported.

  • OctetString attributes greater than 4 KB are specifically not supported in any case.

• Depending on the feature configuration, unexpected notifications can be received during CUDB maintenance tasks, such as backup and restore operations and reallocation and reconciliation procedures because of deletion and creation of DEs in the database.

• PL data is not supported. The feature is limited to work with data stored in the DS only.

• In monitored attributes, changing from no-value (null in the database) to a specific value is considered a change.

• In monitored attributes, changing from a specific value to no-value is considered a change, except when the object class containing the attribute is also removed.

• Multi-valued attributes are not allowed to be included as checked values in the notifications.

• CUDB sends one notification message per LDAP operation that cause a change of any of the monitored attributes. However, consecutive LDAP modify operations received by CUDB within a very short period of time (about 1 second) over the same LDAP entry can be managed as only one LDAP operation according to the notifications feature. This sends just one notification message for all the modifications instead one per LDAP operation. In this case, the data in such notification message can contain inaccurate information in the sent multi-valued attributes.

• Operational attributes (entryDS, structuralObjectClass, createTimestamp, modifyTimestamp) are not supported in notifications.

• It is possible that the notification-related software processes show a high memory consumption. However, this situation is very unlikely, as it requires certain conditions to happen simultaneously, such as many notification events configured, high notifications rate and several notification endpoints showing a slow response time.

• The maximum number of available TCP connections towards the notifications endpoints is 1000. This must be taken into account as an upper limit when configuring the Notifications feature. The number of needed TCP connections (numOfConnections) is calculated as follows:

  numOfConnections = numConnectionsEvent1 + numConnectionsEvent2 + numConnectionsEvent3 + …

  where numConnectionsEvent<X> is the number of TCP connections needed per each defined CudbNotificationEvent.

  Also, numConnectionsEvent<X> is calculated as follows:

  numConnectionsEvent<X> = numberOfEndpoints<X> * numberOfSoapThreads<X>

  where numberOfSoapThreads<X> is the number of SOAP threads and numberOfEndPoints<X> is the number of endpoints defined for CudbNotificationEvent<X>. For information on both multiplication factors, for each CudbNotificationEvent, refer to CUDB Node Configuration Data Model Description.

  See the examples below for three notification events defined with the following parameters:

  • CudbNotificationEvent<1>: 20 SOAP threads and 4 endpoints

  • CudbNotificationEvent<2>: 30 SOAP threads and 2 endpoints

  • CudbNotificationEvent<3>: 40 SOAP threads and 1 endpoint

  numOfConnections = 20*4 + 30*2 + 40*1 = 80 + 60 + 40 = 180 TCP connections

• When Data Repair is invoked, it may perform modifications to LDAP entries. In such case, notifications will be sent just like as if the modification had been performed by a node external to CUDB, such as by PG or any application FE.

  Furthermore, there are some limitations about the lost notifications when the active instance dies. This loss is due to:

• AMF Switchover time.

• Time to initialize the process and the NDB subscription.

• Internal queues of the process.

• Consecutive LDAP insert and delete operations, received by CUDB within a very short period of time and over the same LDAP entry that is also being monitored, can result in getting an error for the delete LDAP operation.

This section describes the activation of the notifications feature.

The notifications module is configured by a set of classes and attributes defined in the CUDB configuration model to provide the feature configuration options.

This feature triggers the following alarms:

• SOAP Notifications, Discarded Notifications, refer to SOAP Notifications, Discarded Notifications.

• SOAP Notifications, Endpoint Unreachable, refer to SOAP Notifications, Endpoint Unreachable.

For more information on counters managed by the notifications module, refer to CUDB Counters List.

It is possible to configure a TLS key and certification in the SOAP interface. For detailed information about security related parameters and security configuration, refer to CUDB Security and Privacy Management.

For more information on the log messages generated by the notifications module, refer to CUDB Node Logging Events.