Application de fichiers de propriétés portables à plusieurs environnements

Utilisez l'outil wsadmin pour extraire un fichier de propriétés à partir d'une cellule, modifier certaines variables de l'environnement dans le fichier de propriétés extrait, puis appliquer le fichier de propriétés modifié à une autre cellule. La modification des variables d'environnement rend un fichier de propriétés portable.

Avant de commencer

Si le fichier de propriétés à modifier a été créé avant la version 7.0.0.7 du produit, examinez-le et déterminer s'il contient un ID XMI, tel que :

#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=ID#VirtualHost_1
#
#Properties
#
name=default_host

EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell

Un ID XMI est un identificateur unique qu'un produit antérieur à la version 7.0.0.7 génère lors de la création d'un objet de configuration. Un ID XMI peut être un autre environnement d'un même objet. Dans cet exemple, la ressource VirtualHost de l'hôte par défaut a l'ID XMI VirtualHost_1. Dans un autre environnement, l'ID XMI peut être une valeur différente, telle que VirtualHost_2. Les fichiers de propriétés ayant des identificateurs XMI ne sont pas portables. Vous ne pouvez pas appliquer des propriétés extraites ayant des identificateurs XMI à un autre environnement sans modifier préalablement les identificateurs de ressource.

La même section d'hôte virtuel dans un fichier de propriétés ayant des identificateurs de ressource portables se présente comme suit :

#
# SubSection 1.0 # Virtual Hosts
#
ResourceType=VirtualHost
ImplementingResourceType=VirtualHost
ResourceId=Cell=!{cellName}:VirtualHost=default_host
#
#Properties
#
name=default_host

EnvironmentVariablesSection
#Environment Variables
cellName=myNode04Cell

Dans cet exemple, name est utilisé comme attribut de clé pour identifier l'objet VirtualHost de manière unique dans un environnement. Un objet peut avoir plusieurs attributs de clé pour l'identifier de manière unique parmi les différentes instances de même type.

Pourquoi et quand exécuter cette tâche

Vous pouvez appliquer des fichiers de propriétés ayant des identificateurs de ressource portables à un autre environnement.

Pour extraire un fichier de propriétés pour qu'il ait des identificateurs de ressource portables, utilisez la commande extractConfigProperties avec l'option PortablePropertiesFile affectée de la valeur true. Les fichiers de propriétés extraits avec cette option sont portables. Les fichiers de propriétés extraits n'identifient pas chaque ressource de manière unique. Un identificateur de ressource peut avoir plusieurs paires nom d'attribut-valeur. Par exemple, un attribut nodeName identifie un noeud et un attribut serverName identifie un serveur.

Par défaut, un fichier de propriétés n'est pas portable. Toutefois, un fichier de propriétés extrait avec l'option PortablePropertiesFile affectée de la valeur true est portable.

Après avoir extrait un fichier de propriétés à l'aide de l'option PortablePropertiesFile définie sur true, modifiez EnvironmentVariablesSection dans le fichier de propriétés, copiez les fichiers de propriétés dans l'environnement cible, puis exécutez la commande applyConfigProperties afin d'appliquer le fichier de propriétés à une autre cellule.

Vous pouvez également utiliser le mode interactif avec ces commandes, tel qu'illustré dans la syntaxe ci-après :
AdminTask.command_name('-interactive')

Procédure

  1. Démarrez l'outil de scriptage wsadmin.
    Pour démarrer wsadmin en utilisant le langage Jython, exécutez la commande suivante depuis le répertoire bin du profil du serveur :
    wsadmin -lang jython
  2. Extrayez un fichier de propriétés en utilisant la commande extractConfigProperties avec l'option PortablePropertiesFile affectée de la valeur true.

    Par exemple, pour extraire le fichiers de propriétés du serveur server1 dans le fichier server.props dans un format portable, exécutez la commande wsadmin suivante :

    AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server=server1 
    -options [[PortablePropertiesFile true]] ]')

    Si un fichier de propriétés fait référence à une ressource de type Serveur, Noeud, Application, Cluster ou AuthorizationGroup qui n'existe pas dans l'environnement cible, affectez à l'option GenerateTemplates la valeur true:

    AdminTask.extractConfigProperties('[-propertiesFileName server.props -configData Server= 
    -options [[GenerateTemplates true][PortablePropertiesFile true]] ]')

    Lorsque vous utilisez l'option GenerateTemplates, le fichier de propriétés extrait contient des sections de propriétés qui permettent de créer un autre objet de même type. Par défaut, cette option est désactivée.

  3. Facultatif : Ouvrez le fichier de propriétés extrait dans un éditeur et vérifiez que les identificateurs de ressource sont portables.

    Les fichiers de propriétés extraits n'identifient pas chaque ressource de manière unique. Les exemples suivants montrent des identificateurs portables dans diverses sous-sections des fichiers de propriétés.

    Exemple 1 : utilisation d'un nom d'attribut et d'une valeur pour un identificateur de ressource

    Dans cet exemple, jndiName est un identificateur de ressource portable qui identifie une source de données :

    #
    # SubSection 1.0.1.0 # DataSource attributes
    #
    Resou:rceType=DataSource
    ImplementingResourceType=JDBCProvider
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=Derby JDBC
     Provider(XA):DataSource=jndiName#jdbc/DefaultEJBTimerDataSource
    Exemple 2 : utilisation de plusieurs paires nom d'attribut-valeur pour un identificateur de ressource

    Dans cet exemple, les attributs nodeName et serverName identifient conjointement la ressource coreGroupServer.

    #
    # SubSection 1.0.8.0 # CoreGroupServer Section
    #
    ResourceType=CoreGroupServer
    ImplementingResourceType=CoreGroup
    ResourceId=Cell=!{cellName}:CoreGroup=!{coreGroup}:CoreGroupServer=nodeName#myNode04,serverName#server1
    AttributeInfo=coreGroupServers
    Exemple 3 : identificateur de ressource singleton

    Dans cet exemple, il existe un seul objet Security dans la cellule. Comme l'objet Security est un objet singleton, aucun attribut n'est nécessaire pour identifier cette ressource de manière unique.

    #
    # SubSection 1.0 # Security Section
    #
    ResourceType=Security
    ImplementingResourceType=Security
    ResourceId=Cell=!{cellName}:Security=
    Eviter les incidents Eviter les incidents: Certaines ressources, telles que JDBCProvider et ThreadPool, peuvent être créées avec un même nom plusieurs fois. La valeur du nom est l'attribut de clé de ces objets. Ne créez pas plusieurs instances de ces objets avec le même nom dans une portée.gotcha
  4. Modifiez le fichier de propriétés de manière appropriée.
    • Si le fichier de propriétés extrait portable fait référence à une ressource de type Serveur, Noeud, Application, Cluster ou AuthorizationGroup qui n'existe pas dans l'autre environnement et que la commande extractConfigProperties a été exécutée avec l'option GenerateTemplates affectée de la valeur true, modifiez le fichier de propriétés pour pouvoir créer la ressource.

      L'option GenerateTemplates permet de créer un autre serveur similaire à un serveur existant. Par exemple, lorsque les propriétés d'un serveur sont extraites en utilisant cette option, le fichier de propriétés extrait contient un modèle pour créer un autre serveur. La section du modèle est ignorée par défaut. Si vous définissez SKIP=false et spécifiez ensuite les propriétés nécessaires pour créer un objet, le produit crée un objet lorsque la commande applyConfigProperties est exécutée et il fournit le fichier de propriétés modifié. Comme les sections suivantes contiennent les propriétés de configuration d'un serveur existant et que ces sections sont traitées lorsque la commande applyConfigProperties est exécutée, le nouveau serveur a la même configuration que l'ancien serveur duquel le fichier des propriétés a été extrait.

      Vous devez modifier la section d'environnement pour refléter le nouveau serveur créé en changeant les variables nodeName, cellName etserverName.

      Cette option génère une section de propriétés de modèle devant chaque section de serveur, cluster, application et d'autorisation. Les sections sont désactivées par défaut.

      Pour chaque objet qui n'existe pas dans l'environnement cible, modifiez la section correspondant à l'objet. Insérez des valeurs de propriétés et supprimez SKIP=true. Définissez les variables d'environnement à la fin du fichier de propriétés, qui reflètent le nouvel environnement cible.

    • Ne modifiez pas ou ne supprimez pas les propriétés utilisées comme clé pour identifier un objet.

      Si vous modifiez ou supprimez un attribut de clé dans un objet, les sections suivantes du fichier des propriétés ne doivent pas faire de nouveau référence à l'objet. La ressource définie dans les sections suivantes sera introuvable.

      Par exemple, examinez les propriétés d'hôte virtuel dans les sections suivantes :

      ResourceType=VirtualHost
      ImplementingResourceType=VirtualHost
      ResourceId=Cell=!{cellName}:VirtualHost=admin_host
      #
      #Properties
      #
      name=admin_host #required
      #
      # SubSection 1.0.1 # MimeTypes section
      #
      ResourceType=VirtualHost
      ImplementingResourceType=VirtualHost
      ResourceId=Cell=!{cellName}:VirtualHost=admin_host
      AttributeInfo=mimeTypes(type,extensions)

      Si vous remplacez name=admin_host par name=my_host, la section Mime Types contenant ResourceId==!{cellName}:VirtualHost=admin_host ne trouvera pas la ressource définie par ResourceId, car le nom a été changé dans la section précédente. De même, si vous supprimez name=admin_host, la section Mime Types ne trouvera pas la ressource définie par ResourceId.

  5. Validez le fichier de propriétés.

    Exécutez la commande validateConfigProperties. Voir la rubrique sur la validation des fichiers de propriétés.

  6. Copiez le fichier de propriétés portable extrait vers un autre environnement.
  7. Si ce fichier fait référence à une ressource de type Serveur, Noeud, Application, Cluster ou AuthorizationGroup qui n'existe pas dans l'environnement cible et que la commande extractConfigProperties n'a pas été exécutée avec l'option GenerateTemplates affectée de la valeur true, créez la ressource dans l'autre environnement.

    Comme le fichier de propriétés s'appliquait initialement à un environnement différent, un identificateur de ressource dans le fichier peut faire référence à une ressource qui n'existe pas dans l'environnement cible. Si une ressource de type Serveur, Noeud, Application, Cluster ou AuthorizationGroup n'existe pas dans l'environnement cible et que le fichier des propriétés ne permet pas de créer la ressource, créez la ressource dans l'environnement cible avant d'appliquer les propriétés de la ressource. En outre, un attribut peut faire référence à une autre ressource. Vérifiez que toutes les ressources référencées existent et, si nécessaire, créez les ressources de type Serveur, Noeud, Application, Cluster ou AuthorizationGroup qui manquent.

  8. Appliquez le fichier de propriétés portable extrait dans l'autre environnement en utilisant la commande applyConfigProperties.

    Par exemple, pour appliquer le fichier de propriétés server.props et générer le rapport rep.txt, exécutez la commande wsadmin suivante :

    AdminTask.applyConfigProperties('[-propertiesFileName server.props -reportFileName rep.txt]')

    Si une ressource est définie dans le fichier de propriétés existe dans l'environnement cible et que la valeur de la propriété définie dans le fichier des propriétés est identique à celle définie dans l'environnement cible, la propriété est ignorée ou elle n'est pas définie dans l'environnement cible. Le produit applique uniquement les propriétés qui sont différentes de celles définies dans le fichier des propriétés.

    Si une ressource définie dans le fichier des propriétés n'existe pas dans l'environnement cible, le produit crée une ressource et définit toutes les propriétés de la nouvelle ressource depuis les valeurs de la ressource dans le fichier des propriétés. Le produit ne crée pas des ressources de type Server, Noeud, Application, Cluster ou AuthorizationGroup, à moins que la commande extractConfigProperties ait été exécutée avec l'option GenerateTemplates affectée de la valeur true et que le fichier des propriétés définit une ou plusieurs ressources de ce type.

    Eviter les incidents Eviter les incidents: Si l'attribut d'une ressource dans le fichier des propriétés fait référence à une autre ressource qui n'existe pas dans l'environnement cible, la ressource référencée n'est alors pas créée par la commande applyConfigProperties. Par exemple, dans le fichier de propriétés suivant, coreGroupName est un attribut de la ressource HAManagerService et référence une ressource coregroup par son nom. Si la ressource coregroup appelée myCoreGroup n'existe pas dans l'environnement cible, l'application du fichier de propriétés avec la commande applyConfigProperties ne crée pas la ressource coregroup.
    #                                                                           
    # SubSection 1.0 # HAManagerService Section                                 
    #                                                                           
    ResourceType=HAManagerService                                               
    ImplementingResourceType=HAManagerService                                   
    ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:HAMana    
    gerService=                                                                 
    AttributeInfo=hamanagerservice                                              
    #                                                                           
                                                                                
    #                                                                           
    #Properties                                                                 
    #                                                                           
    isAlivePeriodSec=120 #integer,required,default(120)                         
    transportBufferSize=10 #integer,required,default(1)                         
    enable=true #boolean,default(false)                                         
    context=null                                                                
    activateEnabled=true #boolean,default(false)                                
    description=Template version of HAManager service.                          
    coreGroupName=myCoreGroup
    gotcha

Résultats

L'environnement cible est mis à jour par le fichier de propriétés appliqué.

Que faire ensuite

Sauvegardez les modifications de la configuration.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_portable_prop
Nom du fichier : txml_portable_prop.html