OBIEE iBots & OBI Caching Strategy with Seeding Cache

One of the best features of OBI iBots (see previous post for iBot acronym) is that a user can perform a seeding cache against reports deemed to exceed a baseline query retrieval time. This would be only a portion of a full-blown OBI Caching Strategy but one that is often left out due to either the OBI Server Cache being turned off, global restriction of an iBot destination, or not being educated about the seeding cache.

Scenario & Solution

For example, if a dashboard contains two reports that take 10 minutes each to return their query and display their respective views this would be unacceptable query performance. If the reports have an SLA of 8am for when the executives arrive and view the dashboards each morning this is really a problem if the executives must wait 10+ minutes to see their dashboards. One immediate solution to this common scenario is to create an iBot using the Oracle BI Server Cache “Seeding Cache” destination option and schedule it to run an hour or so before nearing the breach of the SLA but clearly after any ETL/DW processes have run on the back-end which allow the dashboard reports to be update-to-date. If this iBot is created and scheduled to run at 4am then the report will execute in the background (10+ minutes) and the cache for that report will be saved to the server. Now when your executives arrive at 8am the dashboard will fire-up immediately as it will hit the cache and not need do a full retrieval against the source. Executives will be happy and you not only get to keep your job but there is talk of promotion. Yeah!

Drawbacks

Per the Oracle BI Documentation, the Seeding Cache functionality is that only of the OBI Server Cache.  It abides by all configuration settings established for the OBI Server Cache.  Therefore, if the OBI Server Cache is turned off your iBots attempting to use the Seeding Cache will not function properly.  That is server caching just won’t work.  In addition, the Seeding Cache functionality of an iBot is not directly related to the Presentation Server cache.  Therefore, the Presentation Server cache provides zero bearing on the Seeding Cache destination method.

The OBI Server cache also take up disk space.  The default path in the NQSConfig.ini file for the cache file system storage is set to [Installation Drive]:OracleBIDatacache. A default maximum of 500MB disk allocation is also set.  1/2 a Gig isn’t much on an enterprise server but you must remember that the processor has to write and read that physical space so you will take a hit there.  I could go on about this topic and I just may in another blog post but for now your should get the point and see how there is room for more discussion there.

Security

Since iBots are created via Presentation Services, providing users with the ability to create, publish, schedule an iBot may be a group permissions security model that a company already has in place. However, typically only a handful of users should have access to create an iBot using the “Seeding Cache” destination method.  Mainly this is already pre-structured for you as by investigation only Presentation Services Administrators have the ability to set the System Services destinations for an iBot.  There is no other option available in the Administration panel to set the System Services permission of Delivers.

Conclusion

There are several approaches to building a caching strategy within OBI.  It varies from organization to organization as do most technical strategies of this nature.   However, the pros of using the Seeding Cache destination method of OBI far outweigh the cons.  Just be sure to fully vet out the rationale behind using this strategy.