Utilisation du groupe de commandes BLAManagement de l'objet AdminTask avec les scripts de wsadmin

Le langage de script Jython permet de configurer et d'administrer des applications de niveau métier à l'aide de l'outil wsadmin. Les commandes et paramètres du groupe BLAManagement peuvent être utilisés pour créer, éditer, exporter, supprimer et interroger des applications de niveau métier dans votre configuration.

Pour pouvoir configurer et administrer des applications de niveau métier, vous devez utiliser le rôle administratif Configurateur.

Un actif représente un ou plusieurs fichiers binaires d'application stockés dans un référentiel d'actifs. Il s'agit le plus souvent d'éléments de la logique métier de l'application, tels que des archives d'entreprise, des fichiers de bibliothèque ou d'autres fichiers de ressources. Utilisez les commandes suivantes pour gérer vos configurations d'actifs :
Une application de niveau métier est un artefact de configuration qui peut comporter zéro ou plusieurs unités de composition ou d'autres applications de niveau métier. Les applications de niveau métier sont des modèles d'administration qui définissent une application et qui peuvent contenir des fichiers EAR (Enterprise archive), des bibliothèques partagées, des applications PHP, etc. Utilisez les commandes suivantes pour configurer et administrer des applications de niveau métier :
Une unité de composition représente un actif dans une application de niveau métier. Une unité de composition permet au contenu de l'actif d'interagir avec d'autres actifs dans l'application. Elle permet aussi à l'environnement d'exécution du produit de charger et d'exécuter le contenu de l'actif. Utilisez les commandes suivantes pour gérer les configurations de vos unités de composition :

deleteAsset

La commande deleteAsset supprime un actif d'une configuration d'application de niveau métier. Avant d'utiliser cette commande, vérifiez qu'aucune unité de composition n'est associée à l'actif qui vous intéresse. La commande échoue si l'actif est associé à des unités de composition.

Objet cible

Aucun

Paramètres requis

-assetID
Indique l'ID configuration de l'actif à supprimer. Cette commande accepte des ID incomplets pour le paramètre assetID, tant que le système peut rattacher la chaîne à un actif unique. (Chaîne, obligatoire)

Paramètres optionnels

-force
Indique s'il faut forcer (ou non) le système à supprimer l'actif, même si ce dernier a des dépendances. (Booléen, facultatif)

Valeur renvoyée

La commande renvoie l'ID configuration de l'actif supprimé, comme l'illustre l'exemple suivant :
WebSphere:assetname=asset2.zip

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.deleteAsset('-assetID asset2.zip -force true')
  • A l'aide de la liste Jython :
    AdminTask.deleteAsset(['-assetID', 'asset2.zip', '-force', 'true'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.deleteAsset('-interactive')

editAsset

La commande editAsset modifie les options de configuration supplémentaires de l'actif. Vous pouvez l'utiliser pour modifier la description, l'URL de destination, les relations d'actif, les permissions de fichier et les paramètres de validation.

Objet cible

Aucun

Paramètres requis

-assetID
Indique l'ID configuration de l'actif à éditer. Ce paramètre accepte un ID configuration incomplet tant que le système peut rattacher la chaîne à un ID d'actif unique. (Chaîne, obligatoire)

Etapes facultatives

Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-AssetOptions
Utilisez le paramètre AssetOptions et les arguments suivants pour définir des propriétés supplémentaires de l'actif.
inputAsset (lecture seule)
Indique le module source de l'actif.
name (lecture seule)
Spécifie le nom de l'actif. La valeur par défaut de cet argument est le nom de fichier du module source.
defaultBindingProps (lecture seule)
Indique les propriétés de liaison par défaut de l'actif. Cet argument s'applique uniquement aux actifs d'entreprise. Dans le cas d'actifs externes à l'entreprise, indiquez un astérisque (*) pour la correspondance des masques. Pour les actifs d'entreprise, spécifiez la valeur .* pour définir l'argument comme valeur non nulle.
description
Donne une description de l'actif.
destinationUrl
Indique l'URL des fichiers binaires de l'actif à déployer.
typeAspect
Indique l'aspect du type d'actif.
relationship
Indique la relation de l'actif. Utilisez le signe plus (+) pour ajouter des actifs supplémentaires à une relation existante. Utilisez le symbole dièse (#) pour supprimer un actif existant d'une relation. Pour remplacer des relations existantes, utilisez la même syntaxe que pour la commande importAsset. Si l'actif indiqué dans la relation n'existe pas et ne peut être de ce fait ni ajouté, ni mis à jour, la commande renvoie une exception.
filePermission
Indique la configuration des permissions de fichier.
validate
Indique si l'actif doit être validé. La valeur par défaut est false. Le produit ne sauvegarde pas la valeur spécifiée pour la validation. Par conséquent, si vous choisissez de valider l'actif (true) maintenant et de l'éditer ultérieurement, au moment de cette édition, vous devrez activer de nouveau ce paramètre de sorte que le produit valide les fichiers mis à jour.
-UpdateAppContentVersions
Pour un actif EBA, utilisez cette étape et les arguments suivants pour sélectionner des versions de bundle pour l'actif.
Pour les utilisateurs en transition Pour les utilisateurs en transition: Dans WebSphere Application Server Version 7 Feature Pack for OSGi Applications and Java™ Persistence API 2.0, les modifications de bundle apportées à l'actif sont appliquées en redémarrant l'application de niveau métier. Dans la version 8.x, ces modifications sont appliquées via la mise à jour de l'unité de composition. La nouvelle approche dans la version 8.x signifie que de nombreuses modifications de bundle peuvent être appliquées sans redémarrer l'application de niveau métier en cours d'exécution. Pour activer cette nouvelle approche, le paramètre UpdateAppContentVersionsStep a été remplacé par le paramètre UpdateAppContentVersions, et au lieu de redémarrer l'application de niveau métier, vous exécutez la commande editCompUnit avec le paramètre CompUnitStatusStep.trns
nom_bundle
Spécifie le nom du bundle.
version_en_cours
Indique un numéro de version de bundle, par exemple 1.0.0, ou NON_DEPLOYE pour les bundles partagés (ou bundles d'utilisation) qui sont déclarés dans le manifeste d'application mais non déployés par l'environnement d'exécution. Cet argument décrit la configuration en cours du bundle et n'est pas utilisé pour changer la configuration.
préférence_mise_à_jour
Spécifie la nouvelle préférence de version de bundle. Il s'agit d'un numéro de version de bundle, par exemple 1.0.0, NON_DEPLOYE pour les bundles partagés, ou AUCUNE_PREF si vous voulez que le système choisisse une version de bundle à votre place. Si vous ne souhaitez pas mettre à jour la version d'un bundle donné, affectez à cet attribut la même valeur que celle que vous utilisez pour l'attribut version_en_cours.
Incluez une entrée (à savoir, nom_bundle version_en_cours et préférence_mise_à_jour) pour chaque bundle répertorié dans le manifeste d'application entre l'en-tête du contenu d'application (Application-Content) et l'en-tête du bundle d'utilisation (Use-Bundle). Incluez chaque bundle, que vous mettiez à jour ou non la version du bundle.
Spécifiez la syntaxe de la façon suivante :
AdminTask.editAsset('[
  -assetID asset_name 
  -UpdateAppContentVersions [
    [bundle_1_name current_version update_preference]
    [bundle_2_name current_version update_preference]
    [bundle_3_name current_version update_preference]
    [bundle_4_name current_version update_preference]
    [bundle_5_name current_version update_preference]
  ]]')

Valeur renvoyée

La commande renvoie l'ID configuration de l'actif qui vous intéresse.

Exemple d'utilisation en mode de traitement par lots

Utilisez les exemples suivants pour éditer un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.editAsset('-assetID asset3.zip –AssetOptions [[.* asset3.zip * "asset for testing"
       c:/installedAssets/asset3.zip/BASE/asset3.zip "" assetname=a.jar "" false]]')
  • A l'aide de la liste Jython :
    AdminTask.editAsset(['-assetID', 'asset3.zip', '–AssetOptions', '[[.* asset3.zip * "asset for testing"
       c:/installedAssets/asset3.zip/BASE/asset3.zip "" assetname=a.jar "" false]]'])
Utilisez les exemples suivants pour éditer un actif d'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.editAsset('-assetID defaultapp.ear –AssetOptions 
      [[.* defaultapp.ear .* "asset for testing" "" "" "" "" false]]')
  • A l'aide de la liste Jython :
    AdminTask.editAsset(['-assetID', 'defaultapp.ear', '–AssetOptions', 
       '[[.* defaultapp.ear .* "asset for testing" "" "" "" "" false]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.editAsset('-interactive')

exportAsset

La commande exportAsset exporte une configuration d'actif vers un fichier.

Objet cible

Aucun

Paramètres requis

-assetID
Indique l'ID configuration de l'actif à exporter. Ce paramètre accepte un ID configuration incomplet tant que l'ID correspond à un actif unique. (Chaîne, obligatoire)
-filename
Indique le nom du fichier vers lequel le système exporte la configuration d'actif. (DownloadFile, obligatoire)

Valeur renvoyée

La commande ne renvoie pas de sortie.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.exportAsset('-assetID asset2.zip –filename c:/temp/a2.zip')
  • A l'aide de la liste Jython :
    AdminTask.exportAsset(['-assetID', 'asset2.zip', '–filename', 'c:/temp/a2.zip'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.exportAsset('-interactive')

importAsset

La commande importAsset importe une configuration d'actif dans le référentiel d'actifs. Une fois les actifs importés, vous pouvez les ajouter à des applications de niveau métier en tant qu'unités de composition.

Objet cible

Aucun

Paramètres requis

-source
Indique le nom du fichier source à importer. (UploadFile, obligatoire)

Paramètres optionnels

-storageType
Stipule comment le système enregistre l'actif dans le référentiel. Le référentiel par défaut peut stocker les fichiers binaires complets, les métadonnées qu'ils contiennent ou ne stocker aucun fichier binaire. Indiquez FULL pour stocker les fichiers binaires complets, METADATA pour ne stocker que la partie des métadonnées ou NONE pour ne stocker aucun fichier binaire dans le référentiel d'actifs. La valeur par défaut est FULL. (Chaîne, optionnelle)

Etapes facultatives

Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-AssetOptions
Utilisez le paramètre AssetOptions et les arguments suivants pour définir des propriétés supplémentaires de l'actif.
inputAsset (lecture seule)
Indique le module source de l'actif.
name
Spécifie le nom de l'actif. Le nom du fichier d'extension de l'actif doit correspondre au nom du fichier d'extension du module source. La valeur par défaut de cet argument est le nom de fichier du module source.
defaultBindingProps (lecture seule)
Indique les propriétés de liaison par défaut de l'actif. Cet argument s'applique uniquement aux actifs d'entreprise. Dans le cas d'actifs externes à l'entreprise, indiquez un astérisque (*) pour la correspondance des masques. Pour les actifs d'entreprise, spécifiez la valeur .* pour définir l'argument comme valeur non nulle.
description
Donne une description de l'actif.
destinationUrl
Indique l'URL des fichiers binaires de l'actif à déployer.
typeAspect
Indique l'aspect du type d'actif. Spécifiez l'option typeAspect dans le format du nom d'objet, comme l'illustre la syntaxe suivante : spec=xxx
relationship
Indique la relation de l'actif. Utilisez le signe plus (+) pour indiquer plusieurs relations d'actif. La commande renvoie une exception si vous spécifiez des actifs qui n'existent pas dans la relation.
filePermission
Indique la configuration des permissions de fichier.

Les applications OSGi n'utilisent pas de valeur filePermission.

validate
Indique si l'actif doit être validé. La valeur par défaut est false. Le produit ne sauvegarde pas la valeur spécifiée pour la validation. Par conséquent, si vous choisissez de valider l'actif (true) maintenant et de l'éditer ultérieurement, au moment de cette édition, vous devrez activer de nouveau ce paramètre de sorte que le produit valide les fichiers mis à jour.

Les applications OSGi n'utilisent pas de valeur validate.

Valeur renvoyée

La commande renvoie l'ID configuration de l'actif créé par le système, comme l'illustre l'exemple suivant :
WebSphere:assetname=asset2.zip

Exemple d'utilisation en mode de traitement par lots

Utilisez les exemples suivants pour importer un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.importAsset('-source c:\ears\asset1.zip -storageType NONE')
  • A l'aide de la liste Jython :
    AdminTask.importAsset(['-source', 'c:\ears\asset1.zip', '-storageType', 'NONE'])
Utilisez les exemples suivants pour importer un actif externe à l'entreprise, définissez asset2.zip comme nom d'actif, enregistrez les fichiers binaires de métadonnées dans le référentiel d'actifs et définissez le répertoire de destination des fichiers binaires à déployer :
  • A l'aide de la chaîne Jython :
    AdminTask.importAsset('-source c:\ears\asset1.zip -storageType METADATA –AssetOptions 
      [[.* asset2.zip .* "asset for testing" c:/installedAssets/asset2.zip/BASE/asset2.zip "" "" "" "" false]]')
  • A l'aide de la liste Jython :
    AdminTask.importAsset(['-source', 'c:\ears\asset1.zip', '-storageType', 'METADATA', '–AssetOptions',
       '[[.* asset2.zip .* "asset for testing" c:/installedAssets/asset2.zip/BASE/asset2.zip "" "" "" "" false]]')
Utilisez les exemples suivants pour importer un actif externe à l'entreprise et spécifier des relations avec les actifs a.jar et b.jar :
  • A l'aide de la chaîne Jython :
    AdminTask.importAsset('[-source c:\ears\asset3.zip -storageType FULL –AssetOptions
       [[.* asset3.zip .* "asset for testing" "" spec=zip assetname=a.jar+assetname=b.jar "" false]]]')
  • A l'aide de la liste Jython :
    AdminTask.importAsset(['-source', 'c:\ears\asset3.zip', '-storageType', 'FULL', '–AssetOptions', 
      '[[.* asset3.zip .* "asset for testing" "" spec=zip assetname=a.jar+assetname=b.jar "" false]]'])
Utilisez les exemples suivants pour importer un actif d'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.importAsset('-source c:\ears\defaultapplication.ear –storageType FULL –AssetOptions
       [[.* defaultapp.ear .* "desc" "" "" "" false]]')
  • A l'aide de la liste Jython :
    AdminTask.importAsset(['-source', 'c:\ears\defaultapplication.ear', '–storageType', 
      'FULL', '–AssetOptions', '[[.* defaultapp.ear .* "desc" "" "" "" false]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.importAsset('-interactive')

listAssets

La commande listAssets affiche l'ID configuration de chaque actif présent dans une cellule.

Objet cible

Aucun

Paramètres optionnels

-assetID
Indique l'ID configuration de l'actif qui vous intéresse. Ce paramètre accepte un ID configuration incomplet tant que l'ID correspond à un actif unique. (Chaîne, optionnelle)
-includeDescription
Indique si chaque actif renvoyé par la commande doit être accompagné d'une description. Spécifiez true pour afficher les descriptions d'actif. (Chaîne, optionnelle)
-includeDeplUnit
Indique si chaque actif renvoyé par la commande doit être affiché avec les unités déployables. Spécifiez true pour afficher les unités déployables. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie une liste d'ID configuration pour les actifs qui vous intéressent. En fonction des valeurs spécifiées pour les paramètres, la commande peut afficher la description et les unités de composition déployables pour chaque actif, comme l'illustre l'exemple suivant :
WebSphere:assetname=asset1.zip
"asset for testing"

WebSphere:assetname=asset2.zip
"second asset for testing"
a.jar

WebSphere:aasetname=asset3.zip
"third asset for testing"
a1.jar+a2.jar

WebSphere:assetname=a.jar0
"a.jar for sharedlib"

WebSphere:assetname=b.jar
"b.jar for sharedlib"

WebSphere:assetname=defaultapp.ear
"default app"

Exemple d'utilisation en mode de traitement par lots

Utilisez les exemples suivants pour lister les différents actifs d'une cellule :
  • Avec Jython :
    AdminTask.listAssets()
Utilisez les exemples suivants pour lister les différents actifs d'une cellule :
  • A l'aide de la chaîne Jython :
    AdminTask.listAssets('-assetID asset1.zip')
  • A l'aide de la liste Jython :
    AdminTask.listAssets(['-assetID asset1.zip'])
Utilisez les exemples suivants pour lister tous les actifs, descriptions d'actifs et unités de composition déployables dans une cellule :
  • A l'aide de la chaîne Jython :
    AdminTask.listAssets('-includeDescription true –includeDeplUnit true')
  • A l'aide de la liste Jython :
    AdminTask.listAssets(['-includeDescription', 'true', '–includeDeplUnit', 'true')

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.listAssets('-interactive')

updateAsset

La commande updateAsset modifie un ou plusieurs fichiers ou fichiers de module d'un actif. Elle met à jour le fichier binaire de l'actif, mais non les unités de composition que le système déploie avec l'actif en tant qu'objet de support.

Objet cible

Aucun

Paramètres requis

-assetID
Indique l'ID configuration de l'actif à mettre à jour. Ce paramètre accepte un ID configuration incomplet tant que l'ID correspond à un actif unique. (Chaîne, obligatoire)
-operation
Indique l'opération à appliquer à l'actif qui vous intéresse. (Chaîne, obligatoire)
Le tableau suivant affiche les différentes opérations que vous pouvez appliquer à un actif :
Tableau 1. Opérations updateAsset prises en charge. Spécifiez l'une des opérations.
Opération Description
replace L'opération replace permet de remplacer le contenu de l'actif visé.
merge L'opération merge permet de mettre à jour plusieurs fichiers pour l'actif, mais ne met pas à jour tous les fichiers.
add L'opération add permet d'ajouter un nouveau fichier ou fichier de module.
addupdate L'opération addupdate permet d'ajouter ou de mettre à jour un fichier ou fichier de module. Si le fichier n'existe pas, le système le crée. Si le fichier existe, le système met à jour le fichier.
update L'opération update met à jour un fichier ou fichier de module.
suppression L'opération delete supprime un fichier ou fichier de module.
-contents
Indique le fichier dans lequel se trouve le contenu à ajouter ou à mettre à jour. Ce paramètre n'est pas requis pour l'opération delete. (UploadFile, facultatif)

Paramètres optionnels

-contenturi
Indique l'URI (Uniform Resource Identifier) du fichier à ajouter, mettre à jour ou supprimer de l'actif. Ce paramètre n'est pas requis pour les opérations merge ou replace. (Chaîne, optionnelle)

Etapes facultatives

Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-AssetOptions
Utilisez le paramètre AssetOptions et les arguments suivants pour définir des propriétés supplémentaires de l'actif.
name (lecture seule)
Spécifie le nom de l'actif. La valeur par défaut de cet argument est le nom de fichier du module source.
defaultBindingProps (lecture seule)
Indique les propriétés de liaison par défaut de l'actif. Cet argument s'applique uniquement aux actifs d'entreprise. Dans le cas d'actifs externes à l'entreprise, indiquez un astérisque (*) pour la correspondance des masques. Pour les actifs d'entreprise, spécifiez la valeur .* pour définir l'argument comme valeur non nulle.
description
Donne une description de l'actif.
destinationUrl
Indique l'URL des fichiers binaires de l'actif à déployer.
typeAspect
Indique l'aspect du type d'actif.
relationship
Indique la relation de l'actif. Utilisez le signe plus (+) pour ajouter des actifs supplémentaires à une relation existante. Utilisez le symbole dièse (#) pour supprimer un actif existant d'une relation. Pour remplacer des relations existantes, utilisez la même syntaxe que pour la commande importAsset. Si l'actif indiqué dans la relation n'existe pas et ne peut être de ce fait ni ajouté, ni mis à jour, la commande renvoie une exception.
filePermission
Indique la configuration des permissions de fichier.
validate
Indique si l'actif doit être validé. La valeur par défaut est false. Le produit ne sauvegarde pas la valeur spécifiée pour la validation. Par conséquent, si vous choisissez de valider l'actif (true) maintenant et de l'éditer ultérieurement, au moment de cette édition, vous devrez activer de nouveau ce paramètre de sorte que le produit valide les fichiers mis à jour.
updateAssociatedCUs
Indique si les unités de composition associées à un actif d'entreprise (Java EE) doivent être mises à jour. Cet argument s'applique uniquement aux actifs Java EE. La valeur par défaut est none. Indiquez all pour mettre à jour tous les actifs des unités de composition associées à l'actif Java EE.

Pour l'opération replace, indiquez des valeurs pour les arguments AssetOptionsname, defaultBindingProps, description, destinationUrl, typeAspect, relationship, filePermission, validate et updateAssociatedCUs. En dehors de replace, indiquez des valeurs pour les arguments AssetOptionsname et updateAssociatedCUs pour les autres opérations.

Valeur renvoyée

La commande renvoie l'ID configuration de l'actif qui vous intéresse.

Exemple d'utilisation en mode de traitement par lots

L'exemple suivant remplace le contenu d'un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.updateAsset('-assetID asset1.zip -operation replace -contents c:/temp/a.zip')
  • A l'aide de la liste Jython :
    AdminTask.updateAsset(['-assetID', 'asset1.zip', '-operation', 'replace', '-contents', 'c:/temp/a.zip'])
L'exemple suivant met partiellement à jour les fichiers d'un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.updateAsset('-assetID asset1.zip –operation merge –contents c:/temp/p.zip')
  • A l'aide de la liste Jython :
    AdminTask.updateAsset(['-assetID', 'asset1.zip', '–operation', 'merge', '–contents', 'c:/temp/p.zip'])
L'exemple suivant met à jour une ressource d'entreprise avec un fichier de module EJB (Enterprise JavaBeans) :
  • A l'aide de la chaîne Jython :
    AdminTask.updateAsset('-assetID defaultapp.ear –operation add –contents 
      c:/temp/filename.jar –contenturi filename.jar')
  • A l'aide de la liste Jython :
    AdminTask.updateAsset(['-assetID', 'defaultapp.ear', '–operation', 'add', '–contents', 
      'c:/temp/filename.jar', '–contenturi', 'filename.jar'])
L'exemple suivant remplace un actif Java EE et ses unités de composition à l'aide d'une opération replace :
  • A l'aide de la chaîne Jython :
    AdminTask.updateAsset('-assetID defaultapp.ear –operation replace –contents 
      c:/temp/newapp.ear –AssetOptions [[defaultapp.ear .* newdesc "" "" "" "" false all]]')
  • A l'aide de la liste Jython :
    AdminTask.updateAsset(['-assetID', 'defaultapp.ear', '–operation', 'replace', '–contents',
      'c:/temp/newapp.ear', '–AssetOptions [[defaultapp.ear .* newdesc "" "" "" "" false all]]'])
L'exemple suivant met à jour un actif Java EE et ses unités de composition à l'aide d'une opération merge :
  • A l'aide de la chaîne Jython :
    AdminTask.updateAsset('-assetID defaultapp.ear –operation merge –contents 
      c:/temp/newapp.ear –AssetOptions [[defaultapp.ear all]]')
  • A l'aide de la liste Jython :
    AdminTask.updateAsset(['-assetID', 'defaultapp.ear', '–operation', 'merge', '–contents',
      'c:/temp/newapp.ear', '–AssetOptions [[defaultapp.ear all]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.updateAsset('-interactive')

viewAsset

La commande viewAsset affiche les options supplémentaires de configuration d'un actif ainsi que les valeurs configurées.

Objet cible

Aucun

Paramètres requis

-assetID
Indique l'ID configuration de l'actif qui vous intéresse. Ce paramètre accepte un ID configuration incomplet tant que l'ID correspond à un actif unique. (Chaîne, obligatoire)

Paramètres optionnels

Aucun

Valeur renvoyée

La commande renvoie des informations de configuration sur l'actif qui vous intéresse, comme l'illustre l'exemple suivant :
Specify Asset options (AssetOptions)

Specify options for Asset.

*Asset Name (name): [defaultapp.ear]
Default Binding Properties (defaultBindingProps): 
 [defaultbinding.ejbjndi.prefix#defaultbinding.datasource.jndi#defaultbinding.datasource.username
#defaultbinding.datasource.password#defaultbinding.cf.jndi
#defaultbinding.cf.resauth#defaultbinding.virtual.host#defaultbinding.force]
Asset Description (description): []
Asset Binaries Destination Url (destination): [${USER_INSTALL_ROOT}/installedAssets/defaultapp.ear/BASE/defaultapp.ear]
Asset Type Aspects (typeAspect): [WebSphere:spec=j2ee_ear]
Asset Relationships (relationship): []File Permission (filePermission): [.*\\.dll=755#.*\\.so=755#.*\\.a=755#.*\\.sl=755]
Validate asset (validate): [false]

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.viewAsset('-assetID asset3.zip')
  • A l'aide de la liste Jython :
    AdminTask.viewAsset(['-assetID', 'asset3.zip'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.viewAsset('-interactive')

addCompUnit

La commande addCompUnit ajoute une unité de composition à une application de niveau métier spécifique. Une unité de composition représente un actif dans une application de niveau métier et permet au contenu de l'actif d'interagir avec d'autres actifs de l'application. Elle permet aussi à l'environnement d'exécution du produit de charger et d'exécuter le contenu de l'actif.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)
-cuSourceID
Indique l'ID configuration source de l'unité de composition à ajouter. Vous pouvez spécifier un ID d'actif ou un ID d'application de niveau métier. (Chaîne, obligatoire)

Paramètres optionnels

-deplUnits
Indique les unités déployables à déployer pour l'actif. Vous pouvez spécifier toutes les unités déployables ou un sous-ensemble de celles-ci, ou utiliser la valeur par défaut comme bibliothèque partagée. Si vous n'indiquez pas ce paramètre, le système déploie toute unité déployable. (Chaîne, optionnelle)
Pour des actifs Java EE, le système ignore ce paramètre -deplUnits et quelle que soit la valeur spécifiée, peut ajouter des actifs Java EE comme éléments de cette commande.
-cuConfigStrategyFile
Indique le chemin complet du fichier contenant les propriétés de liaison par défaut personnalisées. Ce paramètre s'applique uniquement aux actifs d'entreprise. (Chaîne, optionnelle)
-defaultBindingOptions
Indique les propriétés de liaison JNDI (Java Naming and Directory Interface) facultatives d'un actif d'entreprise. Les propriétés de liaison disponibles dépendent du type d'actif d'entreprise dépendent du type d'actif d'entreprise. Utilisez le format propriété=valeur pour spécifier une propriété de liaison par défaut. Pour indiquer plusieurs propriétés, séparez chaque instruction propriété=valeur par le délimiteur #.
Vous pouvez spécifier les propriétés de liaison immédiatement lors de la création de l'actif ou ultérieurement, lors de l'ajout de l'actif en tant qu'unité de composition à une application de niveau métier. Si vous spécifiez les propriétés de liaison ultérieurement, vous pouvez utiliser un fichier de stratégie pour les spécifier. (Chaîne, optionnelle)
Indiquez les options suivantes avec le paramètre defaultBindingOptions :
Tableau 2. addCompUnit -defaultBindingOptions propriétés de liaison prises en charge. Indiquez une propriété de liaison qui est prise en charge pour le type d'actif.
Type d'actif d'entreprise Propriétés de liaison prises en charge
Enterprise JavaBeans (EJB)

defaultbinding.ejbjndi.prefix

defaultbinding.force

Source de données

defaultbinding.datasource.jndi

defaultbinding.datasource.username

defaultbinding.datasource.password

defaultbinding.force

Fabrique de connexions

defaultbinding.cf.jndi

defaultbinding.cf.resauth

defaultbinding.force

Hôte virtuel

defaultbinding.virtual.host

defaultbinding.force

Etapes facultatives

Vous pouvez également utiliser des paramètres facultatifs pour définir des propriétés supplémentaires pour la nouvelle unité de composition. Ces étapes ne s'appliquent pas aux actifs d'entreprise. Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-CUOptions
Spécifie des propriétés supplémentaires pour l'unité de composition. Indiquez les options suivantes dans le cadre de l'étape CUOptions :
parentBLA (lecture seule)
Indique l'application de niveau métier parent pour la nouvelle unité de composition.
backingID (lecture seule)
Indique l'ID source de l'unité de composition.
name
Indique le nom de l'unité de composition.
description
Spécifie une description pour l'unité de composition.
startingWeight
Indique la pondération de démarrage de l'unité de composition. Les valeurs prises en charge sont comprises entre 1 et 2147483647, la valeur entière maximale.
startedOnDistributed
Indique si l'unité de composition doit être démarrée après avoir distribué les modifications sur les noeuds cible. La valeur par défaut est false.
restartBehaviorOnUpdate
Indique les noeuds à redémarrer après modification de l'unité de composition. Spécifiez ALL pour redémarrer chaque noeud cible, DEFAULT pour redémarrer les noeuds commandés par les plug-ins synchronisés ou NONE pour que le système ne redémarre aucun noeud.
Par exemple, utilisez la syntaxe suivante pour cette étape : -CUOptions [[.* .* cu4 "cu4 desc" 0 false DEFAULT]]
-MapTargets
Spécifie des propriétés supplémentaires pour le mappage cible de l'unité de composition. Indiquez les options suivantes dans le cadre de l'étape MapTargets :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
Pour un actif EBA (enterprise bundle archive), cet identificateur URI est ebaDeploymentUnit.
server
Indique la ou les cibles sur lesquelles déployer les unités de composition. La valeur par défaut est server1. Utilisez le signe plus (+) pour indiquer plusieurs cibles. Utilisez le signe plus (+) comme préfixe pour ajouter une cible supplémentaire. Précisez le format de nom d'objet complet pour chaque serveur qui n'est pas un serveur WebSphere Application Server.
Par exemple, utilisez la syntaxe suivante pour cette étape : -MapTargets [[a1.jar cluster1+cluster2] [a2.jar +server2]]
-ActivationPlanOptions
Spécifie des propriétés supplémentaires pour le plan d'activation d'une unité de composition. Indiquez les options suivantes dans le cadre de l'étape ActivationPlanOptions :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
activationPlan
Indique une liste de composants d'exécution constitutifs du plan d'activation. Spécifiez chaque plan d'activation sous la forme specName=xxx,specVersion=yyy, où specName représente le nom de la spécification et est obligatoire. Utilisez le signe plus (+) pour indiquer plusieurs plans d'activation.
Par exemple, utilisez la syntaxe suivante pour cette étape : -ActivationPlanOptions [[a1.jar specname=actplan0+specname=actplan1] [a2.jar specname=actplan1+specname=actplan2]]
Pour un actif EBA, utilisez les valeurs par défaut suivantes : -ActivationPlanOptions [[default ""]]
-CreateAuxCUOptions
Spécifie des propriétés supplémentaires pour une unité de composition secondaire. Utilisez ce paramètre si la source de l'unité de composition est un actif qui correspond à un actif qui n'a pas d'unité de composition associée dans l'application de niveau métier. Indiquez les options suivantes dans le cadre de l'étape CreateAuxCUOptions :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
inputAsset (lecture seule)
Indique l'ID source de l'unité de composition.
cuID
Indique l'ID d'unité de composition que le système crée pour l'actif. Si vous ne souhaitez pas créer une nouvelle unité de composition, ne spécifiez pas cet argument.
matchTarget
Indique si les cibles de l'unité de composition secondaire de la dépendance doivent être mises en correspondance avec les cibles de la nouvelle unité de composition. La valeur par défaut est true.
Le produit ne sauvegarde pas la valeur spécifiée pour matchTarget. Ainsi, si vous optez pour une non correspondance à la cible (false) maintenant et de l'éditer ultérieurement, lorsque vous éditez l'unité de composition, vous devez désactiver à nouveau ce paramètre pour que le produit ne correspondent pas aux cibles.
Par exemple, utilisez la syntaxe suivante pour cette étape : –CreateAuxCUOptions [[a1.jar a.jar auxCU true] [a2.jar a.jar defaultCU false]]
-RelationshipOptions
Spécifie des propriétés supplémentaires pour des relations entre des actifs, des unités de composition et des applications de niveau métier. Utilisez ce paramètre si l'ID source de l'unité de composition est un actif qui a une unité de composition correspondante dans l'application de niveau métier. Indiquez les options suivantes dans le cadre de l'étape RelationshipOptions :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
relationship
Définit les relations de l'unité de composition. Spécifiez le nom d'objet de l'unité de composition sous la forme : cuName=xxx. Utilisez le signe plus (+) pour indiquer plusieurs noms d'objets d'unité de composition dans la relation. Si l'unité de composition spécifiée dans la relation n'existe pas dans la même application de niveau métier, le système retourne une erreur.
matchTarget
Indique si les cibles associées à la relation d'unité de composition doivent être mises en correspondance avec les cibles de la nouvelle unité de composition. La valeur par défaut est true.
Le produit ne sauvegarde pas la valeur spécifiée pour matchTarget. Ainsi, si vous optez pour une non correspondance à la cible (false) maintenant et de l'éditer ultérieurement, lorsque vous éditez l'unité de composition, vous devez désactiver à nouveau ce paramètre pour que le produit ne correspondent pas aux cibles.
Par exemple, utilisez la syntaxe suivante pour cette étape : –RelationshipOptions [[a1.jar a.jar auxCU true] [a2.jar a.jar defaultCU false]]
-ContextRootStep
Pour un actif EBA, les racines de contexte déterminent l'emplacement des pages Web d'un bundle d'applications Web (WAB) lors de l'exécution.
La racine de contexte que vous spécifiez ici est combinée avec le mappage de serveur défini pour composer l'URL complète que vous saisissez pour accéder aux pages du bundle d'applications Web (WAB). Par exemple, si l'hôte par défaut du serveur d'applications correspond à www.example.com:8080 et que la racine de contexte du bundle d'applications Web correspond à /sample, les pages Web sont disponibles à l'adresse www.example.com:8080/sample.
Vous devez répertorier les racines de contexte de tous les modules WAB contenus dans l'application OSGi.
Spécifiez la syntaxe de cette étape de la façon suivante :
  -ContextRootStep [
    [bundle_symbolic_name_1 bundle_version_1 context_root_1]
    [bundle_symbolic_name_2 bundle_version_2 context_root_2]]
Par exemple, pour un fichier EBA contenant deux archives WAB (com.ibm.ws.eba.helloWorldService.web à la version 1.0.0, qui doit être mappé à /hello/web, et com.ibm.ws.eba.helloWorldService.withContextRoot à la version 0.9.0, qui doit être mappé à /hello/service), cet aspect de la commande se présente comme suit :
  -ContextRootStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"] 
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
-VirtualHostMappingStep
Pour un actif EBA, vous utilisez un hôte virtuel pour associer un port unique à un module ou à une application. Les alias d'un hôte virtuel identifient les numéros de port définis pour cet hôte virtuel. Le numéro de port indiqué dans un alias d'hôte virtuel est utilisé dans l'URL pour accéder aux artefacts tels que les servlets et les fichiers JSP (JavaServer Page) d'un module Web. Par exemple, l'alias myhost:8080 correspond à la portion nom_hôte:numéro_port de l'URL http://myhost:8080/sample.
Chaque bundle d'applications Web (WAB) contenu dans un actif déployé doit être mappé sur un hôte virtuel. Ces bundles peuvent être installés sur le même hôte virtuel ou dispersés sur différents hôtes virtuels.
Si vous spécifiez un hôte virtuel existant dans le fichier ibm-web-bnd.xml ou .xmi pour un bundle d'applications Web (WAB) donné, l'hôte virtuel indiqué est défini par défaut. Sinon, le paramètre d'hôte virtuel par défaut est default_host, qui fournit plusieurs numéros de port via ses alias :
80
Port interne non sécurisé utilisé lorsqu'aucun numéro de port n'est spécifié.
9080
Port interne
9443
Port externe sécurisé
A moins que vous ne vouliez isoler votre bundle WAB des autres bundles WAB ou ressources du même noeud (machine physique), l'hôte virtuel approprié est default_host. Outre default_host, WebSphere Application Server fournit admin_host, qui est l'hôte virtuel de l'application système de la console d'administration. admin_host se trouve sur le port 9060. Son port sécurisé est 9043. Ne sélectionnez pas hôte_admin sauf si le module Web est lié à l'administration du système.
Spécifiez la syntaxe de cette étape de la façon suivante :
-VirtualHostMappingStep [
    [bundle_symbolic_name_1 bundle_version_1 
    web_module_name_1 virtual_host_1]
    [bundle_symbolic_name_2 bundle_version_2 
     web_module_name_2 virtual_host_2]]
Par exemple, pour un fichier EBA contenant deux archives WAB (com.ibm.ws.eba.helloWorldService.web à la version 1.0.0, qui doit être mappé à default_host, et com.ibm.ws.eba.helloWorldService.withContextRoot à la version 0.9.0, qui doit être mappé à test_host), cet aspect de la commande se présente comme suit :
-VirtualHostMappingStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 "HelloWorld service" default_host]
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "HelloWorld second service" test_host]]
-MapRolesToUsersStep
Pour un actif EBA, utilisez cette étape pour mapper les rôles de sécurité vers les utilisateurs/groupes.
Spécifiez la syntaxe de cette étape de la façon suivante :
-MapRolesToUsersStep [
    [role_name everyone? 
    all_authenticated_in_realm? 
    usernames groups]]
Key :
  • nom_rôle est le nom de rôle défini dans l'application.
  • tous_les_utilisateurs ? a la valeur Yes ou No pour indiquer si quelqu'un est dans le rôle.
  • tous_authentifiés_dans_domaine? a la valeur Yes ou No pour indiquer si tous les utilisateurs authentifiés peuvent accéder au domaine de l'application.
  • usernames est une liste de noms d'utilisateur WebSphere Application Server séparés par le caractère "|".
  • groupes est une liste de groupes WebSphere Application Server séparés par le caractère "|".
Remarque : Pour usernames et groups, la chaîne vide "" signifie "utiliser la valeur par défaut ou la valeur existante". Généralement, aucun utilisateur ou groupe n'est lié au rôle par défaut. Toutefois, lorsqu'une application contient un fichier ibm-application-bnd.xmi, la valeur par défaut de noms_utilisateur est obtenue à partir de ce fichier. Si vous déployez une application contenant un fichier ibm-application-bnd.xmi et que vous souhaitez supprimer les utilisateurs entrants et sortants, indiquez seulement le caractère "|" (séparateur pour plusieurs noms d'utilisateur). Vous spécifiez alors explicitement "aucun utilisateur" et garantissez ainsi qu'aucun utilisateur n'est lié au rôle.
Par exemple :
-MapRolesToUsersStep [
    [ROLE1 No Yes "" ""] 
    [ROLE2 No No WABTestUser1 ""] 
    [ROLE3 No No "" WABTestGroup1] 
    [ROLE4 Yes No "" ""]]
-BlueprintResourceRefBindingStep
Pour un actif EBA, les composants Blueprint peuvent accéder aux références de ressources WebSphere Application Server. Chaque référence est déclarée dans un fichier XML Blueprint et peut être sécurisée à l'aide d'un alias d'authentification Java EE (Java Platform, Enterprise Edition) Connector Architecture (JCA). Chaque bundle d'une application OSGi peut contenir n'importe quel nombre de déclarations de références de ressources dans ses divers fichiers Blueprint XML.
Lorsque vous sécurisez des références de ressources, ces dernières ne peuvent être liées qu'à des alias d'authentification JCA existant sur chaque serveur ou cluster sur lequel l'application OSGi est déployée. Une application OSGi peut être déployée sur plusieurs serveurs et clusters du même domaine de sécurité. Par conséquent, chaque alias d'authentification JCA doit exister dans le domaine de sécurité des serveurs et des clusters cible ou dans le domaine de sécurité global.
Spécifiez la syntaxe de cette étape de la façon suivante :
-BlueprintResourceRefBindingStep [
    [
    bundle_symbolic_name 
    bundle_version 
    blueprint_resource_reference_id 
    interface_name 
    jndi_name 
    authentication_type 
    sharing_setting 
    authentication_alias_name
    ]]
Remarque : La valeur du paramètre nom_jndi doit correspondre au nom jndi que vous déclarez dans l'attribut filter de l'élément de référence de ressource dans le fichier XML Blueprint.
Par exemple, pour un fichier EBA contenant un bundle com.ibm.ws.eba.helloWorldService.properties.bundle.jar à la version 1.0.0, qui doit être associé à un alias d'authentification alias1, la commande est la suivante :
-BlueprintResourceRefBindingStep[
    [com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef 
    javax.sql.DataSource jdbc/Account Container Shareable alias1]]
-WebModuleMsgDestRefs
Pour un actif EBA, la liaison d'une référence de ressource mappe une dépendance de ressource de l'application Web sur une ressource réelle disponible dans l'environnement d'exécution du serveur. Il convient pour cela d'utiliser au moins un mappage qui indique le nom JNDI sous lequel la ressource est connue dans l'environnement d'exécution. Par défaut, le nom JNDI est l'ID de ressource que vous avez spécifié dans le fichier web.xml lors du développement du bundle d'applications Web (WAB). Utilisez cette option pour lier des ressources de type message-destination-ref (référence de destination de message) ou resource-env-ref (référence d'environnement de ressource), comme défini dans la spécification Java JSR-250 : annotations communes pour la plateforme Java.
Spécifiez la syntaxe de cette étape de la façon suivante :
-WebModuleMsgDestRefs [
    [
    bundle_symbolic_name
    bundle_version
    resource_reference_id
    resource_type
    target_jndi_name
	   ]]
Par exemple :
-WebModuleMsgDestRefs [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 
    jms/myQ javax.jms.Queue jms/workQ] 
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 
    jms/myT javax.jms.Topic jms/notificationTopic]]
-WebModuleResourceRefs
Pour un actif EBA, la liaison d'une référence de ressource mappe une dépendance de ressource de l'application Web sur une ressource réelle disponible dans l'environnement d'exécution du serveur. Il convient pour cela d'utiliser au moins un mappage qui indique le nom JNDI sous lequel la ressource est connue dans l'environnement d'exécution. Par défaut, le nom JNDI est l'ID de ressource que vous avez spécifié dans le fichier web.xml lors du développement du bundle d'applications Web (WAB). Utilisez cette option pour lier des ressources de type resource-ref (référence de ressource), comme défini dans la spécification Java JSR-250 : annotations communes pour la plateforme Java.
Spécifiez la syntaxe de cette étape de la façon suivante :
-WebModuleResourceRefs [
    [
    bundle_symbolic_name
    bundle_version
    resource_reference_id
    resource_type
    target_jndi_name
    login_configuration
    login_properties
    extended_properties
	   ]]
Par exemple :
-WebModuleResourceRefs [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/jtaDs javax.sql.DataSource 
    jdbc/helloDs "" "" ""] 
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/nonJtaDs javax.sql.DataSource 
    jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
Remarque : Si vous utilisez plusieurs propriétés étendues, la syntaxe jython est "extprop1=extval1,extprop2=extval2".

Valeur renvoyée

La commande renvoie les ID configuration de l'unité de composition et de la nouvelle unité de composition créée pour l'actif dans le cadre de la relation d'actif, comme l'illustre l'exemple suivant :
WebSphere:cuname=cu4
WebSphere:cuname=cua
WebSphere:cuname=cud

Exemple d'utilisation en mode de traitement par lots

Utilisez les exemples suivants pour ajouter un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID myBLA –cuSourceID assetname=asset1.zip -CUOptions 
      [[.* .* cu1 "cu1 desc1" 0 false DEFAULT]] -MapTargets [[.* server1]] –ActivationPlanOptions 
      [.* specname=actplan0+specname=actplan1]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'myBLA', '–cuSourceID', 'assetname=asset1.zip', '-CUOptions', 
      '[[.* .* cu1 "cu1 desc1" 0 false DEFAULT]]', '-MapTargets', '[[.* server1]]', '–ActivationPlanOptions',
       '[.* specname=actplan0+specname=actplan1]'])
Utilisez les exemples suivants pour ajouter une unité de composition d'application de niveau métier :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID myBLA -cuSourceID yourBLA -CUOptions [[.* .* cu3 "cu3 desc3" 0 false DEFAULT]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'myBLA', '-cuSourceID', 'yourBLA', '-CUOptions', 
      '[[.* .* cu3 "cu3 desc3" 0 false DEFAULT]]'])
Utilisez l'exemple suivant pour créer une unité de composition EBA et l'ajouter à une application de niveau métier.
AdminTask.addCompUnit('[
  -blaID WebSphere:blaname=helloWorldService 
  -cuSourceID WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba
  -CUOptions [
    [WebSphere:blaname=helloWorldService.eba 
    WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba 
    com.ibm.ws.eba.helloWorldService_0001.eba "" 1 false DEFAULT]] 
  -MapTargets [[ebaDeploymentUnit WebSphere:node=node01,server=server1]] 
  -ActivationPlanOptions [[default ""]]  
  -ContextRootStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"] 
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
  -VirtualHostMappingStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 
    "HelloWorld service" default_host]
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 
    "HelloWorld second service" test_host]]
  -MapRolesToUsersStep [
    [ROLE1 No Yes "" ""] 
    [ROLE2 No No WABTestUser1 ""] 
    [ROLE3 No No "" WABTestGroup1] 
    [ROLE4 Yes No "" ""]]
  -BlueprintResourceRefBindingStep[
    [com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef 
    javax.sql.DataSource jdbc/Account Container Shareable alias1]]
  -WebModuleMsgDestRefs [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 
    jms/myQ javax.jms.Queue jms/workQ] 
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 
    jms/myT javax.jms.Topic jms/notificationTopic]]
  -WebModuleResourceRefs [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/jtaDs javax.sql.DataSource 
    jdbc/helloDs "" "" ""] 
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/nonJtaDs javax.sql.DataSource 
    jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
]')
Utilisez les exemples suivants pour ajouter une unité de composition d'actif externe à l'entreprise et déployer cette unité sur plusieurs cibles :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID theirBLA –cuSourceID asset2.zip –CUOptions 
      [[.* .* cu2 "cu2 desc" 0 false DEFAULT]] -MapTargets [[.* server1+server2]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'theirBLA', '–cuSourceID', 'asset2.zip', '–CUOptions', 
      '[[.* .* cu2 "cu2 desc" 0 false DEFAULT]]', '-MapTargets', '[[.* server1+server2]]'])
Utilisez les exemples suivants pour ajouter une unité de composition qui est un actif externe à l'entreprise avec une unité déployable :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID yourBLA –cuSourceID asset2.zip –deplUnits a.jar –CUOptions 
      [[.* .* cu3 "cu3 desc" 0 false DEFAULT]] –MapTargets [[a.jar server1]] –ActivationPlanOptions 
      [[a.jar specname=actplan1]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'yourBLA', '–cuSourceID', 'asset2.zip', '–deplUnits', 'a.jar', '–CUOptions', 
      '[[.* .* cu3 "cu3 desc" 0 false DEFAULT]]', '–MapTargets', '[[a.jar server1]]', '–ActivationPlanOptions',
       '[[a.jar specname=actplan1]]'])
Utilisez les exemples suivants pour ajouter une unité de composition d'actif externe à l'entreprise en tant que bibliothèque partagée :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID ourBLA –cuSourceID b.jar –deplUnits default –CUOptions 
      [[.* .* cub "cub desc" 0 false DEFAULT]] –MapTargets [[default server1]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'ourBLA', '–cuSourceID', 'b.jar', '–deplUnits', 'default', '–CUOptions', 
      '[[.* .* cub "cub desc" 0 false DEFAULT]]', '–MapTargets', '[[default server1]]'])
Utilisez les exemples suivants pour ajouter une unité de composition d'actif externe à l'entreprise avec une dépendance. Dans cet exemple, l'unité de composition cub existe en tant que bibliothèque partagée de l'application de niveau métier ourBLA :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('-blaID ourBLA –cuSourceID asset3.zip –deplUnits a1.jar –CUOptions 
      [[.* .* cu4 "cu4 desc" 0 false DEFAULT]] –MapTargets [[a1.jar cluster1+cluster2]] –CreateAuxCUOptions 
      [[a1.jar a.jar cua true]] –RelationshipOptions [[a1.jar cuname=cub true]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'ourBLA', '–cuSourceID', 'asset3.zip', '–deplUnits', 'a1.jar', '–CUOptions',
     '[[.* .* cu4 "cu4 desc" 0 false DEFAULT]]', '–MapTargets', '[[a1.jar cluster1+cluster2]]', '–CreateAuxCUOptions', 
      '[[a1.jar a.jar cua true]]', '–RelationshipOptions', '[[a1.jar cuname=cub true]]'])
Utilisez les exemples suivants pour ajouter un actif d'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.addCompUnit('[-blaID yourBLA –cuSourceID defaultapp.ear –defaultBindingOptions
      defaultbinding.ejbjndi.prefix=ejb# defaultbinding.virtual.host=default_host#
      defaultbinding.force=yes –AppDeploymentOptions [-appname defaultapp -installed.ear.destination
      application_root/myCell/defaultapp.ear] –MapModulesToServers 
      [[defaultapp.war .* WebSphere:cell=cellName,node=nodeName,server=server1]
      [Increment.jar .* Websphere:cell=cellName,node=nodeName,server=server2]] -CtxRootForWebMod
      [[defaultapp.war .* myctx/]]]')
  • A l'aide de la liste Jython :
    AdminTask.addCompUnit(['-blaID', 'yourBLA', '–cuSourceID', 'defaultapp.ear', '–defaultBindingOptions',
       'defaultbinding.ejbjndi.prefix=ejb# defaultbinding.virtual.host=default_host# defaultbinding.force=yes', 
       '–AppDeploymentOptions', '[-appname defaultapp -installed.ear.destination application_root/myCell/defaultapp.ear]',
       '–MapModulesToServers', '[[defaultapp.war .* WebSphere:cell=cellName,node=nodeName,server=server1]
       [Increment.jar .* Websphere:cell=cellName,node=nodeName,server=server2]]', '-CtxRootForWebMod', 
       '[[defaultapp.war .* myctx/]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.addCompUnit('-interactive')

deleteCompUnit

La commande deleteCompUnit supprime une unité de composition. Les deux paramètres de cette commande acceptent des ID configuration incomplets, tant que le système peut rattacher la chaîne à un ID unique.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)
-cuID
Indique l'ID configuration de l'unité de composition à supprimer. (Chaîne, obligatoire)

Paramètres optionnels

-force
Indique s'il faut ou non forcer le système à supprimer l'unité de composition, même si d'autres unité de composition dépendent de cette unité de composition. (Booléen, facultatif)

Valeur renvoyée

La commande renvoie l'ID configuration de l'unité de composition supprimée par le système, comme l'illustre l'exemple suivant :
WebSphere:cuname=cu1

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.deleteCompUnit('-blaID myBLA –cuID cu1 -force true')
  • A l'aide de la liste Jython :
    AdminTask.deleteCompUnit(['-blaID', 'myBLA', '–cuID', 'cu1', '-force', 'true'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.deleteCompUnit('-interactive')

editCompUnit

La commande editCompUnit modifie les options supplémentaires de l'unité de composition. Vous pouvez l'utiliser pour modifier la pondération de démarrage de l'unité de composition, les cibles de déploiement, les options de plan d'activation et les paramètres d'une relation.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)
-cuID
Indique l'ID configuration de l'unité de composition à éditer. (Chaîne, obligatoire)

Etapes facultatives

Vous pouvez également utiliser des paramètres facultatifs pour modifier les propriétés d'une unité de composition. Ces étapes ne s'appliquent pas aux actifs d'entreprise. Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-CUOptions
Spécifie des propriétés supplémentaires pour l'unité de composition. Indiquez les options suivantes dans le cadre de l'étape CUOptions :
parentBLA (lecture seule)
Indique l'application de niveau métier parente pour l'unité de composition.
backingID (lecture seule)
Indique l'ID source de l'unité de composition.
name (lecture seule)
Indique le nom de l'unité de composition.
description
Spécifie une description pour l'unité de composition.
startingWeight
Indique la pondération de démarrage de l'unité de composition. Les valeurs prises en charge sont comprises entre 1 et 2147483647, la valeur entière maximale.
startedOnDistributed
Indique si l'unité de composition doit être démarrée après avoir distribué les modifications sur les noeuds cible. La valeur par défaut est false.
restartBehaviorOnUpdate
Indique les noeuds à redémarrer après modification de l'unité de composition. Spécifiez ALL pour redémarrer chaque noeud cible, DEFAULT pour redémarrer les noeuds commandés par les plug-ins synchronisés ou NONE pour que le système ne redémarre aucun noeud.
Par exemple, utilisez la syntaxe suivante pour cette étape : -CUOptions [[.* .* cu4 "cu4 description" 0 false DEFAULT]]
-MapTargets
Spécifie des propriétés supplémentaires pour le mappage cible de l'unité de composition. Indiquez les options suivantes dans le cadre de l'étape MapTargets :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
Pour un actif EBA (enterprise bundle archive), cet identificateur URI est ebaDeploymentUnit.
server
Indique la ou les cibles sur lesquelles déployer les unités de composition. La valeur par défaut est server1. Utilisez le signe plus (+) pour indiquer plusieurs cibles. Utilisez le signe plus (+) comme préfixe pour ajouter une cible supplémentaire. Précisez le format de nom d'objet complet pour chaque serveur qui n'est pas un serveur WebSphere Application Server.
Par exemple, utilisez la syntaxe suivante pour cette étape : -MapTargets [[a1.jar cluster1+cluster2] [a2.jar server1+server2]]
-ActivationPlanOptions
Spécifie des propriétés supplémentaires pour le plan d'activation d'une unité de composition. Indiquez les options suivantes dans le cadre de l'étape ActivationPlanOptions :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
activationPlan
Indique une liste de composants d'exécution constitutifs du plan d'activation. Spécifiez chaque plan d'activation sous la forme specName=xxx,specVersion=yyy, où specName représente le nom de la spécification et est obligatoire. Utilisez le signe plus (+) pour indiquer plusieurs plans d'activation.
Par exemple, utilisez la syntaxe suivante pour cette étape : -ActivationPlanOptions [[a1.jar specname=actplan0+actplan1] [a2.jar specname=actplan1+specname=actplan2]]
Pour un actif EBA, ne modifiez pas le plan d'activation. Conservez les valeurs par défaut suivantes définies lors de l'ajout de l'unité de composition : -ActivationPlanOptions [[default ""]]
-RelationshipOptions
Spécifie des propriétés supplémentaires pour des relations entre des actifs, des unités de composition et des applications de niveau métier. Utilisez ce paramètre si l'ID source de l'unité de composition est un actif qui a une unité de composition correspondante dans l'application de niveau métier. Indiquez les options suivantes dans le cadre de l'étape RelationshipOptions :
deplUnit (lecture seule)
Indique l'URI (Uniform Resource Identifier) de l'unité déployable.
relationship
Définit les relations de l'unité de composition. Spécifiez le nom d'objet de l'unité de composition sous la forme : cuName=xxx. Utilisez le signe plus (+) pour indiquer plusieurs noms d'objets d'unité de composition dans la relation. Si l'unité de composition spécifiée dans la relation n'existe pas dans la même application de niveau métier, le système retourne une erreur.
matchTarget
Indique si les cibles associées à la relation d'unité de composition doivent être mises en correspondance avec les cibles de la nouvelle unité de composition. La valeur par défaut est true.
Le produit ne sauvegarde pas la valeur spécifiée pour matchTarget. Ainsi, si vous optez pour une non correspondance à la cible (false) maintenant et de l'éditer ultérieurement, lorsque vous éditez l'unité de composition, vous devez désactiver à nouveau ce paramètre pour que le produit ne correspondent pas aux cibles.
Par exemple, utilisez la syntaxe suivante pour cette étape : –RelationshipOptions [[a1.jar a.jar auxCU true] [a2.jar a.jar defaultCU false]]
-ContextRootStep
Pour un actif EBA, les racines de contexte déterminent l'emplacement des pages Web d'un bundle d'applications Web (WAB) lors de l'exécution.
La racine de contexte que vous spécifiez ici est combinée avec le mappage de serveur défini pour composer l'URL complète que vous saisissez pour accéder aux pages du bundle d'applications Web (WAB). Par exemple, si l'hôte par défaut du serveur d'applications correspond à www.example.com:8080 et que la racine de contexte du bundle d'applications Web correspond à /sample, les pages Web sont disponibles à l'adresse www.example.com:8080/sample.
Vous devez répertorier les racines de contexte de tous les modules WAB contenus dans l'application OSGi.
Spécifiez la syntaxe de cette étape de la façon suivante :
  -ContextRootStep [
    [bundle_symbolic_name_1 bundle_version_1 context_root_1]
    [bundle_symbolic_name_2 bundle_version_2 context_root_2]]
Par exemple, pour un fichier EBA contenant deux archives WAB (com.ibm.ws.eba.helloWorldService.web à la version 1.0.0, qui doit être mappé à /hello/web, et com.ibm.ws.eba.helloWorldService.withContextRoot à la version 0.9.0, qui doit être mappé à /hello/service), cet aspect de la commande se présente comme suit :
  -ContextRootStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"] 
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
-VirtualHostMappingStep
Pour un actif EBA, vous utilisez un hôte virtuel pour associer un port unique à un module ou à une application. Les alias d'un hôte virtuel identifient les numéros de port définis pour cet hôte virtuel. Le numéro de port indiqué dans un alias d'hôte virtuel est utilisé dans l'URL pour accéder aux artefacts tels que les servlets et les fichiers JSP (JavaServer Page) d'un module Web. Par exemple, l'alias myhost:8080 correspond à la portion nom_hôte:numéro_port de l'URL http://myhost:8080/sample.
Chaque bundle d'applications Web (WAB) contenu dans un actif déployé doit être mappé sur un hôte virtuel. Ces bundles peuvent être installés sur le même hôte virtuel ou dispersés sur différents hôtes virtuels.
Si vous spécifiez un hôte virtuel existant dans le fichier ibm-web-bnd.xml ou .xmi pour un bundle d'applications Web (WAB) donné, l'hôte virtuel indiqué est défini par défaut. Sinon, le paramètre d'hôte virtuel par défaut est default_host, qui fournit plusieurs numéros de port via ses alias :
80
Port interne non sécurisé utilisé lorsqu'aucun numéro de port n'est spécifié.
9080
Port interne
9443
Port externe sécurisé
A moins que vous ne vouliez isoler votre bundle WAB des autres bundles WAB ou ressources du même noeud (machine physique), l'hôte virtuel approprié est default_host. Outre default_host, WebSphere Application Server fournit admin_host, qui est l'hôte virtuel de l'application système de la console d'administration. admin_host se trouve sur le port 9060. Son port sécurisé est 9043. Ne sélectionnez pas hôte_admin sauf si le module Web est lié à l'administration du système.
Spécifiez la syntaxe de cette étape de la façon suivante :
-VirtualHostMappingStep [
    [bundle_symbolic_name_1 bundle_version_1 
    web_module_name_1 virtual_host_1]
    [bundle_symbolic_name_2 bundle_version_2 
     web_module_name_2 virtual_host_2]]
Par exemple, pour un fichier EBA contenant deux archives WAB (com.ibm.ws.eba.helloWorldService.web à la version 1.0.0, qui doit être mappé à default_host, et com.ibm.ws.eba.helloWorldService.withContextRoot à la version 0.9.0, qui doit être mappé à test_host), cet aspect de la commande se présente comme suit :
-VirtualHostMappingStep [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 "HelloWorld service" default_host]
    [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "HelloWorld second service" test_host]]
-MapRolesToUsersStep
Pour un actif EBA, utilisez cette étape pour mapper les rôles de sécurité vers les utilisateurs/groupes.
Spécifiez la syntaxe de cette étape de la façon suivante :
-MapRolesToUsersStep [
    [role_name everyone? 
    all_authenticated_in_realm? 
    usernames groups]]
Key :
  • nom_rôle est le nom de rôle défini dans l'application.
  • tous_les_utilisateurs ? a la valeur Yes ou No pour indiquer si quelqu'un est dans le rôle.
  • tous_authentifiés_dans_domaine? a la valeur Yes ou No pour indiquer si tous les utilisateurs authentifiés peuvent accéder au domaine de l'application.
  • usernames est une liste de noms d'utilisateur WebSphere Application Server séparés par le caractère "|".
  • groupes est une liste de groupes WebSphere Application Server séparés par le caractère "|".
Remarque : Pour usernames et groups, la chaîne vide "" signifie "utiliser la valeur par défaut ou la valeur existante". Généralement, aucun utilisateur ou groupe n'est lié au rôle par défaut. Toutefois, lorsqu'une application contient un fichier ibm-application-bnd.xmi, la valeur par défaut de noms_utilisateur est obtenue à partir de ce fichier. Si vous déployez une application contenant un fichier ibm-application-bnd.xmi et que vous souhaitez supprimer les utilisateurs entrants et sortants, indiquez seulement le caractère "|" (séparateur pour plusieurs noms d'utilisateur). Vous spécifiez alors explicitement "aucun utilisateur" et garantissez ainsi qu'aucun utilisateur n'est lié au rôle.
Par exemple :
-MapRolesToUsersStep [
    [ROLE1 No Yes "" ""] 
    [ROLE2 No No WABTestUser1 ""] 
    [ROLE3 No No "" WABTestGroup1] 
    [ROLE4 Yes No "" ""]]
-BlueprintResourceRefPostDeployStep
Pour un actif EBA, les composants Blueprint peuvent accéder aux références de ressources WebSphere Application Server. Chaque référence est déclarée dans un fichier XML Blueprint et peut être sécurisée à l'aide d'un alias d'authentification Java EE (Java Platform, Enterprise Edition) Connector Architecture (JCA). Chaque bundle d'une application OSGi peut contenir n'importe quel nombre de déclarations de références de ressources dans ses divers fichiers Blueprint XML.
Lorsque vous sécurisez des références de ressources, ces dernières ne peuvent être liées qu'à des alias d'authentification JCA existant sur chaque serveur ou cluster sur lequel l'application OSGi est déployée. Une application OSGi peut être déployée sur plusieurs serveurs et clusters du même domaine de sécurité. Par conséquent, chaque alias d'authentification JCA doit exister dans le domaine de sécurité des serveurs et des clusters cible ou dans le domaine de sécurité global.
Spécifiez la syntaxe de cette étape de la façon suivante :
-BlueprintResourceRefPostDeployStep [
    [
    bundle_symbolic_name 
    bundle_version 
    blueprint_resource_reference_id 
    interface_name 
    jndi_name 
    authentication_type 
    sharing_setting 
    authentication_alias_name
    ]]
Remarque : La valeur du paramètre nom_jndi doit correspondre au nom jndi que vous déclarez dans l'attribut filter de l'élément de référence de ressource dans le fichier XML Blueprint.
Par exemple, pour un fichier EBA contenant un bundle com.ibm.ws.eba.helloWorldService.properties.bundle.jar à la version 1.0.0, qui doit être associé à un alias d'authentification alias1, la commande est la suivante :
-BlueprintResourceRefPostDeployStep[
    [com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef 
    javax.sql.DataSource jdbc/Account Container Shareable alias1]]
-WebModuleResourceRefs
Pour un actif EBA, la liaison d'une référence de ressources mappe une dépendance de ressource du module Web sur une ressource réelle disponible dans l'environnement d'exécution du serveur. Il convient pour cela d'utiliser au moins un mappage qui indique le nom JNDI sous lequel la ressource est connue dans l'environnement d'exécution. Par défaut, le nom JNDI est l'ID de ressource que vous avez spécifié dans le fichier web.xml lors du développement du bundle d'applications Web (WAB).
Spécifiez la syntaxe de cette étape de la façon suivante :
-WebModuleResourceRefs [
    [
    bundle_symbolic_name
    bundle_version
    resource_reference_id
    resource_type
    target_jndi_name
    login_configuration
    login_properties
    extended_properties
	   ]]
Par exemple :
-WebModuleResourceRefs [
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/jtaDs javax.sql.DataSource 
    jdbc/helloDs "" "" ""] 
    [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/nonJtaDs javax.sql.DataSource 
    jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
Remarque : Si vous utilisez plusieurs propriétés étendues, la syntaxe jython est "extprop1=extval1,extprop2=extval2".

Valeur renvoyée

La commande renvoie l'ID configuration de l'unité de composition éditée par le système.

Exemple d'utilisation en mode de traitement par lots

Utilisez les exemples suivants pour éditer une unité de composition d'un actif et remplacer la cible par une cible existante :
  • A l'aide de la chaîne Jython :
    AdminTask.editCompUnit('-blaID myBLA –cuID cu1 –CUOptions [[.* .* cu1 cudesc 1 false DEFAULT]] -MapTargets 
      [[.* server2]] -ActivationPlanOptions [.* #specname=actplan0+specname=actplan2]')
  • A l'aide de la liste Jython :
    AdminTask.editCompUnit(['-blaID', 'myBLA', '–cuID', 'cu1', '–CUOptions', 
      '[[.* .* cu1 cudesc 1 false DEFAULT]]', '-MapTargets', '
      [[.* server2]]', '-ActivationPlanOptions', '[.* #specname=actplan0+specname=actplan2]'])
Utilisez les exemples suivants pour éditer une unité de composition d'un actif et ses relations :
  • A l'aide de la chaîne Jython :
    AdminTask.editCompUnit('-blaID ourBLA –cuID cu4 –CUOptions [[.* .* cu4 "new cu desc" 1 false DEFAULT]]
       –MapTargets [[a1.jar server1+server2]] –RelationshipOptions [[a1.jar cuname=cub true]]')
  • A l'aide de la liste Jython :
    AdminTask.editCompUnit(['-blaID', 'ourBLA', '–cuID', 'cu4', '–CUOptions', '
      [[.* .* cu4 "new cu desc" 1 false DEFAULT]]', '–MapTargets', '[[a1.jar server1+server2]]', '–RelationshipOptions', 
      '[[a1.jar cuname=cub true]]'])
Utilisez les exemples suivants pour éditer une unité de composition en ajoutant une nouvelle relation à la relation existante :
  • A l'aide de la chaîne Jython :
    AdminTask.editCompUnit('[-blaID ourBLA –cuID cu4 –CUOptions [[.* .* cu4 "new cu desc" 1 false DEFAULT]]
       –MapTargets [[a1.jar server1+server2]] –RelationshipOptions [[a1.jar +cuname=cuc true]] -ActivationPlanOptions 
      [a1.jar +specname=actplan2#specname=actplan1]]')
  • A l'aide de la liste Jython :
    AdminTask.editCompUnit(['-blaID', 'ourBLA', '–cuID', 'cu4', '–CUOptions', '
      [[.* .* cu4 "new cu desc" 1 false DEFAULT]]', '–MapTargets', '[[a1.jar server1+server2]]', '–RelationshipOptions',
       '[[a1.jar +cuname=cuc true]]', '-ActivationPlanOptions', '[a1.jar +specname=actplan2#specname=actplan1]'])
Utilisez les exemples suivants pour éditer une configuration d'unité de composition d'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.editCompUnit('-blaID yourBLA –cuID defaultapp –MapModulesToServers 
      [[defaultapp.war .* WebSphere:cluster=cluster1][Increment.jar .* Websphere:cluster=cluster2]]
       –CtxRootForWebMod [[defaultapp.war .* /]] –MapWebModToVH [[defaultapp.war .* vh1]]')
  • A l'aide de la liste Jython :
    AdminTask.editCompUnit(['-blaID', 'yourBLA', '–cuID', 'defaultapp', '–MapModulesToServers', 
     '[[defaultapp.war .* WebSphere:cluster=cluster1][Increment.jar .* Websphere:cluster=cluster2]]', '–CtxRootForWebMod', 
     '[[defaultapp.war .* /]]', '–MapWebModToVH', '[[defaultapp.war .* vh1]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.editCompUnit('-interactive')

listCompUnits

La commande listCompUnits affiche chaque unité de composition associée à une application de niveau métier spécifique.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)

Paramètres optionnels

-includeDescription
Indique si chaque actif renvoyé par la commande doit être accompagné d'une description. (Chaîne, optionnelle)
-includeType
Indique si le type doit être précisé pour chaque actif renvoyé par la commande. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie la liste des ID configuration et le type de chaque unité de composition, comme l'illustre l'exemple suivant :
Websphere:cuname=cu1
asset
"description for cu1"
Websphere:cuname=cu4
bla
"description for cu4"
WebSphere:cuname=defaultapp
Java EE
"description for defaultapp"

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.listCompUnits('-blaID blaname=theirBLA')
  • A l'aide de la liste Jython :
    AdminTask.listCompUnits(['-blaID', 'blaname=theirBLA'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.listCompUnits('-interactive')

setCompUnitTargetAutoStart

La commande setCompUnitTargetAutoStart active ou désactive le démarrage automatique des unités de composition. Si vous activez cette option, le système démarre automatiquement l'unité de composition lorsque la cible associée à cette dernière démarre.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. La commande accepte un ID configuration incomplet si le système parvient à le rattacher à un ID unique d'application de niveau métier. (Chaîne, obligatoire)
-cuID
Indique l'unité de composition qui vous intéresse. La commande accepte un ID configuration incomplet si le système parvient à le rattacher à un ID unique d'unité de composition. (Chaîne, obligatoire)
-targetID
Indique le nom de la cible qui vous intéresse. Par exemple, spécifiez le nom de serveur à définir comme cible. (Chaîne, obligatoire)
-enable
Indique si l'unité de composition qui vous intéresse doit être démarrée automatiquement lorsque la cible spécifiée démarre. Spécifiez true pour démarrer automatiquement l'unité de composition. Si vous ne spécifiez pas true, le système ne démarrera pas l'unité de composition au démarrage de la cible. La valeur par défaut est true. (Chaîne, obligatoire)

Valeur renvoyée

La commande ne renvoie pas de sortie.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.setCompUnitTargetAutoStart('-blaID bla1 –cuID cu1 –targetID server1 –enable true')
  • A l'aide de la liste Jython :
    AdminTask.setCompUnitTargetAutoStart(['-blaID', 'bla1', '–cuID', 'cu1', '–targetID',
       'server1', '–enable', 'true'])

Exemple d'utilisation en mode interactif

  • Avec la chaîne Jython :
    AdminTask.setCompUnitTargetAutoStart('-interactive')

viewCompUnit

La commande viewCompUnit affiche des informations de configuration relatives à une unité de composition qui appartient à une application de niveau métier spécifique.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. Ce paramètre accepte un ID configuration incomplet si le système parvient à le rattacher à un ID unique d'application de niveau métier. (Chaîne, obligatoire)
-cuID
Indique l'ID configuration de l'unité de composition qui vous intéresse. Ce paramètre accepte un ID configuration incomplet si le système parvient à le rattacher à un ID unique d'unité de composition. (Chaîne, obligatoire)

Paramètres optionnels

Aucun

Valeur renvoyée

La commande renvoie des informations de configuration sur l'unité de composition qui vous intéresse, comme l'illustre l'exemple suivant :
Specify Composition Unit options (CUOptions)

Specify name, description options for Composition Unit.

Parent BLA (parentBLA): [WebSphere:blaname=myBLA]
Backing Id (backingId): [WebSphere:assetname=asset1.zip]
Name (name): [cu1]
Description (description): [cuDesc]
Starting Weight (startingWeight): [0]
Started on distributed (startedOnDistributed): [false]
Restart behavior on update (restartBehaviorOnUpdate): [DEFAULT]

Specify servers (MapTargets)

Specify targets such as application servers or clusters of application servers where you want 
to deploy the cu contained in the application.

Deployable Unit (deplUnit): [default]
*Servers (server): [WebSphere:node=myNode,server=server1]

Specify Composition Unit activation plan options (ActivationPlanOptions)

Specify CU activation plan optionsDeployableUnit Name (deplUnit): [default]
Activation Plan (activationPlan): [WebSphere:specname=actplan0+WebSphere:specname=actplan1] 
Si l'unité de composition contient un actif EBA (enterprise bundle archive), son statut s'affiche également. Le statut a l'une des valeurs suivantes :
  • Utilisation du dernier niveau de déploiement d'application OSGi.
  • Nouveau déploiement d'application OSGi non disponible car les bundles requis sont encore en cours de téléchargement.
  • Nouveau déploiement d'application OSGi disponible.
  • Impossible d'appliquer le nouveau déploiement d'application OSGi car les téléchargements de bundle ont échoué.

Exemple d'utilisation en mode de traitement par lots

L'exemple suivant affiche les informations de configuration d'un actif externe à l'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.viewCompUnit('-blaID myBLA -cuID myCompUnit')
  • A l'aide de la liste Jython :
    AdminTask.viewCompUnit(['-blaID', 'myBLA', '-cuID', 'myCompUnit'])
L'exemple suivant affiche les informations de configuration d'un actif d'entreprise :
  • A l'aide de la chaîne Jython :
    AdminTask.viewCompUnit('-blaID myBLA -cuID defaultApplication')
  • A l'aide de la liste Jython :
    AdminTask.viewCompUnit(['-blaID', 'myBLA', '-cuID', 'defaultApplication'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.viewCompUnit('-interactive')

createEmptyBLA

La commande createEmptyBLA permet de créer une application de niveau métier vide. Après avoir créé une application de niveau métier, vous pouvez lui ajouter des actifs ou d'autres applications de niveau métier en tant qu'unités de composition.

Objet cible

Aucun

Paramètres requis

-name
Indique un nom unique pour la nouvelle application de niveau métier. (Chaîne, obligatoire)

Paramètres optionnels

-description
Donne une description de la nouvelle application de niveau métier. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie l'ID configuration de la nouvelle application de niveau métier, comme l'illustre l'exemple suivant :
WebSphere:blaname=myBLA

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.createEmptyBLA('-name myBLA -description "my description for BLA"')
  • A l'aide de la liste Jython :
    AdminTask.createEmptyBLA(['-name', 'myBLA', '-description', '"my description for BLA"'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.createEmptyBLA('-interactive')

deleteBLA

La commande deleteBLA supprime une application de niveau métier de votre configuration. Avant de supprimer une application de niveau métier, utilisez la commande deleteCompUnit pour supprimer chaque unité de composition associée à cette application. Vérifiez également qu'aucune autre application de niveau métier ne référence l'application à supprimer.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. La commande accepte un ID incomplet pour le paramètre blaID, tant que le système peut rattacher la chaîne à un identificateur unique. Par exemple, vous pouvez spécifier l'ID partiel myBLA pour identifier l'ID configuration WebSphere:blaname=myBLA. (Chaîne, obligatoire)

Paramètres optionnels

Aucun

Valeur renvoyée

La commande renvoie l'ID configuration de l'application de niveau métier supprimée, comme l'illustre l'exemple suivant :
WebSphere:blaname=myBLA

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.deleteBLA('-blaID myBLA')
  • A l'aide de la liste Jython :
    AdminTask.deleteBLA(['-blaID', 'myBLA'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.deleteBLA('-interactive')

editBLA

La commande editBLA modifie la description d'une application de niveau métier.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)

Etapes facultatives

Pour les étapes facultatives, utilisez les caractères .* pour spécifier un argument en lecture seule dans la syntaxe de commande. Spécifiez une chaîne vide avec les caractères "" pour conserver la valeur existante de l'argument. Si vous n'indiquez pas de valeur ou spécifiez une chaîne vide pour un argument inscriptible, la commande réinitialise l'argument à la valeur null.
-BLAOptions
Utilisez le paramètre BLAOptions pour spécifier une nouvelle description pour l'application de niveau métier qui vous intéresse.
name (lecture seule)
Indique le nom de l'application de niveau métier.
description
Donne une description de l'application de niveau métier.

Valeur renvoyée

La commande ne renvoie pas de sortie.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.editBLA('-blaID DefaultApplication –BLAOptions [[.* "my new description"]]')
  • A l'aide de la liste Jython :
    AdminTask.editBLA(['-blaID', 'DefaultApplication', '–BLAOptions', '[[.* "my new description"]]'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.editBLA('-interactive')

getBLAStatus

La commande getBLAStatus indique si une application de niveau métier ou une unité de composition est en cours d'exécution ou arrêtée.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. Utilisez la commande listBLAs pour afficher la liste des ID configuration des applications de niveau métier. (Chaîne, obligatoire)

Paramètres optionnels

-cuID
Indique l'ID configuration de l'unité de composition qui vous intéresse. Utilisez la commande listCompUnits pour afficher la liste des ID configuration des unités de composition. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie l'état de l'application de niveau métier ou de l'unité de composition qui vous intéresse.

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.getBLAStatus('-blaID WebSphere:blaname=myBLA -cuID Websphere:cuname=cu1')
  • A l'aide de la liste Jython :
    AdminTask.getBLAStatus(['-blaID', 'WebSphere:blaname=myBLA', '-cuID', 'Websphere:cuname=cu1'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.getBLAStatus('-interactive')

listBLAs

La commande listBLAs affiche les applications de niveau métier de votre configuration.

Objet cible

Aucun

Paramètres optionnels

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, optionnelle)
-includeDescription
Indique si chaque application de niveau métier renvoyée par la commande doit être accompagnée d'une description. Spécifiez true pour afficher les descriptions des applications de niveau métier. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie la liste des ID configuration pour chaque application de niveau métier de votre configuration, comme l'illustre l'exemple suivant :
WebSphere:blaname=myBLA
WebSphere:blaname=yourBLA

Exemple d'utilisation en mode de traitement par lots

L'exemple suivant répertorie toutes les applications de niveau métier de la configuration :
  • En langage Jython :
    AdminTask.listBLAs()
Utilisez les exemples suivants pour lister chaque application de niveau métier de la configuration :
  • A l'aide de la chaîne Jython :
    AdminTask.listBLAs('-blaID myBLA')
  • A l'aide de la liste Jython :
    AdminTask.listBLAs(['-blaID', 'myBLA'])
Utilisez les exemples suivants pour lister chaque application de niveau métier avec la description correspondante :
  • A l'aide de la chaîne Jython :
    AdminTask.listBLAs('-includeDescription true')
  • A l'aide de la liste Jython :
    AdminTask.listBLAs(['-includeDescription', 'true'])

Exemple d'utilisation en mode interactif

  • Avec la chaîne Jython :
    AdminTask.listBLAs('-interactive')

listControlOps

La commande listControlOps affiche les opérations de contrôle associées à une application de niveau métier et aux unités de composition correspondantes.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. (Chaîne, obligatoire)

Paramètres optionnels

-cuID
Indique l'unité de composition qui vous intéresse. (Chaîne, optionnelle)
-opName
Indique le nom de l'opération qui vous intéresse. (Chaîne, optionnelle)
-long
Indique si des informations de configuration supplémentaires doivent être incluses dans le résultat de la commande. (Chaîne, optionnelle)

Valeur renvoyée

La commande renvoie la liste des opérations, avec les descriptions d'opérations et de paramètres utilisés dans la requête, comme l'illustre l'exemple suivant :
"Operation: start"
   "Description: Start operation"
   "Operation handler ID: com.mycompany.myasset.ControlOpHandler" 
   "Operation handler data URI: None"
"Operation: stop"
   "Description: Stop operation"
   "Operation handler ID: com.mycompany.myasset.ControlOpHandler"
   "Operation handler data URI: None"
"Operation: clearCache"
   "Description: Clears specified cache or all caches"
   "Operation handler ID: com.mycompany.myasset.ControlOpHandler"
   "Operation handler data URI: None"
   "Parameter: cacheName"
      "Description: Name of cache to clear.  If not specified, all caches are cleared."

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.listControlOps('-blaID myBLA –cuID myservice.jar –long true')
  • A l'aide de la liste Jython :
    AdminTask.listControlOps(['-blaID', 'myBLA', '–cuID', 'myservice.jar', '–long true'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.listControlOps('-interactive')

startBLA

La commande startBLA lance l'application de niveau métier qui vous intéresse.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier à démarrer. La commande accepte un ID configuration incomplet si le système parvient à rattacher la chaîne à un ID unique de votre configuration. (Chaîne, obligatoire)

Valeur renvoyée

La commande renvoie un message d'état si l'application de niveau métier démarre. Si l'application ne démarre pas, la commande ne renvoie pas de sortie. Voici un exemple de message d'état émis en sortie :
BLA ID of started BLA if the BLA was not already running.  

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.startBLA('-blaID myBLA')
  • A l'aide de la liste Jython :
    AdminTask.startBLA(['-blaID', 'myBLA'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.startBLA('-interactive')

stopBLA

La commande stopBLA arrête l'application de niveau métier qui vous intéresse.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier à arrêter. La commande accepte un ID configuration incomplet si le système parvient à rattacher la chaîne à un ID unique de votre configuration. (Chaîne, obligatoire)

Valeur renvoyée

La commande renvoie un message d'état si l'application de niveau métier s'arrête. Si l'application ne s'arrête pas, la commande ne renvoie pas de sortie. Voici un exemple de message d'état émis en sortie :
BLA ID of stopped BLA if the BLA was not already stopped. 

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.stopBLA('-blaID myBLA')
  • A l'aide de la liste Jython :
    AdminTask.stopBLA(['-blaID', 'myBLA'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.stopBLA('-interactive')

viewBLA

La commande viewBLA affiche le nom et la description de l'application de niveau métier qui vous intéresse.

Objet cible

Aucun

Paramètres requis

-blaID
Indique l'ID configuration de l'application de niveau métier qui vous intéresse. La commande accepte un ID configuration incomplet si le système parvient à rattacher la chaîne à une application unique de niveau métier. (Chaîne, obligatoire)

Paramètres optionnels

Aucun

Valeur renvoyée

La commande renvoie des informations de configuration sur l'application de niveau métier qui vous intéresse, comme l'illustre l'exemple suivant :
Specify BLA options (BLAOptions)

Specify options for BLA

*BLA Name (name): [DefaultApplication]
BLA Description (description): []

Exemple d'utilisation en mode de traitement par lots

  • A l'aide de la chaîne Jython :
    AdminTask.viewBLA('-blaID DefaultApplication')
  • A l'aide de la liste Jython :
    AdminTask.viewBLA(['-blaID', 'DefaultApplication'])

Exemple d'utilisation en mode interactif

  • En langage Jython :
    AdminTask.viewBLA('-interactive')

Icône indiquant le type de rubrique Rubrique de référence



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=rxml_7blamgmt
Nom du fichier : rxml_7blamgmt.html