文件处理 - 佐贺的案例？

Question

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

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

我们的流程详情以及我想法我们可以使用Saga如下：

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

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

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

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

Answer 1

免责声明：在谈论Sagas时，我们谈论的是NServiceBus传奇，我希望不会开始宗教讨论。 ：）

你应该定义两到三个传奇。一个用于电子邮件，另一个用于附件。

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

为什么这么多传奇？因为

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

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

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