{section}
{column}

h1. Introduction

Petals ESB CLI is a command line client to administrate a set of Petals nodes.
Petals ESB CLI has 4 interaction modes:
* *Interactive Mode:* [in this mode|#Interactive console], the user types in commands directly in the shell.
* *Scripting Mode:* [in this mode|#Execution of a Petals script file], Petals ESB CLI executes a script file that contains Petals ESB CLI commands.
* *Executable Mode:* [in this mode|#Execution of a Petals ESB CLI command directly on the command line], Petals ESB CLI is launched with a command as an argument.
* *Redirection Mode:* [in this mode|#Execution of an inlined Petals script], Petals ESB CLI takes the commands to execute from the standard input.

To work, Petals ESB CLI needs to establish a connection with a Petals node.
The connection is a JMX connection (see the credentials defined in the _topology.xml_ file of Petals).

h1. Usage of Petals ESB CLI

-a,--alias <alias> Connection alias in the preference file.
-c,--command Execute a command given on the command line after '--'.
-C,--console Enable the mode 'console'.
-d,--debug Print stack trace and debugging informations
--file <filename> Enable the script file execution. If filename is '-',
commands are read from the stdin.
-H,--help Print this help message and exit.
-h,--host <host> JMX host of the remote petals ESB.
-n,--port <port> JMX port of the remote petals ESB.
-p,--password <password> JMX password of the remote petals ESB.
-u,--user <user> JMX user of the remote petals ESB.
-V,--version Print the version number and exit.
-y,--yes Enable automatic confirmation ('yes' flag)

Which evolution would you like on Petals? Share it! http://www.petalslink.com/feedback

connect Connect to a Petals ESB node.
deploy Deploy and start a JBI artifact.
disconnect
Disconnect from a petals container.
exit Exit this shell.
help Display this help message or help for a specific command.
list List JBI artifacts name and current status.
load Load properties from files.
logger-set
Set the specified level to the specified logger.
loggers Return all the loggers.
print Print a message.
properties-list
Get the values defined in its server.properties file.
pwd Print the working directory.
endpoint-list
List the entries of the endpoint directory.
set Assign a value to the system property named key.
show Print informations about a JBI artifact.
start-artifact
Start a JBI artifact.
stop Stop the container.
stop-artifact
Stop a JBI artifact.
system Execute system command.
topology-list
Get information about the topology this node is part o.
undeploy Stop and uninstall or undeploy JBI artifacts.
version Print version informations about petals container.

For help on a specific command type:
help <command>

{panel:title=Table of contents}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}

h1. Use Cases

{gliffy:name=Petals_CLI_Use_Cases|align=center|size=M|version=3}

h1. Petals ESB CLI: the Basis

h2. Installing Petals-CLI

| Mac OS | all | ZIP archive | [Installing Petals ESB CLI using the ZIP archive] |

+Note:+ The ZIP archive can be used on Debian-based systems. In this case, Petals ESB CLI should be installed as a user software without integration with the operating system.

h2. Petals ESB CLI capabilities about script and shell usages

h3. Interactive console

Launching Petals ESB CLI with the following command line starts an interactive console with a prompt where the user can enter commands.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli>
{code}

On Windows, to be able to launch Petals ESB CLI by a double-click, this command is wrapped by another script: *petals-cli-console.bat*.
On Linux, there is no wrapper script but a shell alias can be created.

h3. Execution of a Petals ESB CLI command directly on the command line

Launching Petals ESB CLI with the following command line executes the command specified on the command line.
{code}
> ./petals-cli.sh -c -- <command> <command-args>
{code}

h3. Execution of a Petals script file

Launching Petals ESB CLI with the following command line executes the commands from the specified Petals script.
{code}
> ./petals-cli.sh <filename>
> ./petals-cli.sh --file <filename>

Launching Petals ESB CLI with the following command line executes commands provided through the standard input ("stdin").

{code}
> cat <filename> | ./petals-cli.sh -
> cat <filename> | ./petals-cli.sh --file -
> ./petals-cli.sh - << EOF
<command1> <command1-args>
<command2> <command2-args>
EOF
> ./petals-cli.sh --file - << EOF
<command1> <command1-args>
<command2> <command2-args>
EOF
{code}

h2. Getting help

h3. Getting help on command line options and arguments

The help on command line options and arguments is available through the '_\-H_' option. A text containing options, arguments and available commands is displayed according to the usage defined above.
{code}
> ./petals-cli.sh -H
{code}

h3. Getting help on commands from the command line

The help on a command is available by using the command '_help_'. A usage and a description of the command is displayed:
{code}
> ./petals-cli.sh -c -- help <command>

usage: <command> <command-arguments>

<command description>

>
{code}
where:
* {{<command>}} is the command for which we want to get help.
* {{<command-arguments>}} is the list of arguments for the command.
* {{<command-description}} is a description of the command.

h3. Getting help on available commands and on a command in interactive mode

The list of available commands is available by using the command '_help_' without argument.
Help about a command is available by using the '_help_' command. Command's usage and description are then displayed.
{code}> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> help

Available commands:
deploy Deploy and start a JBI artifact in petals container.
exit Exit this shell.
help Display this help message or help for a specific command.
...

For help on a specific command type:
help <command>

petals-cli> help <command>

usage: <command> <command-arguments>

<command description>

petals-cli>
{code}
where:
* {{<command>}} is the command for which we want to get help.
* {{<command-arguments>}} is the list of arguments for the command.
* {{<command-description}} is a description of the command.

h2. Getting the version of Petals ESB CLI

To get the version of Petals ESB CLI, the version of the JVM running Petals ESB CLI, and its operating system, use the '_\-V_' option:
{code}
> ./petals-cli.sh -V
Petals ESB Command Line Interface 2.2.0
OpenJDK Runtime Environment 1.7.0_79-b14
Linux 3.19.0-30-generic
{code}

h2. Working with variables

Petals ESB CLI supports variables as properties or environment variables. A variable is a placeholder with a name: {{${variable-name\}}}, that is replaced by its value when evaluating the command in which it is used. By default, a variable is a property. An environment variable is identified by a name prefixed with "env:":
{code}
connect -h ${host.name} -n ${host.port} -u ${env:USER} -p ${host.password}
{code}

h3. Listing available variables

The command '_set_' without argument lists all available variables, properties and environment variables:
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> set
...
java.runtime.name=OpenJDK Runtime Environment
java.runtime.version=1.7.0_79-b14
java.specification.name=Java Platform API Specification
java.specification.vendor=Oracle Corporation
java.specification.version=1.7
...
env:PATH=usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/cdeneux/maven/bin
env:PETALS_CLI_PREFS=/home/cdeneux/.petals-cli/petals-cli.default
...
{code}

h3. Setting a variable as property

A property can be set using the command '_set_':
{code}
set [ property-name = property-value ]
set [ property-name =: property-value ]
set [ property-name : property-value ]

> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> set my-property-name=value
{code}

h2. Return codes of Petals ESB CLI

h3. Return code on error parsing mode options

If Petals ESB CLI is not able to determine the mode (interactive, scripting, executable or redirection) to use from arguments, the return code will be 1.

h3. Return code of Petals ESB CLI launched in interactive mode

Petals ESB CLI launched in interactive mode will exist always with the return code 0, even if error occurs executing a command.
If an error occurs during a command execution or parsing:
* The error message is displayed.
* Petals ESB CLI is not interrupted, the user can enter other commands.

h3. Return codes of Petals ESB CLI launched in command line mode

h4. Return code on parsing error of the command arguments

When there is an error about options and arguments of the command, the return code of Petals ESB CLI is 1.

h4. Return code on command execution

When there is an error about the command execution, the command is interrupted and the return code of Petals ESB CLI is 2.

h4. Return code on connection error

When there is an error about the connection establishment, the command is not executed the return code of Petals ESB CLI is 3. If the error is due to an unresolvable hostname, the return code is 1 (ie. error on arguments).

h4. Return code on successful command execution

When there is no error about options, arguments and execution of a the command, the return code of Petals ESB CLI is the return code of the command

h3. Return code of commands

All commands return the return code 0 when the execution succeeds, and 1 when the execution fails. Except the command '{{system}}' that returns the return code of the system command invoked.

h3. Return codes of Petals ESB CLI launched in scripting modes

h4. Return code on error reading script

When there is an error reading the command flow, Petals ESB CLI script is interrupted and the return code of Petals ESB CLI is 1.

h4. Return code on parsing error of the command arguments

When using the script mode or inlined mode, parsing errors (invalid options and/or arguments) result in an interruption of Petals ESB CLI.
The return code 1 then pushed back.

h4. Return code on command execution

When there is an error about a command execution, the command is interrupted, Petals ESB CLI script is interrupted and the return code of Petals ESB CLI is 2.

h4. Return code on connection error

When there is an error about the connection establishment, the command is not executed and the return code of Petals ESB CLI is 3. If the error is due to an unresolvable hostname, the return code is 1 (ie. error on arguments).

h4. Return code on successful command execution

When there is no error about options, arguments and execution of commands, the return code of Petals ESB CLI is the return code of the last command, except if a dedicated value is used through the command {{exit}}.

h4. Error management of a command read from stdin or a file

If an error occurs during the execution of a flow of commands:
* The command that has thrown the error is interrupted.
* The return code of the command can be checked using the commands _isParsingErrorReturned_, _isExecutionErrorReturned_, _isNoErrorReturned_, the ternary conditional operator, and the _lastErrorCode_ attribute.
{code}
> ./petals-cli.sh - << EOF
deploy <artifact-url>
isNoErrorReturned ? listartefacts : exit lastErrorCode
EOF
{code}

\\
Note:
* The return values of command {{isParsingErrorReturned}}, {{isExecutionErrorReturned}} and {{isNoErrorReturned}} are reset when invoking another command. Only the error of the last command execution can be checked.
* The attribute {{lastErrorCode}} is an argument of the command {{exit}} to return the return code of the last executed command.

h2. Exit from the Console mode

To exit the console mode, use the '_exit_' command.
If a number is set as an argument, it is used as return code. Otherwise, the 0 is returned.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> exit
> echo $?
0
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> exit 1
> echo $?
1
{code}

{note}If an asynchronous command is running, the command 'exit' will wait the end of these pending commands to really exit. If you have infinite asynchronous command as defect subscription, you can force to exit using Ctrl+C or kill the processus.{note}

h2. Petals ESB CLI Preferences

It is possible to define preferences in Petals ESB CLI. The preferences are defined in a properties file, as key/value pairs. Two levels of preference files are defined:
* a user level, by the file {{$HOME/.petals-cli/petals-cli.default}}
* and a system level. The location of this file is defined according to the operating system:
|| OS/Distribution || System level file ||
| Linux/Debian-based distribution | {{/etc/petals-cli/petals-cli.default}} |
| Windows | {{%PETALS_CLI_HOME%\conf\petals-cli.default}} |

If the user preference file exists, it is used. Otherwise the system preference file is used.

{tip}
If Petals ESB CLI is installed through the ZIP archive, and no user level file exists, it is possible to define another preference file through the environment variable _$PETALS_CLI_PREFS_.
{tip}

{tip}
If Petals ESB CLI is installed through the Debian archive, the default preference file is protected by system ACL and can be read only by users that are member of its group. So don't forget to add you users to the security group, or you can protect this file with your own group.
{tip}

The preferences files contain a set of keys in several sections:
* section 'Global preferences':
** *alias.default*: the default alias to use (required).
** *user.lang*: the language to use in Petals ESB CLI.
*** This property is optional. If not set, OS settings are used. If the OS language setting is not supported, then English is used.
*** If the value is specified and not supported, then English is picked up.
*** French and English are the two languages that must be supported. Others are optional (but contributions are welcome).
** *embedded.http.port*: the listening port of the embedded HTTP server (see the command {{deploy}}). Default value: 0 (any free port). To be able to use several Petals ESB CLI instances concurrently on the same machine, you must set {{embedded.http.port}} to 0 to force the use of a free port, otherwise an error will occur on deployments.
* section defining aliases. An alias identifies all the properties of a connection. An alias is defined as following:
** *<alias>.host*: the host of the default Petals node (required).
** *<alias>.port*: the JMX port of the default Petals node (required).
** *<alias>.username*: the JMX user name for the default Petals node (optional).
** *<alias>.password*: the JMX password for the default Petals node (optional).
** *<alias>.passphrase*: the security passphrase to access critical information or execute critical operation on other Petals nodes (than the one on which Petals ESB CLI is connected) of the topology (optional).

When optional keys are not defined, Petals ESB CLI will ask for their values manually (or you will have to use the right options with the commands).
If the file does not exist, or that _$PETALS_CLI_PREFS_ points to an invalid location, Petals ESB CLI will use default settings when possible. Otherwise, it will display an error message.

For a server, the *user* and *password* must both be set or both be absent. An error message is displayed if only one of them is specified.

The server alias must be unique in the properties file. If a server alias is used twice, an error message will be displayed.

{note}In a production environment, we discourage setting passphrase at alias level to increase the security.{note}

Sample content of the file:
{code}
# The default server / connection
alias.default = default

# The connection properties of the 1st server
default.host = localhost
default.port = 7700
default.username = petals
default.password = petals
default.passphrase = petals
{code}

h2. Petals ESB CLI extensions

Several Petals ESB CLI extensions are available, they comes with new command(s):
* [Petals BC SFTP tooling|Petals BC SFTP tooling],
* [Monitoring for Cacti|Command 'monitoring'].

h1. Connection to a Petals node

h2. Connection options from the command line

All the required parameters for a JMX connection can be configured on the command line as options or through the command {{connect}}:
{code}

An alias can also be used.
{code}
> ./petals-cli.sh -a <alias> -c -- <command>
> ./petals-cli.sh -C
petals-cli> connect -a <alias1>
petals-cli@<host1>:<port1>>

In console mode, the connection is established, by the command 'connect', with the values given in the preferences file. The connection parameters are identified through the default alias defined by the property {{alias.default}} of the preferences file.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
petals-cli> Would you like to connect to <default-user>:*****@<default-host>:<default-port>? (y/n)
y
petals-cli@<default-host>:<default-port>>
{code}

The confirmation can be skipped by adding the '_yes_' argument to the command.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect -y
petals-cli@<default-host>:<default-port>>
{code}

In command line mode, no default connection is available. A connection is *automatically* established with the connection parameters explicitly set on the command line.

{code}
> ./petals-cli.sh -h localhost -n 7700 -u petals -p petals -c -- stop
> ./petals-cli.sh -a default -c -- stop
{code}

{tip}This is necessary to easily stop a local container{tip}

In script mode, the connection is established, by the command 'connect', with the values given in the preferences file. The connection parameters are identified through the default alias defined by the property {{alias.default}} of the preferences file.
{code}
> ./petals-cli.sh - << EOF
connect
EOF
{code}

If the preferences file does not exist and that _connect_ was invoked without an argument, the command returns the error code 2.

h2. Interacting with several Petals nodes without exiting Petals ESB CLI

In interactive mode or script mode, we should be able to close a connection and open another one without leaving Petals ESB CLI. This is achieved with the '_connect_' and '_disconnect_' commands. If no argument is set on the '_connect_' command, default values are used. These default values are specified in the preferences file. If a connection already exists, the '_connect_' command will realize a disconnection before to establish the new connection.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect -h <host1> -n <port1> -u <user1> -p <password1>
Connected on <host1>:<port1> with '<user1>'
petals-cli@<host1>:<port1>> disconnect
petals-cli> connect -a <alias>
Connected on <host1>:<port1> with '<user1>'
petals-cli@<host1>:<port1>> disconnect
petals-cli> connect -h <host2> -n <port2> -u <user2> -p <password2>
Connected on <host2>:<port2> with '<user2>'
petals-cli@<host2>:<port2>> connect
petals-cli@<host2>:<port2>> Would you like to connect to <default-user>:*****@<default-host>:<default-port>? (y/n)
y
petals-cli@<default-host>:<default-port>>
{code}

h2. Security

For security reasons, a Petals ESB CLI user may decide that there should be no default connection.
In that case, he may decide to delete the preference file, so that any user will have to type in the right information.
If the preference (properties file) does not exist, Petals ESB CLI displays an error message.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
No default connection is available. Use 'help connect' for more information.
{code}

\\
Another possibility is that the user allows to record a default host and port but not the credentials.
In that case, Petals ESB CLI will ask the user to type in the credentials.

{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect
petals-cli> Would you like to connect to <default-host>:<-default-port>? (y/n)
y
petals-cli> Username: wrong-username
petals-cli> Password: right-pwd
Invalid credentials.
petals-cli> Retry? (y/n)
y

petals-cli> Username: right-username
petals-cli> Password: wrong-pwd
Invalid credentials.
petals-cli> Retry? (y/n)
y

petals-cli> Username: right-username
petals-cli> Password: right-pwd
petals-cli@<default-host>:<-default-port>>
{code}

h2. Error Messages

{tip}Error messages should be written in active form.
Negative forms should be avoided.{tip}

\\
The preferences file does not exist.
The connect command results in the following error message.

{quote}No default connection is available. Use 'help connect' for more information.{quote}

\\
The preferences file is invalid (missing property, or duplicate alias...).
The connect command results in the following error message.

{quote}The preferences file contains <N> error(s).
- Error 1
- Error2{quote}

\\
Duplicate Alias.
{quote}The alias '<alias>' can only be used once.{quote}

\\
Missing property.
{quote}The property '<property>' is missing.{quote}

\\
Only *user* was specified for a server.
{quote}The credentials for '<alias>' are invalid: add the password or remove the user.{quote}

\\
Only *password* was specified for a server.
{quote}The credentials for '<alias>' are invalid: add the user or remove the password.{quote}

h1. Administration Commands

h2. Working with JBI artifacts

h3. Artifact lifecycle managed by PetalsCLI

{gliffy:name=Artifact lifecycle of PetalsCLI|align=center|version=4}

Petals ESB CLI is able to deploy and start:
* a JBI artifact without distinction between shared-library, component, service assembly and deployable service unit,
* or [Petals ESB bus object model|petalscomponents:Petals ESB Deployer 1.0.0#busObjectModel],
using the following command:
{code}
deploy -u <artifact-file> [-f,--file <configuration-file> | -D <configuration-properties>] [-s,--skip-startup]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the artifact to install or deploy and start
* *<configuration-file>* is the local file name or the URL correctly encoded of the properties file used to configure the artifact. This argument is used only if the artifact is a component or a Petals ESB bus object model. It has no sense for other artifacts. This argument is exclusive with {{<configuration-properties>}}.

{tip}Auto-completion is available on artifact file names.{tip}

The command {{deploy}} is able to deploy an artifact local to Petals ESB CLI on a remote Petals ESB container. An artifact is local to Petals ESB CLI if deployed using a file or an URL with the protocol 'file'. In this case, the command {{deploy}} uses an embedded HTTP server. So the remote Petals ESB container will be able to download the artifact to deploy from Petals ESB CLI. See Petals ESB CLI preferences to configure the embedded HTTP server.

If the artifact to deploy is:
* a component:
** if its component installer is already loaded (the component is not installed), then the command '{{deploy}}' will unload the component installer, reload a new one and continue the lifecycle (configuration, installation and start),
** if the component is installed:
*** if the component is shutdown, then the command '{{deploy}}' will uninstall the component, unload the component installer, reload a new one and continue the lifecycle (configuration, installation and start),
*** otherwise an error occurs, use command '{{undeploy}}' to fix it.
* a service assembly:
** if the SA is already deployed and in state 'SHUTDOWN', then the command '{{deploy}}' will undeploy the service assembly, before to re-deploy a new one,
** otherwise an error occurs, use command '{{undeploy}}' to fix it.
* a deployable service unit:
** a service assembly is created from the deployable service unit,
** next, the service assembly is deployed usually,
* a Petals ESB bus object model:
** previous rules are applied for components, service-assemblies and deployable service unit.

h3. Bulk Deployment and Start

To deploy and start several artifacts in one command, just put them in a local directory and execute the command '_deploy_':
{code}
deploy -b,--bulk <url|file> [-s,--skip-startup]
{code}
{code}
> ./petals-cli.sh -y - << EOF
deploy -b file:///tmp
EOF
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> deploy -b /tmp
{code}

h3. Starting an Artifact

An artifact can be started by using the '_start-artifact_' command:
{code}
> ./petals-cli.sh -c -- start-artifact [ -u <artifact-file> | -a <artifact-id> [-t <artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the artifact to start.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to start. Accepted values are: SL, BC, SL, SA.
* *<artifact-id>* is the JBI identifier of the artifact to start.

{tip}Auto-completion is available on artifacts IDs, artifact file names and artifact types. The auto-completer for artifact identifiers displays only artifacts in state STOPPED or SHUTDOWNED.{tip}

If the artifact to start is a component or a service assembly, the command '{{start-artifact}}' will succeed only if the artifact state on Petals ESB side is 'STOPPED' or 'SHUTDOWN', otherwise on error will occur.

If you want to start a deployable service unit, you must start the associated service assembly that was created during the deployment of the service unit.

h3. Stopping an artifact

An artifact can be stopped by using the command '_stop\-_{_}artifact_':
{code}
> ./petals-cli.sh -c -- stop-artifact [ -u <artifact-file> | -a <artifact-id> [-t <artifact-type>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the artifact to stop.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to stop. Accepted values are: SL, BC, SL, SA.
* *<artifact-id>* is the JBI identifier of the artifact to stop.

{tip}Auto-completion is available on artifacts IDs, artifact file names and artifact types. The auto-completer for artifact identifiers displays only artifacts in state STARTED.{tip}

If the artifact to deploy is a component or a service assembly, the command '{{stop-artifact}}' will succeed only if the artifact state on Petals ESB side is 'STARTED', otherwise on error will occur.

If you want to stop a deployable service unit, you must stop the associated service assembly that was created during the deployment of the service unit.

h3. Undeploying and Stopping an Artifact at once

Petals ESB CLI is able to stop and uninstall/undeploy a JBI artifact without distinction between shared-library, component and service assembly using the following command:
{code}
undeploy [ -u <artifact-file> | -a <artifact-id> [-t <artifact-type>] [-v <artifact-version>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the artifact to undeploy.
* *<artifact-id>* is the JBI identifier of the artifact to undeploy.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to undeploy. Accepted values are: SL, BC, SL, SA.
* *<artifact-version>* is the artifact version to limit artifacts matching other criteria. Supported only for SL.

{tip}Auto-completion is available on artifacts IDs, artifact file names and artifact types.{tip}

No lifecycle error can occur. Whatever the artifact state, the command 'undeploy' will adapt to it to realize the undeployment. In particular, if the artifact is in state 'STOPPED', it will be undeployed without confirmation and the user will be responsible to re-deploy it.

If you want to undeploy a deployable service unit, you must undeploy the associated service assembly that was created during the deployment of the service unit.

h3. Bulk Undeployment and Stop

The undeployment command is able to stop and uninstall/undeploy several JBI artifact in one shoot using the bulk mode:

{code}
undeploy [ -b [<artifact-directory>] ] [ -y ]
{code}
where *<artifact-directory>* is a local directory name or the URL containing archives of artifacts to undeploy. If not set set, all JBI artifacts are stopped and undeployed/uninstalled.

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- undeploy -b
> ./petals-cli.sh -c -- undeploy -b -y
> ./petals-cli.sh -c -- undeploy -b
ERROR on command 'undeploy': A confirmation is required. Use option: : '-y'
{code}

If the directory, containing artifacts to undeploy, contains an artifact that is not deployed, a warning is displayed, no error occurs and the undeployment of other artifacts continues.
If an error occurs during the undeployment of an artifact, the bulk undeployment is interrupted.

h3. Showing installed JBI artifacts

All the installed JBI artefacts can be listed using the command '_list \[-p <artifact-pattern> \] \[-t artifact-type\]_':
{code}
> ./petals-cli.sh -c -- list
petals-sl-mysql(1.0.0) Installed SL
petals-bc-soap Loaded BC
petals-se-bpel Started SE
soap-consume-provide Started SA
su-SOAP-EchoService-consume SU
su-SOAP-EchoService-provide SU
{code}
where:
* {color:#000000}*<artifact-pattern>*{color} {color:#000000}is an optional RegExp pattern to filter the content of the returned list. All the returned JBI artifacts must have a JBI identifier matching the pattern. If no pattern is defined, all the installed artifacts are returned.{color}
* {color:#000000}*<artifact-type>*{color} {color:#000000}is one of the following values: SL, BC, SE, SA, SU, used to restrict the returned list.{color}

The returned list is ordered:
* firstly, according to the artifact type: SL, BC, SE, SA, SU,
* and secondly the alphabetical order is applied.

For each artifact, the command displays (caution to the padding):
* Its JBI identifier. If the JBI artifact is a shared library, the JBI identifier is displayed according to the following pattern: {{name(version)}}
* Its current status:
** {{Loaded}}, available only for component, the installer is loaded but the component is not installed
** {{Started}}
** {{Stopped}}
* Its type (SL, BC, SE, SA, SU).

{tip}As the SU lifecycle can't be modified through the JMX API, there is no interest to display the SU status (it's the same as the status of its SA).{tip}

h3. Getting information about an Artifact

Information about a JBI artifact can be got with the '_show_' command:
{code}
> ./petals-cli.sh -c -- show [-e] [ -u <artifact-file> | -a <artifact-id> [-t <artifact-type>] [-v <artifact-version>] ]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the artifact to show.
* *<artifact-id>* is the JBI identifier of the artifact to show.
* *<artifact-type>* is the nature (SL, component, SA) of the artifact to show. Accepted values are: SL, BC, SL, SA, SU.
* *<artifact-version>* is the artifact version to limit artifacts matching other criteria. Supported only for SL.

The '-e' option displays extended information.

Displayed information includes:

* For a shared library:
** Its JBI identifier

* For a component (BC or SE):
** Its JBI identifier
** Its type: binding component or service engine

* For a service assembly:
** Its JBI identifier
** If the service-assembly was built with Maven, its Maven version extracted from Maven metadata
** Its state (not-deployed, deployed, started, stopped, shutdown)
** List of embedded service-units (displayed using their JBI identifiers)
** Extended information (replace the previous list of embedded service-units):
*** For each service unit embedded:
*** Its JBI identifier
*** Its target component (displayed using its JBI identifier)

{tip}Auto-completion is available on artifacts IDs, artifact file names and artifact types.{tip}

h3. Reloading the external configuration of a JBI component

Each Petals CDK-based JBI component includes a parameter named '{{properties-file}}' containing placeholders to configure some parameters at service unit level. These placeholder values can be reloaded without stopping anything using the command '_reload\-_{_}configuration_':
{code}
> ./petals-cli.sh -c -- reload-configuration [ -u <artifact-file> | -a <artifact-id> ]
{code}
where:
* *<artifact-file>* is the local file name or the URL correctly encoded of the JBI component artifact for which the configuration must be reloaded,
* *<artifact-id>* is the JBI identifier of JBI component artifact for which the configuration must be reloaded.

{tip}Auto-completion is available on JBI component artifact identifiers and artifact file names. The auto-completer for artifact identifiers displays only artifacts in state STARTED or STOPPED.{tip}

h3. Interrupting a flow of commands

A flow of commands can be interrupted by using the '_exit_' command. If a number is set as argument, it is used as return code. The argument '_lastErrorCode_' is used as return code value of the last executed command. Otherwise, 0 is returned to the shell.
{code}
> ./petals-cli.sh -y - << EOF
deploy /tmp/my-artifact.zip
exit lastErrorCode
EOF
{code}

h3. Ending a flow of commands

When the end of a flow of commands is reached, if the last command is not '_exit_', the '_exit lastErrorCode_' command is implicitly executed.
{code}
> ./petals-cli.sh -y - << EOF
deploy /tmp/my-artifact.zip
EOF
echo $?
0
{code}

h2. Working with the Container

h3. Getting the versions related to a Petals node

To get the version of a Petals node, the version of the JVM running Petals node, and its operating system, use the '_version_' command:
{code}
> ./petals-cli.sh -c -- version
Petals JBI Container 5.0.0-M1
OpenJDK Runtime Environment 24.79-b02 Oracle Corporation
Linux 3.19.0-30-generic amd64
{code}

h3. Stopping the container

The container can be stopped by using the command '_stop_':
{code}
> ./petals-cli.sh -c -- stop
{code}

h3. Shutdowning the container

The container can be shut-downed by using the command '_stop_' and the parameter '_\--shutdown_'.
{code}
> ./petals-cli.sh -C
petals-cli@host:port> stop --shutdown
Are you sure you want to shutdown the container? (y/n)
{code}

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- stop --shutdown
> ./petals-cli.sh -c -- stop --shutdown -y
> ./petals-cli.sh -c -- stop --shutdown
ERROR on command 'stop': A confirmation is required. Use option: : '-y'
{code}

h3. Getting the server properties

When connected to a container, it is possible to get all the values defined in its *server.properties* file.

{code}
petals-cli@host:port> properties-list
Key1: value1
Key2: value2
...
{code}
where "keyN" and "valueN" are the keys and values defined in the *server.properties* file of this container.

h3. Changing logger levels

On a container, it is possible to change the level of a logger.
{code}
petals-cli@host:port> logger-set -n <logger-name> -l <level>
The log level was succesfully changed.
{code}

In case of error, the error message is "The log level could not be changed.", followed by a detailed message (e.g. "WARN is not a valid log level").

\\
To get all the available loggers with their level, use the command {{loggers}} without any argument.
{code}
petals-cli@host:port> loggers
<logger-name-1> <level>
<logger-name-2> <level>
...
{code}

\\
You can also use a regular expression to filter the candidate results.
{code}
petals-cli@host:port> loggers -p <regular expression>
<logger-name-1> <level>
<logger-name-2> <level>
...
{code}

{tip}Auto-completion is available on logger names and log levels.{tip}

h2. Working with the Topology

h3. Getting the topology

h4. Getting the topology only

When connected to a container, it is possible to get information about the topology of this node is part of.

{code}
petals-cli@host:port> topology-list
Domain: Domain 1
* Container: Node1 (Reachable)
** information

* Container: Node2 (Unreachable)
** information

...
{code}

Sensible information as credentials are returned only if a security passphrase is provided. This passphrase can be provided using the command option '-p'. Or, if you used an alias (including the default alias) to connect to the remote Petals container, the passphrase set at alias level ({{<alias>.passphrase}}) will be used automatically if defined.
{code}
petals-cli@host:port> topology-list -p mypassphrase
Domain: Domain 1
* Container: Node1 (Reachable)
** information including credentials
{code}
{note}In a production environment, we discourage setting passphrase at alias level to increase the security{note}

This command shows a set of Petals nodes of the same domain, each node having the following information:
* Container name,
* Container state (possible values are: {{Reachable}}, {{Unreachable}}, {{Unknown}}),
* Host,
* Node ports,
* Node credentials (only if the security passphrase is provided and correct).

petals-cli@host:port> topology-list -a -p mypassphrase
Domain: Domain 1
* Container: Node1 (Reachable)
** container information
** shared library informations
** component informations
** service assembly information

* Container: Node2 (Reachable)
** container information
** shared library informations
** component informations
** service assembly information

* Container: Node2 (Unreachable)
** container information

...
{code}

Information returned are:
* for share libraries: name and version,
* for components: name and state ({{Loaded}}, {{Started}} or {{Stopped}}),
* for service assemblies: name and state ({{Started}} or {{Stopped}}).

{note}To get information about JBI artifacts, the Petals container holding them must be reachable. So if one container can not be reached, no error is returned and no information about shared-libray, component and service-assemblies is displayed for this container.{note}

Domain: Domain 1
* Container: Node1 (Reachable)
** information of Node1

A running container can be moved to another domain, using the command '_move-container_':
{code}
>./petals-cli.sh -C
petals-cli@host:port> move-container [--target-domain <domain-0> [--target-host <localhost>] [--target-port <7700>] [--target-user <petals>] [--target-pwd <petals>] --target-pass-phrase <target-pass-phrase>]
Are you sure you want to move the current container ? (y/n)
{code}

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- move-container ...
> ./petals-cli.sh -c -- move-container -y ...
> ./petals-cli.sh -c -- move-container
ERROR on command 'move-container': A confirmation is required. Use option: : '-y'
{code}


h3. Detaching a container from domain

A running container can be detached from a domain, using the command '_move-container_':

where:
* the container to detach is the container on which Petals ESB CLI is connected

A confirmation is expected, except if the '_yes_' flag is set on the command line or as command argument, otherwise an error will occur.
A confirmation message is displayed in the console mode, except if the '_yes_' flag is set on the command line or as command argument.
{code}
> ./petals-cli.sh -y -c -- move-container ...
> ./petals-cli.sh -c -- move-container -y ...
> ./petals-cli.sh -c -- move-container
ERROR on command 'move-container': A confirmation is required. Use option: : '-y'
{code}

h2. Working with the endpoint directory

h3. Showing the endpoint directory's full content

The full content of the endpoint directory can be dumped by using the '_endpoint-list_' command:
{code}
petals-cli> endpoint-list
Endpoints:
<endpoint-name-1>: <endpoint-1-characteristics>
<endpoint-name-2>: <endpoint-2-characteristics>
Services:
<service-name-1>:
<endpoints-list>
<service-name-2>:
<endpoints-list>
Interfaces:
<interface-name-1>:
<endpoints-list>
<interface-name-2>:
<endpoints-list>
{code}

where:
* <endpoint-name-x> is an endpoint name.
* <endpoint-x-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-x> is a service name.
* <interface-name-x> is an interface name.
* <endpoints-list> is the list of endpoint name implementing the interface or service.

{note}Qualified names, like service and interface names, are written as follows:\{namespace-uri\}local-part.{note}

h4. Filtering the endpoint directory's full content

The content of the endpoint directory can be dumped by using the '_endpoint-list_' command.
It is however possible to filter the dumped result.
{code}
petals-cli> endpoint-list [-e <endpoint-name-regexp>] [-s <service-name-regexp>] [-i <interface-name-regexp>] [-c <container-name-regexp>]
{code}

where:
* *<endpoint-name-regexp>* is a regular expression used as filter on the full end-point name,
* *<service-name-regexp>* is a regular expression used as filter on the full service name,
* *<interface-name-regexp>* is a regular expression used as filter on the full interface name,
* *<container-name-regexp>* is a regular expression used as filter on the container name on which the endpoints are deployed.

The parameter order (endpoint, service, interface) does not matter.
All are optional. If none is specified, the entire endpoint directory content is dumped.

{note}
The \{ and \} are special in Java's regex dialect: they are the opening and closing tokens for the repetition quantifier {{\{n,m\}}} where {{n}} and {{m}} are integers. Hence the error message: "Illegal repetition".

You should escape them: {code}\{http://petals.ow2.org/\}Service{code}
{note}

h4. Controlling the output of the endpoint directory content dumped

The output of the command 'endpoint-list', defined below, is composed of 3 parts:
* endpoints, under the header '{{Endpoints:}}',
* services, under the header '{{Services:}}',
* interfaces, under the header '{{Interface:}}'.

You can select the parts to display one by one using:
{code}
petals-cli> endpoint-list [--output-endpoints] [--output-services] [--output-interfaces]
{code}

{code:title=Sample #1}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01]
Endpoints:
HelloEndpoint-TargetContainer0: target-container-0,petals-se-pojo,INTERNAL
HelloEndpoint-TargetContainer1: target-container-1,petals-se-pojo,INTERNAL
Services:
{http://petals.ow2.org/}HelloService0:
HelloEndpoint-TargetContainer0
{http://petals.ow2.org/}HelloService1:
HelloEndpoint-TargetContainer1
Interfaces:
{http://petals.ow2.org/}HelloPortType:
HelloEndpoint-TargetContainer0 HelloEndpoint-TargetContainer1
{code}
{code:title=Sample #2}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01] --output-endpoints
HelloEndpoint-TargetContainer0: target-container-0,petals-se-pojo,INTERNAL
HelloEndpoint-TargetContainer1: target-container-1,petals-se-pojo,INTERNAL
{code}
{code:title=Sample #3}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01] --output-endpoints --output-interfaces
Endpoints:
HelloEndpoint-TargetContainer0: target-container-0,petals-se-pojo,INTERNAL
HelloEndpoint-TargetContainer1: target-container-1,petals-se-pojo,INTERNAL
Interfaces:
{http://petals.ow2.org/}HelloPortType:
HelloEndpoint-TargetContainer0 HelloEndpoint-TargetContainer1
{code}
{code:title=Sample #4}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01] -s {http://petals.ow2.org/}HelloService0 --output-endpoints --output-services
Endpoints:
HelloEndpoint-TargetContainer0: target-container-0,petals-se-pojo,INTERNAL
HelloEndpoint-TargetContainer1: target-container-1,petals-se-pojo,INTERNAL
Services:
{http://petals.ow2.org/}HelloService0:
HelloEndpoint-TargetContainer0
{code}
{code:title=Sample #5}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01] -s {http://petals.ow2.org/}HelloService0 --output-services
{http://petals.ow2.org/}HelloService0:
HelloEndpoint-TargetContainer0
{code}
{code:title=Sample #6}
petals-cli@localhost:7700>endpoint-list -e HelloEndpoint-TargetContainer[01] --output-services
{http://petals.ow2.org/}HelloService0:
HelloEndpoint-TargetContainer0
{http://petals.ow2.org/}HelloService1:
HelloEndpoint-TargetContainer1
{code}

h2. Utility commands

Petals ESB CLI provides several utility commands:
* {{check-ssl-handshake}}: to check a SSL connection establishment.

check-ssl-handshake usage: check-ssl-handshake [-h <host>] [-k <keystore-file>] [-p <port>]
[--trust-all-certificates] [-u <keystore-file>]


DESCRIPTION:
Check SSL handshake to a geiven serverDeploy and start a JBI artifact

OPTIONS DESCRIPTION:
-h,--host <host> Hostname to connect. Default
value used: localhost
-k,--keystore-file <keystore-file> Keystore file containing
certificates. Default
keystore: the JVM one
-p,--port <port> Port on host to connect.
Default value used: 443
(HTTPS)
--trust-all-certificates Trust all certificates.
Certificate validation is
disabled.
-u,--keystore-passphrase <keystore-file> Passphrase to open the
keystore containing
certificates.
{code}

h2. System Commands

Petals ESB CLI can directly execute system commands.
To achieve it, the system command is an argument of the '_system_' command.

{code}
petals-cli> system <system-command>
{code}

As an example,

{code}
petals-cli> system pwd
{code}

displays the directory in which Petals ESB CLI runs.
The return code of the wrapping command is the return code of the system command.

{info}
A system command having arguments can also be enclosed with quotes:
{code}
petals-cli> system "echo My linux shell: ${env:SHELL}"
My linux shell: /bin/bash
{code}
{info}

{tip}
Caution to correctly escape the symbol '{{$}}' when using a system command with variables on command line:
{code}
$ petals-cli -c -- system echo My linux shell: \${env:SHELL} with the temporary folder: \${java.io.tmpdir}
My linux shell: /bin/bash with the temporary folder: /tmp
$ petals-cli -c -- system "echo My linux shell: \${env:SHELL} with the temporary folder: \${java.io.tmpdir}"
My linux shell: /bin/bash with the temporary folder: /tmp
{code}
{tip}

h1. Advanced usage

h2. Logging in Petals ESB CLI

Petals ESB CLI is provided with a default Java Logging configuration. This configuration displays logging trace as following:
{code}

{anchor:add_your_own_command}

h2. To add your custom command

Petals ESB CLI is provided with an API to add your own command.

h3. Writing your command

To create a new custom command, just create a new Java class that *IMPLEMENTS* the interface {{org.ow2.petals.cli.api.command.Command}}.
To be auto-discovered, your command *MUST* be declared in a resource named '{{META-INF/service/org.ow2.petals.cli.api.command.Command}}' (put the class name with the package part in this file).

If the new command needs third party products in addition of the ones already provided by Petals ESB CLI, they *MUST* be installed with your command.
{warning}No classloader isolation is available between commands, pay attention to versions of third-party products. They MUST match the version of those provided with Petals ESB CLI or those custom commands.{warning}

h3. Custom command installation

To install your command just put all needed JAR files in the directory {{$PETALS_CLI_HOME/extensions}}.

h2. Monitoring Petals with Petals ESB CLI

An extension of Petals ESB CLI was created to monitor Petals ESB.

This extension has several implementations. Each implementation is adapted to a monitoring tool, but can be used as a normal command. Now, only one implementation exist, [the Cacti's implementation|Command 'monitoring']

h2. Error about missing options

For commands requiring at least one option, an error can occur if the operand flag ({{'--'}}) is missing:
{code}
> ./petals-cli.sh -h localhost -n 7700 -u petals -p petals -c -- deploy -u file:///.../my-archive.zip
ERROR on command 'deploy': Missing option(s):b, u
usage: deploy [-b <url> | -u <url>] [-D
<property1=value1,property2=value2> | -f <configuration-file>]
{code}
This is due to the option overriding: the command deploy and Petals ESB CLI have the same option: {{\-u}}. Both {{\-u}} are processed by Petals ESB CLI option parsing. Just add {{'--'}} before the command to exclude the second {{'u'}} of the Petals ESB CLI option parsing. So it will be available for the command option parsing.

h2. Can not connect using URI : service:jmx:rmi:///jndi/rmi://<host>:7700/jmxRmiConnector with petals/petals

This error can reveal several configuration problems:
* a mistake in the *Petals ESB container configuration* at topology level:
If you are running Petals ESB with its *default* configuration on a host 'A', you will get the following error connecting the Petals ESB CLI from another host 'B':
{code}
ERROR: org.ow2.petals.jmx.api.api.exception.ConnectionErrorException: Can not connect using URI : service:jmx:rmi:///jndi/rmi://192.168.0.11:7700/jmxRmiConnector with petals/petals
{code}
By default, Petals ESB listens JMX connection from {{localhost}}, that's why you get the error. Update the host name of the Petals ESB in its topology configuration file to solve the problem.
* a mistake in your *network configuration* at system level:
On Linux system, check your file {{/etc/hosts}}. If declared, the host running the Petals ESB container must be correctly defined with its IP address.

h2. Petals ESB CLI seems to be frozen on command 'exit'

You entered the command exit in the interactive mode, and the Petals ESB CLI seems to be frozen: no prompt.
You probably have launched asynchronous commands as defect subscriptions, use Ctrl-C to force to exit the Petals ESB CLI or kill its process.