The installation deploys the CLI along with the BWC services. CLI can be used to access BWC
service remotely. All BWC operations are also available via REST API, Python, and JavaScript
bindings. Check the CLI and Python Client reference for details.

If authentication is enabled, obtain authentication token with
st2auth<username>, and supply the token to each st2 command using the --token or -t
parameter. For convenience, keep the credential in the CLI config file, or set the environment
variable ST2_AUTH_TOKEN. When using environment variable, make sure that ST2_API_URL and
ST2_AUTH_URL are set appropriately. The doc section on authentication
usage contains additional notes. A nice shortcut for now is:

BWC comes with several generic actions out of the box. The catalog of actions can be easily
extended by getting actions from the community or consuming your existing scripts (more on that
later). Browse the catalog with st2actionlist. Action is referred to by ref as
pack.action_name (e.g. core.local). Learn about an action by doing
st2actionget<action>, or, st2run<action>--h(--help): the command shows the
description along with action parameters so that you know how to run it from the CLI or use it
in rules and workflows.

For core.local and core.remote actions, we use -- to separate action parameters
to ensure that options keys, like -l or -a are properly passed to the action.
Alternatively, core.local and core.remote actions take the cmd parameter to pass
crazily complex commands.

When specifying a command using the command line tool, you also need to escape all the
variables, otherwise the variables will get interpolated locally by a shell. Variables
are escaped using a backslash (\) - e.g.
\$user.

BWC uses rules to fire actions or workflows when events happen. Events are typically monitored
by sensors. When a sensor catches an event, it fires a trigger. Trigger trips the rule, the rule
checks the criteria and if it matches, it runs an action. Easy enough. Let’s look at an example.

The rule definition is a YAML file with three sections: trigger, criteria, and action. This example is
setup to react on a webhook trigger and applies filtering criteria on the content of the trigger.
The webhook in this example is setup to listen on the sample sub-url at
https://{host}/api/v1/webhooks/sample. When a POST is made on this URL, the trigger
fires. If the criteria matches, value in payload is st2 in this case, the payload will be
appended to the file st2.webhook_sample.out in the home directory of the user setup to run BWC.
By default, stanley is the default user and the file will be located at
/home/stanley/st2.webhook_sample.out. See Rules for detailed rule anatomy.

The trigger payload is referred to with {{trigger}}. If the trigger payload is a valid JSON object,
it is parsed and can be accessed like {{trigger.path.to.parameter}} (it’s
Jinja template syntax).

What are the triggers available to use in rules? Just like with actions, use the CLI to browse
triggers, learn what the trigger does, how to configure it, and what the payload structure is:

Examples of rules, custom sensors, actions, and workflows are installed with BWC and located
at /usr/share/doc/st2/examples. To deploy, copy them
to /opt/stackstorm/packs/, setup, and reload the content:

While most data are retrieved as needed by BWC, you may need to store and share some common
variables. Use BWC datastore service to store the values and reference them in rules and workflows
as {{st2kv.system.my_parameter}}. This creates user=stanley key-value pair: