Hi All,
I'm just coming to see what else is available for us to use.
We currently have a GUI system that uses an old CHUI back end and all the reporting on that system has come from that old (15-20 years old) system. It works but it relies on timers to loop round and pick up requests allocating them to queues etc...
I'm currently setting up a new system that starts from scratch and we need some way of producing reports from this.
N.B. When I say "producing reports" I mean the user will choose which report they want to run and enter the parameters on the front end, press "GO" (or whatever) and then an email will arrive in their inbox with the data (spreadhseet, pdf, etc...). Whilst the report is running nothing locks. You can still use the system. This currently works by just adding a record to the DB through the appserver with the report params in and then a separate back end system picks up the record and runs the report.
Is there another (easier, better, more advanced, more efficient, quicker, etc...) way of producing the same result?
We're currently using Progress 10.2B and (for now) we don't have anything like Sonic or ESB or anything. It may be something we get in the future and it may be able to do what I am looking for but for now I have the options of copy the setup currently used by the other system or create a new system that is easier to maintain (or better, faster, etc...).
We are literally starting from scratch with this system so any reports that are created will be brand new so there is nothing to worry about with conforming with old standards or compatibility with old systems etc...
If you can provide any pointers or any advice on where I can start looking it would be a great help!
Thanks very much!
Oliver
Not sure I understand what is it that you'll like to change... you already have a batch reporting solution and the only thing you are not happy with is that the reports are triggered by adding a record in a table while the batch process is watching/looping through it from time to time?
For similar, albeit not the same thing we've successfully used Quartz scheduler (http://www.quartz-scheduler.org/) with an ABL data store for scheduling reports, scheduling can also mean runt the report now and send it by email but ultimately there is still a record in a table and some long-pool mechanism runnig.
Hi,
Thanks for the reply.
It's not that I'm not happy with the current system. I just don't want to blindly copy it without looking at what could be possible aternatives.
The current system works and may well be the best option for us but I wanted to make sure I wasn't missing out on something else that may be better, easier, etc... before doing anything.
Given that I am starting from scratch there is no necessity to stick to any type of system so it's more of a query of what else there is rather than trying to get rid of the old system.
I hope that makes sense?
Thanks
That makes perfectly sense, if going through a major update might be some space for improvements... while you're happy with the current system may I ask what is the system using to produce reports (spreadsheets, pdf...)? Maybe you'll find some alternative options at that level
Otherwise of course a lightweight messaging solution can be envisaged to avoid the long-pool batch process, you might look into one of the Stomp adapters floating around and use ActiveMQ or any other open-source MQ that supports Stomp, that requirement alone won't justify the cost of Sonic I guess
The old system used to output CSV and formatted TXT files using standard Progress ABL.
We now use Prince PDF (I think) and some Office XML thingy to output to PDF and Excel XML files respectively but everything else (batching, running, compiling, queueing, etc...) is all done with Progress ABL.