An abstraction for flow session destinations. A flow can send to and receive from objects which implement this interface. The specifics of how the messages are routed depend on the implementation.
A handle interface representing a
The public factory interface for creating validated
This annotation is required by any
This annotation is required by any
Abstract flow to be used for replacing one state with another, for example when changing the notary of a state. Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these flows.
Get and check the required signature.
A flow to be used for authorising and upgrading state objects of an old contract to a new contract.
Verifies the given transaction, then sends it to the named notary. If the notary agrees that the transaction is acceptable then it is from that point onwards committed to the ledger, and will be written through to the vault. Additionally it will be distributed to the parties reflected in the participants list of the states.
Version and name of the CorDapp hosting the other side of the flow.
A sub-class of
Main data object representing snapshot of the flow stack, extracted from the Quasar stack.
Container for the transaction and notarisation request signature. This is the payload that gets sent by a client to a notary service for committing the input states of the transaction.
A notarisation request specifies a list of states to consume and the id of the consuming transaction. Its primary purpose is for notarisation traceability – a signature over the notarisation request,
A wrapper around a digital signature used for notarisation requests.
Payload returned by the notary service flow to the client.
|NotaryChangeFlow<T extends ContractState>||
A flow to be used for changing a state's Notary. This is required since all input states to a transaction must point to the same notary.
Specifies the cause for notarisation request failure.
The receiving counterpart to
|ReceiveStateAndRefFlow<T extends ContractState>|
Token class, used to indicate stack presence of the corda internal data. Since this data is of no use for a CordApp developer, it is skipped from serialisation and its presence is only marked by this token.
Contains information about the consuming transaction for a particular state.
A unique identifier for a single state machine run, valid across node restarts. Note that a single run always has at least one flow, but that flow may also invoke sub-flows: they all share the same run id.
Sent by the notary when the notary detects it will unlikely respond before the client retries.
Given a flow which uses reference states, the
Exception which can be thrown by a
Thrown if the structure of a class implementing a flow is not correct. There can be several causes for this such as not inheriting from
Exception thrown by the notary service if any issues are encountered while trying to commit a transaction. The underlying error specifies the cause of failure.
Thrown when a flow session ends unexpectedly due to a type mismatch (the other side sent an object of a type that we were not expecting), or the other side had an internal error, or the other side terminated when we were waiting for a response.
Base data types and abstract classes for implementing Corda flows. To implement a new flow start with
class FlowLogic, or
class CollectSignaturesFlow for a simple example flow. Flows are started via a node's
Corda flows are a tool for modelling the interactions between two or more nodes as they negotiate a workflow. This can range from a simple case of completing a trade which has been agreed upon externally, to more complex processes such as handling fixing of interest rate swaps.