【发布时间】：2020-04-07 21:40:45
【问题描述】：
我正在开发一个需要启动和跟踪 Corda 流的系统。该系统的 UI 实现为单页 Web 应用程序，其后端基于无服务器架构（AWS Lambda 或 Azure Cloud Functions）。这有效地排除了使用 Observables 或 Websockets，因为后端代码（无服务器功能）不会运行足够长的时间来通过 RPC 连接接收更新。我需要一种不同的方式来跟踪流程，以便为查看 web 应用的用户提供或多或少的及时反馈。
我希望实现这一目标的方法是使用标准 REST 模式来处理长时间运行的事务。简而言之，流将由 POST 请求启动，并返回 202 Accepted code 和指向流资源 URL 的 Location 标头。该流将由其在 URL 中编码的StateMachineRunId 标识，因此 UI 代码可以不时发出 GET 请求以查看请求的位置。不需要提供实时更新，因此轮询似乎是一种可行的策略。挑战在于可靠地构建对轮询请求的合理响应。
虽然流程正在运行，但这不是问题，我可以调用stateMachinesSnapshot 并根据其 UUID 获取正在运行的流程的详细信息。问题是如何处理已完成的流程。对于已经运行并产生一个或多个事务的流，可以通过stateMachineRecordedTransactionMappingSnapshot 获取从流 UUID 到事务哈希的映射。问题是这个映射随着每个记录的事务变得越来越大，并且在高吞吐量系统上它会减慢一切——不过我还没有对它进行性能测试，只是一种预感。
事务映射的另一个问题是，如果流未能生成任何持久事务，无论是设计原因还是错误，UUID 将不再解析为任何内容，并且 UI 代码将收到 404 Not Found 错误。我想这可能会根据上下文进行解释并提供适当的反馈，但这似乎很麻烦。
理想情况下，我正在寻找一种方法来持久且可扩展地将流实例的唯一标识符与其当前状态或其结果和终止条件相关联。我想知道 RPC 或 Corda API 本身是否有一些东西可以使它变得更容易？
【问题讨论】：
-
当我写这篇关于 Braid (blog.b9lab.com/…) 的文章时，我与其中一位开发人员 (Farzad Pezeshkpour (a.k.a Fuzz)) 联系，他提到他们正在开发“接收通知”来自流程的进度跟踪器和保管库的 TrackBy 查询”。也许值得联系他（他在 Corda Slack 上）并询问他他们正在采取的实施方法。
标签： corda