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
- 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
- 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.
- 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: 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
- 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.
- Validez le fichier de propriétés.
Exécutez la commande validateConfigProperties.
Voir la rubrique sur la validation des fichiers de propriétés.
- Copiez le fichier de propriétés portable extrait vers un autre environnement.
- 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.
- 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: 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.