net.corda.flows

## Class ResolveTransactionsFlow

- FlowLogic
- - net.corda.flows.ResolveTransactionsFlow

-     public class ResolveTransactionsFlow
      extends FlowLogic

  This flow 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 `class SignedTransaction` was provided. If only the `class 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 a finished but partially signed transaction.

  The flow returns a list of verified `class LedgerTransaction` objects, in a depth-first order.

  See Also:
    `class SignedTransaction`, `class WireTransaction`, `class LedgerTransaction`

- - ### Nested Class Summary

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

  - ### Field Summary

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

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `ResolveTransactionsFlow(java.util.Set<? extends net.corda.core.crypto.SecureHash> txHashes, Party otherSide)` This flow 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.
    `ResolveTransactionsFlow(SignedTransaction stx, Party otherSide)` Resolve the full history of a transaction and verify it with its dependencies.
    `ResolveTransactionsFlow(WireTransaction wtx, Party otherSide)` Resolve the full history of a transaction and verify it with its dependencies.

  - ### Method Summary

    All Methods Static Methods Instance Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `java.util.List<net.corda.core.transactions.LedgerTransaction>` | `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.
    `int` | `getTransactionCountLimit()` The maximum number of transactions this flow will try to download before bailing out.
    `void` | `setTransactionCountLimit(int p)` The maximum number of transactions this flow will try to download before bailing out.
    `static java.util.List<net.corda.core.transactions.SignedTransaction>` | `topologicalSort(java.util.Collection<net.corda.core.transactions.SignedTransaction> transactions)` Topologically sorts the given transactions such that dependencies are listed before dependers.

    - ### 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 ResolveTransactionsFlow.Companion Companion

  - ### Constructor Detail

    - #### ResolveTransactionsFlow

          public ResolveTransactionsFlow(java.util.Set<? extends net.corda.core.crypto.SecureHash> txHashes,
                                         Party otherSide)

      This flow 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 `class SignedTransaction` was provided. If only the `class 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 a finished but partially signed transaction.

      The flow returns a list of verified `class LedgerTransaction` objects, in a depth-first order.

      See Also:
        `class SignedTransaction`, `class WireTransaction`, `class LedgerTransaction`

    - #### ResolveTransactionsFlow

          public ResolveTransactionsFlow(SignedTransaction stx,
                                         Party otherSide)

      Resolve the full history of a transaction and verify it with its dependencies.

    - #### ResolveTransactionsFlow

          public ResolveTransactionsFlow(WireTransaction wtx,
                                         Party otherSide)

      Resolve the full history of a transaction and verify it with its dependencies.

  - ### Method Detail

    - #### getTransactionCountLimit

          public int getTransactionCountLimit()

      The maximum number of transactions this flow will try to download before bailing out.

    - #### setTransactionCountLimit

          public void setTransactionCountLimit(int p)

      The maximum number of transactions this flow will try to download before bailing out.

    - #### call

          public java.util.List<net.corda.core.transactions.LedgerTransaction> 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.

    - #### topologicalSort

          public static java.util.List<net.corda.core.transactions.SignedTransaction> topologicalSort(java.util.Collection<net.corda.core.transactions.SignedTransaction> transactions)

      Topologically sorts the given transactions such that dependencies are listed before dependers.