HI Henryk,
A claim check EIP is definitely an excellent use case for a message store.
Regarding your example - it is probably a matter of taste, but I would rather
* register a (global) default message store with the CamelContext
rather than in the route
* allow all applicable EIPs to override this
* not set the CLAIM_CHECK header again (what for?)
One issue with such a claim check is that you should stay in control
about what is temporarily pushed to the store (e.g. the body, or a
specific header, or...). Later when you claim back the data, the
operation must be basically reversed. Then, who is in charge to
remember the destination - the claimCheck/claim EIP pair or the
developer? In the latter case, claiming back the data might look more
like applying a special expression....
...
// store and receive unique id in reserved CLAIM_CHECK header
.claimCheck(myStore, header('myBigHeader'))
...
// and claim back presenting the unique id
.setHeader('myBigHeader', claim(myStore))
...
Does this make sense?
cheers
Christian
2013/2/21 Henryk Konsek <hekon...@gmail.com>:
>> You are invited add, comment, criticize etc.
>
> Hi Christian,
>
> Looks good :) .
>
> I've added some examples to Wiki demonstrating my vision of the usage
> of Claim Check EIP.
>
> // Setting default message store for route:
> defaultMessageStore(myStore);
>
> // Claim Check EIP store:
> // 1) Store body.
> // 2) Set body to null.
> // 3) Set Exchange.CLAIM_CHECK header to unique claim id.
> from(...).claimCheck().to(...);
>
> // Claim Check EIP read:
> // 1) Lookup for the Exchange.CLAIM_CHECK header value.
> // 2) Read the message.
> // 3) Set body to the value fetched from the store.
> from(...).setHeader(Exchange.CLAIM_CHECK, const("id")).claim().to(...);
>
> I'm curious if my claim check DSL design is similar to yours.
>
> Best regards.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
