Hi there I'm pretty new to Java, camel, etc. Here's my problem:
I have code that passes an order containing order items and some other info in xml format from one camel Processor to another. This particular Processor then splits up the order and creates multiple orders, and then passes them all on to the next endpoint as separate messages.
Currently this Processor uses ProducerTemplate to explicitly accomplish this. I would like to move this behaviour to RouteBuilder itself and not use ProducerTemplate. I've looked at Splitter and MessageTranslator, but I don't have all the pieces yet I think.
So basically I want to split the message in the RouteBuilder using Splitter, but I want to supply custom code that will take the message, then deserialize it into an Order object, then create multiple Order objects, and then send them all as separate messages to the next endpoint. How do I accomplish this?
e.g. I want to be able to do something like
from("startPoint").split(MyCustomStrategy).to("endPoint")
//where MyCustomStrategy will take the message,
//and split it up and pass all the newly created messages to endPoint.
You can have a bean or processor in your route which creates the Order objects and returns them as a collection (e.g., List<Order> or similar). Splitter EIP can then be used to process each Order in that collection, one at a time by e.g. passing each order to another processor/bean that handles a single order, possibly continuing on to another endpoint as needed, etc.
// Pseudocode:
from(input).
to(bean-which-returns-a-collection-of-orders).
split(on-the-body).
to(bean-which-processes-a-single-order).
to(anywhere-else-needed-for-your-purposes).
// etc...
Or something along those lines; sorry, I use Spring DSL not Java DSL but camel docs show both. Here's some actual spring DSL code where a collection is being split to process each item in the collection:
<split>
<simple>${body}</simple>
<doTry>
<log message="A.a1 -- splitting batches for transfer" loggingLevel="DEBUG" />
<setHeader headerName="currentBatchNumber">
<simple>${body.batchNumber}</simple>
</setHeader>
<setHeader headerName="CamelFileName">
<simple>${body.batchNumber}.xml</simple>
</setHeader>
<log message="A.a2 -- marshalling a single batch to XML" loggingLevel="DEBUG" />
<marshal>
<jaxb prettyPrint="true" contextPath="generated.gov.nmcourts.ecitation"
partClass="generated.gov.nmcourts.ecitation.NMCitationEFileBatch"
partNamespace="EFileBatch" />
</marshal>
<log message="A.a3 -- xslt transform to add schema location" loggingLevel="DEBUG" />
<to uri="{{addSchemaLocationXsltUri}}"/>
<log message="A.a4 -- ftp now initiating" loggingLevel="DEBUG" />
<log message="ftping $simple{in.header.CamelFileName}" loggingLevel="DEBUG"/>
<bean ref="markFtpStatusOnTickets"/>
<to uri="{{ftpOdysseyInputPath}}"/>
<log message="A.a5 -- ftp now complete" loggingLevel="DEBUG" />
<doCatch>
<exception>java.lang.Exception</exception>
<handled>
<constant>true</constant>
</handled>
<bean ref="ticketExceptionHandler" method="handleException"/>
</doCatch>
</doTry>
</split>
Related
I'm bothered with returning an updated JSON, in fact, I receive a JSON defined as an opportunity (it's a business term, we don't need to explain it) from the cxfrs endpoint, convert it to String, then check the method invoked in jax-rs controller, if the we want make an update of Affair json, we publish the message as string in queue q.gestioncougar.cl.creation as described below:
<route id="serviceToCustomerLinksInboundRouting">
<from uri="cxfrs:bean:oab_serviceToObsIT?loggingFeatureEnabled={{gestioncougar.wscall.log.enable}}&loggingSizeLimit={{gestioncougar.wscall.log.size}}" />
<to uri="bean:log?method=info(*,'Body : ${body}')"/>
<convertBodyTo type="java.lang.String" />
<choice>
<when>
<simple>${header.operationName} == 'updateAffair'</simple>
<to uri="activemq:queue:q.gestioncougar.cl.creation?disableReplyTo=true" />
</when>
</choice>
</route>
The config of cxfrs service that is bonded to jax-rs controller:
<cxf:rsServer address="{{gestioncougar.service.in.obsit.url}}" id="oab_serviceToObsIT"
serviceClass="fr.oab.sie.esb.gestioncougar.customerLink.controller.CougarToCL" />
The JAX-RS controller:
#Consumes(MediaType.APPLICATION_JSON)
#Produces(MediaType.APPLICATION_JSON)
public interface CougarToCL {
#PUT
#Path("/updateAffair")
void updateAffair(String request);
}
Then we create a route that read from the queue q.gestioncougar.cl.creation, next unmarshal the body to POJO format (Java Model), moreover, read it by the method convertToCLFormat defined in the bean traiterCallFromCougar:
<route id="serviceToCustomerLinksCreationOutboundRoute">
<from uri="activemq:queue:q.gestioncougar.cl.creation" />
<!-- Sauvegarde du body initial -->
<unmarshal ref="formatJsonOpportunity" />
<!-- Sauvegarde du body -->
<setProperty propertyName="savedBody">
<simple>${body}</simple>
</setProperty>
<bean ref="traiterCallFromCougar" method="convertToCLFormat"/>
<to uri="bean:log?method=info(*,'CustomerLinks Body Format: ${body}')"/>
</route>
The method convertToCLFormat:
public void convertToCLFormat(Exchange exchange){
Opportunity opportunity = exchange.getProperty("savedBody",Opportunity.class);
EsbLogger.info(exchange, "opportunity {}", opportunity.toString());
exchange.getIn().setHeader(Exchange.CONTENT_TYPE, MediaType.APPLICATION_JSON);
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 200);
Affair affair = opportunityAffairMapper.toDealCL(opportunity.getDealCL());
String clBody = affairJsonParser.parsePojoToJson(affair);
EsbLogger.info(exchange, "affair {}", clBody);
exchange.getOut().setHeaders(exchange.getIn().getHeaders());
exchange.getOut().setBody(clBody);
}
and here is the problem !, even if I set the body with the newly mapped JSON defined as Affair, I don't see any change in postman response, but the body is changed when I check the log.
Take a look at the postman request:
Thanks a lot for your time and your help.
Do not put the converted JSON into the "out" message, but rather in the "in" one.
This was so confusing that they now recommend to simply use exchange.getMessage() (without any distinction whether in or out)
See more here:
https://camel.apache.org/manual/latest/camel-3-migration-guide.html#_getout_on_exchange
So this should work:
exchange.getMessage().setBody(clBody);
Looks like a weird issue or the docs are missing
Case 1
from("direct:ROUTE1").to("someAPI").to("direct:ROUTE2");
from("direct:ROUTE2").log("${body}"); // BODY is printing
Case 2
from("direct:ROUTE1").to("someAPI").to("direct:ROUTE2").log("${body}");
from("direct:ROUTE2").log("${body}"); // BODY is empty
Does adding log clear the exchange body??
As #Spara and #Claus suggested and to save the hassle on how to enable Stream caching.
Below is the sample code:
Using Java DSL for Single route
from("direct:ROUTER1")
.streamCaching()
.to("direct:ROUTER2");
Using Spring DSL for Single route
<route streamCache="true">
<from uri="direct:ROUTER1"/>
<to uri="direct:ROUTER2"/>
</route>
For global and per route scope using JAVA DSL
context.setStreamCache(true);
from("direct:ROUTER1")
.to("direct:ROUTER2");
For global and per route scope using Spring DSL
<route streamCache="true">
<from uri="direct:ROUTER1"/>
<to uri="direct:ROUTER2"/>
</route>
Note link: Camel Stream Caching
why stream caching
I have the following setup of camel routes:
<route id="firstRoute">
<from uri="..." />
<!-- This processor puts a list of items as the out body -->
<process ref="collectItemsProcessor" />
<!-- Now all items should be processed one by one: -->
<split>
<simple>${body}</simple>
<to uri="direct:secondRoute" />
</split>
</route>
<route id="secondRoute">
<from uri="direct:secondRoute" />
<process ref="itemProcessor" />
</route>
In the itemProcessor I want to count the number of items that were successfully processed by putting a property into the exchange:
exchange.setProperty("PROCESSED_ITEMS", exchange.getProperty("PROCESSED_ITEMS", Integer.class) + 1);
For some reason, on each call to the processor the property is null again. Documentation says:
The Exchange also holds meta-data during its entire lifetime stored as
properties accessible using the various getProperty(String) methods.
https://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/Exchange.html
When setting the property initially in the collectItemsProcessor, this value is kept. I suspect that the exchange is copied for each call to the split route, but how can I then really keep "meta-data during the entire lifetime"?
Split creates a new exchange for each item. The lifetime of this exchange only covers what is inside the split element.
If you only want a counter of the elements processed then simply use the property "CamelSplitIndex". The splitter automatically populates this property.
I am using doing integration work with Camel and using the HTTP endpoint as a proxy to route certain messages to an HTTP endpoint. I have my route configured to use my custom error handler which places failed messages in a queue that I specified (Dead Letter Channel pattern).
<route>
...
<to uri="direct:MessageTypeGuaranteed"/>
</route>
<route errorHandlerRef="MyCustomErrorHandler">
<from uri="direct:MessageTypeGuaranteed">
<to uri="http://dummyUri?throwExceptionOnFailure=true"/>
</route>
When anything fails to get delivered to my http endpoint, it's being added to my custom queue ("CustomFailedMessageQueue"), and I have a separate route that attempts to retry these messages:
<route>
<from uri="jms:queue:CustomFailedMessageQueue">
<to uri="direct:MessageTypeGuaranteed"/>
</route>
What I'd like to do is to be able to specify that I only want a message to live say for 10 seconds. So I am trying to set time to live on my http destination itself.
For example, I have a processor that does something like this:
exchange.getIn().setHeader(Exchange.HTTP_URI, "http://localhost/nodeserver?timeToLive=10000");
However, I think I have misunderstood the documentation. The timeToLive option is only valid when passing it to the jms component, correct? In other words, if I want to make use of time to live with this end point, I will need to do that handling myself in a processor, correct?
Yes TimeToLive is an option from the JMS spec that the Camel JMS components support. That options has no meaning for other components such as HTTP.
It seems like you may want to use a filter EIP and discard the message if its to old, and you can use a java method etc to implement some code that figures out if its to old or not, and return a boolean
public boolean isNotToOld(Exchange exchange) {
...
return true // to accept and process the message
}
See more about the filter eip here
http://camel.apache.org/message-filter
And you can use it in a route something a like
<from uri="direct:MessageTypeGuaranteed">
<filter>
<method ref="myBean" method="isNotToOld"/>
<to uri="http://dummyUri?throwExceptionOnFailure=true"/>
</filter>
From a logical perspective this is the kind of routing behaviour I wish to implement:
I want to be able to merge the response of an external service with the original request.
I have been able to implement this using multicasting, an aggregator, and a mock endpoint but I was wondering if there is a cleaner way. My current implementation looks like this:
<multicast strategyRef="serviceAggregator" stopOnException="false">
<to uri="mock:foo" />
<to uri="http://0.0.0.0:9999/service/?throwExceptionOnFailure=false" />
</multicast>
<camel:to uri="log:uk.co.company.aggregated?showAll=true" />
<to uri="http://0.0.0.0:9999/anotherService/
The part I particularly don't like is using a mock endpoint but I also don't think that this is a very readable way to express the above diagram. So I was wondering if there was a more elegant way of doing this?
I suggest to read about the EIP patterns, for example the content enricher
http://camel.apache.org/content-enricher.html
Where you can merge the reply message with the request message.
Mind the Content Enricher has 2 modes
- enrich
- pollEnrich
Make sure to notice the difference, from the docs in the link above.
<route>
<from uri="...">
<enrich uri="http://0.0.0.0:9999/service/?throwExceptionOnFailure=false" strategyRef="serviceAggregator"/>
<to uri="log:uk.co.company.aggregated?showAll=true" />
<to uri="http://0.0.0.0:9999/anotherService/>
...
</route>
And yes you diagram is showing splitter, but the sample code is using multicast EIP.
You could simply store the original message in a header or property and later do some merge in a bean. Using the header and the current body.
.setHeader("orig", body())
.to("externalService")
.bean(new MyMergeBean())