Have you tried a RESTy way of solving the problem ? I mean use HyperMedia as Engine or App State; create a file that embeds context information of what extent of processing has happened in each file; and pass that along in HTTP chains...Not paying much thought to detail here. Camel can the act as intelligent state parser (but should not maintain state) as well as router.
-----Original Message----- From: Iyer, Ramkumar (Cognizant) Sent: Wednesday, October 31, 2012 6:19 AM To: users@camel.apache.org Subject: RE: external scheduler integration I am familiar only with Quartz for scheduling. Why was it not an easy solution ? I remember (before getting introduced to CAMEL) storing the actual job to be processed as a bean in a trigger(along with a vector of future jobs to be processed after this job) and this job would be de-serialized from database and executed and a new job may be created in place. The algo basically was Scheduler wakes up; Fires DB job; Job Unmarshalls; Executes logic; Updates execution history; Points to next job How can this be done for external scheduler ? Will using a database solve this problem ? The above logic can be a CAMEL Logic. We used to run the above on cluster as most jobs were decoupled among themselves and acted on computing values on read only data? -----Original Message----- From: Christian Müller [mailto:christian.muel...@gmail.com] Sent: Wednesday, October 31, 2012 4:29 AM To: users@camel.apache.org Subject: Re: external scheduler integration We have similar requirements. An external scheduler (Tivoli) is used to trigger some batch processing (reading and processing large files). The trigger happens via HTTP and provides the file name which should be processed. After we finished the processing (multiple routes which are decoupled by queues) we have to return the HTTP call with a status code. Like 0 == OK, 1 == Error 1, 2 == Error 2, ... And of course, we have to stop the route... For this, we have implemented our own solution because this was not possible with a route policy (we need something like a "use case policy"). We use the Camel API to start/stop routes, to track inflight messages and whether they failed or not. Not an easy solution at this time... Best, Christian On Sun, Oct 28, 2012 at 4:48 PM, bung_ho <bung...@hotmail.com> wrote: > For various reasons it's not practical to use quartz etc to schedule my > routes, all the scheduling must be done using the corporate scheduler. I > have searched the forums and it seems all scheduler discussion is based on > the built-in quartz/cron etc. > > Anyway my idea to integrate with the external scheduler is simply to use a > <from uri="file: ..." /> that looks for a marker file that will be placed > by > the external scheduler, this will tell the route when to run. I figure > also, > the route can drop another marker file at the end to report success or > failure; the external scheduler can also be made to look for these files to > get the job status. > > Can anyone think of any drawbacks to this approach, or have any better > suggestions? > > Thanks > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/external-scheduler-integration-tp5721668.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful.
