Modèles dynamique et statique : création de nouvelles entités et propriétés en phase d'exécution

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

  1. 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.

  2. 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>
    Remarque : Pour plus d'informations sur l'utilisation des objets de données propertySchema et extensionPropertySchema, voir la section Schéma de propriété étendu de la rubrique Prérequis pour la programmation. Reportez-vous également à la rubrique Configuration d'un référentiel d'extension de propriété dans une configuration de référentiel fédéré dans le centre de documentation WebSphere Application Server.

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.



Conditions d'utilisation | Commentaires