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.