这里有一个类似但更普遍的问题： Business logic in Camel processors vs service endpoints。
现在考虑以下流程（E1和E2代表处理器，它们不像骆驼流中的端点），我用参数（p，q）触发：
Route: E1 -> E2
E1 本身发出带参数（p，q）的HTTP请求，接收响应数据 d （同步）和转发这是 E2 ，它继续根据（p，q，d）进行处理。因此，它实质上丰富了输入和其他数据。
被调用的端点包含要集成的数据，即这不会改变，将来也不需要配置。
我尝试了两种解决方案，这两种解决方案对我来说都是错误的：
http4:url个端点并在消息的标头中备份（p，q）（或者交换的属性）。producerTemplate发送到http4:url时执行了此操作。第一个问题是它增加了许多样板制作器等，并使实际路线真的模糊不清。第二种方法允许将处理卸载到新类中（而不是将其混合到路由中），但仍然需要camel-context并依赖于此。
对此有何建议。除了更多抽象的陈述，如“不要将业务逻辑与布线混合”等等，我找不到任何东西。
*添加了实际用例*
E1获取两个日期（时间跨度）和一个部门名称，获取指定时间段内指定部门中的所有名称。然后（在上面我忽略了这个细节），名称被分割，并且对于每个名称，所有数据都被提取，这些数据已经保存在指定的日期范围内。对于最后一步，需要输入第一步的日期（因此需要通过整个路径）。
感谢， 马库斯
答案 0 :(得分：0)
感谢克劳斯：
无论如何，您可以丰富信息。骆驼并不在乎。如果你使用处理器/ pojo它只是java代码，你可以做任何你想要的。如果您使用enrich / pollEnrich DSL，那么他们使用AggregationStrategy来“合并”浓缩。
我通过http4：url端点的结果丰富了路由的原始输入。通过这种方式，我可以将数据的“获取”与实际业务逻辑分开，后者现在发生在独立于其余（特别是骆驼）的Processor / AggregationStreategy bean中。
感谢 马库斯