I notice that in the API and UI (just disabled currently) is the ability for a single Automation to have multiple Functions defined. I was wondering looking at the future if it would be possible to have state that could be passed between these functions?
A short term idea I had was to just use a dedicated Model as the state but then once the same Automation gets fired twice in quick succession it might not work as expected.
Additionally, in the future do you see these functions running Sequentially or Parallel?
If each function is effectively a CLI application, the AutomationRun is the equivalent of the global environment. This could act as a state, but like your model as state idea - if functions were possible in parallel, this could get messy
I’d try to think of the environment like a Grasshopper or FME graph as a starting point… i.e. no state, only passed data objects.
I’d put the question back to you - other than the possibility of the resultsObject from each function being a form of state in addition to the model data, what other state do you think you’d want to exchange?
Just trying to think how we would approach building out workflows such that we can create reusable functions. For example saying making a building (terrible example sorry, I am a developer not an ideas man ), then we could have functions for defining a footprint (different options like say fetch from MapBox, create from width+length, create from other sources), that footprint then could feed into other functions like a flooring generator, a grid generator, footprint+grid feed into a column generator.
And then the reusability comes when you have situations where you need a grid and column, but not flooring (again I am sorry for the terrible examples).
Just my own opinion here, Automations could run in Parallel, Functions run in Sequence? So if you want things in Parallel then you define them as separate Automations.
The resultsObject is still the best bet, albeit potentially expanded.
Designing the automation first and then functions as subcomponents of it is easier to conceive of and architect than loosely coupled functions (potentially from very different authors) being composed into an automation
Hi @sanchez - we kept to a minimal implementation for the beta rollout of Automate, so limited it to one function per automation.
As you noticed we have allowed some flexibility in the API to allow for future implementation of multiple functions per automation. We considered the possibility of supporting a directed acyclic graph of functions - so functions would could run both sequentially or parallel, depending on what the automation composer wished.
One of the larger remaining question about how to implement this feature is around the transfer of potentially large volumes of information between each function in the graph. I’m looking forward to hearing everyone’s thoughts on this.
), then we could have functions for defining a footprint (different options like say fetch from MapBox, create from width+length, create from other sources), that footprint then could feed into other functions like a flooring generator, a grid generator, footprint+grid feed into a column generator.