Results 1 to 4 of 4

Thread: Retaining the original context / message

  1. #1
    Join Date
    Jul 2009
    Location
    Charlotte, NC
    Posts
    131

    Default Retaining the original context / message

    SI Gurus,

    My question is more towards retaining the message throughout the flow.
    My application is quite complex, with intermediate checks to different systems. Each requires its own format, and only when all checks are successful, I need to pass on the original message to downstream system.

    Lets say, we have 2 intermediate check systems, system1 and system2.
    Both expect some part (a subset) of the original message M1 (which I get after splitting the incoming request using an XPath splitter).

    system1 and system2 calls are webservice calls, and I need to build request object out of my original message, M1.

    My problem is, as soon as I send a request to system1, I loose the original message, which I need for my system2, and subsequently downstream system.

    I am using simple direct channels everywhere, and nothing complicated.

    Is there a way, where in I can access the original message in the next channel(s)? These should be available only if the response from system1 is favorable, else these need to be routed to an aggregator directly.
    Can the original message/context be passed in the header in every request (possible?) or are there any other cleaner alternatives?
    (I might be missing something straight here as well!)

    Let me know, if more details are required!

    Thanks

    Edit: Interceptor is an option, but this is something we want to avoid, as this is not a security check or something similar. The system1 and system2 calls are very much part of the application logic, and come into the normal flow.
    Last edited by GPS; Jun 1st, 2010 at 01:11 PM.

  2. #2
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    You can use ClaimCheck (http://www.eaipatterns.com/StoreInLibrary.html) pattern here and plug your own implementation of MessageStore or use one provided. For example there is a JdbcMessageStore implementation available.
    Upon message receive you use ClaimCheckTransformer to transform message to just a claim check while storing the entire message in the MessageStore.

    Every time you need a message all you need is to ask MessageStore.getMessage(id).
    Code:
    <int:channel="inbound-channel"/>
    <int:transformer input-channel="inbound-channel" output-channel="continue-channel">
    	<bean class="org.springframework.integration.transformer.ClaimCheckInTransformer">
    		<constructor-arg ref="messageStore"/>
    	</bean>
    </int:transformer>

  3. #3
    Join Date
    Jul 2009
    Location
    Charlotte, NC
    Posts
    131

    Default

    Quote Originally Posted by oleg.zhurakousky View Post
    You can use ClaimCheck (http://www.eaipatterns.com/StoreInLibrary.html) pattern here and plug your own implementation of MessageStore or use one provided. For example there is a JdbcMessageStore implementation available.
    Thanks, I think this is what I need. I will explore more.
    btw, is there any sample available as reference for the "one provided"?

    Also, if possible, can ClaimCheckInTransformer/ClaimCheckOutTransformer be included in the reference manual? I found this only today, that it was possible via SI!
    It might help someone else.

  4. #4
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    You can look at the test cases, but the config above should be sufficient. After ClaimCheckInTransformer the output Message will contain the payload which is message id + Message Headers so any time after you need to get a full message, you can either manually get it from the MessageStore (e.g., store.getMessage(payload)) or use ClaimCheckOutTransformer.

    Yes we'll update documentation.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •