Action Inputs
Inputs can be run as actions under some conditions. The first thing to note is that when run as actions they may refer to the input data using field expansions.
For instance, say there is a simple webservice running on port 3030 which is passed two numbers
and returns their sum as {"sum":<num>}
. We can call this webservice on our data like so:
name: adder
input:
text: '{"x":10,"y":20}'
actions:
- input:
http-poll:
address: http://127.0.0.1:3030
raw: true
query:
- a: ${x}
- b: ${y}
output:
write: console
# {"x":10,"y":20,"sum":30}
That is, action-input
takes an event, allows field expansions using that event,
and finally merges the result of the input with the event.
Here we say raw: true
, because the webservice returns JSON; if it returned a simple number,
then we would need raw: false
to quote the result and we would get {"x":10,"y":20,"_raw":"30"}
.
(You could have just said address: 'http://127.0.0.1:3030?a=${x}&b=${y}'
but query
makes it easier
to build more complex URIs)
These inputs may not be scheduled because they run when data
arrives - they are implicitly scheduled by the event stream. For instance, interval: 2m
on the above
http-poll
is an error.
Inputs that are not schedulable cannot be used, because they are externally scheduled by data arriving,
such as tcp
,udp
and http-server
, or subscribing to data streams with amqp
or redis
.
Although you can use input-exec
as an action, it is easier to use action-exec.