Interface | Description |
---|---|
ServiceRequestMessage |
Abstract superclass for request messages sent to services which expect a reply.
|
Class | Description |
---|---|
AbstractStateReplacementFlow<T> |
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.
|
BroadcastTransactionFlow |
Notify all involved parties about a transaction, including storing a copy. Normally this would be called via
class FinalityFlow . |
CashCommand |
A command to initiate the Cash flow with.
|
CashFlow |
Initiates a flow that produces an Issue/Move or Exit Cash transaction.
|
CashFlowResult | |
FetchAttachmentsFlow |
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
attachments are saved to local storage automatically.
|
FetchDataFlow<T extends NamedByHash,W> |
An abstract flow for fetching typed data from a remote peer.
|
FetchTransactionsFlow |
Given a set of tx hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
|
FinalityFlow |
Finalise a transaction by notarising it, then recording it locally, and then sending it to all involved parties.
|
IssuerFlow |
This flow enables a client to request issuance of some
interface FungibleAsset from a
server acting as an issuer (see class Issued ) of FungibleAssets. |
NotaryChangeFlow |
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 | |
NotaryFlow | |
ResolveTransactionsFlow |
This flow is used to verify the validity of a transaction by recursively checking the validity of all the
dependencies. Once a transaction is checked it's inserted into local storage so it can be relayed and won't be
checked again.
|
ServiceRequestMessageKt | |
StateReplacementRefused |
Thrown when a participant refuses the proposed state replacement
|
TwoPartyDealFlow |
Classes for manipulating a two party deal or agreement.
|
TwoPartyTradeFlow |
This asset trading flow implements a "delivery vs payment" type swap. It has two parties (B and S for buyer
and seller) and the following steps:
|
ValidatingNotaryFlow |
A notary commit flow that makes sure a given transaction is valid before committing it. This does mean that the calling
party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party
has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was
indeed valid.
|
Exception | Description |
---|---|
InputStateRefResolveFailed | |
NotaryException | |
StateReplacementException |