Architecture Guidance Needed?

We are about to automate number of process for our reporting team. (The reports are like daily reports, weekly reports, monthly reports, etc..)

Mostly the process is like pulling some data from the oracle and then fill them in particular excel template files.

Each reports and so their templates are different from each other. Except the excel file manipulation, there are hardly any business logic behind these.

Client wanted an integrated tool and all the automated processes are placed as menus/submenus.

Right now roughly there are around 30 process waiting to be automated. And we are expecting more new reports in the next quarter.

I am nowhere to near having any practical experience when comes to architecuring. Already i have been maintaining two or three systems(they are more than 4yrs old.) for this prestegious cl开发者_高级运维ient.The possiblity of the above mentioned tool will be manintained for another 3 yrs is very likely.

From my past experience i've been through the pain of implmenting change requests to the rigd & undocumented code base resulting in the break down of the system and then eventually myself.

So My main and top most concern is the maintainablity.

When i was searching for these i came across this link, Smart Clients Using CAB and SCSF is the above link appropriate for my requirement?

Also Should i place each automated processes in separate forms under a single project, or place them in separate projects under a single solution..

Please correct me if have missed any other important information.

Thx.

---

We built a similar system many years ago. The system consisted of a main process and a series of Excel report generators that implemented a plugin architecture. Each report had its own report generator and could be generated on its own schedule, quite similar to how quartz and quartz.net handle scheduling (but this was many years before they were created). The plugin architecture was the key to the system, as new report generators could be created and dropped in dynamically.

The main process was in charge of launching/monitoring generators, listening for events that were triggered from generators, and distribution of all the reports. Distibution mostly consisted of FTP to a file server where reports could be viewed and saved from a web site. But we did also have some reports emailed to a distribution list.

The main database that stored all the report data also housed all the system meta data that informed the main process and the generators of the details of their work to be performed.

In our system all of the reports ran sequentially, mostly due to Excel limitations at the time. Assuming Excel is now capable of behaving itself, there's no reason that a new system couldn't be designed to run in paralel.

---

Why don't you replace the various Excel templates with a proper reporting solution? Using a decent reporting product has the following benefits:

• everyone can have access to the same report
• you can use roles to prevent people seeing certain reports
• the users can change the parameters of the reports every time they run it, or they can use the defaults you set up for them
• the reporting can be highly automated, it can run automatically on certain schedules (like 9am every Monday morning, or every Sunday evening after end of week processing)
• reports can be delivered in a variety of formats
• reporting tools can use stored procs in the database, those stored procs can encapsulate business logic

Personally i would advocate the use of Sql Server Reporting Services (2008 version, try and avoid 2005), although there are other products out there as well. SSRS can talk to an Oracle database, it can be obtained and used for free.

You also made vague references to "processes". The way i read this, you have some code running somewhere that pulls data out of the database, massages it somewhat, and places it in to some staging area - maybe the Excel spreadsheet is the staging area, and further reports are derived from that staged data. If my interpretation is correct, then the above mentioned reporting product (and possibly many others) remove the need to do this.