-
1. Re: Integration Designer: Can I create a Composed Message Processor Pattern?
gseben Apr 22, 2009 3:42 PM (in response to aordin)Hi there,
I don't think you are doing anything wrong. As far as I can tell it's currently not possible to have multiple data connectors on the input of the Aggregator. I logged a bug for this issue UI-895 .
-Gio
-
2. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus Apr 23, 2009 12:26 AM (in response to gseben)Hi
When you use the content based router its enabled multiple outputs (in your case you have 3 different outputs).
The issue is that
- either of the 3 outputs can have their own route path with multiple EIP patterns as well. So after the HTTP you could also invoke another EIP for that particular "branch" of the route.
- but what you want is to continue after the content based router and for all 3 outputs to route to the Aggregator.
So the EIP designer should be able to route from the CBR to the Aggregator instead.
So the problem is that in your design you are only aggregating the "first branch".
What you can do to remedy this is to split into 2 routes and link using the direct component.
CBR -> http1 -> direct A
-> http2 -> direct A
-> http3 -> direct A
from Direct A -> aggregator
But ideally it should be, eg when the http1 ends it should continue with the => route path.
CBR -> http1 -> end
-> http2 -> end
-> http3 -> end
=> aggregator
This is early in the morning so you may have to excuse me if I did not make myself clear how to explain it. I am still on my first cup of coffee.
-
3. Re: Integration Designer: Can I create a Composed Message Processor Pattern
aordin Apr 23, 2009 3:17 AM (in response to davsclaus)Hi davsclaus,
thank you a lot for your response, but I have some doubts about.
In first time you say:
What you can do to remedy this is to split into 2 routes and link using the direct component.
CBR -> http1 -> direct A
-> http2 -> direct A
-> http3 -> direct A
from Direct A -> aggregatorDoubts about:
1.- I don't know which component is the "direct component" in the example is named like "direct A", I can't find it in the Eclipse plugin palette components.
2.- I think must be a visual distortion caused by the forum editor, but I supose the CBR connect in fist time to the 3 http endpoints, not only to http1. I'm right?
3.- You talk about reference to other EIPs, but this feature is not used here, right?
In second time, you say:
But ideally it should be, eg when the http1 ends it should continue with the => route path.
CBR -> http1 -> end
-> http2 -> end
-> http3 -> end
=> aggregator
Doubts:
1.- When you say "it should continue with the => route path". What do you mean? Put the "aggregator" in other EIP and reference it after each http end?
thank you again!
-
4. Re: Integration Designer: Can I create a Composed Message Processor Pattern?
aordin Apr 23, 2009 3:23 AM (in response to gseben)Thank you Gio,
but I'm not sure if is a issue, when you see at first time the Aggregator component is logic to think it may allow you to connect several inputs, but may be this use not is correct, may be the Aggregator component idea is to take the messages from a queue or something similar.
But I'm not sure, is only a suposition to explain this behavior.
-
5. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus Apr 24, 2009 1:30 AM (in response to aordin)Let me try again.
The aggregator can be attached to the route either at
1) after the http1
2) after the CBR
What you are doing is #1. As the http1 is an indivudual route you can do its own aggreagation, splitter, store to file, enrich, transform or whatever you like.
However you want to aggreagate the response from the CBR, the #2 instead.
So imagine that the CBR is a square box that can be collapsed so whatever its inside it is not visible. Then the route what you want to do is:
from -> CBR -> aggregator
Now imagine the CBR square box can be expanded, so we can look inside it. Inside we see the individual routes you have for your choices in the CBR. Each of these individual routes can route differently than each other and can have multiple EIP patterns (1..N).
So the idea is that at runtime that whenever a message is passing through the CBR it chooses one of the paths and is processed through the CBR path it chose. And when it reached the end of this individual path it continues after the CBR. And this is where it should go to the aggregator. As this allows that any of the choices in the CBR will afterwards all be routed to the same aggregator.
-
6. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus Apr 24, 2009 1:35 AM (in response to aordin)In the Integration Designer tool there should be a "source view" function.
What the designer basically do under the covers is creating the route path in XML notation, aka Spring XML that FUSE MR (Camel) understands.
In this source you should be able to see your route.
For instance to route as from -> CBR - aggregator
-
7. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus Apr 24, 2009 1:37 AM (in response to davsclaus)And this is another example where each of the individual routes also can have their own aggreagator
-
8. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus Apr 24, 2009 1:40 AM (in response to davsclaus)We can leverage the "direct" component in Camel to split routes into sub routes or generic routes that can be reused by others.
So we create 1 route for the CBR
-
9. Re: Integration Designer: Can I create a Composed Message Processor Pattern
oisin May 8, 2009 7:06 AM (in response to aordin)It's a bit late in the play, but I thought I would just follow up on some of the issues in this thread
@aordin is correct - the aggregator pattern is designed to aggregate messages, there's no explicit concession that it has multiple 'channels' of incomint messages. But the on-screen representation is a little counter-intuitive, it seems just to make sense that you aggregate multiple streams.
What @davsclaus is illustrating is a technique where you can simulate a 'join' of multiple exchange sources by having them meet at a direct: endpoint
The FID preview 1.1 doesn't have a direct: endpoint component, but it does have something in the palette named Generic, which will let you write the URL of your endpoint by hand. It's a way to make sure that as the tools tend to lag the runtime capabilities, you still get the power to express any endpoint component type supported by the runtime.
We'll be releasing an update to FID 1.1 that will let you graphically produce this usecase - it expresses @davclaus' solution by routing through the same direct: endpoint (although in this case the same direct: endpoint is represent by more than one box on the screen).
-
aggregator.gif 11.5 KB
-
-
10. Re: Integration Designer: Can I create a Composed Message Processor Pattern
davsclaus May 8, 2009 8:51 AM (in response to oisin)Oisin, looks cool.
May I suggest to sort the choice so Other is last. In the diagram you have:
- when
- other
- when
I suggest it should be
- when
- when
- other