Utilice el método search(DataObject) y ChangeControl DataObject para consultar si el depósito federado contiene entidades modificadas desde un determinado punto de comprobación hacia adelante.
ChangeControl DataObject diferencia entre una búsqueda de entidades modificadas y una operación de búsqueda normal. Cada entidad que se devuelve como resultado de la búsqueda se asocia con la propiedad changeType.
La propiedad changeType de Entity DataObject es una propiedad opcional que sólo se establece en respuesta a una búsqueda de entidades modificadas. La propiedad changeType describe el tipo de cambio que se ha producido, que podría ser añadir una nueva entidad, modificar una entidad existente, suprimir una entidad o renombrar una entidad.
Los valores y constantes de tipo serie válidos de la propiedad changeType son add (para CHANGETYPE_ADD), delete (para CHANGETYPE_DELETE), modify (para CHANGETYPE_MODIFY) y rename (para CHANGETYPE_RENAME).
Para entidades añadidas, modificadas y renombradas, se devuelve la entidad actual del depósito. Para entidades suprimidas, sólo se devuelve el identificador de entidad, formado por el nombre externo y el nombre exclusivo. (En IBM® Tivoli Directory Server versión 6.1 y anterior, el UUID específico del depósito no se devuelve como parte del identificador de entidad, mientras que en IBM Tivoli Directory Server versión 6.2 y posterior, el identificador de entidad incluye el UUID específico del depósito además del nombre externo y el nombre exclusivo.) El punto de comprobación de depósito desconoce los tipos de cambios y la base de búsqueda. El punto de comprobación se aplica a todo el depósito.
Para IBM Tivoli Directory Server, asegúrese también de que está instalado el arreglo para el informe autorizado de análisis de programa (APAR) 1IO10107.
Considere un escenario en el que se configura una aplicación de virtual member manager con tres depósitos: IBM Tivoli Directory Server, Active Directory y un depósito de archivos. Cuando la aplicación está sincronizada con virtual member manager, se recupera y guarda el punto de comprobación. Este punto de comprobación guardado se utiliza en ChangeControl durante el próximo intervalo de sincronización. En el siguiente código de ejemplo se recupera el punto de comprobación actual:
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);
En este ejemplo concreto, se explican los pasos del proceso para manejar una búsqueda de entidades modificadas.
La aplicación cliente de virtual member manager envía un ChangeControl sin ningún punto de comprobación durante la primera búsqueda de entidades modificadas. A continuación se muestra el gráfico de datos de entrada.
<?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>
Durante una búsqueda posterior de entidades modificadas, este punto de comprobación consolidado se devuelve a virtual member manager y la interfaz del gestor de perfiles es responsable de pasar el punto de comprobación apropiado al adaptador correspondiente.
Para copiar el punto de comprobación desde el ChangeResponseControl anterior al ChangeControl de entrada, añada el siguiente código de ejemplo al código de aplicación y sustituya las variables por los valores reales que desea utilizar:
/**
* Obtener el punto de comprobación actual para los depósitos
* @return DataObject: DataObject con ChangeResponseControl incluyendo los puntos de comprobación
* para los depósitos que dan soporte al seguimiento de cambios
*/
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);
}
/**
* Buscar las entidades modificadas desde el punto de comprobación devuelto por searchGetCurrentCheckpoint
* @param prevRoot: DataObject devuelto desde searchGetCurrentCheckpoint
* @return DataObject: DataObject con entidades modificadas y 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étodo para invocar searchGetCurrentCheckpoint y searchChangedEntities
*/
public void search() throws WIMException
{
/* Obtener el punto de comprobación actual */
DataObject result = searchGetCurrentCheckpoint();
/* Añadir, modificar, renombrar y suprimir algunas entidades */
/* Buscar las entidades modificadas desde el punto de comprobación devuelto por searchGetCurrentCheckpoint */
result = searchGetChangedEntities(result);
}
En el código anterior, el primer método search() invoca el método searchGetCurrentChekpoint() para recuperar los puntos de comprobación actuales. El resultado devuelto por searchGetCurrentCheckpoint() se pasa al segundo método, searchGetChangedEntities(). Utiliza el método de programa de utilidad SDOHelper.createChangeCtrlFromChangeRespCtrl() para obtener un ChangeControl actualizado que incluya el punto de comprobación guardado del ChangeResponseControl devuelto por searchGetCurrentCheckpoint.
A continuación se muestra el gráfico de datos de entrada para una búsqueda posterior que contenga el punto de comprobación guardado:
<?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 se añaden tres entidades nuevas en IBM Tivoli Directory Server y dos entidades nuevas en Active Directory, el gráfico de datos de salida resultante se muestra a continuación:
<?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
Los resultados de una búsqueda de entidades modificadas son diferentes entre IBM Tivoli Directory Server y Active Directory. A continuación se explican dos diferencias importantes.
La entidad renombrada se devuelve con el changeType rename. Para identificar la entidad original, la aplicación cliente de virtual member manager debe asociar entre el uniqueID (como se obtiene del atributo ibm-entryUUID) de la entidad antigua y nueva.
La entidad renombrada se devuelve con el changeType modify. La aplicación cliente de virtual member manager puede identificar una operación de renombrar cuando encuentra una operación de modificar para un nombre distinguido (DN) que no existe en esta copia. Sin embargo, se notifica una operación de modificar incluso para un DN nuevo que todavía no esté en la copia de la aplicación. Se notifica una operación de modificar incluso si se añade una entidad y se modifica en el mismo ciclo de sincronización. Por lo tanto, la aplicación cliente de virtual member manager debe asociar entre el ID exclusivo (como se obtiene del atributo objectGUID de Active Directory) de la entidad antigua y nueva. Si no se encuentra ningún uniqueID, se trata de una adición o, de lo contrario, es una operación de renombrar en una entidad existente.
La versión final de la entidad modificada se notifica tantas veces como se han producido modificaciones en la entidad en el ciclo de sincronización, con el changeType modify. Por ejemplo, si existen cuatro modificaciones en una entidad dentro del mismo ciclo de sincronización, la versión final de la entidad modificada se devuelve cuatro veces como entidad modificada con changeType modify. Una excepción de este caso es cuando la entidad se suprime posteriormente dentro del mismo ciclo de sincronización. En este caso, se ignora cualquier operación realizada en la entidad antes de suprimirse y no se devuelve a la aplicación de virtual member manager.
La memoria caché de atributos mantenida por virtual member manager se actualiza cada vez que se buscan entidades modificadas, incluso si se modifica una entidad y a continuación se suprime en el mismo ciclo de sincronización.
Sólo de devuelve la actualización final realizada en la entidad. Por ejemplo, si una entidad se ha añadido y suprimido en el mismo ciclo de sincronización, el cliente de virtual member manager recibe un delete changeType para una entidad que no está presente en su copia. En este caso, la aplicación de virtual member manager debe incluir la lógica para ignorar las notificaciones de cambios.
La memoria caché de atributos mantenida por virtual member manager se actualiza cada vez que se buscan entidades modificadas. Sin embargo, la memoria caché de atributos no se actualiza si se modifica una entidad y, a continuación, se suprime del depósito en el mismo ciclo de sincronización.
Para obtener un código de ejemplo completo, consulte los temas Código de ejemplo para buscar entidades modificadas y Código de ejemplo para buscar entidades modificadas y suprimidas.