OBIEE 10.1.3.4.1 with Weblogic 11gR1 and SSO / OID

I know I haven't posted in a little while...it's just been the daily grind of work and life I suppose.

I'll be updating this post later to illustrate what we did to integrate OBIEE 10.1.3.4.1 with Weblogic 11gR1 and SSO/OID. Note, this changes the game, as we're not dealing with deploying the .WAR file to the old Oracle Application Server. MOD OSSO? Not quite! Weblogic 11gR1 changed the game a bit. Hence, some of the documentation on OBIEE is not quite up to date (heck, I think it has NEVER been rewritten since 2006???)

Expecting certain things to work as they used to with the old way to setup SSO and passing credentials to OBIEE? Well, they won't be exactly the same, and it sadly wasn't documented anywhere. Nobody in the Oracle forums, nor on metalink, nor on ANY blog I had seen posted any solutions. It is only a matter of time before it should be in the docs, as I know at least 3 clients of mine installed Weblogic recently and have OBIEE, and might consider SSO. I'll do what I can to cover the solution. Note to all, this was even more difficult because at my client, Weblogic was being installed and administered by another firm that was responsible for the security and web architecture setup. So we were at their mercy a bit, but they were helpful as well.

To leave you with one last bit before I write more in a later post, look at the diagram out of the documentation below. I refer to this as the 'MASTER' plan because it should be practically memorized by most OBIEE practitioners, considering it has all the default ports, applications, and so on. I highlighted the areas that should be of concern to you. It is primarily where the BI Presentation Services Plug-in Resides, and the communication with the BI presentation services themselves. Assuming you configured SSO correctly, and you've configured MOST of OBIEE correctly, and you've done what you feel is right and you get to the point where you see the infamous OBIEE server message "You are not logged in..." well that's where the stumper comes in. In a nutshell, you likely will miss 1-2 things here because weblogic passes the presentation services something it is not expecting. You will need to change a few things in your instanceconfig.xml file to accommodate this. OR, you can dive into Weblogic, and change a few things as well. I'll try to share more next time. We had to look at log file after log file to finally get this one right. Oh, and this was all pretty much on Linux, not that it matters much.




Anyway, at my client, a large pharmaceuticals and health care insurance/benefits management company, I got to run into quite a few more advanced issues.

For one, anyone that has ever read the beginner Ralph Kimball books on dimensional modeling might be familiar with the concepts of late arriving fact and late arriving dimensions. I can get into the gory details on that later, but suffice to say, they are rampant all over the place with the health care industry! A former colleague of mine was a data architect and ETL admin at a very large insurance company, and told me how common it was, and what a pain in the rear-end as well! Now, I got to see it first-hand, and realized it was VERY common, at least in that industry. It presents some unique architectural challenges for modeling and handling of the ETL. Not a terribly hard problem to solve, but nonetheless, a good experience to get under the belt within this industry that has so much late arriving data.

Why would the healthcare industry have so much late arriving data? Well, to summarize a few points, let us think about it. Think about ALL the data that has to go from 1 place to the next. Your employer had to send your details to an insurance company. The insurance company had so set you up in the system, and provide a temporary ID, maybe not even a real card yet. You go to the doctor and they file a claim, which is even more data exchanged. You may get a bill or invoice or just a notice that a claim was filed, but it might not even be a bill yet. Maybe 1 month later it is a bill and you need to pay your portion of it that insurance didn't cover. There could be differential diagnoses, multiple prescriptions, and so forth. Yes, the claim might be filed, and it might qualify as a FACT in your fact table, but the dimensional attributes such as a drug price, diagnoses, payments, addresses, and so much more might change after the fact table is joined to it's dimensional values on certain keys. Read more about it in the Kimball Data Modeling book to see a clearer picture.