Page: Polling for New Actions
Page: Executing Code Before and After Actions
Page: Action Statuses
Page: Creating Custom Client Actions
Page: Forced Logout
Page: Client Action REST API
Page: Authorizing Users
Page: Creating a Client Action Request
Page: Using Client Actions
Page: Registering Devices for Client Actions
Page: Refresh App Properties
Action statuses provide information about where in the workflow an action might be for a particular action and device. For example, the action status indicates whether an action completed successfully, or if an error occurred during execution. In addition, the action status can indicate if an action timed out or was cancelled by an administrator, or if it is still in the database waiting for a device to receive it.
Client action status fall into two categories:
- Active – Actions that have not yet been received by the client, or have been received but not yet executed on the client.
- Complete – Actions that are no longer active. These can include actions that successfully executed on the client, or failed to execute on the client for some reason.
Each of these categories includes several statuses that provide a more fine-grained understanding of the action.
The following table describes the client action statuses:
The action was cancelled by the Akula administrator before it was sent to the client.
An Akula administrator can cancel an action by using the Management Console, REST API, Command-line Management Utility, or custom module. For more information, see Managing Client Actions.
The action executed successfully.
The client sets the action status to COMPLETED. For pre-built actions, you cannot set this action because you cannot override the execute listener. For custom actions, you can only set this status in the execute listener. You can optionally send a message to the server with the status update.
The action was not sent to the device within the specified time.
The Akula administrator sets the TTL (time-to-live) when they create a new action request. The Action Service periodically checks for actions whose TTL is longer than the time they have been in the CREATED state. If an action request has been in the CREATED state for longer than the TTL value, then the Action Service changes its status to EXPIRED.
Only the server can set an action's status to EXPIRED.
An Akula administrator can expire an action by using the Management Console, REST API, Command-line Management Utility, or custom module. For more information, see Managing Client Actions.
If the Akula administrator sets a new action's TTL to 0, then the status of the action is immediately set to EXPIRED.
The action failed to execute on the device because an error was thrown during action execution.
The client sets the action's status to FAILED. For pre-built actions, the client SDK includes the error message, if any, as part of the status update. In a custom action, you can optionally send a message to the server with the status update.
|IGNORED||Client (in custom actions only)|
The client ignored the action request or a custom action did not contain an execute handler.
Pre-built actions never set an action's status to IGNORED. This status is provided is set by the client SDK when a custom action is called, but there is no execute listener.
In a custom action, you can optionally send a message to the server with the status update.
|Server||The action has been created. The server sets a new action request's status to CREATED when it receives and stores a new action in the Akula database. The action remains in this state until it is cancelled, expired, or received.|
The action was sent to the client app, either as a result of polling or a push notification. When the action is in the RECEIVED state, it has not yet been executed.
When the server sends an action command to a client, either via polling or a push notification, it sets the status to RECEIVED.
Akula administrators can use the action status to determine how many clients have executed an action command. For example, they can get a list of all devices, with a count of how many device's actions are in the COMPLETED state (action executed successfully), FAILED (action threw an error during execution), or CREATED (not yet started). For more information, see Managing Client Actions.
The following image shows when statuses are set:
You cannot set the status of a pre-built action such as the Remote Data Wipe action. The client SDK sets the status and communicates it to the Akula Action Service for you.
For custom actions, you can set the status of an action only in the action's execute listener on the client. You can set the status to only COMPLETED, FAILED, or IGNORED. All other statuses are set by the Action Service on the server.