Fixpack 8.5.5.2 oder höher

Angepasste Eigenschaften von Virtual Member Manager

Angepasste Eigenschaften werden verwendet, um erweiterte Einstellungen zu konfigurieren, die zusätzliche Funktionen im föderierten Repository bereitstellen.

preFetchData

Die angepasste Eigenschaft preFetchData wird hinzugefügt, um den Vorablesezugriff auf einen Satz von Attributen und das Zwischenspeichern dieses Satzes für einen Benutzer- oder Gruppenentitätstyp für das LDAP-Repository zu unterstützen. Mit dieser Eigenschaft können Sie die Liste der Attribute definieren, auf die Sie vorab zugreifen und die Sie permanent für einen bestimmten Benutzer- oder Gruppenentitätstyp permanent zwischenspeichern möchten.

Information Wert
Datentyp String
Gültige Werte Zeichenfolge mit Paaren von Entitätstypennamen und dem zugehörigen Satz von Attributen
Der gültige Wert für diese Eigenschaft enthält Paare von Entitätstypennamen und die entsprechenden Sätze von Attributen. Der Wert für die Eigenschaft muss im folgenden Format definiert werden:
EntityType1:attribute1,attribute2;EntityType2:attribute1,attribute2

Wenn das Format oder der Wert, das bzw. den Sie für die Attribute angegeben haben, nicht richtig ist, wird möglicherweise eine ähnliche Ausnahme wie in den folgenden Beispielen angezeigt:

Verwenden Sie den Befehl setIdMgrCustomProperty, um die Eigenschaft preFetchData im föderierten LDAP-Repository zu definieren.
$AdminTask setIdMgrCustomProperty {-id <Name_des_LDAP-Repositorys> -name <Eigenschaftsname> -value <Wert>}
Beispiel: $AdminTask setIdMgrCustomProperty {-id LDAP1 -name preFetchData -value “PersonAccount:sn,cn,givenName,displayName,preferredLanguage;Group:cn,description”}
Das folgende Beispiel zeigt die LDAP-Repository-Konfiguration mit der Eigenschaft preFetchData:
<config:repositories xsi:type="config:LdapRepositoryType" adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
	id="LDAP1" isExtIdUnique="true" supportAsyncMode="false" supportExternalName="false"
        supportPaging="false" supportSorting="false" supportTransactions="false" certificateFilter=""
        certificateMapMode="exactdn" ldapServerType="IDS" translateRDN="false">
   <config:baseEntries name="o=ldap" nameInRepository="o=ldap"/>
   <config:loginProperties>uid</config:loginProperties>
   <config:CustomProperties name="preFetchData" value="PersonAccount:sn,cn,givenName,displayName,preferredLanguage;Group:cn,description"/>
   <config:ldapServerConfiguration primaryServerQueryTimeInterval="15" returnToPrimaryServer="true"
          sslConfiguration="">
	<config:ldapServers authentication="simple" bindDN="cn=root" bindPassword="{xor}LTAwK25tbA=="
            connectionPool="false" connectTimeout="0" derefAliases="always" referal="ignore"
            sslEnabled="false">
	    <config:connections host="localhost" port="389"/>
        </config:ldapServers>
   </config:ldapServerConfiguration>
</config:repositories>
Im Folgenden sind einige Szenarien aufgeführt, die den Steuerungsablauf zeigen, der auf Werten basiert, die für die Eigenschaft preFetchData konfiguriert sind:
  • Szenario 1: Als Benutzer user1 mit dem Wert PersonAccount:sn;Group:cn für die angepasste Eigenschaft preFetchData anmelden

    Wenn eine Operation zum ersten Mal für user1 ausgeführt wird, wird das Attribut sn mit der Anmeldeeigenschaft des Benutzers abgerufen und zwischengespeichert, obwohl sn im Rahmen der Abfrage nicht explizit angefordert wurde. Für Gruppen, zu denen user1 gehört, wird das Attribut cn zwischengespeichert. Bei nachfolgenden Aufrufen werden die abzurufenden Daten zuerst und auch nur dann im Cache gesucht, wenn die Daten nicht gefunden wurden. Es wird dann ein JNDI-Aufruf für das erforderliche Attribut abgesetzt.

  • Szenario 2: Gruppe mit dem Wert Group:cn für die angepasste Eigenschaft preFetchData abrufen

    Wenn für die Gruppe g1 eine Suche durchgeführt wird, ruft das föderierte Repository die Gruppe cn gemäß der angegebenen Konfiguration ab und speichert sie zwischen. Wenn bei einem nachfolgenden Aufruf nach den Attributen cn und description gesucht wird, wird cn aus dem Cache abgerufen und es wird ein expliziter JNDI-Aufruf zum Abrufen der Gruppe description abgesetzt.

domainNameForAutomaticDiscoveryOfLDAPServers

Sie können diese Eigenschaft verwenden, um alle verfügbaren LDAP-Server zur Ausführungszeit zu finden, die in der DNS-Konfigurationsdatei für das LDAP-Repository für einen bestimmten Domänennamen definiert sind.

Information Wert
Datentyp String
Gültige Werte Der Name der Domäne, für die die LDAP-Serverdatensätze in der DNS-Konfigurationsdatei definiert sind.

Neben primären Serverkonfigurationen können Sie auch Failover-Server in der Konfiguration des föderierten LDAP-Repositorys konfigurieren. Das föderierte Repository wechselt zum Failover-Server, wenn der primäre Server inaktiv wird. Wenn viele LDAP-Server mit den für sie definierten Benutzern und Gruppen vorhanden sind, wird es schwierig, alle LDAP-Servernamen in der Konfiguration des föderierten LDAP-Repositorys anzugeben. Die Konfiguration wird schwieriger und kann länger dauern, wenn viele Knoten in WebSphere Application Server konfiguriert sind und jeder Knoten mit mehreren LDAP-Servern konfiguriert ist. Wenn mehrere LDAP-Server vorhanden sind, verwenden Sie die Eigenschaft domainNameForAutomaticDiscoveryOfLDAPServers, um die LDAP-Servernamen ungeachtet dessen, welcher LDAP-Server im LDAP-Repository konfiguriert ist, dynamisch zur Ausführungszeit zu suchen.

Sie können den Domänenname des LDAP-Servers definieren, für den entsprechende LDAP-Server in der zugehörigen DNS-Konfigurationsdatei in Form von SRV-Datensätzen, wie in den folgenden Beispielen gezeigt, definiert sind:
ldap._tcp.ibm.com 86400 IN SRV 0 0 389 bigbox.ibm.com
ldap._tcp.ibm.com 86400 IN SRV 10 20 1389 smallbox1.ibm.com
Wenn die Eigenschaft domainNameForAutomaticDiscoveryOfLDAPServers definiert ist, sucht das föderierte Repository nach LDAP-Servern in der DNS-Konfigurationsdatei und setzt nachfolgende JNDI-Aufrufe an diesen Server ab.

Sie können die Eigenschaft domainNameForAutomaticDiscoveryOfLDAPServers mit dem Befehl setIdMgrCustomProperty wie folgt definieren: $AdminTask setIdMgrCustomProperty {-id <Name_des_LDAP-Repositorys> -name <Eigenschaftsname> -value <Wert>}

Beispiel:
$AdminTask setIdMgrCustomProperty {-id LDAP1 -name domainNameForAutomaticDiscoveryOfLDAPServers -value “dc=ibm,dc=com”}
Das folgende Beispiel zeigt eine LDAP-Repository-Konfiguration mit der Eigenschaft domainNameForAutomaticDiscoveryOfLDAPServers:
<config:repositories xsi:type="config:LdapRepositoryType" adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
        id="LDAP1" isExtIdUnique="true" supportAsyncMode="false" supportExternalName="false"
        supportPaging="false" supportSorting="false" supportTransactions="false" certificateFilter=""
        certificateMapMode="exactdn" ldapServerType="IDS" translateRDN="false">
   <config:baseEntries name="o=ldap" nameInRepository="o=ldap"/>
   <config:loginProperties>uid</config:loginProperties>
   <config:CustomProperties name="domainNameForAutomaticDiscoveryOfLDAPServers" value="dc=ibm,dc=com"/>
   <config:ldapServerConfiguration primaryServerQueryTimeInterval="15" returnToPrimaryServer="true"
          sslConfiguration="">
        <config:ldapServers authentication="simple" bindDN="cn=root" bindPassword="{xor}LTAwK25tbA=="
            connectionPool="false" connectTimeout="0" derefAliases="always" referal="ignore"
            sslEnabled="false">
            <config:connections host="localhost" port="389"/>
        </config:ldapServers>
   </config:ldapServerConfiguration>
</config:repositories>
Die Eigenschaft domainNameForAutomaticDiscoveryOfLDAPServers überschreibt die LDAP-Server-Konfigurationsgruppe im LDAP-Repository und ruft den Namen und die Portnummer des LDAP-Servers aus der DNS-Konfigurationsdatei ab.

Die folgende URL des föderierten LDAP-Repositorys wird generiert und verwendet, um die LDAP-Serverdatensätze zu suchen: ldap:///dc=ibm,dc=com.

Wenn JNDI die URL als Domänennamen empfängt, wird der LDAP-Server aus der DNS-Konfigurationsdatei abgerufen. Wenn einer der LDAP-Server inaktiv wird, startet JNDI einen anderen LDAP-Server, der in der DNS-Konfigurationsdatei für diese Domäne definiert ist.

minimizeContextPoolThreadBlock

Die angepasste Eigenschaft minimizeContextPoolThreadBlock wird verwendet, um das Verhalten für das Sperren von Threads zu definieren, das Anwendung findet, wenn ein LDAP-Server inaktiv ist und versucht wird, Informationen vom Server zu lesen. Wenn der Wert der Eigenschaft true ist, wird nur eine minimale Anzahl von Threads bei Leseoperationen geblockt und die restlichen Threads schlagen umgehend ohne Warnung fehl. Ist der Wert der Eigenschaft false, wird jeder Thread, der die Leseanforderung absetzt, geblockt, bis für den angeforderten LDAP-Server ein Kontext erstellt wird oder bei der Kontexterstellung das Zeitlimit überschritten wird. Die Standardzeit für die Kontexterstellung beträgt 120 Sekunden.
Information Wert
Datentyp Boolean
Standardwert True

maxThreadsToBlock

Die Eigenschaft maxThreadsToBlock wird mit der Eigenschaft minimizeContextPoolThreadBlock verwendet. Wenn die Eigenschaft minimizeContextPoolThreadBlock auf true gesetzt ist, bestimmt maxThreadsToBlock die maximale Anzahl von Threads, die geblockt werden müssen, sobald eine Leseoperation für den LDAP-Server ausgeführt wird.
Information Wert
Datentyp Integer
Standardwert 5

bindTimeout

Die angepasste Eigenschaft bindTimeout gibt die Zeit in Millisekunden an, in der Bindungen vom Typ quick überwacht werden. Alle Bindungen, die mehr Zeit als angegeben benötigen, werden dem Protokoll hinzugefügt, falls das Traceprotokoll aktiviert ist.
Information Wert
Datentyp Millisekunden
Standardwert 1000


Rechtliche Hinweise | Feedback