NServiceBus设计思路
有 NServiceBus 经验的开发人员/架构师能否提供以下方面的指导和帮助？
我们的业务要求（而且不是很多钱）在外部托管的应用程序和我们的内部 ERP（是的，不止一个）之间创建一个强大的接口。
当第三方应用程序中发生某些活动时，他们会向我们发送消息。即调用在消息等中传递各种信息字段的网络服务。我们无法控制也无法更改此第三方应用程序。
我的职责是创建此 Web 服务并将消息处理到每个 ERP 中。第三方规定了 Web 服务的外观，但不规定其负责的内容。我们必须接受，如果他们得到“成功”的回复，那么我们此时就对该消息承担责任！即我们需要确保尽可能接近完美，不会发生数据丢失。
这就是我对 NServiceBus 的使用感兴趣的地方。首先用它来存储/接受消息。此时我迷失了，我不知道应该发生什么，即遵循什么设计。另一台机器（进程）是否订阅并获取消息以将其处理到 ERP 中，如果是这样，因为每个 ERP 集成逻辑不同，我是否为每个 ERP 指定一个订阅者？然而，一条消息可能有两个目的地 ERP 目标，因此最好发送该消息而不订阅该消息。
显然，在整个设计中，我需要一些业务规则来帮助确定目标 ERP，然后制定业务规则来确定每个 ERP 中实际发生的情况。所以我也有一个关于 BRE 的问题，但这可以等待，尽管仍然可能是该消息必须执行的操作的驱动程序。
所以：
第三方>网络服务调用>存储消息（&返回成功）>确定目标 ERP >将每个处理到 ERP >将消息标记为完成
如果出现任何问题，请确保消息不会丢失。 ps MSMQ如何防止丢失，因为整机可能会死掉？这只是磁盘弹性等吗？
非常感谢您阅读过，甚至更感谢您提供任何建议。
Can any developers/architects with experience with NServiceBus offer guidance and help on the following?
We have a requirement in the business (and not a lot of money) to create a robust interface between an externally hosted application and our internal ERP's (yup, more than one).
When certain activities take place in the third party application they will send us the message. i.e. call a web service passing various fields of information in the message etc. We are not in control nor can we change this third party application.
My responsibility is creating this web service and the processing of the messages into each ERP. The third party dictates how the web service will look, but not what its responsible for. We have to accept that if they get a response back of 'success' then we at this point have taken responsibility for that message! i.e. we need to ensure as close to perfect no data loss takes place.
This is where I'm interested in the use of NServiceBus. Use it to store/accept a message at first. At this point I get lost, I can't tell what should happen, i.e. what design follows. Does another machine (process) subscribe and grab the message to process it into an ERP, if so since each ERPs integration logic differs do I make a subscriber per ERP? A message may have two destination ERP targets however, so is it best the message is sent and not subscribed to.
Obviously in the whole design, I need to have some business rules which help determine the destination ERP's and then business rules that determine what actually takes place with in each ERP. So I also have a question on BRE's but this can wait although still may be a driver for what the message has to do.
so:
Third party > web service call > store message (& return success) > determine which ERP is target > process each into ERP > mark message complete
If anything fails along the lines making sure the message does not get lost. p.s. how does MSMQ prevent loss since the whole machine may die ? is this just disk resilience etc?
Many thanks if you've read and even more for any advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这听起来像是 NServiceBus 的完美应用程序。
您的 Web 服务应该只解析来自第三方的请求并将其转换为 NServiceBus 消息，该消息应该是
Bus.Send()。在该消息到达总线之前，您不会以 200 状态代码进行响应，此时您要对此负责，并且 NServiceBus 的内置错误/重试和错误队列设施成为您最好的朋友。该消息应该由另一个端点接收，但它需要能够考虑重复消息或使用幂等性，这样重复就不会成为问题。如果第三方访问您的 Web 服务，并且消息已成功放置在总线上，但随后出现某些错误阻止他们接收 200 响应代码，您将从他们那里得到重复的消息。
此时，接收 MessageFromWebServiceCommand 消息的端点可以
Bus.Publish()包含命令数据的 SomeBusinessEventHappenedEvent。对于每个 ERP，创建一个订阅 SomeBusinessEventHappenedEvent 的附加端点，并使用您的业务逻辑来决定对该 ERP 执行哪些操作。在某些情况下，“某事”可能是“无”。这里也要记住幂等性，因为如果消息失败，它将重试。
由于 NServiceBus 和 MSMQ 对此类问题具有天然的弹性，因此您担心的所有其他事情（防止消息丢失，如果机器死机会发生什么）都将得到解决。
这是一篇博客文章，其中包括一个示例项目，展示了如何通过 Web 服务从外部合作伙伴接收消息并使用 NServiceBus 处理它们，以及直接指向 GitHub 上示例项目的链接：
This sounds like a perfect application for NServiceBus.
Your web service should ONLY parse the request from the third and translate it into an NServiceBus message, which it should
Bus.Send(). You don't respond with a 200 status code until that message is on the Bus, at which point, you are responsible for it, and NServiceBus's built-in error/retry and error queue facilities become your best friend.This message should be received by another endpoint, but it needs to be able to account for duplicate messages or use idempotence so that duplicates aren't a problem. If the third party hits your web service, and the message is successfully placed on the bus, but then some error prevents them from receiving the 200 response code, you will get duplicates from them.
At this point, the endpoint receiving the MessageFromWebServiceCommand message could
Bus.Publish()a SomeBusinessEventHappenedEvent that contains the command data.For each ERP, create an additional endpoint that subscribes to the SomeBusinessEventHappenedEvent and uses your business logic to decide what to do respective to that ERP. In some cases, that "something" may be "nothing". Keep idempotence in mind here too, because if the message fails it will be retried.
All the other things you're worried about (preventing loss of messages, what happened if machines die) will be taken care of thanks to NServiceBus and MSMQ being naturally resilient to such problems.
Here is a blog post, including a sample project, that shows how to receive messages from an external partner via a web service and handle them with NServiceBus, and a link straight to the sample project on GitHub: