Jared, Have you looked at how Apps (yes, from our favorite vendor) provides reading of previously created report using the FNDFS listener? The APPLSYS.FND_CONCURRENT_REQUESTS table maintains the details of the report, and the FNFS listener pulls that out of the APPLCSF/out directory.
John Kanagaraj Oracle Applications DBA DB Soft Inc Work : (408) 970 7002 Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com ** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers ** >-----Original Message----- >From: Jared Still [mailto:jkstill@;cybcon.com] >Sent: Friday, November 01, 2002 9:00 AM >To: Multiple recipients of list ORACLE-L >Subject: Re: Reporting - Casting about for ideas > > > >Stephane, > >Yes, you have hit upon the crux of the problem. Generating >reports is easy, but managing the output is hard. I was hoping >to find that someone here had faced the same or similar problem >at some time. Doesn't look like it though. > >The idea for using a table with a BFILE sounds like it might be >a good start though. Manipulating the metadata for the report >output would be much easier in a table than trying to do so >by simply walking filesystem directory tree or working with a >flat file. > >Thanks, > >Jared > >On Friday 01 November 2002 00:43, Stephane Faroult wrote: >> [EMAIL PROTECTED] wrote: >> > Dear List, >> > >> > First, a little background. A coworker and I have been >charged with >> > developing and implementing a 'short term' 'Reporting Solution'. >> > >> > Glossary: >> > >> > short term: low cast, fast to implement, throw it away >late next year >> > >> > Reporting Solution: Some method to make it easy for users to >> > see oft run reports without re-running them on the production SAP >> > ( and other apps also ) systems. >> > >> > The goal of the 'Reporting Solution' is perceived performance. >> > Only 1 or 2 of these reports have any detrimental performance >> > impact on the servers. The goal is to allow users to view current >> > and historic reports ( up to 90 days ) without being required to >> > wait on reports to run on the application/database servers. >> > >> > This is partly political, partly user friendly. >> > >> > The political part is that we want to do *something* for users so >> > that it looks like we're taking their requirements to heart, even >> > though we don't have the resources to do much right now. >> > >> > The user friendly part is that we want to do *something* >for users so >> > that we can make their jobs a little easier, even though we don't >> > have the resources to do much right now. >> > >> > One idea we have is to have an ABAPer ( SAP programmer ) setup >> > the most requested reports to run in batch mode with a >specified range >> > of dates and whatever parameters are needed. >> > >> > This would be done periodically, the report output put on a network >> > filer or database or something accessible via browser ( no shared >> > drive type solution, access is to iffy ), and a web page >that would allow >> > simple navigation to reports by Category/Date. >> > >> > Click on the report, view your data. >> > >> > One thing that this is *not*, is a data warehouse and/or >data marts. >> > >> > This is to be a low cost solution. Some software OK, a >server is Ok >> > if necessary. The key is fairly easy and quick implementation. >> > >> > I'm open to any and all ideas you may have for this, >experiences doing >> > similar projects, etc. If it uses Oracle software, that's >cool, if not, >> > that's >> > cool too. Oracle is involved in any solution: at the very >least, that's >> > where >> > all our source data is stored. >> > >> > Thanks for reading this long winded message. >> > >> > Jared >> >> Jared, >> >> I like the idea of putting the reports on the intranet >much. I have >> done something similar some years ago with e-mails sent >automatically to >> give job status. It's easy to administer. The main problem I >see is the >> _identification_ of reports; if you can define a kind of >'primary key' >> for reports (dates - criteria (XMLized perhaps if there can >be a varying >> number of criteria) you can probably store a pointer (BFILE) to all >> available reports in some table, fill it with batch reports >and even - >> there always be somebody wanting that non-standard report - >run reports >> on-demand and make them available to the wide world. >> >> HTH, >> >> Stephane Faroult >> Oriole Software >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: Jared Still > INET: [EMAIL PROTECTED] > >Fat City Network Services -- 858-538-5051 http://www.fatcity.com >San Diego, California -- Mailing list and web hosting services >--------------------------------------------------------------------- >To REMOVE yourself from this mailing list, send an E-Mail message >to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in >the message BODY, include a line containing: UNSUB ORACLE-L >(or the name of mailing list you want to be removed from). You may >also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
