You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by mfrenzel <mi...@gmx.de> on 2016/05/19 12:59:33 UTC

Splitter EIP Best Practice

Hello everyone, this is my first post and I am seeking the opinion of more
experienced camel users.
In my route, I split up the content of a zip file and determine the
completeness of it`s content by using the aggregator EIP, which applies
certain business rules in it`s completion predicate. 
So far so good I think. After that I have to send individual REST calls for
each file contained in the original zip, so I split up again what has been
aggregated and set 
necessary http headers inside the splitters split method.

Here are my questions to you: 
first: when you need to determine (business rule) completeness of some data
items, but need those items as individual messages afterwards...is
aggregating to determine completeness 
and splitting up afterwards the way to go?
second: when splitting up merged data of some kind, is it bad practice to do
something else on the split up messages (i.e. setting http headers) while
you`re at it in the split method? 
I considered adding another bean/processor after the splitter to produce
mainly redundant code, that`s why I did it in the splitter.

thx for your time



--
View this message in context: http://camel.465427.n5.nabble.com/Splitter-EIP-Best-Practice-tp5782787.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: AW: Splitter EIP Best Practice

Posted by mfrenzel <mi...@gmx.de>.
Hi Thomas,

ad 1) That route and the use case behind it is not performance critical at
all. Right now I am already doing a hybrid of what you proposes. I split
from the zip, transform the data from something crude and proprietary to
Json and then aggregate to determine completeness and split and REST POST
after that. It`s just a couple of items, *once* a week. To sum this question
up, I will keep it the way it is. Parallelism may be introduced if the need
arises. 

ad 2) That thought came up purely for seperation of concerns and because I
caught myself wondering where in the the route I set those http headers
weeks ago. A simple rename of the splitter class will clear this up enough I
think.

Thanks Thomas!



--
View this message in context: http://camel.465427.n5.nabble.com/Splitter-EIP-Best-Practice-tp5782787p5782817.html
Sent from the Camel - Users mailing list archive at Nabble.com.

AW: Splitter EIP Best Practice

Posted by "Walzer, Thomas" <th...@integratix.net>.
Hi Mirco,

ad 1) If it saves you from duplicating code & you have no issues performance-wise: I would do it. It seems more logical (in my opinion).
If you need to check for completeness *before* doing any processing, I think that´s the only way to go. If you can allow for parallelism: split first & do you processing. Check for completeness afterwards and roll back if completeness check fails.

Ad 2) No.  Why would that be a problem?

Cheers, Thomas.

-----Ursprüngliche Nachricht-----
Von: mfrenzel [mailto:mirco.frenzel@gmx.de] 
Gesendet: Donnerstag, 19. Mai 2016 15:00
An: users@camel.apache.org
Betreff: Splitter EIP Best Practice

Hello everyone, this is my first post and I am seeking the opinion of more experienced camel users.
In my route, I split up the content of a zip file and determine the completeness of it`s content by using the aggregator EIP, which applies certain business rules in it`s completion predicate. 
So far so good I think. After that I have to send individual REST calls for each file contained in the original zip, so I split up again what has been aggregated and set necessary http headers inside the splitters split method.

Here are my questions to you: 
first: when you need to determine (business rule) completeness of some data items, but need those items as individual messages afterwards...is aggregating to determine completeness and splitting up afterwards the way to go?
second: when splitting up merged data of some kind, is it bad practice to do something else on the split up messages (i.e. setting http headers) while you`re at it in the split method? 
I considered adding another bean/processor after the splitter to produce mainly redundant code, that`s why I did it in the splitter.

thx for your time



--
View this message in context: http://camel.465427.n5.nabble.com/Splitter-EIP-Best-Practice-tp5782787.html
Sent from the Camel - Users mailing list archive at Nabble.com.