CorDapp流和restapi

我正在开发一个需要启动和跟踪Corda流程的系统。该系统的UI实现为单页web应用程序，其后端基于无服务器架构（AWS Lambda或Azure云功能）。这有效地排除了使用可观察或WebSocket的可能性，因为后端代码（无服务器函数）的运行时间不足以通过RPC连接接收更新。我需要一种不同的方式来跟踪流量，这种方式可以为查看webapp的用户提供或多或少的及时反馈

我希望实现这一点的方法是对长时间运行的事务使用标准REST模式。简而言之，流将由POST请求启动，并将返回

202接受的代码

，其中

Location

头指向流资源URL。该流将通过URL中编码的

StateMachineRunId

来标识，因此UI代码可以每隔一段时间发出GET请求，以查看请求的位置。不需要提供实时更新，因此轮询似乎是一种可行的策略。挑战在于可靠地构造对轮询请求的合理响应

当流正在运行时，这不是问题，我可以调用

stateMachinesSnapshot

并根据其UUID获取运行流的详细信息。问题是如何处理已完成的流。对于已经运行并生成一个或多个事务的流，可以通过

stateMachineRecordedTransactionMappingSnapshot

获得从流UUID到事务哈希的映射。问题是，随着每个记录的事务，这种映射变得越来越大，在高吞吐量系统上，它会减慢所有事情的速度——不过我还没有对它进行性能测试，只是预感而已

事务映射的另一个问题是，如果流由于设计或错误而无法生成任何持久事务，UUID将不再解析为任何内容，UI代码将得到

404notfound

error。我想这可能是上下文解释和适当的反馈，但这似乎很麻烦

---

理想情况下，我正在寻找一种方法，以持久和可伸缩的方式将流实例的唯一标识符与其当前状态或结果和终止条件关联起来。我想知道RPC或Corda API本身是否有什么东西可以让它变得更简单？

我们最新发布的CordaOS有一个新功能，允许在长时间运行操作期间暂停流，以提高吞吐量

---

更多信息@

当我写这篇关于Braid（）的文章时，我与一位开发人员（Farzad Pezeshkpour（又称Fuzz））联系，他提到他们正在“接收来自流的进度跟踪程序和保险库的跟踪查询的通知”。也许有必要联系他（他在Corda Slack），问问他他们正在采取什么方法来实现这个功能。这真是一个很酷的功能，谢谢你的提醒。然而，我不确定我是否明白这与这个问题有什么关系？