net.corda.flows

## Class FinalityFlow

- FlowLogic
- - net.corda.flows.FinalityFlow

-     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.

- - ### Nested Class Summary

    Nested Classes
    Modifier and Type | Class and Description
    --- | ---
    `static class` | `FinalityFlow.Companion`

  - ### Field Summary

    Fields
    Modifier and Type | Field and Description
    --- | ---
    `static FinalityFlow.Companion` | `Companion`

  - ### Constructor Summary

    Constructors
    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)`

  - ### Method Summary

    All Methods Instance Methods Concrete Methods
    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()`

    - ### Methods inherited from class net.corda.core.flows.FlowLogic

      `call, getCounterpartyMarker, getLogger, getProgressTracker, getRunId, getServiceHub, getStateMachine, receive, send, sendAndReceive, setStateMachine, subFlow, subFlow, track, waitForLedgerCommit`

- - ### Field Detail

    - #### Companion

          public static FinalityFlow.Companion Companion

  - ### Constructor Detail

    - #### FinalityFlow

          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.

      Parameters:
        `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.

    - #### FinalityFlow

          public FinalityFlow(SignedTransaction transaction,
                              java.util.Set<net.corda.core.crypto.Party> extraParticipants)

    - #### FinalityFlow

          public FinalityFlow(SignedTransaction transaction)

  - ### Method Detail

    - #### call

          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.

    - #### getTransactions

          public java.lang.Iterable<net.corda.core.transactions.SignedTransaction> getTransactions()

    - #### getExtraRecipients

          public java.util.Set<net.corda.core.crypto.Party> getExtraRecipients()

    - #### getProgressTracker

          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.

      See Also:
        `class ProgressTracker`