The claim check pattern is a bit more complex that. I will be touching
on it in my presentation at ApacheCon next week.
Cheers,
Hadrian
On 02/21/2013 06:26 PM, Christian Ohr wrote:
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
