This is a more complicated version of the sort of thing being discussed in How to take user input and calculate individual formula. All the same comments I made there apply here—only more so.
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.