Hi All
I am investigating overhauling our current batch queue process which runs as a _progress.exe and is kicked off via scheduled task in windows.
This process runs jobs synchronously one after another.
We are moving to a PAS /OERA architecture and i would like to move the batch queue into this as well.
My thoughts are that i could have an appserver or PAS instance to manage the queue which just has a startup procedure that continually monitors the queue tables in a loop and when it see's a request that needs to be run it passes the details off to a asynchronous process to run that report/process.
Would this work, Is this a good method and is there any examples out there?
Christian.
This won't work because if the startup doesn't finish the appserver keeps on the "STARTING" status, redering it useless. If I were you I would keep the _progress for looping the queue and and the appserver to do the actual work (iow the jobs which are on the queue). Make them execute asynchronously (on the appserver).
We have had this working in classic appserver for 15 years. You can just startup a second broker and then have a startup procedure connect to this second broker and run your batch queue logic async.
Now, in PAS that did not work. We worked with PSC (Mike Jacobs) and the ability to call scripts upon PAS startup were added. We never did implement as we decided to just use a prowin.exe session as that gave us access to use notify icons.
Thanks for the update. I have managed to model this with a GUI client running the batch jobs on the PAS async. I am now going to try this with an appserver as the controller / looper and the PAS as the executor.
why bother?
if your current method is working quite adequately, why change it? you don’t gain anything (at least you did not give any indication of gain), you are increasing your own workload, and you are adding risk (that the new implementation may have bugs or may not work as well as the old one).