Dynamisches und statisches Modell: Neue Entitäten und Merkmale während der Ausführung erstellen

Virtual Member Manager ist so konfiguriert, dass entweder das dynamische Modell oder das statische Modell verwendet wird. Sie können während der Ausführung neue Entitätstypen und neue Merkmaltypen erstellen und vorhandene oder neue Merkmaltypen zu den neuen Entitätstypen hinzufügen.

Informationen zu diesem Vorgang

Sie müssen die API "createSchema" von Virtual Member Manager aufrufen, um neue Entitätstypen und neue Merkmaltypen zu erstellen sowie vorhandene oder neue Merkmaltypen zu den neuen Entitätstypen während der Ausführung hinzuzufügen, ohne Virtual Member Manager erneut zu starten. Per Vordefinition unterstützen der LDAP-Adapter und der Datenbankadapter diese Vorgehensweise. Im folgenden Beispiel wird der neue Entitätstyp "ContactPerson" erstellt, der eine Erweiterung des integrierten Virtual Member Manager-Entitätstyp "PersonAccount" ist. Außerdem wird der neue Merkmaltyp "cellPhone" erstellt und dem neuen Entitätstyp 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. Für das Beispiel müssen die Objektklasse "eContactPerson" und das Attribut "cellularTelephoneNumber" erstellt werden, wenn sie nicht bereits vordefiniert sind.

    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 "EntitySchema" wird verwendet, um den neuen Entitätstyp zu erstellen, und das Datenobjekt "PropertySchema" wird verwendet, um den neuen Merkmaltyp zu erstellen. Beide Datenobjekte müssen die Namespace-URI angeben, unter der der neue Entitätstyp und der neue Merkmaltyp erstellt werden. Der neue Entitätstyp muss den übergeordneten Entitätstyp angeben, dessen Erweiterung er ist.

    Abgesehen von den Schemainformationen geben beide Datenobjekte die Konfigurationsdaten an, die Virtual Member Manager und der zugrunde liegende Adapter (LDAP-Adapter) benötigen, um die neuen Entitätstypen und Merkmaltypen zu unterstützen. Beispiel: Das übergeordnete Standardmerkmal und das RDN-Merkmal werden benötigt, um die neue Entität zur XML-Konfigurationsdatei von Virtual Member Manager (wimconfig.xml) hinzuzufügen. Das im Realm definierte übergeordnete Standardelement wird über den Konfigurationsmanager erstellt. Die Attribute "objectClasses" und "objectClassForCreate" werden für den LDAP-Adapter benötigt, damit die neue Entität den entsprechenden LDAP-Objektklassen zugeordnet werden kann. Für ein neues Merkmal benötigt der LDAP-Adapter den Namen des zugehörigen LDAP-Attributs, der möglicherweise nicht mit dem Merkmalnamen identisch ist. Sind die Namen nicht identisch, müssen Sie eine LDAP-Attributkonfiguration hinzufügen und den Namen des korrespondierenden Virtual Member Manager-Merkmalsnamens hinzufügen. 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.

    Im Folgenden sehen Sie den Beispieldatengraph. Das Element "entitySchema" wird verwendet, um das Schema für die Entität "ContactPerson" zu definieren. Das Element "entityConfig" enthält die Konfigurationsdaten für den Entitätstyp. Beispiel: Das Element "actionNotAllow" wird verwendet, um anzugeben, dass ein solcher Entitätstyp nicht gelöscht werden kann. Das Element "propertySchema" wird verwendet, um das Schema für das Merkmal "cellPhone" zu definieren.
    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:sdo="commonj.sdo"
        xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:schema>
          <wim:entitySchema entityName="ContactPerson" 
                            nsPrefix="yourext" 
                            nsURI="http://www.yourco.com/wim/yourext"
              parentEntityName="PersonAccount">
            <wim:entityConfiguration defaultParent="cn=users,dc=yourco,dc=com" 
                                     rdnProperty="uid">
              <wim:actionNotAllow actionName="delete"/>
              <wim:metaData name="objectClasses">
                <wim:values>eContactPerson</wim:values>
              </wim:metaData>
              <wim:metaData name="objectClassesForCreate">
                <wim:values>eContactPerson</wim:values>
                <wim:values>inetOrgPerson</wim:values>
              </wim:metaData>
              <wim:metaData name="rdnProperties">
                <wim:values>uid</wim:values>
              </wim:metaData>
            </wim:entityConfiguration>
          </wim:entitySchema>
          <wim:propertySchema nsURI="http://www.yourco.com/wim/yourext"
                              dataType="STRING" 
                              multiValued="true" 
                              propertyName="cellPhone">
            <wim:applicableEntityTypeNames>yourext:ContactPerson</wim:applicableEntityTypeNames>
          </wim:propertySchema>
        </wim:schema>
      </wim:Root>
    </sdo:datagraph>
    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.

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 Entitätstypen und Merkmaltypen bereits vorhanden sind und löst eine Ausnahmebedingung aus, falls dies der Fall ist. Dann erstellt der Schemamanager ein neues ECore-Modell (EPackage) mit einer Namespace-URI (http://www.yourco.com/wim/yourext), falls noch nicht vorhanden. Anschließend fügt er die Schemata der neuen Entitätstypen und Merkmaltypen dem ECore-Modell im Hauptspeicher hinzu.

Der Schemamanager fügt das Schema des neuen Entitäts- und Merkmaltypen der Datei "wimxmlextension.xml" hinzu. Wenn diese Datei nicht vorhanden ist, wird eine neue Datei erstellt. Im Folgenden sehen Sie den Beispielinhalt der Datei "wimxmlextension.xml", nachdem die beschriebene Operation beendet wurde.
Anmerkung: Die Konfigurationsdaten werden nicht in diese XML-Datei geschrieben.
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo"
    xmlns:wim="http://www.ibm.com/websphere/wim">
  <wim:schema>
    <wim:entitySchema nsPrefix="yourext" 
                      nsURI="http://www.yourco.com/wim/yourext"
                      entityName="ContactPerson" 
                      parentEntityName="PersonAccount"/>
    <wim:propertySchema nsURI="http://www.yourco.com/yourext" 
                        dataType="STRING" 
                        multiValued="true"
                        propertyName="cellPhone">
      <wim:applicableEntityTypeNames>ContactPerson</wim:applicableEntityTypeNames>
    </wim:propertySchema>
  </wim:schema>
</sdo:datagraph>
Der Schemamanager ruft anschließend den Konfigurationsmanager auf.
Der Konfigurationsmanager fügt die Konfigurationsdaten der neuen Typen der XML-Konfigurationsdatei von Virtual Member Manager (wimconfig.xml) hinzu. Im Folgenden sehen Sie die Abschnitte, die für den neuen Entitätstyp "ContactPerson" in der Datei "wimconfig.xml" hinzugefügt werden, nachdem die Operation beendet ist.
<config:supportedEntityTypes defaultParent="cn=users,dc=yourco,dc=com"
                             name="yourext:ContactPerson">

      <config:rdnProperties>uid</config:rdnProperties>
    </config:supportedEntityTypes>

<config:repositories xsi:type="config:LdapRepositoryType" ...>

      <config:EntityTypesNotAllowDelete>yourext:ContactPerson</config:EntityTypesNotAllowDelete>

      <config:ldapEntityTypes name="yourext:ContactPerson">
        <config:rdnAttributes name="uid"/>
        <config:objectClasses>eContactPerson</config:objectClasses>
        <config:objectClassesForCreate>eContactPerson</config:objectClassesForCreate>
        <config:objectClassesForCreate>inetOrgPerson</config:objectClassesForCreate>
      </config:ldapEntityTypes>
    </config:repositories>
Der Schemamanager ruft anschließend den Repository Manager auf.
Der Repository-Manager ruft die SPI-Methode "createSchema" aller Adapter auf. 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 der Datenbank und aktualisiert den 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 "ContactPerson" mit dem Merkmal "cellPhone" zu erstellen. Virtual Member Manager muss nicht erneut gestartet werden, die Schemaänderungen werden auch ohne einen Neustart aktiv.



Rechtliche Hinweise | Feedback