Camel splitter处理后如何防止聚集?
How to prevent Camel splitter from aggregating after processing?
我按以下方式设置了骆驼路线:
List<SomeRouteInfo> routes = getRouteInfo(); //I crete the routes using the info in the list.
for ( SomeRouteInfo info : routes ){
RouteDefinition routeDef = from(info.from());
routeDef
.errorHandler(someErrorHandler);
.routeId(info.getId());
if (info.someCondition()){
routeDef
.split().method(someSplitterBean)
.process(processorBean1) //The message seems split here.
}
routeDef
.process(processorBean2) //The message is no longer split here. I need it to be.
.to(info.to())
}
基本上,有些路线我希望分离器出现在其他路线上,而另一些则不需要。消息本身不存在是否拆分消息的信息。
所以,问题是当我在 processorBean1 中处理时,我似乎有多个消息。不幸的是,在 processorBean2 上我似乎没有相同的东西。相反,我得到了原始邮件正文。
我不希望拆分消息在 processorBean2 中因异常而单独失败,而不破坏其他所有内容。因此,出于这个原因,我希望它在 processorBean2 中成为单独的消息。我该怎么做才能做到这一点?
是的,Camel 文档中的 Splitter EIP returns by default the original message. This is explained at "What the Splitter retuns"。
我假设 Splitter 隐式地 "closed" 在 if
块中 routeDef
配置的末尾。
因此,您的路线实际上是这样的:
...
.routeId()
.split().method(someSplitterBean)
.process(processorBean1) // here you got splitted messages
.end // end splitter; from here you got the original message (before split)
.process(processorBean2)
.to(info.to())
因此,对于您的情况,您有多种可能性:
1:将 processorBean2
和 .to(info.to())
移动到拆分器 内。 IE。 processorBean1
正下方。这样拆分器仍然是 return 原始消息,但您不再使用它了。
.split().method(someSplitterBean)
.process(processorBean1) // here you got splitted messages
.process(processorBean2)
.to(info.to())
.end // end splitter; from here you got the original message (before split)
在您的情况下,您需要从拆分器开始,使路由的其余部分成为有条件的。
2:您将自己的聚合器策略添加到return,例如包含拆分消息而不是原始消息的集合。然而,拆分器只能return一条消息。所以you can't continue with the individual splitted messages after the splitter。您唯一可以获得它们的地方是分离器 内部 。
.split(method(someSplitterBean), new MyStrategy())
...
3:你将"split path"和"non-split path"(你的路线构建器中的条件)分成两个单独的子路线 并使 `.to([subroute]) 成为条件。
routeDef
.errorHandler(someErrorHandler);
.routeId(info.getId());
if (info.someCondition()){
routeDef.to("direct:mySplitRoute")
} else {
routeDef.to("direct:myStandardRoute")
}
这样你在两条路由中得到了一些冗余,但另一方面你得到了对(显然)不同消息类型的完全分离的处理。
我按以下方式设置了骆驼路线:
List<SomeRouteInfo> routes = getRouteInfo(); //I crete the routes using the info in the list.
for ( SomeRouteInfo info : routes ){
RouteDefinition routeDef = from(info.from());
routeDef
.errorHandler(someErrorHandler);
.routeId(info.getId());
if (info.someCondition()){
routeDef
.split().method(someSplitterBean)
.process(processorBean1) //The message seems split here.
}
routeDef
.process(processorBean2) //The message is no longer split here. I need it to be.
.to(info.to())
}
基本上,有些路线我希望分离器出现在其他路线上,而另一些则不需要。消息本身不存在是否拆分消息的信息。
所以,问题是当我在 processorBean1 中处理时,我似乎有多个消息。不幸的是,在 processorBean2 上我似乎没有相同的东西。相反,我得到了原始邮件正文。
我不希望拆分消息在 processorBean2 中因异常而单独失败,而不破坏其他所有内容。因此,出于这个原因,我希望它在 processorBean2 中成为单独的消息。我该怎么做才能做到这一点?
是的,Camel 文档中的 Splitter EIP returns by default the original message. This is explained at "What the Splitter retuns"。
我假设 Splitter 隐式地 "closed" 在 if
块中 routeDef
配置的末尾。
因此,您的路线实际上是这样的:
...
.routeId()
.split().method(someSplitterBean)
.process(processorBean1) // here you got splitted messages
.end // end splitter; from here you got the original message (before split)
.process(processorBean2)
.to(info.to())
因此,对于您的情况,您有多种可能性:
1:将 processorBean2
和 .to(info.to())
移动到拆分器 内。 IE。 processorBean1
正下方。这样拆分器仍然是 return 原始消息,但您不再使用它了。
.split().method(someSplitterBean)
.process(processorBean1) // here you got splitted messages
.process(processorBean2)
.to(info.to())
.end // end splitter; from here you got the original message (before split)
在您的情况下,您需要从拆分器开始,使路由的其余部分成为有条件的。
2:您将自己的聚合器策略添加到return,例如包含拆分消息而不是原始消息的集合。然而,拆分器只能return一条消息。所以you can't continue with the individual splitted messages after the splitter。您唯一可以获得它们的地方是分离器 内部 。
.split(method(someSplitterBean), new MyStrategy())
...
3:你将"split path"和"non-split path"(你的路线构建器中的条件)分成两个单独的子路线 并使 `.to([subroute]) 成为条件。
routeDef
.errorHandler(someErrorHandler);
.routeId(info.getId());
if (info.someCondition()){
routeDef.to("direct:mySplitRoute")
} else {
routeDef.to("direct:myStandardRoute")
}
这样你在两条路由中得到了一些冗余,但另一方面你得到了对(显然)不同消息类型的完全分离的处理。