com. between application and persistence of messages.

[y.eurin]

hello,

i'm new with spring integration, i read everything i can, but there is 2 point still not clear for me :

1) if i have an application "full spring integration" who put message in a channel A, how a full "jms application" (not made with Spring integration) can access to the message ? i need to make a bridge or the channel can do the job ?

2) i'm searching a good way to persist message in database, except calling a service in a "service activator", is there any other solution ?

thanks you for your answer.

[Mark Fisher]

There are a few options for connecting to JMS Destinations. You can use inbound/outbound channel adapters or gateways (the latter if you need to accommodate bi-directional request/reply).

The best place to start is the reference manual:
http://static.springsource.org/spring-integration/reference/htmlsingle/spring-integration-reference.html#jms

There are also a couple JMS samples included in the distribution. The reference manual also describes how to setup/import the sample projects.

Hope that helps.
Mark

[iwein]

to your second question:
Try a ChannelInterceptor that persists before send and deletes after send. There are a couple of loose ends to tie, but it is possible to make that work.

[y.eurin]

thanks a lot, i understand better outbound and inbound now. And iwein, you right, the channel interceptor is a very good idea.

i ask a little more help about the delayer ?


my problem is, i need to send message in a particular point of time example between 2h pm and 3h pm

below you can see what i try to do, filterbouchon is setup to refuse every message.

there is something i do wrong, because i receive immediately in filterbouchon the message, even if i put a date object in the header "delaySMS", who is set at 25/12/2040.

maybe can you enlighten me for the delayer ?

thanks a lot.

--------------------------------------------------------------------
<channel id="channelA" />

<channel id="channelB" >

<channel id="channelC" >

<filter id="filter" input-channel="channelC" output-channel="channelA" method="refuseMessage" ref="filterBouchon" />

<beans:bean id="filterBouchon" name="filterBouchon" class="bouchon.FilterBouchon"/>

<delayer input-channel="channelA" output-channel="channelB" default-delay="9999999" delay-header-name="delaySMS" />

[Mark Fisher]

It seems like you might be able to design this with a poller using a cron-based trigger. That way you can define the exact time of day to poll. Are these messages arriving all day and you need to hold them until that processing window? Or, can you actually control when the messages are polled from their original source?

[y.eurin]

i couldn't control when the messages are polled from their original source, then i have no other choice to hold them until that processing window.

i'm searching a way to design my own bean, in order it to be triggered when the delayer do his job.

[Mark Fisher]

I still get the feeling that the 'delayer' is not the right tool for the job. It seems to me that you want to store the messages until the processing window. I would suggest letting the original Messages be sent to a JMS queue (therefore, persistent). You can use a Spring Integration JMS outbound-channel-adapter for that. Then, you can have a JMS inbound-channel-adapter with a poller. That poller could have the processing window configured as a cron trigger.

JMS would not be strictly necessary, since you could just as easily have a service-activator that stores what you need in a DB for the original Messages. Then a poller that retrieves that data during the processing window.

Or, if persistence is not important (depends on the app, but I would assume persistence is important), then you can just use a Spring Integration channel with a queue. Then you only need to consider the capacity of that queue in terms of the memory consumption.

One last suggestion: you could consider Spring Integration for storing the original Messages, but then using Spring Batch to process the data during the window.

I'd be interested to know if any of the above suggestions would fit your application's needs.