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.
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
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
- -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: 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
- 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]]'])
- 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
- -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
WebSphere:assetname=asset2.zip
Exemple d'utilisation en mode de traitement par lots
- 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'])
- 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]]')
- 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]]'])
- 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
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
- Avec Jython :
AdminTask.listAssets()
- 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'])
- 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
- -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
- 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'])
- 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'])
- 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'])
- 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]]'])
- 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
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
- -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
WebSphere:cuname=cu4
WebSphere:cuname=cua
WebSphere:cuname=cud
Exemple d'utilisation en mode de traitement par lots
- 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]'])
- 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]]'])
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"]]
]')
- 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]]'])
- 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]]'])
- 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]]'])
- 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]]'])
- 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
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
- -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
- 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]'])
- 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]]'])
- 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]'])
- 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
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
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]
- 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
- 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'])
- 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
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
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
- -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
WebSphere:blaname=myBLA
WebSphere:blaname=yourBLA
Exemple d'utilisation en mode de traitement par lots
- En langage
Jython :
AdminTask.listBLAs()
- A l'aide de la chaîne Jython :
AdminTask.listBLAs('-blaID myBLA')
- A l'aide de la liste Jython :
AdminTask.listBLAs(['-blaID', 'myBLA'])
- 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
"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
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
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
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')