GNUe Reports Proposal

Steps in the Process
 These are the general steps in the process. The flowchart (Figure 1) gives a graphical representation of the ideas here. 
1. Client submits report request to report engine 
•	 report definition selected 
•	 default or multiple defined (or none) 
•	 output defined (printer, file, webpublish, stream(print preview)) 
2. Report definition processed by report engine 
•	 report definition read 
•	 bizrules from report read 
•	 calls to gedi(libgda) used to receive data 
•	 data merged with specification of report definition 
•	 resulting xml file/stream created 
3. Notification returned to client 
•	 if no default just returns job done 
•	 if default then 
•	 resulting xml file/stream run through jade/xslt 
•	 desired format sent to output selected 
Archiving
 The idea is in large environments often times there is need for static reporting that needs to be archived for large periods of time. This gives you several options. 
Example 1. Monthly Archives
Monthly you could have a batch process run your financials and only create the xml output to disk. Then you could have a web application that on request would run only step 3. Which would run through Jade/XSLT and give html back, or if these reports were accessed frequently maybe that batch process autogenerate the HTML files or PDF for archival. 
Report Management
This report server not only gives you flexible reporting in a client,but gives you lots of archiving flexibility something larger entities are desparate for. This could be a larger part of a document managment / paperless system. As a client could request multiple outputs. 
Example 2. Law Firm Revisions
I am a law firm. I draft a legal document that needs to be submitted. So I throw a copy to the printer and choose to save to file as pdf. Then two days later I make a few edits and do the same. I now have a built in history of the files as I sent them to the client for approval not just the most current copy. Normally I would have to print in duplicate and file one copy. This model removes that manual print and store process. 
Performance
These are just ideas from a few of us loons. We realize performance may take a hit, but we see a lot of repeat reporting in our locations where we woudl see VAST improvement. 
Example 3. We All Need The Same Data
10 directors all want the same report. If we did in a client they all 10 hit the database for the report. (which is a large consolidation so rather intense). 
 The alternative is to pre-print the report and hand to each of them. This model woudl allow us to batch said reports and create static html for online viewing and other formats for printing if need be. We can then save these if we want for archivals. Thus instead of 10 intense queries we have 1 intense query that happens in the middle of the night in off peak hours. 
Supporting Documentation

Figure 1. GNUe Reports Flowchart
 
Authors
 This proposal was written by Derek Neighbors (<derek@gnue.org>) and Jade Meskill (<jade@gnue.org>). Please send all comments and suggestions regarding this proposal by sending an email to <info@gnue.org>.