Out of the box Oracle's caching strategy is to let cache exist for an unlimited amount of time. This is cleared out when the server is bounced. This is almost never an ideal situation, so there are two options, each is available for individual reports.
1) Turn off caching: With Caching turned off, users will always query the latest data from the source system. This is easy tom implement as it is one overall setting and one setting on each report. The downside is that while most of the prebuilt IA dashboards return in a reasonable amount of time, some trending reports do take a few minutes to aggregate all the data. With Cache turned off, users could wait for these reports to return every time they load a page. However, I have noticed very quick response time with the existing dashboards when no cache is available.
2) Caching reports: when reports are set to cache, OBI determines if the report has already been run, and if so, it uses the results from that previous run. This means that if User A runs a query for invoice 123 at 9AM, invoice 123 is entered into Oracle EBS at 10AM, and then User B runs a query for invoice 123 at 11 AM, they will return no results. The advantage here is that if nothing has changed within EBS, the user gets results instantaneously. The obvious disadvantage is that the user could get stale results, which may be problematic during month end close. If the report was never run by user A, then OBI will issue a new query for User B and that user will get "live", up to date results. The issue with this is that users do not know if other people have run a request, so they cannot determine whether a report returns up to date results.
The typically recommended approach is to turn off caching for all reports, and then as more people begin to take use OBI, turn caching on for specific reports for which it makes sense.
