pbfunc外部扩展函数_从外部CorDapp扩展和覆盖流
pbfunc外部扩展函数
Corda 4于上周（2⽉21⽇）发布，带来了⼤量的新功能，使Corda更加令⼈愉快。 ⽼实说，我有点假设有很多新功能。 我快速浏览了变更⽇志，主要是看到我的贡献被引⽤，但是我记得看到很多⽂本⾏。 那⼀定是⼀件好事吧？
⽆论如何，这些功能之⼀就是能够扩展和覆盖流程。 当您意识到Corda⽤Kotlin编写并完全继承了继承性时，听起来并不是很花哨（对于Java也是如此）。 但是，不仅如此。 Corda需要将“发起流程”映射到与其响应的交易对⼿流程。
当两⽅使⽤相同的CorDapp时，这很好。 在这种情况下，不会增加任何额外的复杂性。 另⼀⽅⾯，如果交易对⼿希望在收到交易后将⼀些数据发送到外部系统，他们该怎么做？ 原始的CorDapp不了解或不关⼼此系统，因此⽆法满⾜这些需求。 能够解决这类问题，使开发⼈员可以在现有的CorDapps的基础上进⾏构建，并使它们适应于其⽤例。 此外，⼀旦制定了良好的实践，扩展第三⽅CorDapps将变得更加容易，并且在其他⼈已经解决了部分问题的同时，不再需要开发团队不断重新发明轮⼦。 显然，这假定可以访问这些外部CorDapp，但这完全是可能的。 特别是在已经展⽰了⼀个集合的情况下。
在本⽂中，我们将专注于扩展和覆盖流程。 此外，我们将采⽤两种不同观点的观点。
CorDapp的开发⼈员/维护⼈员
想要使⽤和改编现有CorDapp的开发⼈员
为了使该过程正常进⾏，双⽅都必须努⼒以适当的⽅式编写其应⽤程序，以便可以利⽤其收益。
我们将⾸先查看原始CorDapp必须包含的内容，然后是开发⼈员必须进⾏扩展的内容。荆轲刺秦王原文及翻译
在我们进⾏下⼀步之前，这⾥是指向的的链接。
取英文名编写基本流程以允许扩展
以⼀种易于扩展的⽅式编写CorDapp可能需要进⾏⼤量思考。 这在很⼤程度上取决于CorDapp维护⼈员要实现的⽬标。 为开发⼈员提供⼀种扩展CorDapp的⽅式，以便他们可以将数据发送到外部系统或添加⾃⼰的⽇志记录，这不会造成任何问题。 另⼀⽅⾯，允许更改事务的内容或将事务的内容发送给谁将需要更多的考虑以确保不滥⽤CorDapp。 我希望在以后的帖⼦中进⼀步探讨这个主题。
出于本⽂的⽬的，我们将介绍更简单的选项。 让我们直接进⼊，因为到⽬前为⽌有很多⽂本，没有代码。 下⾯是将充当“基本”流
的SendMessageFlow ，它将在后⾯的部分中进⾏扩展：
@InitiatingFlow
open class SendMessageFlow(private val message: MessageState) :
FlowLogic<SignedTransaction>() {
open fun preTransactionBuild() {
// to be implemented by sub type flows - otherwi do nothing
}
open fun preSignaturesCollected(transaction: SignedTransaction) {
// to be implemented by sub type flows - otherwi do nothing
}
cpmopen fun postSignaturesCollected(transaction: SignedTransaction) {
// to be implemented by sub type flows - otherwi do nothing
陪练专家
}
open fun postTransactionCommitted(transaction: SignedTransaction) {
// to be implemented by sub type flows - otherwi do nothing
}
@Suspendable
final override fun call(): SignedTransaction {
logger.info("Started nding message ${ts}")
preTransactionBuild()
val tx = verifyAndSign(transaction())
preSignaturesCollected(tx)
val ssions = listOf(ipient))
val stx = collectSignature(tx, ssions)
postSignaturesCollected(stx)
return subFlow(FinalityFlow(stx, ssions)).also {
logger.info("Finished nding message ${ts}")
postTransactionCommitted(it)
}
}
// collectSignature
截ens是什么意思// verifyAndSign
// transaction
}
我删除了⼀些功能，因此我们可以专注于重要的事情。
允许扩展此类的第⼀步甚⾄有时很重要的步骤是它是open 。 这更像是Kotlin，⽽不是Java，因为Kotlin中的所有类默认都是final 。 如果您使⽤Java编写此代码，则只需忽略最后⼏句话！
接下来，有⼀系列可以被覆盖的功能。 每个功能已放置在Flow主要执⾏程序内的适当位置。 Flow运⾏时将调⽤它们。 ⽬前，由于没有为CorDapp开发⼈员提供任何使⽤，因此为他们提供了空的实现。
关于open功能。 您可以命名它们或将它们放置在任何需要的位置。 我认为这些功能对于希望在基本应⽤程序提供的内容上增加额外可追溯性的开发⼈员很有⽤。
深⼊了解更多细节。 call函数已被final （与Java中相同），以防⽌覆盖Flow的全部内容。 如果有⼈想采⽤您的Flow并完全取代其“主
要”功能，那有什么意义呢？ 对我来说，这似乎有点狡猾。 为了消除这种可能性，将其final是明智之举。
稍后，我们将研究如何将此Flow⼦类化。
下⾯是与SendMessageResponder交互的SendMessageFlow 。 它遵循与上述相同的概念，因此在以后我仅将其作为参考：
@InitiatedBy(SendMessageFlow::class)
open class SendMessageResponder(private val ssion: FlowSession) : FlowLogic<Unit>() {
open fun postTransactionSigned(transaction: SignedTransaction) {
// to be implemented by sub type flows - otherwi do nothing
}
open fun postTransactionCommitted(transaction: SignedTransaction) {
// to be implemented by sub type flows - otherwi do nothing
}
@Suspendable
final override fun call() {
val stx = subFlow(object : SignTransactionFlow(ssion) {
amerooverride fun checkTransaction(stx: SignedTransaction) {}
})
奥巴马演讲视频postTransactionSigned(stx)
val committed = subFlow(
ReceiveFinalityFlow(
otherSideSession = ssion,
expectedTxId = stx.id
)
高考后出国留学)
postTransactionCommitted(committed)
}
}
扩展现有的启动流
在本节中，我们将看到开发⼈员如何利⽤在上⼀个Flow上完成的⼯作。 它已经具有所有必需的功能。 唯⼀缺少的是开发⼈员想要添加的少量额外的可跟踪性。这要归功于基本Flow所添加的功能。 这不会造成任何问题。
让我们从扩展启动流开始。 这样做的要求如下：
扩展基础@InitiatingFlow
不要添加@InitiatingFlow到新的流程（错误会发⽣，如果你这样做）
引⽤基本Flow的构造函数（Java中的super ）
覆盖任何所需的功能
调⽤新流程⽽不是基本流程
阅读该列表后，您可能已经意识到，这⼏乎是对⾯向对象语⾔（例如Kotlin和Java）中继承的描述。
Corda内可能还有更多事情要做，但是从您的⾓度来看，您只是像往常⼀样编写普通的⾯向对象代码。
遵循这些要求，我们可以看到扩展的Flow可能是什么样的：
@StartableByRPC
class CassandraSendMessageFlow(private val message: MessageState) :
SendMessageFlow(message) {
override fun preTransactionBuild() {
message,
nder = true,
committed = fal
)
logger.info("Starting transaction for message: $message")
}
override fun preSignaturesCollected(transaction: SignedTransaction) {
val keys = quiredSigningKeys - ourIdentity.owningKey
logger.info("Collecting signatures from $keys for transaction for message: $message")
}
override fun postSignaturesCollected(transaction: SignedTransaction) {
logger.info("Collected signatures for transaction for message: $message")
}
override fun postTransactionCommitted(transaction: SignedTransaction) {
message,
nder = true,
committed = true
)
logger.info("Committed transaction for message: $message")
}
}
我留下了实现我所谈论的额外可追溯性的所有嘈杂函数，但这是由于没有它们的类将有多么空。 由于不需要call 。 此流程仅需要覆盖open功能。 ⽼实说，根本不需要覆盖它们，它们是可选的。 如果需要，此流可以覆盖单个函数，然后将其保留为空。
是否满⾜上述所有要求？
CassandraSendMessageFlow扩展了SendMessageFlow
看不到@InitiatingFlow
在Kotlin中，⽆论如何都必须调⽤super构造函数，这样就完成了
在这种情况下，所有功能都被覆盖
我们还没有⾛这么远
好的，到⽬前为⽌是4/5。 那是⼀个很好的开始。 要划掉列表中的最后⼀项，我们需要查看其调⽤⽅式。 以下是调⽤基
本SendMessageFlow和CassandraSendMessageFlow扩展Flow的代码⽚段。
从SendMessageFlow开始：
proxy.startFlow(::SendMessageFlow, messageState)
其次是CassandraSendMessageFlow ：
proxy.startFlow(::CassandraSendMessageFlow, messageState)
注意区别吗？ 在这种情况下，仅流的名称已更改。 没有其他的。
这两个代码段都是完全有效的。 仍然允许调⽤原始的SendMessageFlow 。 请记住，从我们的⾓度来看，它只是普通的⾯向对象代码。 它不会在扩展的Flow中添加多余的代码，但是它仍然可以执⾏⽽不会出现问题。 完成此步骤符合扩展@InitiatingFlow的最后要求。
在结束本节之前，这⾥是需要记住的重要信息：
“您必须确保⼦类中的发送/接收/⼦流的顺序与⽗类兼容。”
我将把它放在以下所有部分中，因为不遵循这将导致您的流程失败。
扩展响应者流程
扩展响应者流的⽅式与扩展@InitiatingFlow流的⽅式⾮常相似。 唯⼀的区别是它的调⽤⽅式。 如中所述：
“ Corda会检测到BaResponder和SubResponder都已配置为响应发起⽅。然后，Corda将计算到FlowLogic的跃点，并选择距离最远的实现，即：⼦类化最多的实现。”hokage
“最⼦类化”的陈述是本⽂的重要内容。 因此，从开发⼈员的⾓度来看，他们所需要做的就是扩展外部基本响应程序流，仅此⽽已。 我⾮常喜欢之前的需求列表，因此让我们再看⼀遍扩展响应者流程：
扩展基础@InitiatedBy /响应者流
将@InitiatedBy添加到新流程
引⽤基本Flow的构造函数（Java中的super ）
覆盖任何所需的功能
如果您保持警惕，您可能已经注意到，没有提到如何调⽤它。 扩展的“响应者流”不需要在其他任何地⽅调⽤或引⽤。 Corda将尽⼀切努⼒将所有物品路由到正确的位置。
可以肯定的是，让我们快速看⼀个例⼦：
@InitiatedBy(SendMessageFlow::class)
class CassandraSendMessageResponder(ssion: FlowSession) :
SendMessageResponder(ssion) {
override fun postTransactionSigned(transaction: SignedTransaction) {
val message = Transaction.outputsOfType<MessageState>().single()
logger.info("Signed transaction for message: $message")
}
override fun postTransactionCommitted(transaction: SignedTransaction) {
val message = Transaction.outputsOfType<MessageState>().single()
message,
nder = fal,
committed = true
)
logger.info("Committed transaction for message: $message")
}
}
此外，让我们再次回顾“最⼦类化”的说法。 CassandraSendMessageResponder是SendMessageResponder的⼦类，因此由Corda选择以处理来⾃启动流的请求。 但是，这可以采取进⼀步的措施。 如果还有另⼀个类，例如
说SuperSpecialCassandraSendMessageResponder ，那么此流程现在就是Corda将开始使⽤的流程。 尽管我确实发现这种情况⽬前不太可能，但绝对值得了解。
英语小故事100字
再次复制并粘贴此语句，这样您就不会忘记：
“您必须确保⼦类中的发送/接收/⼦流的顺序与⽗类兼容。”
覆盖响应者流程
