Skip to content
Sirveo Documentation

0.2.5 ✔️

Summary

This release implements a key capability from Sirveo’s roadmap; list and array processing. Array data could easily be processed and manipulated within JS Code nodes. However, flows had no way of doing something like “get a list of URLs, and make an HTTP request to every target URL”. A new node, Subflow Loop, allows flows to process array elements with other flows.

In order to implement the new array processing and iteration capabilities, some long-standing constraints on the flow engine have been relaxed. Previously:

  • Flows could only accept JSON objects as input data
  • Most nodes only accepted JSON objects, or arrays of objects
  • Most nodes only allowed JSON objects or arrays of objects as outputs

As of 0.2.5, these constraints have been removed, except for a limited number of cases where nodes (JWT Create, JWT parse, and the event node) specifically requires JSON object shapes as input data. This change significantly increases the versatility of flows. It also simplifies many data handling scenarios, as it is no longer necessary to wrap inputs and outputs as JSON objects.

Lastly, care has been taken to avoid breaking changes. The new features have been implemented on an opt-in basis. As such, existing flow and node behaviour can be expected to work as per 0.2.4. Edge cases which may require testing and verification are noted below.

Potential breaking changes

If any logic in your existing flows rely on the contents of specific node error messages, please note that some error messages have changed.

For example, some nodes that previously expected a JSON object as input data would provide an output with an error message like this in 0.2.4:

{ "error": "input data must be a JSON object" }

Where this constraint has been removed, error messages have changed:

{ "error": "input data contains invalid JSON: <error detail>" }

Fixes

  • 🐞 ui: fix that running flows via the flow editor could display malformed error messages

Features

  • ⚡🔥 flows now accept any valid JSON or JSON-serializable data as input data. Previously, only JSON objects were allowed as flow inputs

  • ⚡💠 a new Subflow Loop node is available, which allows flows to process (loop over) array elements using another flow. Supports:

    • Graceful handling of both array and non-array input data
    • Automatic conversion of non-array input to a single-element array
    • Limiting iteration to the first N array items
    • Error suppression
    • Deep tracing (like the subflow node)
    • Static JSON input data

Enhancements

Nodes

  • 🔼💠 http client node: correct error message when $out contains invalid data type after post-processing

  • 🔼💠 http client node: JS code that post-processes response data may now produce any valid JSON as node output, instead of only a JSON object. Doing this loses the ability to override or suppress request errors, by changing the value of the ok property which is otherwise present in the default node output.

  • 🔼💠 JS code node: any valid JSON data may now be used as the value of the $out store. Previously, using values which were not JSON objects resulted in a node error.

  • 🔼💠 schedule node: the “Input JSON” option may now contain any valid JSON data. Previously, using values which were not JSON objects resulted in a node error.

  • 🔼💠 subflow node: any valid JSON data is now allowed as input to the target flow, either from node input, or from the “Input JSON” setting. Previously, input data which were not JSON objects resulted in a node error.

UI

  • 🔼 ui: when testing flows via the flow editor, any valid JSON data can be provided as flow input data. Previously, only JSON objects were allowed.

Internal

  • ⚙️ flow engine: flows now accepts any valid JSON as input data, instead of only JSON objects

  • ⚙️ flow engine: variable expressions like ${in:key-name} or ${in:key-name||default} will yield an empty string value (or default) when the related node input is not a JSON object