Today’s release adds Resource Jobs to the Losant platform - a major new feature that makes the development and ongoing management of IoT solutions much easier for a wide breadth of our users. Separately, today’s release also introduces a usability improvement to Losant Dashboards.
What Are Resource Jobs?
Resource Jobs allow for executing long-running, asynchronous tasks against Losant application resources, all backed by our drag-and-drop workflow engine.
A Resource Job starts with a collection of Devices or Data Table Rows defined by a query. For each item in the collection, Losant will kick off a workflow execution, and each run can be acknowledged as a success or a failure depending on what actions are taken and what output is received. At the end of the Resource Job execution, users are provided a CSV detailing how each resource in the collection fared.
Most importantly, an iteration’s success or failure does not need to be determined within that initial workflow execution. Rather, that run can spawn other processes within Losant, on third-party servers, or on device hardware, and when those processes are complete, they can send a request back to Losant to close out the iteration. It is this asynchronous acknowledgement that really sets Resource Jobs apart compared to other solutions that can be built atop the Losant platform.
To demonstrate this new feature and to lay down some best practices, we've developed a guide around using Resource Jobs to poll third-party APIs for state data. If you will be utilizing Resource Jobs in your IoT applications, we recommend starting out with this walkthrough of the feature.
Resource Job Use Cases
There were several cases where users were trying to fit too much work into a single workflow execution - or were building elaborate workarounds to get around those limitations - that Resource Jobs now easily enable…
Over-the-Air (OTA) Firmware Updates
A typical firmware update initiated from the cloud looks like the following:
- A command is sent down to all devices requiring the update. The command payload includes any information necessary to execute the update - such as a signed URL from which the devices can request the new firmware.
- Each device is responsible for downloading the update, applying the changes, and rebooting.
- Each device then reports back to the cloud platform whether the update was successful.
Resource Jobs make this process much easier to manage cloud-side. Requests can be sent individually to devices if each requires unique configuration, and any devices that are disconnected from the MQTT broker (and thus could not receive the initial command) can be logged as failing to receive the update and tried again at a later time. And because of the asynchronous nature of acknowledging Resource Job iterations, devices that do receive the command can apply the updates and acknowledge their success or failure when they have completed their tasks.
Polling Third-Party APIs
Some applications rely on a third-party service as the source of truth for their device telemetry data, and that data can only be retrieved by initiating a request from Losant to the service. In the proof-of-concept phase, where only a few devices exist in the application, a Loop Node iterating over the collection of devices and requesting data for each one (usually through an HTTP Node) works well.
But even the snappiest APIs can take several hundred milliseconds to resolve each request, so it doesn’t take too many iterations before this approach will hit a workflow execution’s 60-second timeout. On top of that, most APIs have rate limits in place to prevent any one client from abusing and overwhelming their service, so it may be necessary to throttle requests to avoid hitting those limits.
Resource Jobs solve both of these problems. Each device gets a full 60-second workflow execution to make the web request, process the data as necessary, and then save it as device state. And thanks to delay options exposed in Resource Jobs, those iterations can be slowed down to fit within the third-party service’s rate limits.
Dynamic Bulk Updates
Occasionally, every device in an application may need some sort of configuration change, such as a new tag. If the values vary per device, then these changes cannot be accomplished with a bulk update request, which requires the same update be applied to every device matching the query.
A Resource Job execution easily solves this use case. A CSV containing rows for each device and its new configuration values can be loaded into the application as a Data Table; then, those updates can be applied per iteration using a Device: Update Node.
Looking Forward
Resource Jobs are a major expansion of our platform footprint, and we recommend reading more about the feature in our product documentation. We look forward to hearing from our users how they will be utilizing this new feature, and of course we always welcome your suggestions for improvements.
Other Updates
As always, this release comes with a number of smaller feature improvements, including:
- We’ve tweaked the layout of our in-platform dashboards to place context variables, global duration and resolution, and past dashboard states in a toolbar at the top of the layout - settings that were previously accessible only from a dropdown menu. The toolbar makes it easier to change these values while also providing details about what data is currently being displayed in the dashboard.
- The Redis Node now exposes a handful of new commands, and to support those, we now allow for passing query arguments as a payload path. Many commands (such as MGET) take an array of arguments and now users can pass a full array into the node, whereas each needed to be individually defined before - something that was impossible to do if the array was of an unknown length.
- We’ve added several new Handlebars format helpers, several of which came directly from user requests. We’ve also tweaked a couple existing helpers to add some new functionality - for example, expanding the native {{#each}} helper to allow for passing a number as the context to iterate a specific number of times. You can read more about the new helpers in our documentation.
Template Library Updates
We’re continuing to grow our Template Library with new entries designed to demonstrate Losant best practices, shorten time to market, and improve end user experience.
We’ve added a React.js Experience Bootstrap template that demonstrates how to use the popular React.js JavaScript framework as the user interface for an application experience. The template itself demonstrates:
- How to serve static resources for the interface through Application Files.
- How to build a RESTful JSON API using Experience Endpoints and Experience Workflows to handle HTTP requests initiated by the interface.
We’ve also developed a simple React.js application that works in conjunction with the template to handle user authentication, storing of the token in a cookie to authorize future requests, and routing users through the interface. While not required, we recommend starting your project from this example repo as it demonstrates some advanced techniques for creating a robust and user-friendly application.
What’s Next?
With every new release, we listen to your feedback. By combining your suggestions with our roadmap, we can continue to improve the platform while maintaining its ease of use. Let us know what you think in the Losant Forums.