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.