Claim check as messages are being routed?

[nickspacek]

Hi folks,

Loving Spring Integration! I have a scenario where I am routing two messages based on the payload type to different channels. I want both to be claim-check-in before reaching the channel. What is the easiest way to do that?

I currently have the routing taking place in a chain and it would be nice to be able to send them through the payload-type-router, then through the claim-check, and then on to the output-channel the payload-type-router decided upon.

[objectamit]

I don't think Its possible and/or sensible to use any messaging endpoint after the router. Because after routing, the message is gone/routed. Here's I think I would do the same - place a header-enricher

<header-enricher>
<header name="payloadDatatypeHeader" expression="payload.class.name" />
</header-enricher>

and add an additional header with value as the class name of the payload.
Then do a

claim-check-in

and then use a

header-value-router

.

[nickspacek]

Alright, that'll work. I was fairly certain that an approach like you suggested was the only way to do it, but I wanted to make sure I wasn't missing something obvious or a slick way of solving the problem.

[Cleric]

Hello!

Well, there is some other workaround for you:

<channel-interceptor pattern="routing1, routing1, routingN">
	<beans:bean class="org.springframework.integration.transformer.MessageTransformingChannelInterceptor">
             <beans:constructor-arg>
                   <beans:bean class="org.springframework.integration.transformer.ClaimCheckInTransformer">
                        <beans:constructor-arg ref="messageStore"/>          
                  </beans:bean>
             </beans:constructor-arg>
        </beans:bean>
</channel-interceptor>

But I'd named it as "anti-pattern": it's breaks the main purpose of message-flow. I don't like any transformation of the payload in the interceptors.

I'd said you need: Routing Slip, but unfortunaly we don't have yet similar solution in the Spring Integration: https://jira.springsource.org/browse/INT-267.
So, you can vote it and may we pull this issue to the closer timeline.

Take care,
Artem