0

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

到目前为止，我对消息总线的使用仅限于 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加载并附加新的页面。OrderDocumentBundleOrderOrderDocument
  4. 传奇完成。

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

4

1 回答 1

3

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

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

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

为什么这么多传奇？因为

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

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

当然记得包括一些与超时有关的东西。如果一个 AttachmentSaga 在一定时间内没有回答，通知用户什么的。

于 2013-05-24T13:01:40.193 回答