Virtual member manager est configuré pour utiliser le modèle dynamique ou le
modèle statique. En phase d'exécution, vous pouvez créer de nouveaux types d'entité, de nouveaux
types de propriété et ajouter des types de propriétés, existants ou nouveaux,
aux nouveaux types d'entité.
Pourquoi et quand exécuter cette tâche
Vous devez appeler l'API createSchema de virtual member manager pour créer des types d'entité et de propriété et ajouter les types de propriété existants et nouveaux aux nouveaux types d'entité en phase d'exécution sans redémarrer virtual member manager.
Prêts à l'emploi, les
adaptateurs LDAP et BDD prennent en charge ce type de procédure. Dans cet exemple, vous
souhaitez créer une nouvelle entité appelée ContactPerson qui est une extension du type
d'entité intégrée PersonAccount de virtual member manager. Vous souhaitez également créer un nouveau type de
propriété appelé cellPhone et l'ajouter au type d'entité de l'exemple précédent. Cet exemple utilise un adaptateur LDAP.
Procédez comme suit :
Procédure
- Si les adaptateurs sous-jacents
incluent l'adaptateur LDAP, vérifiez que le schéma de l'attribut LDAP
correspondant du nouveau type de propriété est défini sur le serveur LDAP et
contenu dans les classes d'objets LDAP du type d'entité. Virtual member manager ne fournit pas la fonction de création et de mise à jour
du schéma LDAP sur le serveur LDAP. Dans cet exemple, la classe d'objets
eContactPerson et l'attribut cellularTelephoneNumber doivent être créés s'ils
ne sont pas prédéfinis.
Si
les adaptateurs sous-jacents incluent l'adaptateur BDD, aucune préparation
supplémentaire n'est nécessaire.
- Côté client, vous devez construire un graphique de données pour créer le nouveau type de propriété.
L'objet de données EntitySchema permet de créer le nouveau type d'entité et
PropertySchema, le nouveau type de propriété. Les
deux objets de données doivent indiquer l'URI de l'espace de nom sous lequel
les nouveaux types d'entité et de propriété sont créés. Le nouveau type
d'entité doit indiquer le type d'entité parent dont il est une extension.
Outre les informations relatives au schéma, les deux objets de données
indiquent les informations de configuration nécessaires à virtual member
manager et à l'adaptateur sous-jacent (adaptateur LDAP) pour prendre en charge
les nouveaux types d'entité et de propriété. Par exemple, le parent par
défaut et la propriété RDN sont indispensables pour ajouter cette nouvelle
entité au fichier XML de configuration virtual member manager (wimconfig.xml).
Le
parent par défaut défini dans le domaine est créé via le Gestionnaire de configuration. L'adaptateur
LDAP a besoin des attributs objectClasses et objectClassForCreate pour associer
la nouvelle entité aux classes d'objets LDAP correspondantes. Pour une nouvelle
propriété, l'adaptateur LDAP a besoin du nom de l'attribut LDAP correspondant,
qui peut être différent du nom de propriété. S'ils ne sont pas identiques, vous devez
ajouter une configuration d'attribut LDAP et indiquer le nom de la propriété
virtual member manager correspondante. Pour plus d'informations sur la configuration de cette interface de ligne de commande, reportez-vous à la commande addIdMgrLDAPAttr dans la rubrique Groupe de commandes IdMgrRepositoryConfig pour l'objet AdminTask du centre de documentation de WebSphere Application Server.
Voici l'exemple de graphique de données. L'élément entitySchema permet de
définir le schéma de l'entité ContactPerson. L'élément entityConfig contient
des informations de configuration pour le type d'entité. Par exemple,
l'élément actionNotAllow est utilisé pour indiquer que ce type d'entité ne
peut être supprimé. L'élément propertySchema permet de définir le schéma
de la propriété cellPhone.
<?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>
Résultats
Côté client, l'application d'exploitation virtual member manager appelle l'API
createSchema de virtual member manager via le fournisseur de services local. Le fournisseur de services local détecte que cet appel modifie
le schéma et met à jour le schéma local (ECore) dès que l'appel de l'API createSchema est terminé.
Côté serveur, le gestionnaire de schémas reçoit l'appel de l'API du client.
Il
vérifie d'abord si les nouveaux types d'entité et de propriété existent déjà
et émet une exception le cas échéant. Puis il crée un nouveau modèle ECore
(EPackage) avec un URI d'espace de nom (http://www.yourco.com/wim/yourext) s'il
n'existe pas déjà. Ensuite, le schéma des nouveaux types d'entité et de
propriété sont ajoutés au modèle ECore dans la mémoire.
Le
gestionnaire de schémas ajoute le schéma du nouveau type d'entité et du
nouveau type de propriété au fichier wimxmlextension.xml. Si ce fichier n'existe pas, vous devez en créer un. Vous trouverez ci-dessous
un exemple de contenu du fichier wimxmlextension.xml à la fin de cette opération.
Remarque : Les
informations de configuration ne sont pas écrites dans ce fichier XML.
<?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>
Le gestionnaire de schémas appelle
ensuite le gestionnaire de configuration.
Ce
dernier ajoute les informations de configuration des nouveaux types au
fichier XML de configuration de virtual member manager (wimconfig.xml).
Vous
trouverez ci-dessous les sections ajoutées pour ce nouveau type d'entité
ContactPerson dans wimconfig.xml à la fin de cette opération.
<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>
Le gestionnaire de schémas
appelle ensuite le gestionnaire de référentiels.
Ce
dernier appelle la méthode de l'interface SPI createSchema de tous les adaptateurs.
Les adaptateurs qui prennent en charge la création de schéma peuvent exécuter
ensuite toutes les opérations nécessaires pour prendre en charge le nouveau
schéma. Par exemple, l'adaptateur LDAP actualise la mémoire cache afin de
refléter les modifications effectuées dans le schéma et la configuration.
L'adaptateur BDD crée le schéma de la nouvelle entité et de la nouvelle
propriété dans la base de données et actualise les mémoires cache.
Remarque : Les adaptateurs qui ne prennent pas en charge la création de schémas, par
exemple l'adaptateur de fichier qui ne permet pas de créer de nouveaux types en
phase d'exécution, émettent une exception OperationNotSupportedException.
Si au moins un adaptateur de référentiel prend en charge la création de
nouvelles entités et n'émet pas l'exception OperationNotSupportedException,
virtual member manager renvoie les ID des référentiels dans le graphique de
données de sortie.
Côté client, après
le renvoi de l'interface API createSchema, le fournisseur de services local
appelle l'interface API getEPackages pour extraire les derniers schémas. Il
enregistre de nouveau les schémas dans la machine virtuelle Java du client. Les
applications d'exploitation peuvent appeler l'interface API de création de
virtual member manager afin de créer une nouvelle entité de type ContactPerson
avec une propriété cellPhone. Il n'est pas nécessaire de redémarrer virtual
member manager pour valider les modifications effectuées sur les schémas.