public class ReceiveFinalityFlow extends FlowLogic<T>
The receiving counterpart to class FinalityFlow
.
All parties who are receiving a finalised transaction from a sender flow must subcall this flow in their own flows.
It's typical to have already signed the transaction proposal in the same workflow using class SignTransactionFlow
. If so
then the transaction ID can be passed in as an extra check to ensure the finalised transaction is the one that was signed
before it's committed to the vault.
class FinalityFlow
,
class SignTransactionFlow
@JvmOverloads public ReceiveFinalityFlow(@NotNull FlowSession otherSideSession, @Nullable SecureHash expectedTxId, @NotNull StatesToRecord statesToRecord)
The receiving counterpart to class FinalityFlow
.
All parties who are receiving a finalised transaction from a sender flow must subcall this flow in their own flows.
It's typical to have already signed the transaction proposal in the same workflow using class SignTransactionFlow
. If so
then the transaction ID can be passed in as an extra check to ensure the finalised transaction is the one that was signed
before it's committed to the vault.
otherSideSession
- The session which is providing the transaction to record.expectedTxId
- Expected ID of the transaction that's about to be received. This is typically retrieved fromclass SignTransactionFlow
. Setting it to null disables the expected transaction ID check.statesToRecord
- Which states to commit to the vault. Defaults to StatesToRecord.ONLY_RELEVANT.class FinalityFlow
,
class SignTransactionFlow
@JvmOverloads public ReceiveFinalityFlow(@NotNull FlowSession otherSideSession, @Nullable SecureHash expectedTxId)
The receiving counterpart to class FinalityFlow
.
All parties who are receiving a finalised transaction from a sender flow must subcall this flow in their own flows.
It's typical to have already signed the transaction proposal in the same workflow using class SignTransactionFlow
. If so
then the transaction ID can be passed in as an extra check to ensure the finalised transaction is the one that was signed
before it's committed to the vault.
otherSideSession
- The session which is providing the transaction to record.expectedTxId
- Expected ID of the transaction that's about to be received. This is typically retrieved fromclass SignTransactionFlow
. Setting it to null disables the expected transaction ID check.class FinalityFlow
,
class SignTransactionFlow
@JvmOverloads public ReceiveFinalityFlow(@NotNull FlowSession otherSideSession)
The receiving counterpart to class FinalityFlow
.
All parties who are receiving a finalised transaction from a sender flow must subcall this flow in their own flows.
It's typical to have already signed the transaction proposal in the same workflow using class SignTransactionFlow
. If so
then the transaction ID can be passed in as an extra check to ensure the finalised transaction is the one that was signed
before it's committed to the vault.
otherSideSession
- The session which is providing the transaction to record.class FinalityFlow
,
class SignTransactionFlow
@Suspendable @NotNull public SignedTransaction call()
This is where you fill out your business logic.