I have to create a report every month. The report contains many tables. Each tables has multiple rows and columns. Each row and column values/formulas are interdependent on other table values/formulas. Some of the values are user input (every month user will provide). Using daml smart contract, can we perform this operation? I have attached the example report table. Can anyone suggest is this possible in daml smart contract? I have done this using go chaincode (added rows in a table using json). If yes, Can you please share the example, how to get user input and how to add rows in a table?
Do I understand correctly that what you’re asking here is which Daml data structure would be most appropriate to store table data with variable number of rows and columns? If this is the question, I would recommend using a nested Map. I.e. a Map, where each value is another Map. The top level Map would represent table rows with Map keys corresponding to row headers or labels and each Map value being another Map and representing the cells in the row with Map keys corresponding to column headers or labels and Map values corresponding to the cell values. See the documentation for the DA.Map module in Daml standard library for details.
Daml itself is extremely well suited to collecting and managing the input data that drives this sort of reporting function. As mentioned in the previous answer it is not particularly good at RPC-style functions. In the case of historical reporting functions Daml is particularly challenging.
The short answer is: Use Daml to authorize, collect, validate, and manage the underlying data; generate reports via one or more queries against PQS.
The longer answer starts with the link I provided above, but with the additional consideration:
Daml needs to scale across an unbounded number of domains, participants, parties, and contracts. This potentially “infinite” data set, combined with strict privacy controls that limit visibility to a small subset of this “virtual ledger” means that a participant node executing a choice on a Daml smart contract by definition cannot know every contract on the ledger. Either of these requirements of scalability or security would preclude Daml having access to an internal query facility. As a result, Daml cannot “query the ledger”.
The problem when generating reports is that “querying the ledger” is precisely the functionality you need to ensure your report is complete. This is before considering the additional complication that many of the contracts you would need to analyse to generate a historical report such as this, will be archived by the time you are generating the report.
So the solution is the same as that mooted in the link above. Divide your problem into two distinct responsibilities:
Authorized attestation, generation, and synchronization of data
Off-ledger report generation based on historical ledger data obtained via #1
The quickest and easiest way to handle the second of these is to setup a PQS instance for the party generating the report. This can be configured to provide a projection of the historical ledger including both active and archived contracts. The reports can then be generated in the usual fashion using SQL queries against the PQS.
