External Initiators
#chainlinknode #externalinitiators #nodeoperator
Last updated
#chainlinknode #externalinitiators #nodeoperator
Last updated
To better understand why we need External Initiators and what role they play, it's worth getting a better understanding of the Job Spec. The Job Spec conceptually consists of two parts:
Initiator - When the Job is to be executed
Task - How and in which order the Job is to be executed
Under the hood, Chainlink Node has a built-in set of Initiators and Tasks. If the built-in tools are not suitable for your task, the External Initiators and External Adapters come to the rescue.
The External Initiator has a bi-directional action. This means that we can both send data to the client and receive data from the data sources.
For connected External Initiators, the Chainlink Node will notify them about the events of creating a new Job or deleting an existing Job whose whitelist contains a specific External Initiator.
The External Initiator is a service (e.g. written in go, nodejs, etc.) that must have a connection to the Postgres database (different from the database used by the Chainlink Node).
In order to communicate with the Job deployed on the Chainlink Node, the External Initiator must have cryptographic pairs:
External Initiator Outgoing Access Key / External Initiator Outgoing Secret - To interact External Initiator → Chainlink Node
External Initiator Incoming Access Key/External Initiator Incoming Secret - For interaction Chainlink Node → External Initiator
These pairs are automatically generated on the Chainlink Node side when you add the External Initiator. You will also need to add certain env variables to the External Initiator service after that.
What you should pay attention to:
The .env file with variables like EI_* must be plugged into the service that acts as the External Initiator.
Important! The database specified in the variable EI_DATABASEURL must be different from the Chainlink Node database.
The basic process is described in the documentation:
