net.corda.core.flows

Class ReceiveFinalityFlow

net.corda.core.flows.FlowLogic<T>

net.corda.core.flows.ReceiveFinalityFlow

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.

See Also:

class FinalityFlow, class SignTransactionFlow

Constructor Detail

ReceiveFinalityFlow

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

Parameters:

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.

See Also:

class FinalityFlow, class SignTransactionFlow

ReceiveFinalityFlow

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

Parameters:

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.

See Also:

class FinalityFlow, class SignTransactionFlow

ReceiveFinalityFlow

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

Parameters:

otherSideSession - The session which is providing the transaction to record.

See Also:

class FinalityFlow, class SignTransactionFlow

Method Detail

call

@Suspendable
 @NotNull
public SignedTransaction call()

This is where you fill out your business logic.