In this fourth tutorial on flows™, we will again create a contract between a transport company and a producer of fragile goods for the transportation of fragile goods.

This time the cargo will include an accelerometer which will keep track of its readings as well as its delivery status.

This time, we will create a recurring flow to periodically (according to a schedule defined by us) poll the sensor and react according to its output.

The contract will, as before, deduct an agreed-upon amount for every reading that exceeds an agreed-upon threshold, but ignore readings when the cargo is still in transit.

1.Contract, Signatory & Clause

Let's start by creating a contract, adding a signatory (other than yourself), and adding the fragile-goods clause to the contract:

  • Contracts -> New Contract
  • Edit Title -> Enter Contract Title
  • Add Signatory
  • Add Clause -> fragile-goods

2. Create Recurring flow

Next, we'll create a new type of flow that. This flow will invoke itself on a recurring schedule, defined by us. Every time it invokes itself, it will poll an accelerometer that not only returns an array of readings, but also the status value that the contract expects to be triggered with.

To simulate the accelerometer, we will poll this test service, which generates three random sample readings and a random status:

We will use an HTTP step to make a GET request to the above url, and then use the following JSONata expression in a JSONata step to transform it into a clause payload:

    "$class": "io.clause.demo.fragileGoods.DeliveryUpdate",
    "startTime": $now(),
    "finishTime": $now(),
    "status": step[1].output.status,
    "accelerometerReadings": step[1].output.accelerometerReadings
  • Edit Clause
  • Add additional trigger flow
  • Flow Name
  • Trigger Type -> Recurring
  • Frequency -> Minutes
  • Leave default amount (10 minutes)
  • Add Step -> HTTP
  • HTTP input attributes
  • Add Step -> JSONata
  • JSONata Expression
  • Save

NB: Note that, unlike with HTTP trigger flows, we can't easily test a recurring flow without getting the contract into the running state (which is when the flow schedule will commence). To help with this limitation, it might be beneficial to first create a recurring flow as an HTTP trigger flow, and once it's been tested manually, changing it to a recurring flow.

3. Create Action Flow

Before we get the contract signed and active, let's first add an action flow to notify us by email whenever the contract gets triggered, and notify us how much was paid out. To this effect, we will configured the email body to reference the paid amount and currency code from the emitted obligation as such:

{{step[0].output.amount.doubleValue}} {{step[0].output.amount.currencyCode}} has been paid out
  • Edit Clause
  • Add additional action flow
  • Flow Name
  • Add Step -> Email
  • Email step input attributes
  • Save

4. Request Signatures

Click on Request Signatures, and follow the dialog to sign the contract and request a signature fro the second signatory. Once the contract has been signed by both parties, its status should be running.

5. Verify triggers

Within a minute or so of the contract transitioning to running status, the flow should be triggered for the first time, and thereafter every 10 minutes.
You can verify that this is happening by viewing and refreshing the contract timeline:

You can also view the exact trigger that was being generated by the recurring flow by clicking on details in the contract timeline event. The contract should only emit an obligation whenever the status in this trigger payload is set to ARRIVED:

When that is the case, an email will be sent to the email address defined in the action flow:

6. Conclusion

In this tutorial we have seen how recurring flows can be used to poll some value independently of any other input. This allows a smart clause to become the active party when all you have to work with are passive integrations.