instanceconfig.xml

Uncategorized

When upgrading existing customized installations of OBIEE to 11.1.1.7, one thing that you may run into is a subtle change in the usage of the vanilla style and skin of the application.

FusionFX has become the default, but isn’t immediately or better directly suited as a basis for your own custom style and skin.
The reason for that is, that FusionFX itself is only a subset of a full style+skin package and the vanilla application continues to use a lot of blafp.

Oh yes, /web/app/res also has become /web/appv2/res for some reason or another within Oracle_BI1, so here’s what you find in there:

A cursory glance at the folder contents of FusionFX and blafp side-by-side shows quite some differences already:

Whipping out out trusty Firebug and what an out-of-the-box applications actually renders, we see blafp used for the application header:

while we see FusionFX being the source for the dashboards themselves:

As most GUI customizations replace first and foremost the logos in the application header and then moving on to the look & feel of the dashboards and analyses, this logically means that adapting the default FusionFX will only get you halfway to your destination.

What you need to do, in order to have a full and complete basis for your own custom skin, which contains all files and artifacts while retaining the slick FusionFX look (it does look a lot leaner and nicer now), is to merge the two into one package. doing this couldn’t be any simpler than this:
1.) clone s_blafp and sk_blafp
2.) copy all the content of s_FusionFX and sk_FusionFX into the respective blafp folders, replacing all existing files

Since FusionFX is a modified subset of blafp, you’ll retain all base blafp files and gain the modified and “newer” FusionFX files which supersede blafp.

All you need to do now, is rename the resulting folders…

…push them to the /analyticsRes/ directory (or whatever directory holds the deployment of your custom style and skin), reference it in the instanceconfig.xml and, voila, you’ve got a complete and fully customizable 11.1.1.7 style and skin package.

Uncategorized

A while back our oraclenerd had a question about presentation server cache settings which he sent out through twitter.

rnm1978 and me answered to his distress call (emails not included. twitter’s quite useless for sending instanceconfig.xml subsets ;-)).

However, I wanted to make it clear through this post, what part of the presentation server cache is actually managed by which parameter since there’s a little gotcha in there.
So basically we there are four parameter which exist for the presentation servers instanceconfig.xml (see also Johns pdf extract). By default they’re not explicitly noted in the file so you need to specify them in order to change them. Here’s a little sample with already modified paths:

Now normally the cache files for the presentation server reside in the tmp directory within the respective subdirectories sawcharts, sawrptcache and sawvc; with the xml cache files lying in the tmp folder itself. Note that I cleaned out all files in the directory for in the screenshot below to have a clean testing baseline:

Restarting the presentation server with the additional XML above gives me the following results:

Chart cache:

Report cache:

State pool cache:

XML cache:

XML cache empty? Aha, seems there’s an issue. Let’s check the original path:

The XML cache files are still here. Not really what we wanted. So the XMLCacheDefault CacheDirectory seems to be useless. At this point I actually created an SR on MyOracleSupport to confirm a hunch I had. Result:
“With regards the parameter , I have researched this and have not found any documentation on it, internally or published. Infact through my research it appears that it has never been the case that this parameter is used to determine the path of the nqsxxxx temp files.
Previous versions of OBI i.e. Siebel Analytics document that the temp files generated by the Analytics Web server could be redirected by using the parameter ‘TempDir’ in Instance config or as a registry variable, in conjunction with the work directory path.”

So off to the NQSConfig.ini and change the WORK_DIRECTORY_PATHS:

#WORK_DIRECTORY_PATHS = “C:OracleOracleBIDatatmp”;
WORK_DIRECTORY_PATHS = “C:DataSourcesCachetmp”;
SORT_MEMORY_SIZE = 4 MB ;
SORT_BUFFER_INCREMENT_SIZE = 256 KB ;
VIRTUAL_TABLE_PAGE_SIZE = 128 KB ;

After that, restart all the services and check again where the cache files went.

Ok now we know how to make the rest of the cache files elsewhere.

Cheers!