Today’s platform update makes workflow debug output more consumable, adds a new node to assist with application logging, and provides several other improvements to our platform.
Today’s release introduces debug message verbosity settings, which allow for the categorization and quick filtering of debug output by those types. Each Debug Node’s message can fire as one of four standard levels (Verbose, Info, Warning, Error), and users may reduce the messages hitting the debug log to one or more of those levels.
The sheer number of messages that appear in a high-volume production workflow’s debug panel can make it impossible to identify, diagnose, and resolve unintended behavior - especially when that volume triggers debug throttle limit messages. We’ve seen users temporarily strip out Debug Nodes one at a time to get around this problem, but that is tedious as it requires re-attaching the nodes that led into and out of the deleted node. Workflow debug verbosity is a quick and easy solution to this problem.
Reducing debug log output is a standard tool used by all software developers. It translates well to crafting Losant workflows: it allows our users to hone in on the conditions that matter to them at any stage of the development process, just as other professional coders do.
Additionally, there are a couple of other platform behavior changes that coincide with this update:
console methods; for example, console.warn() will appear as a warning-level message in the debug panel (but only if Warning-level messages are enabled).As we undertook this change to reduce the noise in the workflow editor, we took an added step to also move the Debug Node to its own category and node color. Previously, Debug Nodes on the stage did not stand out from other output nodes in a workflow; they just blended in with Endpoint: Reply Nodes, Device: State Nodes, and other critical elements. Applying the Blur Test to a workflow before and after this change significantly improves the at-a-glance interpretation of the workflow and its intended behavior, as you can now look past all the Debug Nodes and focus on the actual functionality you are delivering for your IoT solution.
Next, this release includes a new way of tracking application activity with the addition of the Loggly: Write Workflow Node.
Loggly is a popular application logging service acquired by SolarWinds in 2018. The company specializes in ingesting massive volumes of structured or unstructured data - usually representing inbound application requests, program errors, and outbound messages - and presenting that data to software developers and system administrators in an organized, aggregated way. That makes it a great fit for IoT solutions built on Losant, given the amount of traffic generated by MQTT messages, third-party service integrations, and end-user HTTP requests.
One of the first Custom Nodes we developed - and eventually added to our Template Library - was a wrapper that sent messages to Loggly. The node has always been one of our most imported library templates, and we decided it was time to convert it to a first-class Losant workflow node. Existing Loggly custom nodes will continue to function, though we recommend moving to the new node for several reasons:
Usage of the node requires a Loggly account; the service offers 200MB per day of free data ingestion, which is more than enough for most mid-sized applications built on Losant. That, combined with how easy it is to integrate this node into your existing workflows (since logging activity should be treated as a parallel, unblocking process as depicted in the screenshot), makes this a simple and worthwhile addition to your existing IoT solutions.
Today’s release includes one more improvement to our Resource Jobs feature: the ability to automatically retry an iteration in the event of failures and/or timeouts.
As we’ve been rolling out Resource Jobs to our internal applications and speaking with users adopting the feature, it’s apparent that many use cases are subject to occasional random failures when working with third-party APIs. This can lead to necessary processes that are only mostly completed through the use of a Resource Job, which then requires manual intervention to correct the failed iterations or living with the result until the job runs again.
Now, a Resource Job can be configured to retry an iteration that times out or is marked as a failure, with the option of adding a delay before kicking off the retry. In our usage, this has led to a much higher per-item success rate and more efficient processes, as most of these issues get resolved by simply kicking off the third-party service request a second time.
As always, this release comes with a number of smaller feature improvements, including:
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.