You can use the Jacl or Jython scripting languages to manage
application editions.
Use the following commands to activate, deactivate, perform
a rollout on, and validate an edition.
activateEdition
The activateEdition command
activates an edition.
Target object
None.
Required parameters
- -appName
- Specifies the name of the application. (String)
- -edition
- Specifies the name of the application edition. (String)
Optional parameters
None.
Return value
The command returns:
- true: success
- false: failure
Batch mode example usage
- Using Jacl:
$AdminTask activateEdition {-appName BeenThere -edition 1.0}
- Using Jython string:
AdminTask.activateEdition ('[-appName BeenThere -edition 1.0]')
Interactive mode example usage
- Using Jacl:
$AdminTask activateEdition {-interactive}
- Using Jython string:
AdminTask.activateEdition ('[-interactive]')
deactivateEdition
The deactivateEdition command
deactivates an edition.
Target object
None.
Required parameters
- -appName
- Specifies the name of the application. (String)
- -edition
- Specifies the name of the application edition. (String)
Optional parameters
None.
Return value
The command returns:
- true: success
- false: failure
Batch mode example usage
- Using Jacl:
$AdminTask deactivateEdition {-appName BeenThere -edition 1.0}
- Using Jython string:
AdminTask.deactivateEdition ('[-appName BeenThere -edition 1.0]')
Interactive mode example usage
- Using Jacl:
$AdminTask deactivateEdition {-interactive}
- Using Jython string:
AdminTask.deactivateEdition ('[-interactive]')
rolloutEdition
The rolloutEdition command
rolls out an edition and specifies the group size.
Target object
None.
Required parameters
- -appName
- Specifies the name of the application. (String)
- -edition
- Specifies the value of the custom property. (String)
- -params
- Specifies configuration values for the rollout. (String)
rollout
strategy
- group: Activates the specified application in place of the current
edition of the same application across the cluster on which the application
cluster deploys, N servers at a time, as specified by the groupSize keyword.
The default group size is 1. During rollout, both
editions of the application can serve requests. Always set the group
number to be at least one less than the cluster size so that at least
one cluster member serves the old edition while the rollout of the
new edition starts.
- atomic: Activates the specified application in place of the current
edition of the same application across the cluster on which the application
cluster deploys, one half of the cluster at a time, such that only
one edition of the application serves requests at any given time.
reset strategy
Specifies how to start an
application edition instance during the rollout operation.
- hard: Stops or restarts the application server.
- soft: Stops or restarts the application instance, while leaving
the application server running.
group size for group rollout
Specifies the
number of servers to update when
rolloutStrategy is
grouped.
drainage interval
Specifies the number of
seconds to wait before stopping an application edition instance during
the rollout such that sessions can complete. The default is
30 seconds.
Optional parameters
None.
Return value
The command returns:
- true: success
- false: failure
Batch mode example usage
- Using Jacl:
$AdminTask rolloutEdition {-appName BeenThere -edition 1.0 -params “{rolloutStrategy grouped}{resetStrategy soft}{groupSize 1}{drainageInterval 30}”}
- Using Jython string:
AdminTask.rolloutEdition ('[-appName BeenThere -edition 1.0 -params “{rolloutStrategy grouped}{resetStrategy soft}{groupSize 1}{drainageInterval 30}”]')
Interactive mode example usage
- Using Jacl:
$AdminTask rolloutEdition {-interactive}
- Using Jython string:
AdminTask.rolloutEdition ('[-interactive]')
validateEdition
The validateEdition command
validates an edition.
Target object
None.
Parameters
- -appName
- Specifies the name of the application. (String)
- -edition
- Specifies the name of the application edition. (String)
Optional parameters
- -params
- Specifies the parameters for setting the size of the cluster that
is being cloned during validation. By default, the size of the original
cluster is used if the parameters are not specified.
- Dynamic cluster:
- dynClusterMaxSize
- Specifies the maximum size of the dynamic cluster.
- dynClusterMinSize
- Specifies the minimum size of the dynamic cluster.
- Static cluster:
- staticClusterSize
- Specifies the size of the static cluster. The value of staticClusterSize cannot
exceed the size of the static cluster that is kbeing cloned.
Return value
The
command returns:
- true: success
- false: failure
Batch mode example usage
- Using Jacl:
$AdminTask validateEdition {-appName BeenThere -edition 1.0 -params “{dynClusterMaxSize 2}{dynClusterMinSize 1}”}
- Using Jython string:
AdminTask.validateEdition ('[-appName BeenThere -edition 1.0 -params “{dynClusterMaxSize 2}{dynClusterMinSize 1}”]')
Interactive mode example usage
- Using Jacl:
$AdminTask validateEdition {-interactive}
- Using Jython string:
AdminTask.validateEdition ('[-interactive]')