Lesson 3: Daml Applications

Captions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.

1. 0:05

   when designing a daml application we need to understand the underlying architecture on which it is installed and how it interacts with the key components of its text stack in this lesson we will take an overview of a simple daml application how it spans multiple participant nodes and accesses The Ledger using Ledger and Json apis this diagram shows a simple yet foundational architecture to demonstrate how a daml application enables

2. 0:35

   multi-party transactions while ensuring data sovereignty and privacy the daml application as an example in this diagram is a bank app offered by the bank as the app provider and used by another organization company a which is the app user these are two organizations that have their own infrastructure with full control on its components both both these organizations have their own participant nodes that host their respective private contract stores the bank's participant node provides the

3. 1:08

   bank's view of The Ledger that the bank shares with its own employees similarly company A's participant node provides company is view of The Ledger visible to the end users at company a the participant nodes also maintain a private contract store or PCS where their local copy of the The daml Ledger persists this Ledger is shared between the parties in a way that each party has a shared Ledger State visible to other parties depicted here as a white box and

4. 1:41

   a private State shown here as green and orange boxes in the private contract store all changes to the shared state are coordinated between the participant nodes using the sync domain this enables two important properties of The Ledger first no single party can unilaterally change the shared state of The Ledger and second parties can see only the shared State and do not have visibility into other parties private Ledger State these two properties ensure data

5. 2:13

   sovereignty as well as privacy of each organization's data the schema for the shared State and related workflows are defined in the doors or daml archive files note that the DAR file for the bank app is hosted on each participant node as the two companies and their daml application infrastructure are isolated from each other their participant nodes use a common sync domain to be able to communicate with each other a sync domain is a service that helps

6. 2:45

   synchronize transactions across a set of participant nodes where the parties participating in a transaction reside the sync domain for a specific app is typically operated by the app provider but other options are possible depending on the use case the participant node exposes The Ledger API for external applications to access The Ledger stored in the PCS The Ledger API can be accessed either directly using grpc or

7. 3:17

   via the Json API proxy using HTTP the front end runs in the browser and thus uses HTTP to submit commands to The Ledger through the Json API or the app backend submits commands to The Ledger using The Ledger API notice in this diagram that only the app provider that is the bank runs the app backend the app user which is company a needs to have only the front end to use the services enabled by the back end that is hosted by the app provider for querying The Ledger the frontend can query The

8. 3:56

   Ledger directly using the Json API however such queries should be limited to small sets of contracts say less than 100 contracts so as not to negatively impact the dlap performance The Ledger API and Json API are not optimized for efficiently executing complex queries for complex queries a better alternative is to use an operational data store optimized for efficiently executing the

9. 4:27

   application's queries a good default option is to use the participant query store or pqs which provides a SQL API on the contract in transaction data from the PCS the pqs mirrors The Ledger and allows for efficient querying it stores contract creation archival and exercise information in a postgis SQL database that can be accessed over a jdbc connection the read API exposed by the app back

10. 5:00

    exposes access to app relevant queries to the frontend when a bank employee logs into the bank app through the web UI the bank's identity access and management system or I am authenticates them the participant node retrieves the jot issuer key from the bank's IAM and authorizes the user to perform actions on behalf of the party to which the end user is mapped in this case we can assume that the bank employee is authorized to perform certain actions on bank's

11. 5:33

    behalf similarly when a company a employee logs in the I am system controlled by company a authenticates them company A's participant node retrieves the jot issuer key and authorizes the employee to act on behalf of the party to which the employee is mapped in this way both organizations have their own I am systems and this is important because each business entity wants to control and provision access to its systems on its own the architecture

12. 6:05

    diagram shown here focuses on the workings of a daml application such an application often has to integrate with backend systems because the workflows modeled in daml applications are linked to other workflows handled by an organization's internal systems the app provider organization can integrate its internal systems directly through the app backend the daml app thereby enables the app provider to allow controlled access to

13. 6:34

    the proprietary internal system and processes company a which is the app user also has the option to automate their integration with their internal systems by building their own backend thanks to their data sovereignty the backend can access their own data directly from their participant node potentially via the pqs for complex queries the custom backend can also access the provider's app backend in an authenticated fashion which is for

14. 7:04

    example required to retrieve reference data managed by the provider this custom backend will be treated as an external user and will be authenticated through the I am system like the web UI user we have seen before the mechanisms for login command submissions and querying a ledger will be similar to those for a web UI we saw earlier let us summarize a daml application is a multi-party application and is therefore installed at the app

15. 7:35

    provider site as well as at one or more app user sites a daml application has three key components frontend UI app backend and dar files the frontend UI and dar files are needed for both the app provider and the app users the backend runs only at the app provider end the daml application can submit commands either through the front end using Json API or through app backend using Ledger API for querying the frontend UI can directly query The

16. 8:09

    Ledger using Json API however for complex querying it is recommended that the app provider's participant node should Implement an operational data store one option is to use the participant query store or pqs which mirrors The Ledger and can be accessed through jdbc connection the end users are authenticated using the party's own I am system thereby preserving data sovereignty and privacy of each Organization for endtoend

17. 8:41

    business workflows within the organization daml application can be extended through custom developed backends that can interface between daml application and other internal systems