Configuration OpenLDAP Documentum 6.5

De EjnTricks
Révision de 15 avril 2012 à 22:23 par Etienne (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Cet article va permettre d'étudier la mise en place de OpenLDAP sur un serveur Documentum en version 6.5, suite à l'erreur constatée lors de la tentative de création, voir Configuration OpenLDAP Documentum. Les sources de cette analyse sont disponible sur http://www.jouvinio.net/svn/study/branches/documentum/6.5_SP1/Server/dmldap/

Synchronisation des utilisateurs

Une fois la configuration de LDAP réalisée sur OpenLDAP, il est nécessaire de modifier le job de synchronisation. En effet, malgré la bonne configuration, des erreurs se produisent.

Etude Job

La synchronisation s'effectue par le job dm_LDAPSynchronization qui va exécutée la méthode du même nom.

DQL> select dm_method.object_name as methodname, dm_method.method_verb, dm_job.object_name as jobname
from dm_method, dm_job
where dm_job.object_name = 'dm_LDAPSynchronization' and dm_job.method_name = dm_method.object_name;

methodname                method_verb                     jobname                                                                                                                                                                                                                                                          
======================    ============================    =======================

dm_LDAPSynchronization    com.documentum.ldap.LDAPSync    dm_LDAPSynchronization

Le contenu de cette méthode serveur se trouve dans le fichier dmldap.jar déployé sur le serveur de méthode.


Etude Méthode

L'annuaire OpenLDAP étant configuré comme un annuaire Sun, la classe com.documentum.ldap.internal.processors.com.documentum.ldap.internal.processors sera instanciée lors de la création du processeur depuis l'instance de com.documentum.ldap.internal.processors.DirectoryProcessorFactory. Cette instance est créée depuis la méthode prepareSync de la classe com.documentum.ldap.LDAPSync.

Ce processeur est alors utilisé lors de la synchronisation des groupes et/ou utilisateurs. Lors de l'appel de la fonction createDirectoryProcessor, sur l'instance de DirectoryProcessorFactory, une instance de SunDirectoryProcessor est retournée.

Or l'analyse de cette classe permet d'identifier l'origine de l'erreur. Lors du traitement d'un objet de l'annuaire, la référence unique est recherchée depuis la fonction getUniqueId, retournant la valeur de la propriété nsuniqueid. Or cette valeur n'est pas présente sous OpenLDAP.


Mise en place du patch

La solution consiste donc à modifier le comportement de la fonction getUniqueId afin de retourner une propriété autre que nsuniqueid. Afin d'apporter un peu de généricité, la valeur retournée sera mise en place dans un fichier de configuration, permettant ainsi d'adapter en fonction des déploiements.

De plus, la fonction est appelée aussi bien pour les groupes que pour les utilisateurs. Or, il est probable que la propriété soit différente pour ces deux types d'information.

Une classe est mise en place pour gérer la lecture des fichiers de configurations et exposer les méthodes:

  • getUniqueAttrGroup: Nom de la propriété pour l'identifiant unique des groupes.
  • getUniqueAttrUser: Nom de la propriété pour l'identifiant unique des utilisateurs.

Cette classe implémente l'interface DefaultConfig.

Deux fichiers de configuration sont donc chargés. Les mécanismes déjà en place, à partir de la classe com.documentum.ldap.internal.utils.LDAPResourceBundle sont utilisés. Cependant, cette classe ayant une visibilité interne au paquet, elle est difficilement utilisable par l'extension. Il est donc nécessaire de mettre en place une nouvelle classe, dans le même paquet, donnant un accès aux méthodes souhaitées.


Le premier fichier de configuration fr.amexio.documentum.ldap.config.impl.LdapDefaultConfigBundle.properties est utilisé pour les messages affichés dans la log.

Le second fichier de configuration fr.amexio.documentum.ldap.config.impl.openldap_config.properties est utilisé pour paramétrer les deux propriétés contenant l'identifiant unique des objets.


Le nouveau processeur mis en place, classe SunDirectoryProcessorPatched, ne fait qu'étendre le code standard. A noter que la méthode dumpConfig est également surchargée pour annuler le traitement. En effet, celle-ci ne fait qu'afficher dans la log des informations sur le schéma LDAP. Or, celles-ci sont récupérées depuis l'objet cn=config qui peut ne pas exister.

Dans le constructeur de l'extension, un chargement de la classe DefaultConfigImpl est réalisée, entraînant la lecture des configurations. Ainsi, dans la fonction getUniqueId, il est possible de récupérer la valeur de la propriété souhaitée.


La dernière modification concerne la classe com.documentum.ldap.internal.processors.DirectoryProcessorFactory. Malheureusement, celle-ci est un singleton et n'offre aucune possibilité de surcharge. Elle est donc réécrite entièrement afin de prendre en compte la nouvelle instance du processeur.

Enfin, il faut injecter toutes ces classes dans le fichier dmldap.jar et relancer le serveur de méthode.