'How much effort should I put into a apache Camel route versus just writing the logic in a Processor?

I've used Camel to do some message processing, to take a message from a source, massage it a bit, and send it on to some target.

But I'm trying to use it for a more complex use case and not sure if my approach is correct. Basically, I need to call a RESTful API and get a list of objects. For each object, I need to call another REST API that will also return a list of objects. I then need to loop over that list, and call another REST API based on that object. Given the results of that call, I'll either leave in or remove the object from the list. Once that is done, there is another REST call that returns another list. I then take data from the original REST call (the out loop object), combine it with the next level list object, and all the data from the last list. Once I get all that, I build up a JSON object and make yet another REST call.

I can image how to to this in code and it seems like it would be way simpler. Right now I am doing with several route. The first route makes the first REST call, unmarshals the JSON to a POJO, splits the message, and the sends the POJO to the next route.

I'm essentially using the routes like subroutines or function calls. Is that the right approach?



Solution 1:[1]

Yes, I believe you're on the right track. The use case you describe is a somewhat typical combination of Enterprise Integration Patterns (EIPs): the splitter, the aggregator, the translator, the filter, probably the enricher too.

These are where Apache Camel shines so yes, do use them. Putting all your logic inside a Camel Processor would beg the question: why even use Camel at all? Yes, it may sound like more work to write all this as Camel routes in the beginning, when you're not so used to the library yet. But pretty soon, I am sure you will see the added value and collect the rewards of those efforts. Just an example: when relying on Camel to do the splitting, deciding to have your individual records processed in parallel is just a handful of keystrokes away!

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Laurent Chabot