@SchedulableFlow @StartableByService @InitiatedBy @StartableByRPC @InitiatingFlow
Interface | Description |
---|---|
Destination |
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.
|
FlowExternalAsyncOperation<R> |
interface FlowExternalAsyncOperation represents an external future that blocks a flow from continuing until the future returned by
FlowExternalAsyncOperation.execute has completed. Examples of external processes where interface FlowExternalAsyncOperation would be useful
include, triggering a long running process on an external system or retrieving information from a service that might be down. |
FlowExternalOperation<R> |
interface FlowExternalOperation represents an external process that blocks a flow from continuing until the result of execute
has been retrieved. Examples of external processes where interface FlowExternalOperation would be useful include, triggering a long running
process on an external system or retrieving information from a service that might be down. |
FlowLogicRef |
A handle interface representing a
class FlowLogic instance which would be possible to safely pass out of the contract sandbox.
Use FlowLogicRefFactory to construct a concrete security checked instance. |
FlowLogicRefFactory |
The public factory interface for creating validated
interface FlowLogicRef instances as part of the scheduling framework. |
Class | Description |
---|---|
AbstractStateReplacementFlow |
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.
|
CollectSignatureFlow |
Get and check the required signature.
|
CollectSignaturesFlow |
The
class CollectSignaturesFlow is used to automate the collection of counterparty signatures for a given transaction. |
ContractUpgradeFlow |
A flow to be used for authorising and upgrading state objects of an old contract to a new contract.
|
DataVendingFlow | |
FinalityFlow |
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.
|
FlowInfo |
Version and name of the CorDapp hosting the other side of the flow.
|
FlowInitiator |
Please note that
class FlowInitiator has been superceded by class InvocationContext , which offers
more detail for the same event. |
FlowLogic<T> |
A sub-class of
class FlowLogic implements a flow using direct, straight line blocking code. Thus you
can write complex flow logic in an ordinary fashion, without having to think about callbacks, restarting after
a node crash, how many instances of your flow there are running and so on. |
FlowSession |
A
class FlowSession is a handle on a communication sequence between two paired flows, possibly running on separate nodes.
It is used to send and receive messages between the flows as well as to query information about the counter-flow. |
FlowStackSnapshot |
Main data object representing snapshot of the flow stack, extracted from the Quasar stack.
|
MaybeSerializedSignedTransaction |
In the words of Matt working code is more important then pretty code. This class that contains code that may
be serialized. If it were always serialized then the local disk fetch would need to serialize then de-serialize
which wastes time. However over the wire we get batch fetch items serialized. This is because we need to get the exact
length of the objects to pack them into the 10MB max message size buffer. We do not want to serialize them multiple times
so it's a lot more efficient to send the byte stream.
|
NotarisationPayload |
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.
|
NotarisationRequest |
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,
class NotarisationRequestSignature ,
allows a notary to prove that a certain party requested the consumption of a particular state. |
NotarisationRequestSignature |
A wrapper around a digital signature used for notarisation requests.
|
NotarisationResponse |
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.
|
NotaryError |
Specifies the cause for notarisation request failure.
|
NotaryFlow | |
ReceiveFinalityFlow |
The receiving counterpart to
class FinalityFlow . |
ReceiveStateAndRefFlow<T extends ContractState> |
The
class ReceiveStateAndRefFlow should be called in response to the class SendStateAndRefFlow . |
ReceiveTransactionFlow |
The
class ReceiveTransactionFlow should be called in response to the class SendTransactionFlow . |
SendStateAndRefFlow |
The
class SendStateAndRefFlow should be used to send a list of input class StateAndRef to another peer that wishes to verify
the input's integrity by resolving and checking the dependencies as well. The other side should invoke class ReceiveStateAndRefFlow
at the right point in the conversation to receive the input state and ref and perform the resolution back-and-forth
required to check the dependencies. |
SendTransactionFlow |
The
class SendTransactionFlow should be used to send a transaction to another peer that wishes to verify that transaction's
integrity by resolving and checking the dependencies as well. The other side should invoke class ReceiveTransactionFlow at
the right point in the conversation to receive the sent transaction and perform the resolution back-and-forth required
to check the dependencies and download any missing attachments. |
SignTransactionFlow |
The
class SignTransactionFlow should be called in response to the class CollectSignaturesFlow . It automates the signing of
a transaction providing the transaction: |
StackFrameDataToken |
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.
|
StateConsumptionDetails |
Contains information about the consuming transaction for a particular state.
|
StateMachineRunId |
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.
|
WaitTimeUpdate |
Sent by the notary when the notary detects it will unlikely respond before the client retries.
|
WithReferencedStatesFlow<T> |
Given a flow which uses reference states, the
class WithReferencedStatesFlow will execute the flow as a subFlow.
If the flow fails due to a class NotaryError.Conflict for a reference state, then WithReferencedStatesFlow will be suspended until the
state refs for the reference states are consumed. In this case, a consumption means that: |
Exception | Description |
---|---|
FlowException |
Exception which can be thrown by a
class FlowLogic at any point in its logic to unexpectedly bring it to a permanent end.
The exception will propagate to all counterparty flows and will be thrown on their end the next time they wait on a
FlowSession.receive or FlowSession.sendAndReceive. Any flow which no longer needs to do a receive, or has already
ended, will not receive the exception (if this is required then have them wait for a confirmation message). |
HospitalizeFlowException |
This exception allows a flow to pass itself to the flow hospital. Once the flow reaches
the hospital it will determine how to progress depending on what
cause s the exception wraps.
Assuming there are no important wrapped exceptions, throwing a exception HospitalizeFlowException
will place the flow in overnight observation, where it will be replayed at a later time. |
IllegalFlowLogicException |
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
class FlowLogic , not having a valid constructor and so on. |
KilledFlowException |
An exception that is thrown when a flow has been killed.
|
NotaryException |
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.
|
ResultSerializationException |
Thrown whenever a flow result cannot be serialized when attempting to save it in the database
|
StateReplacementException | |
UnexpectedFlowEndException |
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.
|