6d1462f8eb
* Initial commit for CollectSignaturesFlow, some tests and associated documentation via a new "Flow Library" section of the docsite. * Refactored the TwoPartyDealFlow to use the CollectSignaturesFlow. * Added the subclassed CollectsigsFlow to the trader demo, whitelisted it and added a flow initiator for the responder. * Minor edits to progress tracker. * Amended as per Rick's comments. * Generalised this flow, so it now works if more than one signatures have been collected, initially. * Minor edits to the IRS demo so it uses the CollectSignaturesFlow. * For debugging purposes... * Adding CollectsigsFlow support to SIMM Demo. * Removing debug logging. * Amended top level comment: transactions can only have one notary. * Added TODOs as checkTransaction logic is absent. * Addressed Mike's review comments. * Minor edit to flow-library docs. * Updated flow based on Mike's review comments. * Added two usage examples and updated the tests. * Made changes to accommodate new CollectSignaturesFlow approach. * Made changes to SIMM demo to accommodate new CollectSignaturesFlow approach. * Added abstract check proposal method to two party deal flow. * Added missing TODOs. * Addressed Sham's comments. * Rebased to M11.
3.5 KiB
Flow Library
There are a number of built-in flows supplied with Corda, which cover some core functionality.
FinalityFlow
The FinalityFlow verifies the given transactions, then sends them to the specified notary.
If the notary agrees that the transactions are acceptable then they are from that point onwards committed to the ledger, and will be written through to the vault. Additionally they will be distributed to the parties reflected in the participants list of the states.
The transactions will be topologically sorted before commitment to ensure that dependencies are committed before dependers, so you don't need to do this yourself.
The transactions are expected to have already been resolved: if their dependencies are not available in local storage or within the given set, verification will fail. They must have signatures from all necessary parties other than the notary.
If specified, the extra recipients are sent all the given transactions. The base set of parties to inform of each transaction are calculated on a per transaction basis from the contract-given set of participants.
The flow returns the same transactions, in the same order, with the additional signatures.
CollectSignaturesFlow
The CollectSignaturesFlow is used to automate the collection of signatures from the counter-parties to a transaction.
You use the CollectSignaturesFlow by passing it a SignedTransaction which has at least been signed by yourself. The flow will handle the resolution of the counter-party identities and request a signature from each counter-party.
Finally, the flow will verify all the signatures and return a SignedTransaction with all the collected signatures.
When using this flow on the responding side you will have to subclass the AbstractCollectSignaturesFlowResponder and provide your own implementation of the checkTransaction method. This is to add additional verification logic on the responder side. Types of things you will need to check include:
- Ensuring that the transaction you are receiving is the transaction you EXPECT to receive. I.e. is has the expected type of inputs and outputs
- Checking that the properties of the outputs are as you would expect, this is in the absence of integrating reference data sources to facilitate this for us
- Checking that the transaction is not incorrectly spending (perhaps maliciously) one of your asset states, as potentially the transaction creator has access to some of your state references
Typically after calling the CollectSignaturesFlow you then called the FinalityFlow.
ResolveTransactionsFlow
This ResolveTransactionsFlow is used to verify the validity of a transaction by recursively checking the validity of all the dependencies. Once a transaction is checked it's inserted into local storage so it can be relayed and won't be checked again.
A couple of constructors are provided that accept a single transaction. When these are used, the dependencies of that transaction are resolved and then the transaction itself is verified. Again, if successful, the results are inserted into the database as long as a [SignedTransaction] was provided. If only the WireTransaction form was provided then this isn't enough to put into the local database, so only the dependencies are checked and inserted. This way to use the flow is helpful when resolving and verifying an unfinished transaction.
The flow returns a list of verified LedgerTransaction objects, in a depth-first order.