Actions are stateless functions that run on the OpenWhisk platform. For example, an action can be used to detect the faces in an image, respond to a database change, respond to an API call, or post a Tweet. In general, an action is invoked in response to an event and produces some observable output.
An action may be created from a function programmed using a number of supported languages and runtimes, or from a binary-compatible executable, or even executables packaged as Docker containers.
- The OpenWhisk CLI
wskmakes it easy to create and invoke actions. Instructions for configuring the CLI are available here.
While the actual function code will be specific to a language and runtime, the OpenWhisk operations to create, invoke and manage an action are the same regardless of the implementation choice. We recommend that you review the basics before moving on to advanced topics.
- The basics of working with actions (start here)
wskCLI operations and tips
- Accessing action metadata within the action body
To use a function as an action, it must conform to the following:
- The function accepts a dictionary as input and produces a dictionary as output. The input and output dictionaries are key-value pairs, where the key is a string and the value is any valid JSON value. The dictionaries are canonically represented as JSON objects when interfacing to an action via the REST API or the
- The function must be called
mainor otherwise must be explicitly exported to identify it as the entry point. The mechanics may vary depending on your choice of language, but in general the entry point can be specified using the
--mainflag when using the
In this section, you'll invoke a built-in action using the
wsk CLI, which you should
download and configure first if necessary.
Actions are identified by fully qualified names which generally have three parts separated by a forward slash:
- a namespace
- a package name
- the action name
As an example, we will work with a built-in sample action called
The namespace for this action is
whisk.system, the package name
samples, and the action name is
greeting. There are other sample actions and
utility actions, and later you'll learn how to explore the platform to discover more actions.
Let's take a look at the action body by saving the function locally:
.js extension. It will run using a Node.js runtime.
The contents of the file
greeting.js should match the function below. It is a short function which
accepts optional parameters and returns a standard greeting.
The command to invoke an action and get its result is
wsk action invoke <name> --result as in:
This command will print the following result to the terminal:
Actions may receive parameters as input, and the
wsk CLI makes it convenient to pass parameters to the actions from the command line. Briefly, this is done with the flag
--param key value where
key is the property name and
value is any valid JSON value. There is a longer tutorial on working with parameters that you should read after completing this basic walk-through.
/whisk.system/samples/greeting action accepts two optional input arguments, which are used to tailor the response. The default greeting as described earlier is "Hello, stranger from somewhere!". The words "stranger" and "somewhere" may be replaced by specifying the following parameters respectively:
namewhose value will replace the word "stranger",
placewhose value will replace the word "somewhere".
The style of invocation shown above is synchronous in that the request from the CLI blocks until the activation completes and the result is available from the OpenWhisk platform. This is generally useful for rapid iteration and development.
You can invoke an action asynchronously as well, by dropping the
--result command line option. In this case the action is invoked, and the OpenWhisk platform returns an activation ID which you can use later to retrieve the activation record.
To retrieve the activation record, you use the
wsk activation get <id> command, as in:
Sometimes it is helpful to invoke an action in a blocking style and receiving the activation record entirely
instead of just the result. This is achieved using the
--blocking command line parameter.
A blocking invocation request will wait for the activation result to be available. The wait period is the lesser of 60 seconds (this is the default for blocking invocations) or the action's configured time limit.
The result of the activation is returned if it is available within the blocking wait period. Otherwise, the activation continues processing in the system and an activation ID is returned so that one may check for the result later, as with non-blocking requests.
When an action exceeds its configured time limit, the activation record will indicate this error.
Some common CLI commands for working with activations are:
wsk activation list: lists all activations
wsk activation get --last: retrieves the most recent activation record
wsk activation result <activationId>: retrieves only the result of the activation (or use
--lastto get the most recent result).
wsk activation logs <activationId>: retrieves only the logs of the activation.
wsk activation logs <activationId> --strip: strips metadata from each log line so the logs are easier to read.
wsk activation list command#
activation list command lists all activations, or activations filtered by namespace or name. The result set can be limited by using several flags:
For example, to list the last 6 activations:
The meaning of the different columns in the list are:
|The date and time when the invocation occurred.|
|An activation ID that can be used to retrive the result using the |
|The runtime or action type|
|An indication of the latency, i.e. if the runtime container was cold or warm started.|
|Time taken to execute the invocation.|
|The outcome of the invocation. For an explanation of the various statuses, see the description of the |
|The fully qualified name of entity that was invoked.|
Each action invocation results in an activation record which contains the following fields:
activationId: The activation ID.
name: The namespace and name of the entity.
end: Timestamps recording the start and end of the activation. The values are in UNIX time format.
logs: An array of strings with the logs that are produced by the action during its activation. Each array element corresponds to a line output to
stderrby the action, and includes the time and stream of the log output. The structure is as follows:
annotations: An array of key-value pairs that record metadata about the action activation.
response: A dictionary that defines the following keys
status: The activation result, which might be one of the following values:
"success": the action invocation completed successfully.
"application error": the action was invoked, but returned an error value on purpose, for instance because a precondition on the arguments was not met.
"action developer error": the action was invoked, but it completed abnormally, for instance the action did not detect an exception, or a syntax error existed. This status code is also returned under specific conditions such as:- the action failed to initialize for any reason- the action exceeded its time limit during the init or run phase- the action specified a wrong docker container name- the action did not properly implement the expected runtime protocol- *"whisk internal error"*: the system was unable to invoke the action.
statusCode: A value between 0 and 3 that maps to the activation result, as described by the status field:
statusCode status 0 success 1 application error 2 action developer error 3 whisk internal error
success: Is true if and only if the status is "success".
result: A dictionary as a JSON object which contains the activation result. If the activation was successful, this contains the value that is returned by the action. If the activation was unsuccessful,
errorkey, generally with an explanation of the failure.
Earlier we saved the code from the
greeting action locally. We can use it to create our own version of the action in our own namespace.
For convenience, you can omit the namespace when working with actions that belong to you. Also if there is no package, then you simply use the action name without a package name.
If you modify the code and want to update the action, you can use
wsk action update instead of
wsk action create. The two commands are otherwise the same in terms of their command like parameters.
Sometimes it is necessary or just convenient to provide values for function parameters. These can serve as defaults, or as a way of reusing an action but with different parameters. Parameters can be bound to an action and unless overridden later by an invocation, they will provide the specified value to the function.
Here is an example.
You may still provide additional parameters, as in the
and even override the
When an invocation request is received, the system records the request and dispatches an activation.
The system returns an activation ID (in the case of a non-blocking invocation) to confirm that the invocation was received.
Notice that if there's a network failure or other failure which intervenes before you receive an HTTP response, it is possible that OpenWhisk received and processed the request.
The system attempts to invoke the action once and records the
status in the activation record.
Every invocation that is successfully received, and that the user might be billed for, will eventually have an activation record.
Note that in the case of action developer error the action may have partially run and generated externally visible side effects. It is the user's responsibility to check whether such side effects actually happened, and issue retry logic if desired. Also note that certain whisk internal errors will indicate that an action started running but the system failed before the action registered completion.
- Functions should be stateless, or idempotent. While the system does not enforce this property, there is no guarantee that any state maintained by an action will be available across invocations. In some cases, deliberately leaking state across invocations may be advantageous for performance, but also exposes some risks.
- An action executes in a sandboxed environment, namely a container. At any given time, a single activation will execute inside the container. Subsequent invocations of the same action may reuse a previous container, and there may exist more than one container at any given time, each having its own state.
- Invocations of an action are not ordered. If the user invokes an action twice from the command line or the REST API, the second invocation might run before the first. If the actions have side effects, they might be observed in any order.
- There is no guarantee that actions will execute atomically. Two actions can run concurrently and their side effects can be interleaved. OpenWhisk does not ensure any particular concurrent consistency model for side effects. Any concurrency side effects will be implementation-dependent.
- Actions have two phases: an initialization phase, and a run phase. During initialization, the function is loaded and prepared for execution. The run phase receives the action parameters provided at invocation time. Initialization is skipped if an action is dispatched to a previously initialized container --- this is referred to as a warm start. You can tell if an invocation was a warm activation or a cold one requiring initialization by inspecting the activation record.
- An action runs for a bounded amount of time. This limit can be configured per action, and applies to both the initialization and the execution separately. If the action time limit is exceeded during the initialization or run phase, the activation's response status is action developer error.
- Functions should follow best practices to reduce vulnerabilities by treating input as untrusted, and be aware of vulnerabilities they may inherit from third-party dependencies.
OpenWhisk actions might be invoked by other users, in response to various events, or as part of an action sequence. In such cases it can be useful to monitor the invocations.
You can use the OpenWhisk CLI to watch the output of actions as they are invoked.
- Issue the following command from a shell:
This command starts a polling loop that continuously checks for logs from activations.
- Switch to another window and invoke an action:
- Observe the activation log in the polling window:
Similarly, whenever you run the poll utility, you see in real time the logs for any actions running on your behalf in OpenWhisk.
Metadata that describes existing actions can be retrieved via the
wsk action get command.
An action can be invoked through the REST interface via an HTTPS request. To get an action URL, execute the following command:
A URL with the following format will be returned for standard actions:
Authentication is required when invoking an action via an HTTPS request using this resource path. For more information regarding action invocations using the REST interface.
Another way of invoking an action which does not require authentication is via web actions.
Any action may be exposed as a web action, using the
--web true command line option at action
creation time (or later when updating the action).
The resource URL for a web action is different:
You can use
curl or wget to invoke the action.
Code associated with an existing action may be retrieved and saved locally. Saving can be performed on all actions except sequences and docker actions.
- Save action code to a filename that corresponds with an existing action name in the current working directory. A file extension that corresponds to the action kind is used, or an extension of
.zipwill be used for action code that is a zip file.
- You may provide your own file name and extension as well using the
You can list all the actions that you have created using
wsk action list:
Here, we see actions listed in order from most to least recently updated. For easier browsing, you can use the flag
-n to sort the list alphabetically:
Notice that the list is now sorted alphabetically by namespace, then package name if any, and finally action name, with the default package (no specified package) listed at the top.
Note: The printed list is sorted alphabetically after it is received from the platform. Other list flags such as
--skip will be applied to the block of actions before they are received for sorting. To list actions in order by creation time, use the flag
As you write more actions, this list gets longer and it can be helpful to group related actions into packages. To filter your list of actions to just those within a specific package, you can use:
You can clean up by deleting actions that you do not want to use.
- Run the following command to delete an action:
- Verify that the action no longer appears in the list of actions.
The action environment contains several properties that are specific to the running action. These allow the action to programmatically work with OpenWhisk assets via the REST API, or set an internal alarm when the action is about to use up its allotted time budget. The properties are accessible via the system environment for all supported runtimes: Node.js, Python, Swift, Java and Docker actions when using the OpenWhisk Docker skeleton.
__OW_API_HOSTthe API host for the OpenWhisk deployment running this action.
__OW_API_KEYthe API key for the subject invoking the action, this key may be a restricted API key. This property is absent unless explicitly requested.
__OW_NAMESPACEthe namespace for the activation (this may not be the same as the namespace for the action).
__OW_ACTION_NAMEthe fully qualified name of the running action.
__OW_ACTION_VERSIONthe internal version number of the running action.
__OW_ACTIVATION_IDthe activation id for this running action instance.
__OW_DEADLINEthe approximate time when this action will have consumed its entire duration quota (measured in epoch milliseconds).
Large portions of this page is copied from the Apache OpenWhisk documentation on April 23rd 2021 - where there have been customisations to match Hypi's deployment this has been noted. Apache OpenWhisk and the Apache name are the property of the Apache Foundation and licensed under the Apache V2 license .