Tag Archives: Obiee

OBI already has a caching mechanism in presentation layer and BI server layer. How is the new in-memory caching better for performance?

Question:

OBI already has a caching mechanism in presentation layer and BI server layer. How is the new in-memory caching better for performance?

Answer:

OBI Caching only speeds up what has been seen before. An In-memory data structure generated by the summary advisor is optimized to provide maximum value by accounting for the expected broad usage and drilldowns. It is possible to adapt the in-memory data to seasonality by running the summary advisor on specific workloads. Moreover, the in-memory data is created in an analytic database providing maximum performance for the large amount of memory available.

OBIEE “Act As” vs “Impersonate”

There will come a point in the lifecycle of an OBIEE deployment when one user will need to access another user’s account. This may be to cover whilst a colleague is on leave, or a support staff trying to reproduce a reported error.

Password sharing aside (it’s zero-config! but a really really bad idea), OBIEE supports two methods for one user to access the system as if they were another: Impersonation and Act As.

This blog article is not an explanation of how to set these up (there are plenty of blogs and rip-off blogs detailing this already), but to explain the difference between the two options.

First, a quick look at what they actually are.

Impersonation

Impersonation is where a “superuser” (one with oracle.bi.server.impersonateUser application policy grant) can login to OBIEE as another user, without needing their password. It is achieved in the front end by constructing a URL, specifying:

  • The superuser’s login name and password (NQUser and NQPasword)
  • The login ID of the user to impersonate (Impersonate)

For example:

http://server:port/analytics/saw.dll?Logon&NQUser=weblogic&NQPassword=Password01&Impersonate=FSmith_FundY

The server will return a blank page to this request, but you can then submit another URL to OBIEE (eg the OBIEE catalog page or home page) and will already be authenticated as the Impersonate user – without having specified their password.

From here you can view the system as they would, and carry out whatever support or troubleshooting tasks are required.

Caution :  Impersonation is disabled by default, even for the weblogic Administrator user, and it is a good idea to leave it that way. If you do decide to enable it, make sure that the user to whom you grant it has a secure password that is not shared or known by anyone other than the account owner. Also, you will see from the illustration above that the password is submitted in plain text which is not good from a security point of view. It could be “sniffed” along the way, or more easily, extracted from the browser history.

Act As

Whilst Act As is a very similar concept to Impersonation (allow one user to access OBIEE as if they were another), Act As is much more controlled in how it grants the rights. Act As requires you to specify a list of users who may use the functionality (“Proxy users”), and for each of the proxy users, a list of users (“Target users”) who they may access OBIEE as.

Act As functionality is accessed from the user dropdown menu :

From where a list of users that the logged-in user (“proxy user”) has been configured to be able to access is shown :

Selecting a user switches straight to it:

In addition to this fine grained specification of user:user relationships, you can specify the level of access a Proxy user gets – full, or read-only. Target users (those others can Act As) can see from their account page who exactly has access to their account, and what level of access.

So what’s the difference?

Here’s a comparison I’ve drawn up

Here are a couple of examples to illustrate the point:

 

Based on this, my guidelines for use would be :

  • As an OBIEE sysadmin, you may want to use Impersonate to be able to test and troubleshoot issues. However, it is functionality much more intended for systems integration than front-end user consumption. It doesn’t offer anything that Act As doesn’t, except fewer configuration steps. It is less secure that Act As, and could even be seen as a “backdoor” option. Particularly at companies where audit/traceability is important should be left disabled.
  • Act As is generally the better choice in all scenarios of an OBIEE user needing the ability to access another’s account, whether between colleagues, L1/L2 support staff, or administrators.
    Compared to Impersonation, it is more secure, more flexible, and more granular in whose accounts can be accessed by whom. It is also fully integrated into the user interface as standard functionality of the tool.

Reference

Thanks to Christian Berg, Gianni Ceresa and Gianni Ceresa for reading drafts of this article and providing valuable feedback

Tips and Tricks for the OBIEE linux sysadmin

As well as industry-leading solution architecture, consultancy and training on Oracle BI, here at Rittman Mead we also provide expert services in implementation and support of such systems. In this blog I want to share some of the things I find useful when working with OBIEE on a Linux system.

OBIEE Linux start up script / service

Ticking both the OBIEE and Linux boxes, this script that I wrote is probably top of my list of recommendations (he says modestly…). It enables you to start and stop OBIEE using the Linux standard service command, integrate it into system startup/shutdown (through init.d), and also supports an advanced status command which does its very best to determine the health of your OBIEE system.

Start up

Shutdown

Status

You can get the script from the Rittman Mead public GitHub repository, or directly download the script here (but don’t forget to check out the README).

screen

GNU screen is one of the most useful programs that I use on Linux. I wrote extensively about it in my blog post screen and OBIEE. It enables you to do things such as:

  • Run multiple commands simultaneously in one SSH session
  • Disconnect and reconnect (deliberately, or from dropped connections, e.g. on unreliable wi-fi or 3G) and pick up exactly where you left off, with all processes still running
  • Share your SSH view with someone else, for remote training or a second pair of eyes when troubleshooting
  • Search through screen scroll back history, cut and paste
  • …a lot more!

There are other screen multiplexers such as tmux, but I’ve found that screen is the most widely available by default. Since they all have quite steep learning curves and esoteric key shortcuts to operate them, I tend to stick with screen.

SSH keys

Like screen, nothing to do with OBIEE per se, but an important part of Linux server security to understand, IMNSHO (In My Not-So Humble Opinion!).

Maybe I’m overly simple but I like pretty pictures when I’m trying to grasp concepts, so here goes:


  • You create a pair of keys using ssh-keygen. These are plain text and can be cut and pasted , copied, as required. One is private (e.g. id_rsa), and you need to protect this as you would any other security artifact such as server passwords, and you can optionally secure with a pass phrase. The other is public (e.g. id_rsa.pub), and you can share with anyone.

  • Your public key is placed on any server you need access to, by the server’s administrator. It needs to go in the .ssh folder in the user’s home folder, in a file called authorized_keys. As many public keys as need access can be placed in this file. Don’t forget the leading dot on .ssh.

Why are SSH keys good?

  • You don’t need a password to login to a server, which is a big time saver and productivity booster.
  • Authentication becomes about “this is WHO may access something” rather than “here is the code to access it, we have no idea who knows it though”.
  • It removes the need to share server passwords
    • Better security practice
    • Easier auditing of exactly who used a server
  • It enables the ability to grant temporary access to servers, and precisely control when it is revoked and from whom.
  • Private keys can be protected with a passphrase, without which they can’t be used.
  • Using SSH keys to control server access is a lot more secure since you can disable server password login entirely, thus kiboshing any chance of brute force attacks
  • SSH keys can be used to support automatic connections between servers for backups, starting jobs, etc, without the need to store a password in plain text

Tips

  • SSH keys are just plain text, making them dead easy to backup in a Password Manager such as LastPass, KeePass, or 1Password.
  • SSH keys work just fine from Windows. Tools such as PuTTY and WinSCP support them, although you need to initially change the format of the private key to ppk using PuTTYGen, an ancillary PuTTY tool.
  • Whilst SSH keys reside by default in your user home .ssh folder, you can store them on a cloud service such as Dropbox and then use them from any machine you want.
    • To make an ssh connection using a key not in the default location, use the -i flag, for example
      ssh -i ~/Dropbox/ssh-keys/mykey foo@bar.com
      
  • To see more information about setting up SSH keys, type:
    man ssh
    
  • The authorized_keys file is space separated, and the last entry on each line can be a comment. This normally defaults to the user and host name where the key was generated, but can be freeform text to help identify the key more clearly if needed. See man sshd for the full spec of the file.
    ssh4

Determining your server’s public IP / validating Internet connectivity

Dead simple this one – if you’re working on a server, or maybe a development VM, and need to check it has internet connection or want to know what the IP address is :

curl -s http://icanhazip.com/

This command returns just the IP and nothing else. Of course if you don’t have curl installed then it won’t work, so you’re left with the ever-reliable

ping google.com

Learn vi

…or emacs, or whatever your poison is. My point is that if you are going to be spending any serious time as an admin you need to be able to view and edit files locally on the Linux server. Transferring them to your Windows desktop with WinSCP to view in Notepad is what my granny does, and even then she’s embarrassed about it.

Elitism and disdain aside, the point remains. The learning curve of these console-based editors repays itself many-fold in time and thus efficiency savings in the long run. It’s not only faster to work with files locally, it reduces context-switching and the associated productivity loss.

Compare:

  1. I need to view this log file
  2. vi log.txt
  3. Done

with

  1. I need to check this log file for an error
  2. Close terminal window
  3. Start menu … now where was that program … hey fred, what’s the program … yeh yeh WinSCP that’s right
  4. Scroll though list of servers, or find IP to connect to
  5. Try to remember connection credentials
  6. Hey I wonder if devopsreactions has anything cool on it today
  7. Back to the job in hand … transfer file , which file?
  8. Hmmm, what was that folder called … something something logs, right?
  9. Dammit, back to the terminal … pwd , right, gottcha
  10. Navigate to the folder in WinSCP, find the file
  11. Download the file
  12. That dbareactions is pretty funny too, might just have a quick look at that
  13. Open Notepad (or at least Notepad++, please)
  14. Open file … where did Windows put it? My Documents? Desktop? Downloads? Libraries, whatever the heck they are ? gnaaargh
  15. Wonder if those cool guys at Rittman Mead have posted anything on their blog, let’s go have a look
  16. Back to Notepad, got the log file, now …… what was I looking for?
  17. Soddit

Silent Installs

This has to be my #1 tip in the Work Smarter, Not Harder category of OBIEE administration, and is as applicable to OBIEE on Windows as it is to OBIEE on Linux. Silent installs are where you run the installer “hands off”. You create a file in advance that describes all the configuration options to use, and then crank the handle and off it goes. You can use silent installs for

  • OBIEE Enterprise install
  • OBIEE Software Only install
  • OBIEE domain configurtion
  • WebLogic Server (WLS) install
  • Repository Creation Utility (RCU), both Drop and Create

The advantages of silent installs are many:

  • Guaranteed identical configurations across installations
  • No need to waste time getting a X Server working for non-Windows installs to run the graphical install client
  • Entire configuration of a server can be pre-canned and scripted
  • Running the graphical installer is TEDIOUS the first time, the second, third, tenth, twentieth … kill me. Silent installs make the angels sing and new born lambs frolic in the virtual glades of OBIEE grass meadows heady with the scent of automatically built RCU schemas

To find out more about silent installations, check out:

We’ve shared some example response files on the Rittman Mead public GitHub repository, or you can generate your own by running the installer once in GUI mode and selecting the Save option on the Summary screen of an installation. You can just run the installer to generate the response file – you don’t have to actually proceed with the installation if all you want to do is generate the response file.

opatch napply

I wrote about this handy little option for opatch in a blog post here. Where you have more than one patch to apply (as happens frequently with OBIEE patch bundles) this can be quite a time saver.

Bash

Bash is the standard command line that you will encounter on Linux. Here are a few tricks I find useful:

Ctrl-R – command history

This is one of those shortcuts that you’ll wonder how you did without. It’s like going through your command history by pressing the up/down arrows (you knew about that one, right?), but on speed.

What Ctrl-R does is let you search through your command history and re-use a command just by hitting enter.

How it works is this:

1) Press Ctrl-R. The bash prompt changes to

    (reverse-i-search)`':

2) Start entering part of the command line entry that you want to repeat. For example, I want to switch back to my FMW config folder. All I type is “co” to match the “co” in config, and bash shows me the match:

    (reverse-i-search)`co': cd /u01/dit/fmw/instances/instance1/config/

3) If I want to amend the command, I can press left/right arrows to move along the line, or just hit enter and it gets re-issued straight off

4) If there are multiple matches, either keep typing to narrow the search down, or press Ctrl-R to show the next match or Shift-Ctrl-R to show the previous match

Another example, I want to repeat my sqlplus command, I just press Ctrl-R and start typing sql and it’s matched:

(reverse-i-search)`sq': sqlplus / as sysdba

Finally, repeat the restart of Presentation Services, just by entering ps:

(reverse-i-search)`ps': ./opmnctl restartproc ias-component=coreapplication_obips1

time

If you prefix any command by time you get a nice breakdown of how long it took to run and where the time was spent after it completes. Very handy for quick bits of performance testing etc, or just curiosity :-)

$ time ./opmnctl restartproc ias-component=coreapplication_obis1
opmnctl restartproc: restarting opmn managed processes...

real    0m14.387s
user    0m0.016s
sys     0m0.031s

watch

This is a fantastic little utility that will take the command you pass it and repeatedly issue it, by default every two seconds.

You can use it to watch disk space, directory contents, and so on.

watch df -h

watch

sudo !!

Not the exclamation “sudo!”, but sudo !!, meaning, repeat the last command but with sudo.

$ tail /var/log/messages
tail: cannot open `/var/log/messages' for reading: Permission denied

$ sudo !!
sudo tail /var/log/messages
Sep 26 18:18:16 rnm-exa-01-prod kernel: e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Sep 26 18:18:16 rnm-exa-01-prod avahi-daemon[4965]: Invalid query packet.

sudo !!

What is sudo? Well I’m glad you asked:

xkcd sudo
(credit: XKCD)

Over to you!

Which commands or techniques are you flabbergasted aren’t on this list? What functionality or concept should all budding OBI sysadmin padawans learn? Let us know in the comments section below.

Sending OBIEE content to non-OBIEE users through agents

I often get to hear the following question concerning OBIEE agents:

"Why can't we send out personalized content (filtered data / row-level security) to non-OBIEE users by simply using their email address residing in the data?"


Killer answer: Security!

Think about it: If you use "Get Recipients from the Analysis used in the Agent Condition", it will actually perform a complete login with authentication + authorization through the security realm and only the fetch the data.

Now imagine that you bypass this "because it's so convenient to just have the email in the data". And now imagine me doing this:

update MYTABLE set EMAIL = 'uber.h4xx0r@somenastyplace.thief';
commit;


I think this should be answer enough as to why you do NOT want to be able to do this.
At all.

Custom style and skin in OBIEE 11.1.1.7