Skip to content
Discussions/App Development/Implementing Atomicity for 3 separate exercise API calls involving different partiesForum ↗

Implementing Atomicity for 3 separate exercise API calls involving different parties

App Development5 posts242 views3 likesLast activity Jul 2022
JU
Julius_WilliamOP
Jul 2022

Hi, I had a question regarding implementing atomicity for the below flow.

We have two contracts: A and B.
Contract A’s signatory is: Operator
Contract B’s signatory is: User

Through API calls from a Node.js backend, we want to achieve the following flow:

  1. Operator exercises choice on Contract A.
  2. User exercises choice on contract B.
  3. Operator exercises choice on Contract A.

Can we make these 3 steps atomic somehow?

Thanks!

CO
cocreature
Jul 2022

To get a single Daml transaction and therefore atomicity, you also have to make a single command submission. Multi-command submissions don’t really help here to do the different exercises since they have different controllers and you almost certainly cannot expect to have actAs = [user, operator].

So your command submission has to be a single exercise. Given that the operator seems to initiate this process they should be the controller. In the body of that choice you can then do the 3 operations you suggested. To make authorization work out the user needs to delegate their authority to the operator.

So in the end, you end up with a template like this:

template Helper
  with
    user : Party
    operator : Party
    contractA : ContractId A
    contractB : ContractId B
  where
    signatory user
    observer operator
    nonconsuming choice DoStuff : ()
      controller operator
      do exercise contractA FirstChoice -- operator is controller
         exercise contractB SecondChoice -- user is controller
         exercise contractA ThirdChoice -- operator is controller

If having the user delegate their authorization by creating such a contract is not an option, I don’t think you can make this atomic.

DA
davide_ooz
Jul 2022

assuming operator is not a stakeholder of B, for the above to work one needs to be able to at least readAs user to fetch contractB, i.e. something like

submitMulti [operator] [user] do exerciseCmd helper DoStuff

would work. However if operator is set as an observer of B DoStuff would work with just

submit operator do exerciseCmd helper DoStuff

correct?

CO
cocreature
Jul 2022

Good point, yes you need to make the contract visibile via observers or readAs.

JU
Julius_William
Jul 2022

Thanks @cocreature and @davide_ooz for the input! Will give it another go :slight_smile:

← Back to Discussions