Le serveur LDAP eDirectory prend en charge le regroupement de plusieurs opérations de mise à jour en une seule opération atomique, également appelée transaction. Dans eDirectory, la prise en charge de transactions via le protocole LDAP est basée sur deux spécifications Internet : LDAP Transactions (Transactions LDAP) et LDAP: Grouping of Related Operations (LDAP : Regroupement d'opérations associées).
Les transactions LDAP permettent à une application LDAP d'envoyer plusieurs opérations de mise à jour LDAP (ajouter, modifier, supprimer, renommer) en tant que groupe, puis de valider ou d'abandonner ce groupe d'opérations.
Il existe quelques entités qui figurent dans le contexte des transactions LDAP :
CreateGroupingRequest ( 2.16.840.1.113719.1.27.103.1 ) : opération étendue LDAP qui permet de regrouper des opérations associées. L'opération étendue comporte une valeur : createGroupType qui identifie le type de regroupement demandé. Pour les transactions LDAP, le type de regroupement est transactionGroupingType. ( 2.16.840.1.113719.1.27.103.8)
CreateGroupingResponse ( 2.16.840.1.113719.1.27.103.1 ) : réponse du serveur LDAP à la requête createGroupingRequest qui contient 2 champs de réponse groupCookie et createGroupValue (ce dernier étant facultatif).
GroupingControl ( 2.16.840.1.113719.1.27.103.7 ) : sert à indiquer l'association d'une opération à un groupe via groupCookie qui est la valeur associée à ce contrôle.
EndGroupingRequest ( 2.16.840.1.113719.1.27.103.2 ) : autre opération étendue LDAP qui permet d'indiquer la fin d'une requête de regroupement. En cas de transactions LDAP, cette opération indique l'issue de la transaction : validation ou annulation.
EndGroupingResponse ( 2.16.840.1.113719.1.27.103.2 ) : réponse du serveur LDAP à la réponse endGroupingResponse indiquant le succès ou l'échec au client LDAP.
Voici l'ordre des requêtes et des réponses échangées entre le serveur LDAP et le client LDAP dans le cadre d'une transaction LDAP :
Si un client souhaite envoyer plusieurs opérations LDAP devant être traitées par un serveur dans le cadre d'une opération atomique, autrement dit une transaction, il doit d'abord envoyer une requête createGroupingRequest, avec un type createGroupType de type transactionGroupingType et sans valeur createGroupValue.
Si le serveur eDirectory est en mesure de traiter les transactions, il renvoie un code de résultat de réussite, avec un cookie groupingCookie qui identifie de manière unique le regroupement demandé par le client. Dans le cas contraire, le serveur renvoie un code de résultat d'échec précisant la raison au client.
Si le client reçoit un code de résultat de réussite du serveur, il joint ensuite un contrôle GroupingControl, qui inclut le cookie groupingCookie renvoyé par le serveur, aux opérations de mise à jour suivantes pour indiquer qu'elles doivent être traitées dans le cadre d'une même transaction. Si le serveur est prêt et en mesure de traiter l'opération de mise à jour dans le cadre de la transaction, il renvoie un code de réussite et place cette requête dans une file d'attente. Si le serveur n'est pas prêt ou en mesure de traiter l'opération de mise à jour dans le cadre de la transaction, il renvoie un code de résultat d'échec indiquant la raison au client.
Une fois que le client a envoyé à toutes les opérations de mise à jour accompagnées du contrôle de regroupement au serveur, il envoie une requête endGroupingRequest avec le cookie groupingCookie au serveur pour indiquer qu'il souhaite finaliser la transaction. L'absence de valeur endGroupValue indique une requête de validation, la présence d'une valeur endGroupValue vide indique une requête d'annulation.
Le serveur applique toutes les opérations en attente dans le cadre d'une seule transaction. En cas de réussite, il renvoie un code de réussite. Dans le cas contraire, il renvoie un code de résultat d'échec.
Si, à un moment donné au cours de l'échange ci-dessus entre le client et le serveur, le serveur n'est pas prêt ou en mesure de continuer la spécification d'une transaction, il émet une notification endGroupingNotice ( 2.16.840.1.113719.1.27.103.4 ). L'utilisation ultérieure d'un cookie par le client entraîne une réponse contenant un code de résultat d'échec.
La prise en charge de transactions LDAP est indiquée par la présence du type transactionGroupingType dans l'attribut supportedGroupingTypes de l'entrée rootDSE.
La mise en oeuvre des transactions LDAP dans eDirectory est basée sur une version datée de la spécification de transaction LDAP. Au moment de la rédaction du présent guide, la dernière révision du projet de document relatif aux transactions LDAP est disponible sur la page « Lightweight Directory Access Protocol (LDAP) Transactions » (Transactions LDAP).
La fonctionnalité de transactions LDAP présente les limites suivantes :
Tous les objets concernés par les opérations regroupées dans le cadre d'une transaction doivent être hébergés localement sur le serveur. Aucune de ces opérations ne doit exiger un chaînage du serveur LDAP sur un autre serveur.
Les modifications de schéma et l'opération de modification de DN (déplacement de sous-arborescence ?) ne peuvent pas être regroupées en une transaction LDAP.
Les mots de passe et les attributs avec syntaxe de flux ne peuvent pas être ajoutés dans le cadre d'une transaction LDAP.
L'imbrication d'une transaction dans une autre n'est pas prise en charge.