问题标签 [integration-patterns]

我是消息传递和集成的新手。当我试图了解 Apache Camel 如何使 EIP 变得简单时，消息路由器引起了我的注意，它使用来自一个队列的消息并基于谓词传输到其他队列的特定场景。

以下是我的问题：

• 为什么使用消息路由器来执行此任务？
• 为什么不让消息 Producer 直接将消息发送到正确的 Queue/Destination？
• 为什么消费者不能依靠消息选择器来做同样的事情？

有人可以分享您对现实生活用例的看法吗？

我对 Camel (2.24.x) 比较陌生，我正在尝试在 Java DSL 中使用 AggregationStrategy，但有一些相关的问题/顾虑。另请注意，虽然我选择使用 Java DSL，但我也会接受 Spring Camel XML 格式的答案/解释，如果这是我能得到的最好的！

我正在尝试像“阀门”一样使用 AggregationStrategy，这意味着，收集/聚合入站交换，直到它确定它准备好将该聚合交换移动到路由的其余部分，但不允许任何交换/消息通过它，直到它下定决心。所以本质上，这个“阀门”（聚合器）是关闭的，直到它确定它已经充分聚合了 1 次以上的交换，然后一旦它做出这个决定，它就会“打开”。

要实现 AggregationStrategy 接口，准系统代码如下：

oldExchange 和 newExchange 分别对应什么？oldExchange 是否是我们正在聚合的消息，而 newExchange 只是我们可以（可选）附加到 oldExchange 的下一条消息？aggregate(...) 方法应该返回什么，oldExchange 还是 newExchange？或者是其他东西？！

然后，一旦我确定（在 aggregate(...) 方法内）是时候“打开阀门”了（例如，我们已经成功聚合 100%），我如何告诉 Camel 允许聚合交换通过到路线的其余部分？

提前感谢您提供全面的见解！

是否有 groupExchanges() 方法的替代品；根据最新的文档，这应该是可能的，但是我无法编译代码，因为该方法似乎已经消失了。

我有一项销售服务，它在确认销售时接受付款并引发事件。

我有一个订单服务，它使用这个事件并记录作为交易的一部分购买的所有东西。因此，在确认销售后不久，该购买信息最终是一致的。

这种架构的好处是销售服务对其有巨大的需求量，因此使其尽可能轻量级是理想的。

问题是......当确认销售时，销售服务需要知道已经购买了什么，然后才能为该客户进行任何进一步的交易。这是因为他们可以购买的物品数量等以及其他限制条件存在限制。它不能在任何时候依赖订单服务来提供此信息，因为处理订单时可能存在积压。

我可以通过让销售服务在确认销售后立即记录所有这些信息来解决这个问题，但是我会在销售服务中引入更多的逻辑和处理。除了编写事件之外，它现在还计算作为订单一部分购买的所有东西并将其全部推送到其数据库中。

有没有解决这些类型问题的模式？我是否实际上被迫让销售服务也了解如何处理和存储订单？

我正在处理一个消息请求，该请求将包含用于在目标中创建记录的完整请求详细信息。

这种集成在不同时间创建了 3 种不同类型的记录（订单、装运、发票），即并不总是可以一次创建所有记录，因此我需要让系统知道只创建某些请求。

我的问题，在请求中添加此信息的最佳方式是什么？

• 它是否需要在请求的正文中？

• 它需要在路径中吗？

• 它需要在单独的对象中吗？说

我在试图找出解决这个问题的方法时遇到了一些问题：我需要在 Apache Camel 上实现一个 DLC，但是当消息从我在 ActiveMQ 上的死信队列中出列时，必须比较它们中的每一个另一个 AMQ 队列上存在最新的按摩。

所以要明确：当 Camel 从 queue1（死信队列）消耗消息 M1 时，在尝试将其重新发送到某个路由之前，它必须将 M1（例如标头比较）与 queue2、M2 上的最新消息进行比较. M2 不会从 queue2 中移除（它也将用于下一次比较），而 M1 必须从 queue1 中移除。

我想了解这是否可行以及我缺少哪个 EIP 来实现这一点。