文档处理 - 一个 Saga 案例？

Question

我正在处理的应用程序的一部分涉及下载包含附件的电子邮件、检测每个附件中的条形码、扫描它以查找标识符并使​​用该标识符将数据插入数据库。

到目前为止，我对消息总线的使用仅限于 Pub/Sub，而且我从来没有真正需要使用 Sagas。但是，鉴于上述每个步骤都是同一相关流程的一部分，并且我们希望在流程的任何部分失败时保持持久性，那么 Saga 是否合适？

我们的过程的详细信息以及我认为我们可以使用 Saga 的方式如下：

1. Quartz 作业用于下载包含 PDF 附件的电子邮件。 Quartz 作业使用Connector，其中包含有关Tenant 的信息。 Saga 将需要此租户信息，以便我们可以与租户特定资源（数据库/存储）进行交互。
2. 对于每个 PDF 附件，我们都会启动一个“处理文档”Saga，将租户信息和文档本身（假设消息总线可以持久保存）或磁盘上文件的路径传递给它。为源电子邮件上的每个附件启动 Saga 后，连接器可以从邮箱中删除/存档电子邮件，以便不再处理它。

然后每个 Saga 将执行以下任务：

1. 尝试从附件/文件中读取条形码。如果条码检测失败，我们需要将文件上传到指定位置，以便手动处理。这将完成 Saga。如果检测到条形码，我们会解码数据库标识符。
2. 使用标识符我们从我们的数据库中加载相关的Order记录，如果它存在：
   1. 将文件上传到返回 URI 的指定位置
   2. 在我们的数据库中插入一条新的OrderDocument 记录，该记录引用文件 URI。
3. 我们更新了OrderDocumentBundle，它是一个包含与订单相关联的所有文档的单个文件。因此，当创建一个新的OrderDocument 时，我们应该为相关的Order 加载OrderDocumentBundle 并附加来自新OrderDocument 的页面。
4. 传奇完成。

我担心最终捆绑过程中的并发问题，因为我们可能有多个消息尝试更新捆绑包。我们需要确保 Saga 等待捆绑文件可用以便完成。

Answer 1

免责声明：当谈论 Sagas 时，我们谈论的是 NServiceBus sagas，我希望没有宗教讨论开始。 :)

您应该定义两个或三个 saga。一个用于电子邮件，另一个用于附件。

• EmailSaga 会知道有多少附件，并且在每个 AttachmentSaga 返回答案之前不会完成。
• 每个 AttachmentSaga 都可以从调用处理程序 (RetrieveBarCodeHandler) 开始检索条形码。如果此处理程序失败，它也会回复，但状态为失败。
• AttachmentSaga 可以调用另一个 saga (ManualProcessingSaga) 来存储附件并向用户发送电子邮件（或类似的东西，它可以调用其他处理程序）以手动处理条形码。
  • 用户手动处理附件并使用命令（RegisterBarcodeCommand）提交结果
  • ManualProcessingSaga 接收命令并向发起者 AttachmentSaga 发送回复。
  • AttachmentSaga 可以继续其工作，并最终向 EmailSaga 发送回复
• EmailSaga 已收到所有回复，并且知道已完成。

为什么这么多传奇？因为

1. 处理电子邮件是一个漫长的过程
2. 处理附件是一个长期运行的过程
3. 手动处理附件是一个长期运行的过程

长时间运行的进程不是因为时间问题，而是因为正在发生多件事情，或者它正在等待答案或超时。

当然记得包含与超时相关的内容。如果一个 AttachmentSaga 在一定时间内没有回复，通知用户什么的。