NServiceBus设计思想

Question

有NServiceBus经验的开发人员/架构师可以在以下方面提供指导和帮助吗？

在业务中，我们需要在外部托管的应用程序和内部ERP(是的，不止一个)之间创建一个健壮的接口(而且不是很多钱)。

当第三方应用程序中发生某些活动时，他们会向我们发送消息。例如，调用web服务，在消息中传递各种字段的信息等。我们无法控制，也不能更改此第三方应用程序。

我的职责是创建这个web服务，并将消息处理到每个ERP中。第三方决定web服务的外观，而不是它所负责的内容。我们必须接受，如果他们得到的回复是“成功”，那么我们在这一点上已经对这条消息负责了！也就是说，我们需要确保尽可能完美地不会发生数据丢失。

这就是我对NServiceBus的用法感兴趣的地方。首先使用它来存储/接受消息。在这一点上，我迷路了，我不知道应该发生什么，也就是说，设计遵循什么。是否另一台机器(处理)订阅并抓取消息以将其处理到ERP中?如果是，由于每个ERP集成逻辑不同，我是否为每个ERP创建一个订阅者？然而，一条消息可能有两个目标ERP目标，因此最好发送消息而不是订阅消息。

显然，在整个设计中，我需要一些业务规则来帮助确定目标ERP，然后需要一些业务规则来确定每个ERP中实际发生的事情。所以我也有一个关于BRE的问题，但这可以等待，尽管仍然可能是消息必须做的驱动程序。

所以：

第三方> web服务调用>存储消息(& return success) >确定目标ERP >将每个ERP处理成ERP>将消息标记为已完成

如果沿途有任何失败，请确保消息不会丢失。附注：由于整个机器可能会死掉，MSMQ如何防止丢失？这仅仅是磁盘弹性之类的吗？

如果你读过，非常感谢，更感谢你的任何建议。

Answer 1

这听起来是一个完美的NServiceBus应用程序。

您的web服务应该只解析来自第三方的请求，并将其转换为NServiceBus消息，该消息应该是Bus.Send()消息。直到消息在总线上时，您才会使用200状态代码进行响应，此时，您将对消息负责，而NServiceBus的内置错误/重试和错误队列功能将成为您最好的朋友。

此消息应该由另一个端点接收，但它需要能够处理重复的消息或使用幂等性，以便重复的消息不是问题。如果第三方访问了您的web服务，并且消息被成功地放置到总线上，但是随后的某个错误阻止了他们接收200响应代码，那么您将从他们那里获得重复的响应代码。

此时，接收MessageFromWebServiceCommand消息的端点可以Bus.Publish()一个包含命令数据的SomeBusinessEventHappenedEvent。

对于每个企业资源规划，创建一个额外的端点，该端点订阅SomeBusinessEventHappenedEvent并使用您的业务逻辑来决定对该企业资源规划分别执行什么操作。在某些情况下，“有”可能是“无”。这里也要记住幂等性，因为如果消息失败，它将被重试。

您担心的所有其他事情(防止消息丢失，如果机器死机会发生什么)都会得到解决，这要归功于NServiceBus和MSMQ对此类问题的自然弹性。

这是一篇博客文章，包括一个示例项目，展示了如何通过web服务接收来自外部合作伙伴的消息并使用NServiceBus处理它们，以及一个直接指向GitHub上的示例项目的链接：

• Robust 3rd Party Integrations with NServiceBus
  • Project Source Code on GitHub

​