RE: Reporting - Casting about for ideas

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_at_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:
>> Jared.Still_at_radisys.com 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: jkstill_at_cybcon.com
>
>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: ListGuru_at_fatcity.com (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: john.kanagaraj_at_hds.com

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: ListGuru_at_fatcity.com (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).