public static class NotaryFlow.Service
extends FlowLogic
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict if any of the input states have been previously committed.
Extend this class, overriding beforeCommit to add custom transaction processing/validation logic.
TODO: the notary service should only be able to see timestamp commands and inputs
Constructor and Description |
---|
Service(Party otherSide,
TimestampChecker timestampChecker,
UniquenessProvider uniquenessProvider)
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
if any of the input states have been previously committed.
|
Modifier and Type | Method and Description |
---|---|
void |
beforeCommit(SignedTransaction stx)
No pre-commit processing is done. Transaction is not checked for contract-validity, as that would require fully
resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction
history chain.
As a result, the Notary will commit invalid transactions as well, but as it also records the identity of
the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently
undo the commit of the input states (the exact mechanism still needs to be worked out).
|
void |
call()
This is where you fill out your business logic. The returned object will usually be ignored, but can be
helpful if this flow is meant to be used as a subflow.
|
Party |
getOtherSide() |
TimestampChecker |
getTimestampChecker() |
UniquenessProvider |
getUniquenessProvider() |
call, getCounterpartyMarker, getLogger, getProgressTracker, getRunId, getServiceHub, getStateMachine, receive, send, sendAndReceive, setStateMachine, subFlow, subFlow, track
public Service(Party otherSide, TimestampChecker timestampChecker, UniquenessProvider uniquenessProvider)
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict if any of the input states have been previously committed.
Extend this class, overriding beforeCommit to add custom transaction processing/validation logic.
TODO: the notary service should only be able to see timestamp commands and inputs
public void call()
This is where you fill out your business logic. The returned object will usually be ignored, but can be helpful if this flow is meant to be used as a subflow.
public void beforeCommit(SignedTransaction stx)
No pre-commit processing is done. Transaction is not checked for contract-validity, as that would require fully resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction history chain. As a result, the Notary will commit invalid transactions as well, but as it also records the identity of the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently undo the commit of the input states (the exact mechanism still needs to be worked out).
public Party getOtherSide()
public TimestampChecker getTimestampChecker()
public UniquenessProvider getUniquenessProvider()