Dynamisches Modell: Neue Merkmale zu Virtual Member Manager-Entitäten während der Ausführung hinzufügen

Virtual Member Manager ist für die Verwendung des dynamischen Modells konfiguriert. Sie können neue Merkmaltypen erstellen und sie dynamisch zu vorhandenen integrierten Entitätstypen von Virtual Member Manager während der Ausführung hinzufügen.

Informationen zu diesem Vorgang

Sie müssen die Virtual Member Manager-API "createSchema" aufrufen, um neue Merkmaltypen zu erstellen und sie zu vorhandenen integrierten Virtual Member Manager-Entitätstypen während der Ausführung hinzuzufügen, ohne Virtual Member Manager neu zu starten. Per Vordefinition unterstützen der LDAP-Adapter und der Datenbankadapter diese Vorgehensweise. Für das folgende Beispiel wird ein neuer Merkmaltyp namens "postOfficeBox" erstellt und dem integrierten Virtual Member Manager-Entitätstyp "PersonAccount" hinzugefügt. Für das vorliegende Beispiel wird der LDAP-Adapter verwendet.

Gehen Sie wie folgt vor:

Vorgehensweise

  1. Wenn zu den zugrunde liegenden Adaptern auch LDAP-Adapter gehören, müssen Sie sicherstellen, dass das entsprechende LDAP-Attributschema des neuen Merkmaltyps auf dem LDAP-Server definiert und in den LDAP-Objektklassen des Entitätstyps enthalten ist. Virtual Member Manager enthält keine Funktion zum Erstellen und Aktualisieren eines LDAP-Schemas auf einem LDAP-Server. Im vorliegenden Beispiel enthält die Objektklasse "inetOrgPerson" des Entitätstyps "PersonAccount" bereits das LDAP-Attribut "postOfficeBox".

    Wenn zu den zugrunde liegenden Adaptern ein Datenbankadapter gehört, sind keine besonderen Vorbereitungen notwendig.

  2. Erstellen Sie auf der Clientseite einen Datengraph, um den neuen Merkmaltyp zu erstellen. Das Datenobjekt "PropertySchema" wird verwendet, um einen neuen Merkmaltyp zu erstellen. Mit Attributen wie "propertyName", "dataType" und "multiValued" werden die Metadaten des neuen Merkmaltyps angegeben. Die betreffenden Entitätstypen werden im Element "applicableEntityTypeNames" definiert. Es können mehrere Entitätstypen angegeben werden. Sie können den entsprechenden Repositoryattributnamen dieses Merkmals definieren, indem Sie eine LDAP-Attributkonfiguration hinzufügen und den Namen des korrespondierenden Virtual Member Manager-Merkmalsnamens angeben. Angaben über das Verwenden der Befehlszeilenschnittstelle für diese Konfiguration enthalten die Informationen zum Befehl "addIdMgrLDAPAttr" im Thema über die Befehlsgruppe "IdMgrRepositoryConfig" für das Objekt "AdminTask" im Information Center von WebSphere Application Server.
    Anmerkung: Weitere Informationen zur Verwendung der Datenobjekte "propertySchema" und "extensionPropertySchema" finden Sie im Abschnitt Merkmalschema erweitern im Thema Voraussetzungen für die Programmierung. Weitere Informationen finden Sie im Thema über das Konfigurieren eines Repositorys für Merkmalserweiterungen in einer Konfiguration mit föderierten Repositorys im Information Center von WebSphere Application Server.
    Im Folgenden sehen Sie den Beispieldatengraph. Der neue zu erstellende Merkmaltyp wird als "postOfficeBox" bezeichnet und dem Entitätstyp "PersonAccount" hinzugefügt. Da der entsprechende LDAP-Attributname "postOfficeBox" mit dem Merkmalnamen identisch ist, ist es nicht notwendig, eine LDAP-Konfiguration für diesen Merkmalnamen hinzuzufügen.
    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:sdo="commonj.sdo"
        xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:schema>
        <wim:propertySchema nsURI="http://www.yourco.com/wim/yourext" 
         dataType="STRING" multiValued="true"
            propertyName="postOfficeBox">
          <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
        </wim:propertySchema>
      </wim:schema>
    </sdo:datagraph>

Ergebnisse

Auf der Clientseite ruft die Virtual Member Manager-Anwendung die Virtual Member Manager-API "createSchema" über den Local Service Provider auf. Der Local Service Provider stellt fest, dass durch den Aufruf das Schema geändert wird und aktualisiert das lokale Schema (ECore), nachdem der API-Aufruf "createSchema" beendet ist.

Auf der Serverseite empfängt der Schemamanager den API-Aufruf des Clients. Der Schemamanager prüft zunächst, ob die neuen Merkmaltypen bereits vorhanden sind und löst eine Ausnahmebedingung aus, falls dies der Fall ist. Daraufhin aktualisiert der Schemamanager das ECore-Modell im Hauptspeicher, indem er neue Entitätstypen zu den vorhandenen Entitätstypen hinzufügt. Im vorliegenden Beispiel wird dem Merkmal "EClass" der Entität "PersonAccount" ein neues "EAttribute" mit dem Namen "postOfficeBox" hinzugefügt.

Der Schemamanager fügt das Schema der neuen Merkmaltypen der Datei "wimxmlextension.xml" hinzu. Im Folgenden sehen Sie den Beispielinhalt der Datei "wimxmlextension.xml", nachdem die beschriebene Aktualisierung beendet ist.
<wim:propertySchema nsURI="http://www.yourco.com/wim/yourext"
    dataType="STRING" multiValued="true" propertyName="postOfficeBox">
      <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
    </wim:propertySchema>
Der Schemamanager ruft den Repositorymanager auf, der wiederum die SPI-Methode "createSchema" von allen Adaptern aufruft.
Die Adapter, die die Schemaerstellung unterstützen, führen anschließend etwaige notwendige Operationen aus, um das neue Schema zu unterstützen. Beispiele: Der LDAP-Adapter aktualisiert den Cache, um die Änderungen im Schema und der Konfiguration abzubilden. Der Datenbankadapter erstellt das Schema der neuen Entität und des neuen Merkmals in seiner Datenbank und aktualisiert seinen Cache.
Anmerkung: Adapter, die die Schemaerstellung nicht unterstützen, z. B. der Dateiadapter, der die Erstellung neuer Typen während der Ausführung nicht unterstützt, lösen die Ausnahmebedingung "OperationNotSupportedException" aus.

Wenn mindestens ein Repository-Adapter das Erstellen neuer Entitäten unterstützt und nicht die Ausnahmebedingung "OperationNotSupportedException" auslöst, gibt Virtual Member Manager die Repository-IDs der betreffenden Repositorys im Ausgabedatengraph zurück.

Auf der Clientseite ruft der Local Service Provider, nachdem der API-Aufruf "createSchema" zurückgegeben wurde, die API "getEPackages" auf, um die neusten Schemata abzurufen. Der Local Service Provider registriert die Schemata erneut in der Client-JVM. Die verwendenden Anwendungen können die Virtual Member Manager-API "create" aufrufen, um eine neue Entität des Typs "PersonAccount" mit dem Merkmal "postOfficeBox" zu erstellen. Virtual Member Manager muss nicht erneut gestartet werden, die Schemaänderungen werden auch ohne einen Neustart aktiv.

Beispiel

Beispiele für Datengraphen und Code finden Sie unter Neuen Merkmaltyp erstellen und zu einem vorhandenen Entitätstyp hinzufügen.


Rechtliche Hinweise | Feedback