Cloud workflows execute within Losant's cloud platform. Generally they are more robust than edge workflows in regards to the available functionality, speed of execution and uptime.
There are a number of benefits that come with workflows of this type:
- They can be triggered by a wide variety of events, such as device connections, messages from third-party sources and more.
- You may edit application resources such as devices or anything else exposed in the Losant API Node.
- You can query device data and respond to experience endpoint requests in order to build a custom UI for your end users.
- Events emitted by one device can directly impact another without the devices speaking directly to each other.
The primary drawback of cloud workflows is the potential for network latency issues. For example, if you'd like to fire a workflow every time a device reports state, and firing that workflow is critical to the operation of your system, a slow internet connection (from the device reading state and sending it up to the cloud) could make or break your application.
Cloud workflows also do not have the ability to interact with any deployed device's operating system; they cannot execute scripts, write files or read inputs. They can, however, listen to a number of events emitted by the devices, such as connections, disconnections, inactivity and state reports, and in response they may send commands to or report state on behalf of your devices.
There are a handful of configuration options that are specific to cloud workflows ...
Cloud workflows can be enabled or disabled with a simple toggle. Disabling a workflow stops any triggers from firing in any of its versions. This can be done either from your application's list of cloud workflows or within the "Properties" tab of the cloud workflow editor.
Cloud workflows have the concept of a "default version", which is the version of the workflow to run in the absence of the version being specified in the trigger event. Some cloud triggers, such as the Endpoint Trigger, can target a specific version of your workflow. Conversely, other triggers, such as the Timer Trigger, will only ever fire on the default version.
Manual Storage Manipulation
In cloud workflows, the values in workflow storage may be directly edited, instead of having to go through the Storage: Get Value and Storage: Set Value Nodes. This is because these values are stored in the cloud platform and are universal across all versions of the workflow, whereas in edge workflows, these values are specific to each device where the workflow is deployed.
Saving and Deploying
Workflows are saved and deployed using the
Deploy Workflow button.
The button will be green whenever there are changes that can be deployed. It will be gray when there are no changes. Once a workflow has been saved and deployed, its changes will take effect immediately.
If you are viewing a workflow version, the button will not allow the deployment of any changes; instead, it will allow you to return to the Develop version.
Deleting Cloud Workflows
Cloud workflows can be deleted directly by clicking the "Delete Flow" button at the bottom of the workflow's Properties panel. They can also be deleted by clicking the "Delete" icon in your application's workflow list.
Cloud workflows can also be deleted indirectly by deleting resources that depend directly on the workflow engine. For example, when deleting an experience endpoint, you are presented with the option of also deleting any workflow triggered by a request to that endpoint. Take care when doing this, as this action will delete the entire workflow, and not just any series of nodes within the workflow that start from the endpoint trigger.
When a cloud workflow is deleted, it ceases execution immediately – unlike deleting an edge workflow, the deletion of which must be rolled out to any devices to which the flow was deployed before they cease to fire.