10 Replies Latest reply on May 8, 2009 8:51 AM by davsclaus

    Integration Designer: Can I create a Composed Message Processor Pattern?

    aordin

      Hi,

       

      I want to create a  Composed Message Processor

      But in Eclipse I can't put more than one connections to "Aggregator" component.

      See the attached image to best undersanting (Name: composedMessageProcessor.jpg  , situated at the top of this message)

      You can see only one connection is possible between Aggregator and Endpoints. The other endpoints don't have any connection.

       

      Can someone tell me what I'm doing wrong?

       

      Thank you in advance.

        • 1. Re: Integration Designer: Can I create a Composed Message Processor Pattern?
          gseben

          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

            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

              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

                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

                  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

                    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

                      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

                        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

                          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).

                           

                          • 10. Re: Integration Designer: Can I create a Composed Message Processor Pattern
                            davsclaus

                            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