Check out this SlideShare Presentation:
View more presentations from Rafal Rusin.
Check out this SlideShare Presentation:
public class SimpleTest { public void setUp() throws Exception { TestRouter tr = new TestRouter(); ctx.addRoutes(tr); } @Test public void shouldCheck() throws Exception { ctx.createProducerTemplate().send("direct:in", getInOut("")); } class TestRouter extends RouteBuilder { public void configure() throws Exception { ((ProcessorType)from("direct:in") .setProperty("operation").xpath("local-name(/*)", String.class) .multicast(new MergeAggregationStrategy()) .to("direct:a", "direct:b", "direct:c") .end() .setBody().simple("${in.body}")) .bean(RequestEnricher.class, "enrich") .to("log:pl.touk.debug"); from("direct:a").process(new SimpleContentSetter("")); from("direct:b").process(new SimpleContentSetter("")); from("direct:c").process(new SimpleContentSetter("")); } } }What's unusual in this code is the fact, that what normally Camel does when you write a piece of DSL like:
.to("direct:a", "direct:b", "direct:c")is pass input to service a, than a's output gets passed to b, becomes it's input, than b's output becomes c's input. The problem being, you loose the output from a and b, not mentioning that you might want to send the same input to all three services. That's where a little tool called multicast() comes in handy. It offers you the ability to aggregate the outputs of those services. You may even create an AggregationStrategy that will do it the way you like. Below class, MergeAggregationStrategy does exactly that kind of work - it joins outputs from all three services. A lot of info about proper use of AggregationStrategy-ies can be found in this post by Torsten Mielke.
public class MergeAggregationStrategy implements AggregationStrategy { public Exchange aggregate(Exchange oldExchange, Exchange newExchange) { if (oldExchange.isFailed()) { return oldExchange; } transformMessage(oldExchange.getIn(), newExchange.getIn()); transformMessage(oldExchange.getOut(), newExchange.getOut()); return newExchange; } private void transformMessage(Message oldM, Message newM) { String oldBody = oldM.getBody(String.class); String newBody = newM.getBody(String.class); newM.setBody(oldBody + newBody); } }However nice this may look (or not), what you're left with is a mix of multiple XMLs. Normally this won't do you much good. Better thing to do is to parse this output in some way. What we're using for this is a Groovy :). Which is great for the task of parsing XML. A lot less verbose than ordinary Java. Let's assume a scenario, that the aggregated output, currently looking like this: is to be processed with the following steps in mind:
public class RequestEnricher { public String enrich(@Property(name = "operation") String operation, Exchange ex) { use(DOMCategory) { def dhl = new groovy.xml.Namespace("http://example.com/common/dhl/schema", 'dhl') def pc = new groovy.xml.Namespace("http://example.com/pc/types", 'pc') def doc = new XmlParser().parseText(ex.in.body) def pcRequest = doc."aaaa"[0] ["param1", "param2", "param3"].each() { def node = doc.'**'[("" + it)][0] if (node) pcRequest['@' + it] = node.text() } gNodeListToString([pcRequest]) } } String gNodeListToString(list) { StringBuilder sb = new StringBuilder(); list.each { listItem -> StringWriter sw = new StringWriter(); new XmlNodePrinter(new PrintWriter(sw)).print(listItem) sb.append(sw.toString()); } return sb.toString(); } }What we're doing here, especially the last line of enrich method is the conversion to String. There are some problems for Camel if we spit out Groovy objects. The rest is just some Groovy specific ways of manipulating XML. But looking into enrich method's parameters, there is @Property annotation used, which binds the property assigned earlier in a router code to one of the arguments. That is really cool feature and there are more such annotations:
In this post I’ll try to introduce Apache Camel component for Drools library – a great an widely used Business Rules Management System. When Read more