Embedded Workflows

Embedded Workflows execute within WEGnology’s Embedded Edge Agent, which is typically integrated into hardware with limited compute capabilities. This hardware is represented in a WEGnology application as Embedded Devices. The workflows are versioned independently and are deployed as embedded deployment bundles.

Initial Setup

While Embedded Workflows do provide an easy-to use-interface for updating hardware behavior, it does require some level of developer expertise to initially set up the Embedded Edge Agent.

• The agent must be integrated with your device’s code, and the methods exposed by the EEA must be invoked appropriately.
• Unlike the Gateway Edge Agent, the EEA does not expose drivers for integrations with your hardware’s peripherals.
• Also, the EEA does not come with built-in integration to WEGnology’s MQTT cloud broker. It is up to those integrating the EEA to build an MQTT client into their device’s native code, to authenticate and connect to the broker, and to trigger the EEA’s various methods on receipt of messages from the cloud broker on certain topics.

More information on how to set up the Embedded Edge Agent is available in the Embedded Edge Agent API.

Advantages

The main benefit of Embedded Workflows is the ability to deploy behavior changes to embedded hardware without requiring updates to the device’s native code, which usually requires physical access to the hardware and re-compiling and flashing code.

Unlike the Gateway Edge Agent, Embedded Workflows do not require an operating system, which gives them a clear advantage over Edge Workflows when it comes to use within resource-constrained environments.

Limitations

Because of their intended use case (executing on hardware with low memory limits and processing power), there are a number of limitations that apply to Embedded Workflows that do not exist in other workflow types:

• Native Handlebars helpers and format helpers are not valid within Embedded Workflows. Any input that takes a template can only accept a direct reference to a value on the payload.
• Parallel execution paths — in other words, two connections to two separate nodes out of a previous node’s individual output — are not allowed.
• Instances of triggers and branching nodes (i.e. Conditional Nodes) must connect to one other node. The workflow cannot be saved or deployed otherwise.
• Payload paths are limited to a maximum depth of 16 levels and a character limit of 100 per level part (though those limits are unlikely to be reached in practical scenarios). You will not be able to save your workflow if these limits are breached.

Configuration

There are some key differences between Embedded Workflows and other flow types, particularly around the viewing of on-device workflow behavior.

Workflow Storage

Similar to Edge Workflows, Embedded Workflows may make use of the Storage: Get Value and Storage: Set Value Nodes. Values are stored on the hardware itself, though it is up to the user implementing the Embedded Edge Agent to configure the hardware’s storage. The amount of data that can be stored is likely to be much lower than for Edge Workflows given the hardware constraints.

Unlike for Application Workflows and Experience Workflows, there is no way to tell what the current values stored on the Embedded Device are. Therefore, the workflow storage tab offers no way to view or set storage values directly.

Debugging

Debugging Embedded Workflows is very similar to debugging Edge Workflows, in that you may utilize the Live Look feature to view the debug output for a given workflow, running on a given device, in real time.

Unlike for other workflow classes, this debug output does not include per-node workflow timing.

Workflow Metrics

Workflow execution and error metrics are not available for Embedded Workflows. This is due to the need to limit the footprint, memory usage, and bandwidth consumed by low-powered devices.

Payload

The fields on a triggering payload for an Embedded Workflow are as follows:

• data contains variable information related to what caused the workflow to execute. The shape of this property varies depending on the trigger type. For example, Device: Command Triggers contain an object with properties name, time, and payload at this property, while MQTT Triggers contain a string with the message received on the configured topic.
• deploymentId is the WEGnology ID of the deployment bundle.
• deviceId is the WEGnology ID of the Embedded Device.
• flowId is the WEGnology ID of the current workflow that is running.
• flowName is the name of the current workflow that is running.
• flowVersion is the version of the current workflow that is running.
• globals is an object of any workflow or application globals available within the workflow.
• isConnectedToWnology is a boolean representing if the device is currently connected to WEGnology.
• time is an unsigned 64-bit integer representing the system time in milliseconds (since Epoch or since boot). It is up to your native code to provide this value to the Embedded Edge Agent when invoking eea_loop.
• triggerId is, in most cases, a unique ID assigned to each trigger within a workflow.
• triggerType is the type of trigger that caused this workflow run. This will be specific to each trigger type.

Note that this list should not be considered exhaustive, as depending on the trigger being invoked, additional fields may be present.

Saving and Deploying

Much like Edge Workflows, Embedded Workflows are built within WEGnology’s web-based, drag-and-drop flow editor and are deployed to your hardware through the web interface. The act of building and saving changes is independent of publishing (deploying) those changes to your application’s Embedded Devices.

Saving Changes

The “Save” button will be enabled whenever there are changes to your “develop” workflow version. When there are no pending changes, the button will be disabled. The button is only present when viewing the “develop” version and if you have edit permissions for the workflow in question.

Deploying Versions

Any version of an Embedded Workflow can be deployed by clicking the “Deploy” button in the top right corner. This will display a configuration modal for which devices to deploy the selected workflow to. If you are viewing the “develop” version when the “Deploy” button is clicked, you will have to create a new version as part of the process.

More information on deploying Embedded Workflows is available within the edge compute documentation.

Exporting Deployment Bundles

Optionally, you may export the WASM bundle of all workflows scheduled for deployment to a given device and manually load that bundle into your hardware (that is, not through the WEGnology MQTT broker). Note that doing so means WEGnology will not be able to track the deployment’s status and manage it through the web interface.

Deleting Embedded Workflows

Embedded 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.

Deleting an Embedded Workflow - or a deployed version - will remove the workflow from all devices where it is deployed only once the device is connected to the platform. If the device is offline, it will continue to execute the workflow until it reconnects and receives the new WASM bundle without the deleted workflow.

Note: If you are managing your deployments manually using exported WASM bundles, the deleted workflow will not be removed from the device automatically. Rather, you will have to regenerate WASM bundles for all the devices that previously had the deleted workflow within it and reload them onto your hardware. However, if your hardware is connected to WEGnology’s MQTT broker and has been set up to receive Embedded Workflows, the new workflow bundle that does not contain the deleted workflow will deploy to the device the next time it has an internet connection.