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.
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 IBM Tivoli Directory Server, assurez-vous également que le correctif de l'APAR (Authorized Program Analysis Report) 1IO10107 est installé.
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.
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>
<?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>
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>
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
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.
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é.
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.
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.
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.