Announcement Announcement Module
Collapse
No announcement yet.
Is it possible to have more than one <router> inside a <chain> ? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is it possible to have more than one <router> inside a <chain> ?

    Hi

    1) I would like to know if its possible to have more than one router inside a chain element ?

    For eg., is below possible?
    Code:
    	<int:chain input-channel="ersSvc2execSvcChannel">
    		<int:transformer ref="json2ObjTransformer" method="transformToERSOrchestrationSvcReq" />
    		<int:router expression="payload.messageHeader.reportInfo.rptEngineCode">
    			<int:mapping value="QMR" channel="QMRexecutionSvcReqMsgBuilderChannel" />
    			<int:mapping value="ACT" channel="ACTexecutionSvcReqMsgBuilderChannel" />
    		</int:router>
    		<int:router expression="payload.messageHeader.cbrInfo['executionCtxCode'].toUpperCase()">
    			<int:mapping value="ADH" channel="executionSvcSubmitAdhocReqChannel" />
    			<int:mapping value="RUN" channel="ersSvcSubmitNonAdhocReqChannel" />
    			<int:mapping value="SCH" channel="ersSvcSubmitNonAdhocReqChannel" />
    		</int:router>
    	</int:chain>
    If yes, then does it mean that the output from first router will be provided as input to the second router ?

    2) Secondly, is it possible to have a <header-enricher> insider a <router> element ?

    For eg., is below possible ?

    Code:
    	
    <int:chain input-channel="ersSvc2execSvcChannel">
    		<int:transformer ref="json2ObjTransformer" method="transformToERSOrchestrationSvcReq" />
    		<int:router expression="payload.messageHeader.reportInfo.rptEngineCode">
    			<int:mapping value="QMR" channel="QMRexecutionSvcReqMsgBuilderChannel" />
    			<int:mapping value="ACT" channel="ACTexecutionSvcReqMsgBuilderChannel" />
    		</int:router>
    		<int:router expression="payload.messageHeader.cbrInfo['executionCtxCode'].toUpperCase()">
    		        <int:header-enricher>
    			         <int:header name="MSG_REQ_MQ_PUB_SVCCODE" value="erx"/>
                            </int:header-enricher>
    			<int:mapping value="ADH" channel="executionSvcSubmitAdhocReqChannel" />
    			<int:mapping value="RUN" channel="ersSvcSubmitNonAdhocReqChannel" />
    			<int:mapping value="SCH" channel="ersSvcSubmitNonAdhocReqChannel" />
    		</int:router>
    	</int:chain>
    3) Lastly, is it possible to have <header-enricher> within the <int:mapping> of a router ?

    For eg., is below possible ?

    Code:
    	
    <int:chain input-channel="ersSvc2execSvcChannel">
    		<int:transformer ref="json2ObjTransformer" method="transformToERSOrchestrationSvcReq" />
    		<int:router expression="payload.messageHeader.reportInfo.rptEngineCode">
    			<int:mapping value="QMR" channel="QMRexecutionSvcReqMsgBuilderChannel" />
    			<int:mapping value="ACT" channel="ACTexecutionSvcReqMsgBuilderChannel" />
    		</int:router>
    		<int:router expression="payload.messageHeader.cbrInfo['executionCtxCode'].toUpperCase()">
    			<int:mapping value="ADH" channel="executionSvcSubmitAdhocReqChannel" />
    
    			<int:mapping value="RUN" channel="ersSvcSubmitNonAdhocReqChannel">
    		                  <int:header-enricher>
    			                       <int:header name="MSG_REQ_MQ_PUB_SVCCODE"  value="erx"/>
                                      </int:header-enricher>
                            </int:mapping>
    
    			<int:mapping value="SCH" channel="ersSvcSubmitNonAdhocReqChannel" />
    		</int:router>
    	</int:chain>
    Last edited by lbvirgo; Jul 10th, 2013, 07:46 AM.

  • #2
    H-m-m...
    No for all.
    Each component has its own responsibility. Don't mix concerns: it won't look like loosely-coupled architecture.
    I don't know how to convince you to follow with existing SI programming model (it's not your first strange post...) and don't try to reinvent the wheel.
    Please, read integration specific books:
    http://www.amazon.com/Enterprise-Int.../dp/0321200683
    http://www.manning.com/fisher
    Or, at least, SI Reference Manual: http://static.springsource.org/sprin...eference/html/

    Comment


    • #3
      Thanks.

      (it's not your first strange post...)
      I'm not sure what other "strange" post you are referring to. Probably you are referring to my post where I mentioned strange behavior from interceptors. I believe if I start getting a behavior other than what is expected from framework, it indeed should sound "strange".

      don't try to reinvent the wheel.
      I'm not. In fact I'm trying my best to use the already invented wheel.

      Or, at least, SI Reference Manual: http://static.springsource.org/sprin...eference/html/
      Believe me, I've never looked at any other doc other than the reference Manual while trying to understand concepts of SI.
      The only reason that I can think of for coming up with so-called "strange" posts is either the reference Manual is not detailed enough or the authors have assumed that readers should read between the lines.

      Anyway, many thanks again for clarifying on my queries.

      Best Regards
      LB

      Comment


      • #4
        the reference Manual is not detailed enough or the authors have assumed that readers should read between the lines.
        Almost
        If you read the Manual carefully, you saw this chapter: http://static.springsource.org/sprin.../overview.html
        From here you should understand, that RM is just a framework descripting document. But the EIP theory is somewhere in the another place - http://www.eaipatterns.com.
        Unlike Apache Camel or Mule, Spring Integration doesn't break any EIP principle.
        So believe me: after reading the EIP book I don't have any confused questions about architectural concepts of the Spring Integration.
        It is the best (canonical) implementation of EIP, it uses an existing ecosystem from Spring Framework, any adapters are based on best practies from most specific Spring projects (e.g. Spring AMQP or Spring Social) and there is no need to step aside from Spring, when you implement the business of your applications.
        Our main goal to make your (end-developers) day-to-day life easier: we try to provide out-of-the-box components to solve most specific tasks, e.g. Splitter-Aggregator, data ingestion from one system to another via just configuration of concrate components etc.

        Hope I'm clear

        Best Regards
        Artem

        Comment


        • #5
          Our main goal to make your (end-developers) day-to-day life easier
          Indeed and that is the reason we have chosen to go SI way instead of using the so-called famous Camel, Mule, etc frameworks.
          But the EIP theory is somewhere in the another place - http://www.eaipatterns.com.
          Thanks for it, i'll give my best effort to refer it but the tight project deadlines always keeps me away from it
          I've said this earlier and will be more than happy to say again, that the response I've been getting on this forum related to my queries [both "strange" and "not-so-strange" ] is awesome. The response are very quick, crisp and to the point.

          While we are doing this SI vs non-SI debate and while I'm still struggling to find some time in getting concepts of EIP, I will still be curious to know as to why "router" can be placed only as the last element in chain ? Why can't we have two routers ? Or why can't we have another component (say a service-activator) after router component ?
          Was it not possible to have output for router directed as input to the "subsequent" component in the chain ?

          And one more thing, more related to memory occupation of objects inside the heap :

          Is there any difference (not functionally but from respect of memory usage) between the two:

          Code:
          	<int:chain input-channel="transformationSvcSubmitAdhocReqChannel" output-channel="ersServiceResRcvPostValidationChannel">
          		<int:service-activator ref="transformationSvcRESTStub" method="executeReportJSON" />
          	</int:chain>
          vs

          Code:
          		<int:service-activator input-channel="transformationSvcSubmitAdhocReqChannel" ref="transformationSvcRESTStub" method="executeReportJSON" output-channel="ersServiceResRcvPostValidationChannel" />
          Is it an overkill to put a single component inside a chain ? I believe in the first case, a chain "object" might be getting created which probably is not required considering that there is just one component inside the chain, correct ?

          Best Regards
          LB
          Last edited by lbvirgo; Jul 11th, 2013, 04:25 AM.

          Comment


          • #6
            I will still be curious to know as to why "router" can be placed only as the last element in chain ?
            The router is some specific component (and pattern at all), how has several channels to output:
            http://static.springsource.org/sprin...g-chapter.html
            http://www.enterpriseintegrationpatt...ageRouter.html
            The <chain> is a 'black-box' for siries of MessageHandlers, who connect each other with some internal direct channel:
            http://static.springsource.org/sprin...ter.html#chain
            That's why the <router> isn't appropriate within the middle of <chain>, just in the end.

            Is there any difference (not functionally but from respect of memory usage) between the two:
            For archtecture concepts of messaging - no, there is no difference. Both configs are create the Endpoint and handles Message between input-channel and output-channel. The difference inside: the <chain> creates the container for handlers, who is a handler too: MessageHandlerChain. The top <service-activator> creates just a ServiceActivatingHandler.

            Is it an overkill to put a single component inside a chain ?
            In general no, there is no overkill. But for begginers we recommend do not to use <chain> at all. There is need some time to get used to SI central concepts: channel, message, endpoint.
            Do you agree with me, if you hadn't seen to the <chain>, you haven't got similar questions at all?

            Unfortunately I don't have enough time to have polemics, so my advice read more books and source codes

            Comment


            • #7
              Do you agree with me, if you hadn't seen to the <chain>, you haven't got similar questions at all?
              Indeed !

              Thanks for all the clarifications.

              Best Regards
              LB

              Comment


              • #8
                Just to drive home the point, any component after a router would be "unreachable" because, by definition, the router sends the message to one (or more) channels, which have to be outside the chain; there is no "else" on a router that "falls" past the router - the "else" is the discard-channel (if specified).

                Comment

                Working...
                X