Is it possible to add scheduler as a feature for Daml Trigger

While developing a PoC we have the scenario: at the end of the day, there’s a need to calculate NAV by collecting market data (on ledger) and perform a calculation to update Holdings contract.

template Holdings
  with 
    ...
    fundManager: Party
    eodNav: Decimal
  where
   ...
   choice UpdateNav: ContractId Holdings
      with 
      controller fundManager 
      do 
          // collect market data and update eodNav
         ...

We are currently using a one day heartbeat similar to Daml Trigger heartbeat example - #6 by cocreature
but the shortcomings, as described in the above link, is we need to start our trigger at exactly the time when we hope our trigger to run at (if the trigger shutdown intra-day, we will also need to wait and restart at exactly that time)
I wonder if we can add a scheduler feature, so instead of setting heartbeat to the running interval we can set a cron to indicate when we want the trigger to run at.
Or if trigger is not designed to perform task like this? Should we use external scheduler instead?

Thanks so much in advance!

What would be the advantage of a built-in cron function over using the existing facilities of the host operating system (like cron) or of the orchestration framework in case you are handling a more complex production system (like Kubernetes’ cronjobs)?

1 Like

Hi @stefanobaghino-da thanks for the fast reply, there’s no particular reason that I think built-in is better, was just wondering what is the right way to handle the above scenario.

It sounds like for EOD operations like this, triggers might not be the preferred approach, instead a scheduled task (using any scheduler) that exercise UpdateNav will be the way.

I’d imagine I should instead do something like: creating a script that leverages json api and scheduling this script on any scheduler will be better suited for this scenario than using trigger.
Is this correct?

Thanks again!

Yes. In general I like to see Triggers as an automation triggered by an on-ledger event and Scripts as an automation triggered by an off-ledger event. Even though time is an important part of transactions (you can read more on how a specific timestamp is attributed to each transaction here), I would still regard a timer going off as an off-ledger event.

1 Like

@stefanobaghino-da One advantage is that there is one less thing to configure. While it would be nicer to have a trigger rule execute at a given time; or even allow a running trigger to modify its scheduled heartbeats (ex. after a configuration contract that it is subscribed to changes). If we do want to have a mixed approach, or avoid having a trigger update its schedule, delegating that capability to the trigger service (ex Control trigger heartbeats externally. · Issue #12094 · digital-asset/daml · GitHub) would be useful.

I understand the lure of this, but I’d rather configure The Right Tool for the Job™ rather than having one tool doing everything. Daml is designed to sit at the very core of complex systems, it will be unavoidable that there will be some necessary complexity to deal with and I’m not convinced that in this regard, Triggers should also take over time-based scheduling. There’s plenty of tools that are specifically designed to address this concerns and they can be used with Daml to solve the problem at hand.

/me grows a white beard and goes on to a rant about the Unix philosophy

1 Like

Children, gather round! Uncle @stefanobaghino-da will tell us about the perfect days of cron; The Right Tool for the Job!

I think that I understand your concern, especially as there is a lot of underlying complexity to writing and managing scheduled services. But I will not that one can get scheduled execution right now. Have one contract that tells you when to run next, a heartbeat that keeps going off and a guard asking if it is the right time. If polling is possible now, why not add a better mechanism to avoid that?

You might want to stay away from cron for anything except for basic use cases. In a production environment you are also likely going to want HA and something that give you a framework to manage containers running Triggers so that if any problem occurs, you can still have some expectation that the logic will be executed reliably (which is why I suggested to also have a look at Kubernetes cronjobs).

Buy please, feel free to gather around to listen about the many wonders of awk! :smiley:

1 Like

If you need extra error handling and orchestration a BPMN solution works well for this type of scheduling:

The job is DB backed and you can add gateway logic for handling “what if the job was delayed and did not occur at the proper time” , etc.

You can also build these sequential flows using fluent code builder and deploy it as a groovy file.

There is obviously some overhead but it gives you some robust insurance options to orchestrate out-of-band steps.

2 Likes