Setting up Chainlink on Ethereum, Part 2.: Running your Jobs

For Part 1. click here. We are already at the 4th step.

4. Creating Jobs on your Chainlink node

The only step left is to populate your node with Jobs so they can actually serve requests coming from your smart contracts. Read about what Jobs, Adapters and Initiators are here. These are your building blocks.

TL;DR version:

• Job: A sequence of actions processing a request.
• Adapter: A step in processing a request.
• Initiator: Defines how a Job run is triggered. The “first step”.

An ancient Initiator and Adapters, 100 BC, colorized

You have to specify Jobs in a JSON format, and you can add them in the Jobs section of your node’s GUI.

I want to make an oracle for the EWT/EUR price pair listed on Liquid, so I am using the following Job specification:

{
    "initiators":[
        {
            "type":"runlog",
            "params":{
               "address":"0x1a63f77dD7Dc0c28220e10D6DBbd7d1e5104fb05"
            }
        }
    ],
    "tasks":[
        {
            "type":"httpget",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"jsonparse",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"multiply",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"ethuint256",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"ethtx",
            "confirmations":null,
            "params":{
            }
        }
    ],
    "startAt":null,
    "endAt":null
}

Let’s go through what these mean:

Initiator is a RunLog, which means the node will trigger a job run to an OracleRequest event emitted by the Oracle contract at 0x1a63f77dD7Dc0c28220e10D6DBbd7d1e5104fb05, which I deployed earlier.

Then our request will get processed by the Adapters, in the order they are defined sequentially, as a pipeline:

1. We create HTTP GET request to a URL that will be given from the client Smart Contract
2. We parse the result to JSON and get the value defined in a path given from the client Contract as a request parameter
3. We multiply it by a certain amount which is also given from the client Contract as a request parameter
4. Transform it to uint256 type
5. Aaand fire the result as a transaction

As you see this job description is quite generic, which means the adapters can get parametrized with the request initiated from the smart contract, e.g.: which URL should be fetched, what value to multiply the result with, what are the callback transaction params, etc.

There are so many other cool options that you can try. e.g.: CronJobs as Initiators that regularly feed data to your smart contracts or Compare Adaptors for true/false results.

Once you create the job, your job gets an ID. You can create many jobs running on one node, and list it in the Jobs section of the GUI.

List of Jobs on a Chainlink node

5. Use your Chainlinked contract

Now with all contracts in place it is time to try things out. Let’s call the “requestEwtPrice” function. It takes the Oracle address and the Job ID as params.

function requestEwtPrice(address _oracle, string _jobId)
    public
    onlyOwner
{
    Chainlink.Request memory req = buildChainlinkRequest(
        stringToBytes32(_jobId),
        this,
        this.fulfillEwtPrice.selector
    );
    req.add("get", "https://api.liquid.com/products/560");
    req.add("path", "last_traded_price");
    req.addInt("times", 10000);
    sendChainlinkRequestTo(_oracle, req, ORACLE_PAYMENT);
}

You can see in the source code what is the URL being called, what JSON field we are accessing, and what value are we multiplying the price with. You can just check the URL in the browser to see how it looks like: https://api.liquid.com/products/560. We access the last traded EWT/EUR price pair through Liquid’s public API.

You can also see that “fulfillEwtPrice” is the function that gets fired once the results are in, which just sets the “currentEwtPrice” state variable in the client contract.

If all went well, you have to see the “currentEwtPrice” to be set to a non-zero value in Remix. If you check you node, you can see that a successful Job Run was triggered. You can access its details to see the transformations that were applied at each step.

This is what you have to see on a successful Job run

That’s it with the basics! Now we can move to the cool stuff everyone is waiting for: how aggregation of results look like in smart contracts in Part 3.

Materials

You can find all the materials on my GitHub for the scripts and Chainlink contracts.

Navigation

← Part 1.: Setting up a single node
Part 3.: Aggregation of results and synthesis →

Need help with your blockchain based project? Shoot me a mail: adam.zsolt.nagy@gmail.com
Did you learn something useful? Made your job easier? Tips are welcome too: Ethereum: 0x74dd76E24B2CFB43C1b1a4498295d553D0843746