d7e4aa1783
approach which assumes a dedicated node for observers: states that are reported to the node will appear in the database and update feeds as normal. Apps that expect all updates to be relevant to themselves may need adjusting if they run on an observer node too, but this is likely to be rare.
1.9 KiB
Observer nodes
Posting transactions to an observer node is a common requirement in finance, where regulators often want to receive comprehensive reporting on all actions taken. By running their own node, regulators can receive a stream of digitally signed, de-duplicated reports useful for later processing.
Adding support for observer nodes to your application is easy. The IRS (interest rate swap) demo shows to do it.
Just define a new flow that wraps the SendTransactionFlow/ReceiveTransactionFlow, as follows:
../../samples/irs-demo/cordapp/src/main/kotlin/net/corda/irs/flows/AutoOfferFlow.kt
In this example, the AutoOfferFlow is the business logic, and we define two very short and simple flows to send the transaction to the regulator. There are two important aspects to note here:
- The
ReportToRegulatorFlowis marked as an@InitiatingFlowbecause it will start a new conversation, context free, with the regulator. - The
ReceiveRegulatoryReportFlowusesReceiveTransactionFlowin a special way - it tells it to send the transaction to the vault for processing, including all states even if not involving our public keys. This is required because otherwise the vault will ignore states that don't list any of the node's public keys, but in this case, we do want to passively observe states we can't change. So overriding this behaviour is required.
If the states define a relational mapping (see api-persistence) then the regulator will be able to query the reports from their database and observe new transactions coming in via RPC.