Mit der Methode "search(DataObject)" und dem Datenobjekt "ChangeControl" können Sie die föderierten Repositorys nach Entitäten abfragen, die seit einem bestimmten Prüfpunkt geändert wurden.
Das Datenobjekt "ChangeControl" unterscheidet zwischen einer Suche nach geänderten Entitäten und einer normalen Suchoperation. Jeder Entität, die als Ergebnis der Suche zurückgegeben wird, ist das Mermal "changeType" zugeordnet.
Das Merkmal "changeType" des Datenobjekts "Entity" ist ein optionales Merkmal und wird nur als Reaktion auf eine Suche nach geänderten Entitäten festgelegt. Es beschreibt den Typ der stattgefundenen Änderung. Dies kann das Hinzufügen einer neuen Entität, das Ändern einer vorhandenen Entität, das Löschen einer Entität oder das Umbenennen einer Entität sein.
Die gültigen Werte und Zeichenfolgekonstanten für das Merkmal "changeType" sind add (für CHANGETYPE_ADD), delete (für CHANGETYPE_DELETE), modify (für CHANGETYPE_MODIFY) und rename (für CHANGETYPE_RENAME).
Für hinzugefügte, geänderte und umbenannte Entitäten wird die aktuelle Entität im Repository zurückgegeben. Für gelöschte Entitäten wird nur die Entitäts-ID zurückgegeben, die aus dem externen Namen und dem eindeutigen Namen besteht. (In IBM® Tivoli Directory Server Version 6.1 und älteren Versionen wird die repositoryspezifische UUID nicht als Teil der Entitäts-ID zurückgegeben. In IBM Tivoli Directory Server Version 6.2 und höher enthält die Entitäts-ID hingegen zusammen mit dem externen Namen und dem eindeutigen Namen auch die repositoryspezifische UUID.) Der Repository-Prüfpunkt ist von den Änderungstypen und der Suchbasis unabhängig. Der Prüfpunkt gilt für das gesamte Repository.
Stellen Sie für IBM Tivoli Directory Server außerdem sicher, dass das Fix für Authorized Program Analysis Report (APAR) 1IO10107 installiert ist.
Als Beispiel wird ein Szenario verwendet, in dem eine Virtual Member Manager-Anwendung mit drei Repositorys konfiguriert ist: IBM Tivoli Directory Server, Active Directory und ein Dateirepository. Wenn die Anwendung mit Virtual Member Manager synchron ist, wird der Prüfpunkt abgerufen und gespeichert. Dieser gespeicherte Prüfpunkt wird während des nächsten Synchronisationsintervalls im Datenobjekt "ChangeControl" verwendet. Der folgende Mustercode ruft den aktuellen Prüfpunkt ab:
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);
In diesem speziellen Beispiel sind die Schritte im Prozess für die Verarbeitung einer Suche nach geänderten Entitäten nachstehend erläutert.
Die Virtual Member Manager-Clientanwendung sendet während der ersten Suche nach geänderten Entitäten ein Datenobjekt" ChangeControl", das keinen Prüfpunkt enthält. Der Eingabedatengraph ist nachfolgend dargestellt.
<?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>
Bei einer nachfolgenden Suche nach geänderten Entitäten wird dieser konsolidierte Prüfpunkt an Virtual Member Manager zurückgegeben und die Profilmanagerschnittstelle ist dafür zuständig, den geeigneten Prüfpunkt an den entsprechenden Adapter zu übergeben.
Um den Prüfpunkt aus dem vorherigen Datenobjekt "ChangeResponseControl" in das Eingabedatenobjekt "ChangeControl" zu kopieren, fügen Sie den folgenden Mustercode zu Ihrem Anwendungscode hinzu. Ersetzen Sie hierbei die Variablen durch die tatsächlichen Werte, die Sie verwenden wollen:
/**
* Get the current checkpoint for the repositories
* @return DataObject: DataObject with ChangeResponseControl containing the checkpoints
* for the repositories that support change tracking
*/
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);
}
/**
* Search the changed entities since the checkpoint returned by searchGetCurrentCheckpoint
* @param prevRoot: DataObject returned from searchGetCurrentCheckpoint
* @return DataObject: DataObject with changed entities and 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);
}
/**
* Method to call searchGetCurrentCheckpoint and searchChangedEntities
*/
public void search() throws WIMException
{
/* Get the current checkpoint */
DataObject result = searchGetCurrentCheckpoint();
/* Here add, modify, rename, delete some entities */
/* Search for the changed entities since the checkpoint returned by searchGetCurrentCheckpoint */
result = searchGetChangedEntities(result);
}
Im obigen Code ruft die Methode "search()" zunächst die Methode "searchGetCurrentChekpoint()" auf, um die aktuellen Prüfpunkte abzurufen. Das von der Methode "searchGetCurrentCheckpoint()" zurückgegebene Ergebnis wird an die zweite Methode - "searchGetChangedEntities()" - übergeben. Sie verwendet die Dienstprogrammmethode "SDOHelper.createChangeCtrlFromChangeRespCtrl()", um ein aktualisiertes Datenobjekt "ChangeControl" anzufordern, das den gespeicherten Prüfpunkt aus dem Datenobjekt "ChangeResponseControl" (zurückgegeben durch "searchGetCurrentCheckpoint") enthält.
Der Eingabedatengraph für eine nachfolgende Suche, die den gespeicherten Prüfpunkt enthält, sieht wie folgt aus:
<?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>
Falls in IBM Tivoli Directory Server drei neue Entitäten und in Active Directory zwei neue Entitäten hinzugefügt wurden, sieht der resultierende Ausgabedatengraph folgendermaßen aus:
<?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
Die Ergebnisse einer Suche nach geänderten Entitäten unterscheiden sich bei IBM Tivoli Directory Server und Active Directory. Zwei wichtige Unterschiede sind im Folgenden erläutert.
Die umbenannte Entität wird mit dem Änderungstyp (changeType) rename zurückgegeben. Um die ursprüngliche Entität zu identifizieren, muss die Virtual Member Manager-Clientanwendung eine Zuordnung der eindeutigen ID (uniqueID), die aus dem Attribut "ibm-entryUUID" erhalten wird, zwischen der alten und der neuen Entität vornehmen.
Die umbenannte Entität wird mit dem Änderungstyp (changeType) modify zurückgegeben. Die Virtual Member Manager-Clientanwendung kann eine Umbenennungsoperation erkennen, wenn sie eine Änderungsoperation für einen definierten Namen (DN) feststellt, der in ihrer Kopie nicht vorhanden ist. Eine Änderungsoperation wird jedoch auch für einen neuen definierten Namen gemeldet, der noch nicht in der Kopie der Anwendung enthalten ist. Eine Änderungsoperation wird sogar dann gemeldet, wenn eine Entität im gleichen Synchronisationszyklus hinzugefügt und geändert wurde. Daher muss die Virtual Member Manager-Clientanwendung eine Zuordnung der eindeutigen ID (erhalten aus dem Active Directory-Attribut "objectGUID") zwischen der alten und der neuen Entität vornehmen. Wird keine eindeutige ID gefunden, wurde die Entität hinzugefügt. Andernfalls handelte es sich um eine Umbenennungsoperation für eine vorhandene Entität.
Die finale Version der geänderten Entität wird mit dem Änderungstyp (changeType) modify so oft gemeldet, wie Änderungen an der Entität vorgenommen wurden. Falls an einer Entität im gleichen Synchronisationszyklus beispielsweise vier Änderungen vorgenommen wurden, wird die finale Version der geänderten Entität vier Mal als geänderte Entität mit dem Änderungstyp modify zurückgegeben. Hiervon ausgenommen sind Fälle, in denen eine Entität zu einem späteren Zeitpunkt im gleichen Synchronisationszyklus gelöscht wird. In diesem Fall werden alle anderen Operationen für die Entität vor dem Löschen ignoriert und nicht an die Virtual Member Manager-Anwendung zurückgegeben.
Der von Virtual Member Manager verwaltete Attributcache wird bei jeder Suche nach geänderten Entitäten aktualisiert. Dies trifft auch dann zu, wenn eine Entität im gleichen Synchronisationszyklus zunächst geändert und später gelöscht wird.
Nur die finale Aktualisierung der Entität wird zurückgegeben. Falls eine Entität im gleichen Synchronisationszyklus beispielsweise hinzugefügt und gelöscht wurde, empfäng der Virtual Member Manager-Client einen Änderungstyp delete für eine Entität, die in seiner Kopie nicht vorhanden ist. In diesem Fall muss die Virtual Member Manager-Anwendung die Logik zum Ignorieren der Benachrichtigungen über Änderungen enthalten.
Der von Virtual Member Manager verwaltete Attributcache wird bei jeder Suche nach geänderten Entitäten aktualisiert. Er wird jedoch nicht aktualisiert, wenn eine Entität im gleichen Synchronisationszyklus zunächst geändert und später aus dem Repository gelöscht wird.
Den umfassenden Mustercode finden Sie unter Mustercode für die Suche nach geänderten Entitäten und Mustercode für die Suche nach geänderten und gelöschten Entitäten.