Several advantages using this approach are evident. Firstly, performance and efficiency. When using header enrichment, if message payloads need to be managed outside of the JVM that generates the enriched message header, the object will not be available unless it's serialised and transported around the distributed application. This could be costly in terms of performance and transport efficiency. The key factor here is the frequency of remote dispatch and the size of the header object. In specific circumstances the claim-check pattern may offer an advantage here, objects can be serialised and/or transformed into a storage specific format and stored internally in memory or externally in a data store.
Secondly, accessibility. It's conceivable that message payloads undergoing claim-check processing may need to be accessed by third party applications that are unable to receive Spring Integration messages. The claim-check pattern allows this type of processing to take place.
Thirdly, resiliency is offered. A data store can be chosen that guarantees persistence for messages in order that they can be recovered following failure.
The following code details how the claim-check pattern can be used:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:int="http://www.springframework.org/schema/integration" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration-2.1.xsd"> <bean id="simpleMessageStore" class="org.springframework.integration.store.SimpleMessageStore"/> <int:gateway id="claimCheckGateway" service-interface="com.l8mdv.sample.ClaimCheckGateway"/> <int:chain input-channel="claim-check-in-channel" output-channel="processing-channel"> <int:claim-check-in message-store="simpleMessageStore"/> <int:header-enricher> <int:header
name="#{T(com.l8mdv.sample.ClaimCheckGateway).CLAIM_CHECK_ID}" expression="payload"/> </int:header-enricher> </int:chain> <int:chain input-channel="processing-channel" output-channel="claim-check-out-channel"> <int:service-activator expression="new String('different string')"/> </int:chain> <int:chain input-channel="claim-check-out-channel"> <int:transformer expression="headers.get('#{T(com.l8mdv.sample.ClaimCheckGateway) .CLAIM_CHECK_ID}')"/> <int:claim-check-out message-store="simpleMessageStore" remove-message="true"/> </int:chain> </beans>
The gateway used is specified as the following Java class:
package com.l8mdv.sample; import org.springframework.integration.Message; import org.springframework.integration.annotation.Gateway; public interface ClaimCheckGateway { public static final String CLAIM_CHECK_ID = "CLAIM_CHECK_ID"; @Gateway (requestChannel = "claim-check-in-channel") public Message<String> send(Message<String> message); }
Lastly, this can all be tested by using the following JUnit test case:
package com.l8mdv.sample; import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.integration.Message; import org.springframework.integration.support.MessageBuilder; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import static com.l8mdv.sample.ClaimCheckGateway.CLAIM_CHECK_ID; @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration( locations = {"classpath:META-INF/spring/claim-check.xml"} ) public class ClaimCheckIntegrationTest { @Autowired ClaimCheckGateway claimCheckGateway; @Test public void locatePayloadInHeader() { String payload = "Sample test message."; Message<String> message = MessageBuilder.withPayload(payload).build(); Message<String> response = claimCheckGateway.send(message); Assert.assertTrue(response.getPayload().equals(payload)); Assert.assertTrue(response.getHeaders().get(CLAIM_CHECK_ID) != null); } }
What is the point of this line?
ReplyDelete<int:service-activator expression="new String('different string')"/>
Hi, your suspicion is well founded about this highly contrived step - it's not really necessary. It only really serves the purpose of showing that you can continue with alternate payload processing and that the claim-check header is available to be pulled back into the payload at any stage ready for a claim-check-out.
DeleteI've used this type of processing commonly for storing API request messages (or their claim-check id) in the Spring Integration message header whilst an API response message undergoes processing as the Spring Integration payload - this probably would have made a slightly more convincing example.