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.
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.
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…
A typical firmware update initiated from the cloud looks like the following:
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.
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.
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.
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.
As always, this release comes with a number of smaller feature improvements, including:
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:
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.
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.