I’m using a workflow to determine whether my REST-based devices are still connected to Losant, based on the last time they sent a “heartbeat” attribute report to Losant. If the heartbeat was too long ago, I consider them disconnected and create an event to report the problem.
Because a disconnected device can’t report itself disconnected (over REST, at least), I trigger my watchdog workflow with a timer. When the timer fires, I examine each device matching my filter criteria (right now, just a tag filter on the device recipe). Currently, I’m able to do this as follows: when the timer expires, the workflow calls an AWS Lambda function that fetches a list of the devices then POSTs the list to a webhook that triggers another part of the same workflow.
The Lambda function is basically a means of transferring the result of
GET /devices on the Losant API to the workflow. The piece that would allow me to eliminate the Lambda function is a workflow node that emits a list of devices.
The workflow ID is
578d165826434a01005416b0 in application
577d2bdc7b3f830100d937ae, for a more concrete example.
Of course, complementing this request would be a workflow node that performs a for-each on a specified array in the payload. For each element in the array, it could place that current element at a specified payload path then emit the current payload to its output. It would thus emit one copy of the payload for each element in the array, with each emitted payload containing a reference to the current array element. Because workflows already have conditionals and a way to “jump” by connecting the graph in a loop, the for-each node wouldn’t offer anything that is not already possible, but it would save some space and reduce the number of moving parts in the workflow.
For the most part, it seems that the workflows are geared towards dealing with one payload at a time, end-to-end, so perhaps my need for a loop suggests that I’m drifting off base.