this would be achieved by creating BI Agents. BI Agents can run conditionally, based on the results of another analysis and the reports can be generated in pdf, excel etc etc format.
So not identical method but similar result.
Trigger tends to be a dirty word in Oracle DB circles....
"...replicate my current Cognos reports ..." very shaky foundation. Approaching in this way will bring failure.
What information is critical to the business, when is it needed and to whom should it go?
If you are just going to recreate Cognos reports - then all you've done is spend money and time.
Why excel output?
-further manipulation by users? <- introduction of errors and inconsistencies -- now you have an ungoverned asset
-outbound data sets or internal integration? <- OBIEE is not a data pump -- expensive and inefficient implementation; choose the proper tool
What would you suggest is "The proper Tool". I see this answer a lot on this forum though I've not seen anyone give recommendation?
Serious question, not goading just struggling to articulate without coming across as facetious.
I have been on a lot of projects with OBIEE....
At some point in every project you hear the words "I need to export 600,000+ rows"...
At this point my heart invariably sinks.
1. Export of large volumes is usually indicative of a 'cottage industry' where people spends large amounts of time manipulating data using desktop tools.
What is the point of buying a BI tool to do what you always did? If there is a valid business need for the processing then it should be done as part of an ETL process and the users should spend their limited time interpreting and acting on the results.
2. cf 1 - when people without less skills and less technology that IT professionals process large volumes of data they are more likely to corrupt it than collate it
3. cf 1 - the collation process is unlikely to be timely or reliable or corporately controlled
4. Some people think that they have to have 600,000+ rows of data to be able to see the picture. This is fallacious in extreme. What they need is a tool which reports in a timely fashion on exceptions and allows them to drill into limited subsets of data - the problem areas
5. "Formatted excel output" - why - because that is what they have always done
6. "Formatted excel output" - why - so they can 'correct' the numbers - note correct usually means amending data based on local knowledge with more up to date information. Again this is not correct, people have a reporting cycle for a reason, any corrections should be done in the source systems
In short, never mind a better way to perform a sub-optimal process, this is business ignorance not business intelligence!
a) Oh look another data dump thread! :-)
b) OBIEE and OAC are analytical platform tools. Not reporting. That's what Oracle has BI Publisher for. And BI Publisher has tons of bursting options. https://docs.oracle.com/middleware/12213/bip/BIPDM/GUID-A926D588-426F-47C7-8A9A-B0A7959C5814.htm
c) Applause for Thomas and Robert (without any sarcasm)
I've been away ... Robert Angel has hit most of the points ... basically it comes down to not having a BI Professional vetting requirements. If there is a true need for a dump - then do it straight from the database; run the subsequent analysis and tinkering AS A DISCOVERY PROJECT. At the end make the decision to either institutionalize the knowledge (EDW/BI front end) or scrap it due to little or no value found.
I fear we may be talking to ourselves, is that what happens when you try to stop someone using a screwdriver as a hammer? ;-)
Absolutely. Because they will just turn away, put their fingers in their ears, go la-la-la-la and keep screwdrivering away.