0

这里提出了一个类似但更普遍的问题： Camel 处理器中的业务逻辑与服务端点。

现在考虑以下流程（E1 和 E2 代表处理器，它们不是骆驼流程中的端点），我使用参数(p,q)触发：

Route: E1 -> E2

E1本身发出带有参数(p,q)的 HTTP 请求，接收响应数据d (sync) 并将其转发给E2，E2 继续基于(p,q,d)进行处理。所以它本质上用额外的数据丰富了输入。

被调用的端点包含要被集成的数据，即这不会改变并且将来不需要可配置。

我尝试了两种解决方案，这两种解决方案对我来说似乎都是错误的：

  • 使用http4:url端点并捎带消息头中的(p,q)（或交换的属性）。
  • 使用显式/以编程方式发出 http 请求、处理响应并转发预期(p,q,d)的处理器。为方便起见，我将producerTemplate其发送到http4:url骆驼上下文中。

第一个问题是它添加了很多样板生产者等，并使实际路线非常模糊。第二种方法允许将处理卸载到一个新类中（而不是将其混合到路由中），但仍然需要骆驼上下文并依赖于此。

对此有何建议。除了“不要将业务逻辑与布线混合”等更抽象的语句外，我找不到任何东西。

*添加了真实用例*

E1 获取两个日期（一个时间跨度）和一个部门名称，获取指定部门在指定时间跨度内的所有名称。然后（上面我忽略了这个细节）名称被拆分，并且对于每个单独的名称，所有数据都已保存在指定的日期范围内。对于这最后一步，需要来自第一个输入的日期（因此这些需要通过整个路线传递）。

谢谢，马库斯

4

1 回答 1

0

感谢克劳斯：

您可以随心所欲地丰富信息。骆驼真的不在乎。如果你使用处理器/pojo，它只是 java 代码，你可以做任何你想做的事情。如果您使用丰富 / pollEnrich DSL，那么他们使用 AggregationStrategy 来“合并”丰富。

我通过 http4:url 端点的结果丰富了路由的原始输入。通过这种方式，我可以将数据的“获取”与实际业务逻辑分开，这现在发生在独立于其余部分（特别是骆驼）的 Processor/AggregationStreategy bean 中。

谢谢马库斯

于 2013-10-04T08:10:07.183 回答