9.4. Claim Check

download PDF

Claim Check

The claim check pattern, shown in Figure 9.4, “Claim Check Pattern”, allows you to replace message content with a claim check (a unique key), which can be used to retrieve the message content at a later time. The message content is stored temporarily in a persistent store like a database or file system. This pattern is very useful when message content is very large (thus it would be expensive to send around) and not all components require all information.
It can also be useful in situations where you cannot trust the information with an outside party; in this case, you can use the Claim Check to hide the sensitive portions of data.

Figure 9.4. Claim Check Pattern

Claim Check Pattern

Java DSL example

The following example shows how to replace a message body with a claim check and restore the body at a later step.
from("direct:start").to("bean:checkLuggage", "mock:testCheckpoint", "bean:dataEnricher", "mock:result");
The next step in the pipeline is the mock:testCheckpoint endpoint, which checks that the message body has been removed, the claim check added, and so on.

XML DSL example

The preceding example can also be written in XML, as follows:
     <from uri="direct:start"/>
         <to uri="bean:checkLuggage"/>
         <to uri="mock:testCheckpoint"/>
         <to uri="bean:dataEnricher"/>
         <to uri="mock:result"/>

checkLuggage bean

The message is first sent to the checkLuggage bean which is implemented as follows:
public static final class CheckLuggageBean {        
    public void checkLuggage(Exchange exchange, @Body String body, @XPath("/order/@custId") String custId) {   
        // store the message body into the data store, using the custId as the claim check
        dataStore.put(custId, body);
        // add the claim check as a header
        exchange.getIn().setHeader("claimCheck", custId);
        // remove the body from the message
This bean stores the message body into the data store, using the custId as the claim check. In this example, we are using a HashMap to store the message body; in a real application you would use a database or the file system. The claim check is added as a message header for later use and, finally, we remove the body from the message and pass it down the pipeline.

testCheckpoint endpoint

The example route is just a Pipeline. In a real application, you would substitute some other steps for the mock:testCheckpoint endpoint.

dataEnricher bean

To add the message body back into the message, we use the dataEnricher bean, which is implemented as follows:
public static final class DataEnricherBean {
    public void addDataBackIn(Exchange exchange, @Header("claimCheck") String claimCheck) { 
        // query the data store using the claim check as the key and add the data
        // back into the message body
        // remove the message data from the data store
        // remove the claim check header
This bean queries the data store, using the claim check as the key, and then adds the recovered data back into the message body. The bean then deletes the message data from the data store and removes the claimCheck header from the message.
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.