Búsqueda de entidades modificadas

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.

Acerca de esta tarea

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 evitar pasar un ChangeControl a un adaptador que no pueda manejarlo, cada ID de depósito de wimconfig.xml se asocia a una propiedad llamada supportChangeLog. Los valores válidos de la propiedad supportChangeLog son:
  • none- indica que no existe soporte de seguimiento de cambios para este depósito. Este valor es el valor predeterminado si supportChangeLog no está establecido.
  • native - indica que virtual member manager utiliza el mecanismo de seguimiento de cambios del depósito para devolver entidades modificadas.
El gestor de perfiles consulta este valor antes de pasarlo en la solicitud al adaptador correspondiente. Si el valor de supportChangeLog es none, este depósito no se llama para recuperar las entidades modificadas. Puede utilizar los mandatos wsadmin createIdMgrLDAPRepository, updateIdMgrLDAPRepository o updateIdMgrRepository para establecer la propiedad supportChangeLog. Para obtener más información sobre estos mandatos, consulte Grupo de mandatos IdMgrRepositoryConfig para el objeto AdminTask.
Están soportados los siguientes depósitos para el adaptador LDAP:
  • IBM Tivoli Directory Server
  • Active directory
Importante: Antes de consultar las entidades modificadas para un adaptador que da soporte a esta característica, asegúrese de que está habilitada la característica de seguimiento de cambios del depósito. Por ejemplo, para habilitar el seguimiento de cambios para IBM Tivoli Directory Server, consulte el tema Programas de utilidad del servidor, idscfgchglg en el Information Center de IBM Tivoli Directory Server.

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.

Gráficos de ejemplo de datos de entrada y salida

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.

  1. Enviar ChangeControl vacío

    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>
  2. Devolver ChangeResponseControl con el punto de comprobación
    1. La interfaz del gestor de perfiles pasa la solicitud a los adaptadores asociados, dependiendo de la base de búsqueda y de si el depósito da soporte al seguimiento de cambios.
    2. Cada adaptador responde con la serie de punto de comprobación actual que debe utilizarse para el adaptador durante la búsqueda posterior.
    3. La interfaz del gestor de perfiles consolida la serie de punto de comprobación que devuelven todos los adaptadores y la devuelve en un control de respuesta.
    En este ejemplo, dado que el depósito de archivos no da soporte a la solicitud de cambios, el punto de comprobación para el depósito de archivos no se muestra en el control de respuesta. Si IBM Tivoli Directory Server tenía 20 cambios y Active Directory tenía 40 cambios, 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: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. Enviar solicitud de búsqueda con ChangeControl incluyendo de comprobación

    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>
  4. Devolver resultados de búsqueda y ChangeResponseControl con el punto de comprobación actualizado

    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

Diferencias en los resultados de búsqueda entre IBM Tivoli Directory Server y Active Directory

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.

Operaciones de renombrar
  • IBM Tivoli Directory Server:

    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.

  • Active Directory:

    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.

Múltiples modificaciones en una entidad del mismo ciclo de sincronización
  • IBM Tivoli Directory Server:

    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.

  • Active Directory:

    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.



Condiciones de uso | Comentarios