ExercisingByKey a HolidayCalendar from a Service requires implementation dependency


From one of our Services we need to check that a HolidayCalendar exists given a HolidayCalendarKey. In order to exerciseByKey we are forced to depend on the module Daml.Finance.Data.Reference.HolidayCalendar which breaks the rule “Services should only depend on Interfaces”.

Would it possible to create a Reference in the module Daml.Finance.Interface.Data.Reference.HolidayCalendar like others Daml finance Interfaces provide?


Hi @jvelasco.intellecteu,

thanks for sharing your concern. Currently the Bond package is in early access, and we are exploring an alternative approach to handle calendars that do not require keys. Please note that HolidayCalendarKey currently differs from AccountKey and InstrumentKey, as it does not key an interface (meaning that there is no corresponding Reference template like for AccountKey and InstrumentKey).

In the meantime, we suggest that you try to verify whether you could check that the calendar exists in a key-less manner (by entering a list of calendars in your service and manually building the key for each of them), i.e., you wouldn’t rely on exerciseByKey , fetchByKey nor HolidayCalendarKey.

Hope that helps.


1 Like

Thanks @Johan_Sjodin !

I’m not sure if I get your point. Do you mean something like that?

module Foo.Structuring.Service

template Service
    operator : Party
    provider : Party
    customer : Party
    supportedHolidayCalendars : [(Text, Party)] -- [(CalendarId, CalendarProvider)]
    floatingRateBondFactoryCid : ContractId FloatingRateBond.F
    signatory operator, provider, customer

    nonconsuming choice RequestFloatingRateBond : ContractId FloatingRateBondRequest.I
        id : Text
        description : Text
        holidayCalendarIds : [Text]
        calendarDataProvider : Party
        -- Ignoring the rest of atrributes
      controller customer
        assert $ all (\id -> (id, calendarDataProvider) `elem` supportedHolidayCalendars) holidayCalendarIds
        toInterfaceContractId <$> create Model.FloatingRateBondRequest with ..

Hi @jvelasco.intellecteu,

If I understand your question correctly, you would like to

  • verify that a certain calendar exists on the ledger
  • avoid depending on an implementation package (hence you cannot depend on CalendarKey)

A way to achieve that by working only against the HolidayCalendar.I interface is to

  • collect the relevant ContractIds for the calendars in your application
  • have a choice that takes a [ContractId HolidayCalendar.I] as an input, fetches the calendars and verifies that the desired (provider, id) pair appears in one of the input calendars

I hope this helps,