A colleague of mine asked recently if we had any <evil term alert>best practices</evil term alert> for BI Publisher, the latest and greatest reporting tool we use within Enterprise Manager (the old tool, Information Publisher, is of course also still supported but this post is relevant to BI Publisher). As you would well know if you’ve been following my posts or heard me presenting at conferences, <evil term alert>best practices</evil term alert> is a term I hate, so rather than using that term let’s discuss some tips and techniques that might be relevant to you when using BI Publisher.
Tip #1: Allocate Extra Memory
The amount of required memory for BI Publisher depends on a huge number of factors – complexity of reports, size of datasets being returned, BI Publisher scheduling load, etc. We recommend adding at least 1.5 Gb of RAM for the OMS machine, but you may need as much as 4-5 Gb depending on the factors just mentioned.
Tip #2: Configure BI Publisher on All Nodes Behind a Server Load Balancer
This one is not so much a tip as an actual requirement. If you are running Enterprise Manager in a HA configuration (i.e. behind a server load balancer), you have to have BI Publisher configured on all the servers behind the load balancer. If you don’t, you might find users get an error that BI Publisher doesn’t exist, which doesn’t lead to happy users. 🙂
Tip #3: Reissuing the “emctl secure wls” command
Again, this one is a requirement. If you have previously secured EM with an SSL certificate (and if you haven’t, why haven’t you!?) using the “emctl secure wls” command, and then you configure BI Publisher, you will need to reissue that command.
Tip #4: Deploying New Reports
Let’s say we have BI Publisher installed already, and then we decide to add an additional EM plugin that contains reports. Generally speaking, you will find that plugin deployment doesn’t deploy the new BI Publisher reports from Enterprise Manager to BI Publisher, so you will need to take care of that.
Tip #5: Changing the Out-of-Box Reports
This one is simple. Just don’t do this. 🙂 Do not extend or alter any of the out-of-the-box reports in the EM report catalog. The reason for this is simple – future patches may overwrite your changes, and you will have to manually add them back again. It’s much better to create a copy of the report, make your changes and then save it into a custom folder. We are looking at ways we can handle this for future releases, but until that happens just don’t do this.
Tip #6: Create Site-Specific Reports
As an addendum to the last tip, make sure to create your own site-specific reports in their own folders, and provide the relevant privileges to the different users, following the BI Publisher security model discussed in my earlier post here.
Tip #7: Plan your backup strategy
If you’re using an HA configuration, make sure to plan your backup strategy for both the config volume and the cluster volume. I posted a blog earlier about how to set up BI Publisher in an HA configuration, so make sure you have a look at that if you’re not familiar with that terminology.
Tip #8: Generate Sample Data
When you create a report, make sure you click the option to generate sample data. That gives you a great way to visualize the report layout, and it also makes sure that you can quickly determine you’ve requested the right data! 🙂
Tip #9: NFS Locking
If the WebLogic Server is not restarting after an unplanned machine failure, check whether or not it is due to an I/O exception that looks like this:
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent store "_WLS_server_1" could not be deployed: weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file "_WLS_SERVER_1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException: [Store:280021]There was an error while opening the file store file "_WLS_SERVER_1000000.DAT"
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11
You can find that by reviewing the server log files (in this case, BIP.out, BIP2.out, BIP3.out, etc.) Basically, this error occurs when the NFSv3 system does not release locks on the file stores. WebLogic Server maintains locks on files that store JMS data and transaction logs to prevent data corruption that can occur if you accidentally start two instances of the same Managed Server. You can find the resolution to this issue here.
And finally, if you insist on reading something that uses that <evil term alert>best practices</evil term alert> term, there are some guidelines in this presentation for BI Publisher generically. Note that this is generic, rather than for BI Publisher in an EM environment. It does, however, include a link to a sizing tool that might be of benefit to you.
Best of luck, and if you have any other tips and techniques for BI Publisher, feel free to post them as comments here for others to see!