We need a better API to trigger an on-demand process when a request is made from an API. Such on-demand process generates observations on-demand rather than pre-computing them and pushing them to the bus like real-time system drivers do (note that the output produced by an on-demand could still be optionally pushed to the event bus).
We could use the datastore API directly but a simpler API / interface for this would be better. Internally, an on-demand process can still be adapted to the datastore API so that there is no change required in APIs and services implementations. In this case, the on-demand process would this be registered with the federated datastore just like any other database.
The datastore API adapter would solve the need for any process that takes standard observation filtering parameters as input (i.e. phenomenon time, result time, FOI, location, datastream, etc.). Additional process parameters could be specified via a command with attached results (see #205).
We need a better API to trigger an on-demand process when a request is made from an API. Such on-demand process generates observations on-demand rather than pre-computing them and pushing them to the bus like real-time system drivers do (note that the output produced by an on-demand could still be optionally pushed to the event bus).
We could use the datastore API directly but a simpler API / interface for this would be better. Internally, an on-demand process can still be adapted to the datastore API so that there is no change required in APIs and services implementations. In this case, the on-demand process would this be registered with the federated datastore just like any other database.
The datastore API adapter would solve the need for any process that takes standard observation filtering parameters as input (i.e. phenomenon time, result time, FOI, location, datastream, etc.). Additional process parameters could be specified via a command with attached results (see #205).