Recherche des entités modifiées

Utilisez la méthode search(DataObject) et l'objet de données ChangeControl pour rechercher dans le référentiel fédéré les entités modifiées à partir d'un certain point de contrôle.

A propos de cette tâche

L'objet de données ChangeControl différencie la recherche des entités modifiées d'une opération de recherche normale. Chaque entité renvoyée comme résultat de la recherche est associée à la propriété changeType.

La propriété changeType de l'objet de données Entity est une propriété facultative définie uniquement en réponse à une recherche d'entités modifiées. La propriété changeType décrit le type de modification effectuée (ajout d'une nouvelle entité, modification d'une entité existante, suppression d'une entité ou modification du nom d'une entité).

Les valeurs valides et les constantes de type chaîne de la propriété changeType sont add (pour CHANGETYPE_ADD), delete (pour CHANGETYPE_DELETE), modify (pour CHANGETYPE_MODIFY) et rename (pour CHANGETYPE_RENAME).

Pour les entités ajoutées, modifiées et renommées, l'entité actuelle dans le référentiel est renvoyée. Pour les entités supprimées, seul l'identificateur d'entité, comprenant le nom externe et le nom unique est renvoyé. (Dans IBM® Tivoli Directory Server version 6.1 et les versions antérieures, l'identificateur unique universel spécifique au référentiel n'est pas renvoyé comme partie intégrante de l'identificateur d'entité, tandis que dans IBM Tivoli Directory Server version 6.2 et les versions ultérieures, l'identificateur d'entité inclut l'identificateur unique universel spécifique au référentiel, ainsi que le nom externe et le nom unique.) Le point de contrôle du référentiel ne tient pas compte des types de modification et de la base de recherche. Le point de contrôle s'applique à l'ensemble du référentiel.

Pour éviter de transmettre un contrôle de modification à un adaptateur qui ne peut pas le gérer, chaque ID référentiel du fichier wimconfig.xml est associé à une propriété appelée supportChangeLog. Les valeurs valides de la propriété supportChangeLog sont les suivantes :
  • none : indique que le suivi des modifications n'est pas pris en charge pour ce référentiel. Il s'agit de la valeur par défaut si supportChangeLog n'est pas défini.
  • native - Indique que virtual member manager utilise le mécanisme de suivi des modifications natif du référentiel pour renvoyer les entités modifiées.
Le gestionnaire de profils fait référence à cette valeur avant de transmettre la demande à l'adaptateur correspondant. Si la valeur de supportChangeLog est none, ce référentiel n'est pas appelé pour extraire les entités modifiées. Vous pouvez utiliser les commandes wsadmin createIdMgrLDAPRepository, updateIdMgrLDAPRepository ou updateIdMgrRepository pour définir la propriété supportChangeLog. Pour plus d'informations sur ces commandes, voir la rubrique Groupe de commandes IdMgrRepositoryConfig pour l'objet AdminTask.
Les référentiels suivants sont pris en charge pour l'adaptateur LDAP :
  • IBM Tivoli Directory Server
  • Active directory
Important : Avant de rechercher les entités modifiées dans un adaptateur prenant en charge cette fonction, vérifiez que la fonction de suivi des modifications du référentiel est activée. Par exemple, pour activer le suivi des modifications pour IBM Tivoli Directory Server, reportez-vous à la rubrique Server Utilities, idscfgchglg dans le centre de documentation d'IBM Tivoli Directory Server.

Pour IBM Tivoli Directory Server, assurez-vous également que le correctif de l'APAR (Authorized Program Analysis Report) 1IO10107 est installé.

Modèles de graphiques de données d'entrée et de sortie

Etudions un scénario où une application virtual member manager est configurée avec trois référentiels : IBM Tivoli Directory Server, Active Directory et un référentiel de fichiers. Lorsque l'application est synchronisée avec virtual member manager, le point de contrôle est extrait et sauvegardé. Ce point de contrôle sauvegardé est utilisé dans le contrôle de modification au cours du prochain intervalle de synchronisation. L'exemple de code suivant extrait le point de contrôle actuel :

DataObject root = com.ibm.websphere.wim.util.SDOHelper.createRootDataObject();
com.ibm.websphere.wim.util.SDOHelper.createControlDataObject(root, WIM_NS_URI, DO_CHANGE_CONTROL);
return service.search(root);

Pour cet exemple particulier, les étapes du processus de gestion de la recherche des entités modifiées sont expliquées ici.

  1. Envoi d'un contrôle de modification vide

    L'application client de virtual member manager envoie un contrôle de modification sans aucun point de contrôle lors de la première recherche d'entités modifiées. Le graphique de données d'entrée est affiché ici.

    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:controls xsi:type="wim:ChangeControl" changeTypes="*"/>
      </wim:Root>
    </sdo:datagraph><?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:controls xsi:type="wim:ChangeControl"/>
      </wim:Root>
    </sdo:datagraph>
  2. Renvoyez ChangeResponseControl avec un point de contrôle
    1. L'interface du gestionnaire de profils transmet la demande aux adaptateurs associés, en fonction de la base de recherche et de la prise en charge ou non du suivi des modifications par le référentiel.
    2. Chaque adaptateur répond avec la chaîne de point de contrôle en cours qui doit être utilisée sur cet adaptateur lors de la recherche ultérieure.
    3. L'interface du gestionnaire de profils regroupe les chaînes de point de contrôle renvoyées par tous les adaptateurs et envoie la chaîne consolidée dans un contrôle de réponse.
    Dans cet exemple, comme le référentiel de fichiers ne prend pas en charge les demandes de modification, le point de contrôle du référentiel de fichiers n'est pas affiché dans le contrôle de réponse. Si IBM Tivoli Directory Server contient 20 modifications et Active Directory, 40, le graphique de données résultant est affiché ici.
    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:controls xsi:type="wim:ChangeResponseControl">
          <wim:checkPoint>
            <wim:repositoryId>TDS_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>21</wim:repositoryCheckPoint>
          </wim:checkPoint>
          <wim:checkPoint>
            <wim:repositoryId>AD_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>41</wim:repositoryCheckPoint>
          </wim:checkPoint>
        </wim:controls>
      </wim:Root>
    </sdo:datagraph>
  3. Envoyez une demande de recherche avec le contrôle de modification contenant le point de contrôle

    Lors d'une prochaine recherche d'entités modifiées, ce point de contrôle consolidé est renvoyé à virtual member manager et l'interface du gestionnaire de profils est chargé de transmettre le point de contrôle approprié à l'adaptateur correspondant.

    Pour copier le point de contrôle du précédent ChangeResponseControl dans le contrôle de modification en entrée, ajoutez l'exemple de code suivant à votre code d'application et remplacez les variables par les valeurs réelles à utiliser :

    /**  
     * Extraire le point de contrôle actuel des référentiels
     * @return DataObject : objet de données avec ChangeResponseControl contenant les points de contrôle
     * des référentiels qui prennent en charge le suivi des modifications
     */
    public DataObject searchGetCurrentCheckpoint() throws WIMException 
    {
       DataObject root = com.ibm.websphere.wim.util.SDOHelper.createRootDataObject();
       com.ibm.websphere.wim.util.SDOHelper.createControlDataObject(root, WIM_NS_URI, DO_CHANGE_CONTROL);
       return service.search(root);
    }
    
    /** 
     * Rechercher les entités modifiées depuis le point de contrôle renvoyé par searchGetCurrentCheckpoint
     * @param prevRoot : objet de données renvoyé à partir de searchGetCurrentCheckpoint
     * @return DataObject : objet de données avec entités modifiées et ChangeResponseControl
     */
    public DataObject searchGetChangedEntities(final DataObject prevRoot) throws WIMException 
    {
       DataObject root = com.ibm.websphere.wim.util.SDOHelper.createRootDataObject();
       DataObject changeCtrl = com.ibm.websphere.wim.util.SDOHelper.createControlDataObject(root, null, DO_CHANGE_CONTROL);
       changeCtrl.setString(SchemaConstants.PROP_SEARCH_EXPRESSION, "@xsi:type='PersonAccount'");                
       changeCtrl.getList(SchemaConstants.PROP_PROPERTIES).add("uid");
       changeCtrl.getList(SchemaConstants.PROP_PROPERTIES).add("cn");
       changeCtrl.getList(SchemaConstants.PROP_PROPERTIES).add("sn");
       changeCtrl.getList(PROP_CHANGETYPES).add(SchemaConstants.CHANGETYPE_ALL);
       com.ibm.websphere.wim.util.SDOHelper.createChangeCtrlFromChangeRespCtrl(root, prevRoot);
       return service.search(root);
    }
      
    /**
     * Méthode permettant d'appeler searchGetCurrentCheckpoint et searchChangedEntities
     */
    public void search() throws WIMException
    {
      /* Extraire le point de contrôle actuel */
      DataObject result = searchGetCurrentCheckpoint();
      
      /* Ajouter, modifier, renommer, supprimer des entités */
    
      /* Rechercher les entités modifiées depuis le point de contrôle renvoyé par searchGetCurrentCheckpoint */
      result = searchGetChangedEntities(result);
    }

    Dans le code précédent, la méthode search() appelle d'abord la méthode searchGetCurrentChekpoint() pour extraire les points de contrôle actuels. Le résultat renvoyé par searchGetCurrentCheckpoint() est transmis à la deuxième méthode, searchGetChangedEntities(). Elle utilise la méthode d'utilitaire SDOHelper.createChangeCtrlFromChangeRespCtrl() pour obtenir un ChangeControl contenant le point de contrôle sauvegardé à partir du ChangeResponseControl renvoyé par searchGetCurrentCheckpoint.

    Le graphique de données en entrée d'une recherche ultérieure contenant le point de contrôle sauvegardé est affiché ici :

    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:controls xsi:type="wim:ChangeControl" expression="@xsi:type='PersonAccount' and cn='tuser*'">
          <wim:checkPoint>
            <wim:repositoryId>TDS_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>21</wim:repositoryCheckPoint>
          </wim:checkPoint>
          <wim:checkPoint>
            <wim:repositoryId>AD_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>41</wim:repositoryCheckPoint>
          </wim:checkPoint>
          <wim:changeTypes>add</wim:changeTypes>
        </wim:controls>
      </wim:Root>
    </sdo:datagraph>
  4. Renvoyez les résultats de la recherche et ChangeResponseControl avec le point de contrôle mis à jour

    Si trois nouvelles entités sont ajoutées dans IBM Tivoli Directory Server et deux nouvelles entités sont ajoutées dans Active Directory, le graphique de données résultant est illustré ici :

    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:entities xsi:type="wim:PersonAccount">
          <wim:identifier externalName="cn=tuser1,o=tds" repositoryId="TDS_LDAP" uniqueId="13f1c1c8-ff43-433c-b0ca-02fb5a56b522"
              uniqueName="cn=tuser1,o=tds"/>
          <wim:changeType>add</wim:changeType>
        </wim:entities>
        <wim:entities xsi:type="wim:PersonAccount">
          <wim:identifier externalName="cn=tuser3,o=tds" repositoryId="TDS_LDAP" uniqueId="25641e84-b17b-48ee-b9cb-d7eea2496005"
              uniqueName="cn=tuser3,o=tds"/>
          <wim:changeType>add</wim:changeType>
        </wim:entities>
        <wim:entities xsi:type="wim:PersonAccount">
          <wim:identifier externalName="cn=tuser5,o=tds" repositoryId="TDS_LDAP" uniqueId="a3316b8d-f496-4a5b-93eb-ba59f47aa2ab"
              uniqueName="cn=tuser5,o=tds"/>
          <wim:changeType>add</wim:changeType>
        </wim:entities>
        <wim:entities xsi:type="wim:PersonAccount">
          <wim:identifier externalName="CN=tuser4,DC=vmm-server11,DC=in,DC=ibm,DC=com"
              repositoryId="AD_LDAP" uniqueId="855c13b14a2e5e448af0699d4b2aaf47" uniqueName="CN=tuser4,o=ad"/>
          <wim:changeType>add</wim:changeType>
        </wim:entities>
        <wim:entities xsi:type="wim:PersonAccount">
          <wim:identifier externalName="CN=tuser2,DC=vmm-server11,DC=in,DC=ibm,DC=com"
              repositoryId="AD_LDAP" uniqueId="725199db56ac8342b7c6a08ae3cb93e3" uniqueName="CN=tuser2,o=ad"/>
          <wim:changeType>add</wim:changeType>
        </wim:entities>
        <wim:controls xsi:type="wim:ChangeResponseControl">
          <wim:checkPoint>
            <wim:repositoryId>TDS_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>24</wim:repositoryCheckPoint>
          </wim:checkPoint>
          <wim:checkPoint>
            <wim:repositoryId>AD_LDAP</wim:repositoryId>
            <wim:repositoryCheckPoint>43</wim:repositoryCheckPoint>
          </wim:checkPoint>
        </wim:controls>
      </wim:Root>
    </sdo:datagraph

Différences dans les résultats de la recherche entre IBM Tivoli Directory Server et Active Directory

Les résultats d'une recherche d'entités modifiées diffèrent entre IBM Tivoli Directory Server et Active Directory. Deux différences importantes sont expliquées ici.

Opérations de changement de nom
  • IBM Tivoli Directory Server :

    L'entité renommée est renvoyée avec le type de modification rename. Pour identifier l'entité d'origine, l'application client de virtual member manager doit associer l'identificateur unique (obtenu par l'attribut ibm-entryUUID) de l'ancienne et de la nouvelle entité.

  • Active Directory :

    L'entité renommée est renvoyée avec le type de modification modify. L'application client de virtual member manager peut identifier une opération de changement de nom lorsqu'elle rencontre une opération de modification d'un nom distinctif (DN) qui n'existe pas dans sa copie. Toutefois, une opération de modification est signalée même pour un nouveau nom distinctif qui ne se trouve pas encore dans la copie de l'application. Une opération de modification est signalée même si une entité est ajoutée et modifiée dans le même cycle de synchronisation. Par conséquent, l'application client de virtual member manager doivent associer l'identificateur unique (obtenu à partir de l'attribut objectGUID d'Active Directory) de l'ancienne et de la nouvelle entité. Si aucun identificateur unique n'est trouvé, il s'agit d'un ajout ; sinon il s'agit d'une opération de changement de nom sur une entité existante.

Modifications multiple apportées à une entité dans le même cycle de synchronisation
  • IBM Tivoli Directory Server :

    La version finale de l'entité modifiée est consignée autant de fois qu'il y a eu des modifications sur l'entité dans le cycle de synchronisation, avec le type de modification modify. Par exemple, si une entité a été modifiée quatre fois dans le même cycle de synchronisation, la version finale de l'entité modifiée est renvoyée quatre fois comme entité modifiée avec le type de modification modify. Une exception à cette règle concerne le cas où l'entité est supprimée ultérieurement dans le même cycle de synchronisation. Dans ce cas, toute autre opération sur l'entité avant que celle-ci n'ait été supprimée est ignorée et n'est pas renvoyée à l'application virtual member manager.

    La mémoire cache des attributs gérée par virtual member manager est mise à jour chaque fois que vous recherchez des entités modifiées, même si une entité est modifiée, puis supprimée dans le même cycle de synchronisation.

  • Active Directory :

    Seule la mise à jour finale de l'entité est renvoyée. Par exemple, si une entité a été ajoutée et supprimée dans le même cycle de synchronisation, le client virtual member manager reçoit un type de modification delete pour une entité qui n'est pas présente dans sa copie. Dans ce cas, l'application virtual member manager doit inclure la logique permettant d'ignorer les notifications de modification.

    La mémoire cache des attributs gérée par virtual member manager est mise à jour chaque fois que vous recherchez des entités modifiées. Toutefois, elle n'est pas mise à jour si une entité est modifiée, puis supprimée du référentiel dans le même cycle de synchronisation.

Pour un exemple de code de bout en bout, voir les rubriques Exemple de code pour la recherche d'entités modifiées et Exemple de code pour la recherche des entités modifiées et supprimées.



Conditions d'utilisation | Commentaires