public class FinalityFlow
extends FlowLogic
Verifies the given transactions, then sends them to the named notaries. 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.
Modifier and Type | Class and Description |
---|---|
static class |
FinalityFlow.Companion |
Modifier and Type | Field and Description |
---|---|
static FinalityFlow.Companion |
Companion |
Constructor and Description |
---|
FinalityFlow(java.lang.Iterable<net.corda.core.transactions.SignedTransaction> transactions,
java.util.Set<net.corda.core.crypto.Party> extraRecipients,
ProgressTracker progressTracker)
Verifies the given transactions, then sends them to the named notaries. 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.
|
FinalityFlow(SignedTransaction transaction,
java.util.Set<net.corda.core.crypto.Party> extraParticipants) |
FinalityFlow(SignedTransaction transaction) |
Modifier and Type | Method and Description |
---|---|
java.util.List<net.corda.core.transactions.SignedTransaction> |
call()
This is where you fill out your business logic. The returned object will usually be ignored, but can be
helpful if this flow is meant to be used as a subflow.
|
java.util.Set<net.corda.core.crypto.Party> |
getExtraRecipients() |
ProgressTracker |
getProgressTracker()
Override this to provide a
class ProgressTracker . If one is provided and stepped, the framework will do something
helpful with the progress reports. If this flow is invoked as a subflow of another, then the
tracker will be made a child of the current step in the parent. If it's null, this flow doesn't track
progress. |
java.lang.Iterable<net.corda.core.transactions.SignedTransaction> |
getTransactions() |
call, getCounterpartyMarker, getLogger, getProgressTracker, getRunId, getServiceHub, getStateMachine, receive, send, sendAndReceive, setStateMachine, subFlow, subFlow, track, waitForLedgerCommit
public static FinalityFlow.Companion Companion
public FinalityFlow(java.lang.Iterable<net.corda.core.transactions.SignedTransaction> transactions, java.util.Set<net.corda.core.crypto.Party> extraRecipients, ProgressTracker progressTracker)
Verifies the given transactions, then sends them to the named notaries. 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.
progressTracker
- Override this to provide a class ProgressTracker
. If one is provided and stepped, the framework will do something
helpful with the progress reports. If this flow is invoked as a subflow of another, then the
tracker will be made a child of the current step in the parent. If it's null, this flow doesn't track
progress.
Note that this has to return a tracker before the flow is invoked. You can't change your mind half way through.
transactions
- What to commit.extraRecipients
- A list of additional participants to inform of the transaction.public FinalityFlow(SignedTransaction transaction, java.util.Set<net.corda.core.crypto.Party> extraParticipants)
public FinalityFlow(SignedTransaction transaction)
public java.util.List<net.corda.core.transactions.SignedTransaction> call()
This is where you fill out your business logic. The returned object will usually be ignored, but can be helpful if this flow is meant to be used as a subflow.
public java.lang.Iterable<net.corda.core.transactions.SignedTransaction> getTransactions()
public java.util.Set<net.corda.core.crypto.Party> getExtraRecipients()
public ProgressTracker getProgressTracker()
Override this to provide a class ProgressTracker
. If one is provided and stepped, the framework will do something
helpful with the progress reports. If this flow is invoked as a subflow of another, then the
tracker will be made a child of the current step in the parent. If it's null, this flow doesn't track
progress.
Note that this has to return a tracker before the flow is invoked. You can't change your mind half way through.
class ProgressTracker