Timer Source Endpoint

[david_geary]

Hi,

I need a source endpoint that regularly places an xml message onto a channel (eg to call a web service and process the results at regular intervals).

Currently I'm doing this using an inbound file adapter ie

<si-file:inbound-channel-adapter id="timer_msg_file" directory="file:D:\test\timer_message" filter="myfilter">
	<poller max-messages-per-poll="1">
	<interval-trigger interval="3" time-unit="SECONDS"/>
	</poller>
</si-file:inbound-channel-adapter>
<si-file:file-to-string-transformer input-channel="timer_msg_file" output-channel="test_channel" delete-files="false"/>
	
<beans:bean id="myfilter" class="org.springframework.integration.file.PatternMatchingFileListFilter">
	<beans:constructor-arg value="MyRequest.xml"/>
</beans:bean>

But this seems a bit of a hack - particularly the way I can't use the filter attribute in the inbound-channel-adapter since this automatically applies the AcceptOnceFileListFilter which I don't want.

Is this the best way to do this for now and are there any plans to provide a better alternative? Ideally a quartz source endpoint (allowing database definition of jobs) would be nice but even a simpler one that allows you to easily specify the payload (xml would be a specific case) and interval would be better.

Thanks for any help

Dave

[david_geary]

I meant I'm not able to use the filter-pattern attribute as this applies the AcceptOnceFileListFilter.

[iwein]

yes, I think you might be better off using a generic inbound-channel-adapter (just pointing to a method on a bean). Could you create an issue for this linking back to the thread? I guess you're looking for something like:

<hartbeat payload-ref="aMessage" channel="aChannel">
  <interval-trigger ... />
</hartbeat>

where aMessage could be a prototype FactoryBean that creates your message. Hartbeat is probably a bad name, but I hope you get the point anyway.

[Grzegorz Grzybek]

Hi

Why don't you try Spring's scheduling features (quartz task executor, MethodInvokingJobDetailFactoryBean, CronTriggerBean and SchedulerFactoryBean)?

I had similar problems with integration (first Mule, then SI), but when I started to think, that invoking some processing in time intervals is not about "sending a message from some <i>time endpoint</i>" but simply about triggering, everything was much more elegant.

regards
Grzegorz Grzybek

[iwein]

Excellent point. I'd like to make sure that Spring Integration's polling mechanism can deal with this in an elegant way, but there is no reason why you couldn't push the message in through a gateway using a scheduling mechanism unrelated to Spring Integration.

In fact the tight coupling between my suggested <hartbeat/> and a SI channel isn't necessarily my brightest idea ever.

[david_geary]

OK - decoupling the scheduling mechanism is fine - and this would let us use quartz, but one of the main requirements is to be able to do this with just (simple) XML config. It seems very generic so it would be better to use something built into Spring Integration than write Java code - even if this is just a gateway interface.

[iwein]

That makes sense. I think this is something we will build on top of the new scheduling namespace that Mark is writing for Spring 3.0. If that is done we can see what is missing. Please make sure to create an issue for this if you want to make sure it gets some priority.

[Mark Fisher]

David,

I still think the simplest approach here is to use a Method-invoking inbound-channel-adapter:

<inbound-channel-adapter ref="someBean" method="someMethodThatReturnsThePayload" channel="x">
    <poller ... />
</inbound-channel-adapter>

Then, you can of course provide either an interval-trigger or cron-trigger within the poller element.

However, I guess what you prefer is to not require a method at all but point directly to a (presumably prototype) bean that represents the payload instead?

[david_geary]

Yes that works fine - its just that the bean in most cases would be very generic. In fact a bean with just a getter and setter for the payload would work and allow configuration of different payloads via the spring config (for XML / string payloads at least). So it just seems unnecessary to have to write a simple bean for this when something similar could be added to the framework and avoid the need to write java code. Currently virtually everything we need to do with Spring Integration (using XML messages) can be done without having to write java code.

[iwein]

Ah, too lazy to write code are we .

Just make sure that there is a JIRA issue for the things you like to see added to the framework. There is no guarantee that they will be implemented, but they will be tracked and decided on eventually.