Announcement Announcement Module
No announcement yet.
Timer Source Endpoint Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Timer Source Endpoint


    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"/>
    <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"/>
    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


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


    • #3
      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 ... />
      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.


      • #4

        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.

        Grzegorz Grzybek


        • #5
          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.


          • #6
            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.


            • #7
              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.


              • #8

                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 ... />
                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?


                • #9
                  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.


                  • #10
                    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.


                    • #11

                      So, I guess you are looking for something like this instead?:
                      <inbound-channel-adapter payload="somePrototypeBean" channel="x">
                          <poller ... />
                      Can you go ahead and add an issue via JIRA and then link to this thread?

                      In reality, I would most likely not use that approach above directly ("poller" does not make much sense in this context). It is more like a scheduled publisher. The new scheduling namespace in Spring 3 (I will be starting work on that today hopefully) will simplify this, but I could still see something more like this in Spring Integration:
                      <publisher payload="somePrototypeBean" channel="x">
                          <interval-trigger ... />

                      P.S. Iwein is just as lazy .... a great virtue IMO


                      • #12
                        Originally posted by Mark Fisher View Post
                        P.S. Iwein is just as lazy .... a great virtue IMO
                        I'm too lazy for a witty response even

                        I like the publisher suggestion. Being an actual pattern from the book it makes more sense to do this than to reuse an non fitting name (channel adapter) or something out of thin air (heartbeat). In fact we had something like it in an early milestone iirc, right Mark?


                        • #13
                          We had a @Publisher annotation (in a 1.0 milestone) for using AOP interception on existing methods. So it was similar, but still a bit different. The reason we deferred that is that the determination of payload from the MethodInvocation seemed like a great case for using EL. With Spring 3.0 as the base for Spring Integration 2.0, we will be re-adding that feature and likely enabling EL for that role. We should therefore consider these two features together:

                          1) AOP-interceptor-driven publisher
                          2) trigger-driven publisher


                          • #14
                            Thanks for the feedback on this - I've raised INT-650 for it. Both the publisher and new spring 3 scheduling namespace sound like good approaches that should provide what I'm looking for.