CODEWITHSUNDEEP
corda
Sil
Sil

Reputation: 25

What do we mean by writing multiple responder flows in cordapp?

What is literally happening in multiple responder flow?Are we communicating with multiple nodes?Can we do use multiple responder flow for some other purpose?

Upvotes: 2

Views: 213

Answers (3)

Alessandro B
Alessandro B

Reputation: 1138

As the previous comments say, you can choose to create multiple responder flows or having a single one that implements different logics depending on the information stored in the responding node. There are multiple example in the source code of Corda, if you look for flow handlers, like this one below (on github) where you can see that different logics apply depending on the role of the responding node (set by the InitiatingFlow, in this case):

class ObserverAwareFinalityFlowHandler(val otherSession: FlowSession) : FlowLogic<Unit>() {
    @Suspendable
    override fun call() {
        val role = otherSession.receive<TransactionRole>().unwrap { it }
        val statesToRecord = when (role) {
            TransactionRole.PARTICIPANT -> StatesToRecord.ONLY_RELEVANT
            TransactionRole.OBSERVER -> StatesToRecord.ALL_VISIBLE
        }
        // If states are issued to self, then ReceiveFinalityFlow does not need to be invoked.
        if (!serviceHub.myInfo.isLegalIdentity(otherSession.counterparty)) {
            subFlow(ReceiveFinalityFlow(otherSideSession = otherSession, statesToRecord = statesToRecord))
        }
    }
}

Upvotes: 1

Adel Rustum
Adel Rustum

Reputation: 2548

Imagine this, you (the initiator) is applying for a loan; you go to 5 different banks (i.e. 5 responders). Every bank has their own criteria to approve your loan application (one bank requires you to own a house as a guarantee, another requires you to have an annual salary higher than 100,000, and so on).

So even though all responding nodes can use the responder flow that was supplied by the organization that wrote the initiating flow; they are not obliged too, actually it is the responsibility of the responding node to write its own version of the responder flow to implement its own business rules.

If the received transaction passes those business rules, the responder approves it (i.e. it signs the transaction); otherwise it rejects it (i.e. throws a FlowException).

Upvotes: 1

Ashutosh Meher
Ashutosh Meher

Reputation: 1821

I suppose you are referring to the overriding of responder flows. It allows developers to configure a node to respond using an overridden responder flow rather than the base responder.

You could find more details here: https://docs.corda.net/docs/corda-os/4.5/flow-overriding.html

Upvotes: 1

Related Questions