分布式消息排序
我有一个关于处理消息排序的架构问题。就这个问题而言，传输方式无关紧要，因此我不会指定传输方式。
假设我们有三个系统：一个网站、一个 CRM 和一个 ERP。为了这 例如，就数据所有权而言，ERP将成为“主”系统。 网站和 CRM 都可以向 ERP 发送新客户消息 系统。然后ERP系统添加客户并发布客户 使用新分配的帐号，以便网站和 CRM 可以 将帐号添加到本地客户记录中。这是一个漂亮的 直接的过程。
接下来我们继续下订单。帐号需要在 CRM 或网站向 ERP 系统下订单的订单。 然而，CRM 将允许用户下订单，即使 客户缺少帐号。 （对于这个例子，假设我们不能 修改 CRM 行为）这创造了用户可以 创建一个新客户，并在帐号获得之前下订单 在 CRM 中更新。
处理这种情况的最佳方法是什么？最好发一下吗 订单消息没有帐号并让它进入错误队列？ 让 CRM 端点保留消息并等待会更好吗？ 直到账号在 CRM 中更新？也许有什么 完全不一样，是我没想到的吗？
预先感谢您的任何帮助。
I have an architectural question on handling message ordering. For purposes of this question, the transport is irrelevant, so I'm not going to specify one.
Say we have three systems, a website, a CRM and an ERP. For this
example, the ERP will be the "master" system in terms of data ownership.
The website and the CRM can both send a new customer message to the ERP
system. The ERP system then adds a customer and publishes the customer
with the newly assigned account number so that the website and CRM can
add the account number to their local customer records. This is a pretty
straight forward process.
Next we move on to placing orders. The account number is required in
order for the CRM or website to place an order with the ERP system.
However the CRM will permit the user to place an order even if the
customer lacks an account number. (For this example assume we can't
modify the CRM behavior) This creates the possibility that a user could
create a new customer, and place an order before the account number gets
updated in the CRM.
What is the best way to handle this scenario? Would it be best to send
the order message sans account number and let it go to an error queue?
Would it be better to have the CRM endpoint hold the message and wait
until the account number is updated in the CRM? Maybe something
completely different that I haven't thought of?
Thanks in advance for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
CRM 系统应该有自己的帐号，供内部使用。这为您提供了一种在 ERP 系统创建主帐户之前处理订单的机制。 CRM 应用程序将 ERP 帐号作为其客户记录中的唯一密钥；基本上，CRM 帐号是合成密钥，ERP 帐号是业务密钥。
在此设计中，CRM 向 ERP 发送一条新客户消息和一条新订单消息。两条消息均发送 CRM 客户编号和空白 ERP 帐号。假设 ERP 系统只有一个消息队列，则通常的物理定律适用，因此 ERP 系统应该首先处理新客户消息；它会向 CRM 系统发回一条新帐户消息，将 CRM 客户编号与新的 ERP 帐号关联起来。 ERP 系统需要一个将其客户编号与 CRM 帐号关联起来的数据存储，以便它可以处理在发出 ERP 帐号之前发送的任何新订单消息。
如果您遇到新订单消息在处理新客户消息之前到达进行处理的情况，您将需要将其路由到待处理队列。当 ERP 系统处理新客户消息时，需要检查待处理队列。实际上，也许队列这个术语是错误的，因为 ERP 系统将快速浏览所有新订单消息，寻找与 CRM 客户编号匹配的消息。
The CRM system should have its own Account Numbers, which are used internally. This gives you a mechanism for processing orders before the ERP system has created the master account. The CRM app holds the ERP Account Number as a unique key on its Customer Record; basically CRM Account Number is a synthetic key and the ERP Account Number is a business key.
In this design the CRM sends a New Customer message and a New Order message to the ERP. Both messages send the CRM Customer Number and a blank ERP Account Number. Assuming the ERP system has just the one message queue the usual laws of physics apply so the ERP system should process the New Customer message first; it sends back a New Account message to the CRM system, tying the CRM Customer Number to a new ERP Account Number. The ERP system needs a data store which correlates its Customer numbers with the CRM account numbers, so that it can process any New Order messages which were sent before before it issued the ERP Account Number.
If you have a situation in which a New Order message arrives for processing before the New Customer message has been processed you will need to route it to a pending queue. When the ERP system processes a New Customer message then it would need to check the pending queue. Actually perhaps queue is the wrong term, as the ERP system is going to have riffle through all the New Order messages looking for ones which match that CRM Customer Number.
队列不太适合服务编排场景。我建议您研究 Cadence 工作流程，这将大大简化实施并提供对交互状态的全面可见性。
观看描述 Cadence 编程模型的此演示。
Queues are not a good fit for the service orchestration scenarios. I would recommend looking into Cadence Workflow that would greatly simplify the implementation and give the full visibility into the state of your interaction.
Watch this presentation that describes the Cadence programming model.
我想 CRM 对于新创建的客户有自己唯一的客户 ID。此 CRM 客户 ID 是 ERP 的外部密钥，它应该出现在 ERP->CRM 更新中，否则 CRM 无法关联和更新其自己的用户记录。如果这个假设正确，您可以在 CRM 和 ERP 之间放置一个中间人，该中间人可以保留没有帐号的订单在队列中等待，直到它捕获来自 ERP 的帐号更新。中间人将使用 CRM 客户 ID 将等待订单请求与帐号更新相关联，然后使用帐户 ID 丰富订单并将订单转发到 ERP。
如果订单在中间人队列中停留太长时间，则应将其移至错误/升级队列。
中间人可以在 CRM 或 ERP 或某些集成平台中实施。
I suppose CRM has its own unique customer id for the newly created customer. This CRM customer id is an external key for ERP and it should be present in the ERP->CRM update, otherwise CRM cannot correlate and update its own user record. If this assumption is right, you can put a middleman between CRM and ERP that keeps the orders without account numbers waiting in a queue, until it catches the account number update from ERP. The middleman would use the CRM customer id to correlate the waiting order request with the account number update, then enrich the order with the account id and forward the order to ERP.
If an order is stuck in the middleman's queue for too long, it should be moved to an error/escalation queue.
The middleman may be implemented within CRM or in ERP or in some integration platform.
难道你不能将“创建新客户并下订单”操作封装成一条消息，简单解构并在ERP系统中按顺序播放吗？因此，您将收到一条“创建新客户”消息、一条“下订单”消息和一条新的“创建客户并下订单”消息。
Could you not encapsulate the "create new customer & place order" operation into a single message that is simple deconstructed and played in sequence in the ERP system? So you'd have a "create new customer" message, a "place order" message and a new "create customer & place order" message.