The execution of chains happens by a trigger (npm module) that could be developed and coupled to Runnerty.
In the config.json file of the project we are going to write the configuration of the different triggers that are going to be used in the chain.
This is an example of the configuration of two triggers:
@runnerty/triggers-file-watcher. Each trigger has it's owns properties, some of them are mandatory, you can have a look at each triggers documentation to know how to use them.
The destination of an trigger is to use it in our chains. We could say that using a trigger has two parts:
The configuration properties are set in the config.json. They are the identifiers fields of the trigger. For example, this is the configuration properties for the @runnerty/trigger-schedule:
id is the name given for the trigger configuration. Note that we could have all the differents configuratios that we want for the same executor. The
type is the name of the trigger module.
In the processes are set the variable properties (params) for the executor. This is an example of the usage of the
@runnerty/trigger-schedule in a process
Runnerty matchs the
id property from the plan with the config.json one to identify the executor to run. Properties like
end_date are the variable properties that may change in every chain.
It is important to know that it is possible to overwrite some configuration properties from the
triggers properties of the chain. For example: if we are using the @runnerty/trigger-schedule we may want to change the database that the trigger is going to connect.
This is the configuration of the trigger. We are planing the execution of chain when file
myfile.txt is added to the folder
We can overwrite this information from the
triggers properties of the chain:
plan.json (object chains)
Overwrite file_name by
There is also the possibility to trigger a chain using a calendars. The calendars path can be indicated in the config.json file:
Calendars can be used for both, enabling or disabling execution dates through the enable and disable properties, so it can be specified, for example, to only execute a chain on laboral days, excluding weekends, like in the sample below:
Servers allow us to forget about the endpoints implementation in the triggers development. Runnerty will pull up the web servers indicted in the config file and will also manage the routing. It will make available the trigger's property
on_request. This will receive the requests to it's endpoint. Additionally, It allows us to customize the response either sending the status code and the response object.
You can use two different authentication strategies, basic auth or API Key.
Basic Auth (standard):
You can send your API-Key in the endpoint call using the
api_key query parameter or the
Both the values that arrive by
query and those that arrive in
body will be available in the chain (via customValues).
So if for example we make a "post" like this:
We can make use of the values through the
get values function: