这里有一个类似但更普遍的问题：Business logic in Camel processors vs service endpoints .
现在考虑以下流程（E1和E2代表处理器，它们不是像camel流程中的 endpoints ），我用参数（p，q）触发：
Route: E1 -> E2
E1本身发出带参数（p，q）的HTTP请求，接收响应数据d（sync）并将其转发给E2，E2继续根据（p，q，d）进行处理 . 因此它实质上丰富了额外数据的输入 .
被调用的 endpoints 包含要集成的数据，即，这将不会改变，并且将来不需要配置 .
我尝试了两种解决方案，这两种解决方案对我来说都是错误的：
-
使用
http4:urlendpoints 并在消息头中搭载（p，q）（或者交换的属性） . -
使用显式/编程发出http请求的处理器，处理响应并转发预期的（p，q，d） . 为方便起见，我使用
producerTemplate发送到camel-context内的http4:url.
第一个问题是它增加了许多样板处理器等，并使实际路线真的模糊不清 . 第二种方法允许将处理卸载到新类中（而不是将其混合到路由中），但仍然需要camel-context并依赖于此 .
对此有何建议？除了更多抽象的陈述，如“不要将业务逻辑与布线混合”等，我找不到任何东西 .
*** added real use-case ***
E1获取两个日期（时间 Span ）和部门名称，获取指定时间段内指定部门中的所有名称 . 然后（在上面我忽略了这个细节），名称被分割，并且对于每个名称，所有数据都被提取，这些数据已经保存在指定的日期范围内 . 对于最后一步，需要输入第一步的日期（因此这些日期需要通过整个路径） .
谢谢，马库斯
1 回答
感谢克劳斯：
我通过http4：url endpoints 的结果丰富了路由的原始输入 . 通过这种方式，我可以将数据的“获取”与实际业务逻辑分开，后者现在发生在独立于其余（特别是骆驼）的Processor / AggregationStreategy bean中 .
谢谢马库斯