I’ve talked in the past about releasing some code around Oracle BI and placing it into the open source community. Finally, that day has arrived.  I would like to introduce the Amelia Project. This is the first in most likely several open source projects from which we hope to garner the support of many within the Oracle Business Intelligence and Fusion Middleware (FMW) communities.  Project Amelia is free to use, free to learn from, and free to distribute. It is currently under the GPL License although we may switch that to the MIT or Apache license down the road.

Going forward the use of this application technique for security migration of FMW applications such as Oracle Business Intelligence 11g should be known as “Project Amelia”. That is,

• Question: “We need to migrate security from development to QA. How do we do that?”
• Answer: “That’s easy. Just use Project Amelia.”

Background

Without very clear direction on how to migrate the security from a source to target environment in Oracle BI 11g it was easy to attempt several manual approaches based on file migrations and other techniques.  All of these techniques required several steps and ultimately required manual intervention within the Enterprise Manager Fusion Control console to complete a proper source to target environment migration.  Even still, there was no clear view of the application roles, users, groups and especially not the relationship of assigned principals to applications roles.  Also lacking is a programmatic solution.  It is clear that the WebLogic Server’s use of MBeans is a great idea but it is not completely vetted for programmable access to manipulate application roles. Though the capability to programmatically manage users and groups via JMX does exist it could only provide half the solution to the problem when dealing with an application like Oracle BI 11g.

In the end the simplest solution is indeed the easiest.  Create a program that leverages the file based system-jazn-data.xml to parse out the application roles and its assigned principals to build an WLST (python) script that can then be executed in the target environment.  This WLST script is clean and provides an easy way to see what is being modified before it is executed.  The script can even be tweaked to eliminate certain executions against the target environment as well as to provide a change control script for changes made to each environment.

Use It

Shortly there will be a step-by-step guide, video, etc. on implementing the Project Amelia.  Right now the ReadMe file included with the project should suffice for advanced users. This is also a command-line only project for the moment.

Ultimately it boils down to:

1. Grab the source system-jazn-data.xml file (or locate it for reference if on the same machine)
2. Grab the Project Amelia JAR file from the /dist folder of the open source project
3. Run Project Amelia via command-line using > java -jar obiee11g_amelia.jar <arguments 1-6>
4. The output python (.py) file will be placed in the output directory defined in argument #2
5. Assess the .py script produced via Project Amelia (make tweaks, comment or uncomment commands, etc.)
6. Start the WLST console from the FMW oracle_common path
7. Execute (execfile()) or paste the script in the WLST console.
8. Verify the updates in the Enterprise Manager Fusion Control console

Download It

We mentioned it is open source so we have chosen to host the project on Github.  The project can be downloaded from,

https://github.com/artofbi/Oracle-FMW-Amelia

Wiki or Web Site

A base website for Project Amelia is currently under development to provide a quick reference, documentation, and home for the project.  As of now, the ArtOfBI.com will post any updates, faqs, etc. about the project until development is completed.

Anything It Doesn’t Help with for Security Migration?

Sudo, make me a sandwich!

That would be nice.  But Project Amelia is currently only assisting with the migration of Application Roles and Application Role to Principal assignments.  Although much more is in development, soon to be included features, not included in the initial release include:

• No Credential Store migration (this should be done manually anyway as a best practice)
• No Security Policy Migration
• No Security Policy Grants Migration
• No incremental diff/distinction (generates a full app role & app-role to principal assignment list each time)
• No validation of RPD groups against LDAP (i.e.: when upgrading from OBI 10g to 11g)

Other items to point out are:

• Users and/or Groups must be created or available for reference in advance of executing the resulting WLST script.  That is to say that if a user is to be assigned to a app role but the user or group is not listed in the LDAP configuration (WLS Embedded or other) then the grant will fail.
• App Roles Get Created by the script but will throw an error if the app role currently exists in the target system.

How Can I Contribute to this Project

Open Source projects are all about community, sharing, collaboration, contribution, and feedback.  If you use the tool, please at a minimum provide feedback via  comment to this blog post.  If you would like to contribute to the project, just let me know here, find me at OOW, email me your changes, etc.  I’ll make sure you get set up properly and get the credit you deserve.

Disclaimer

As of this writing, Project Amelia’s underlying Java code is not heavily documented per best practices or really any standard.  This product has not hit the version 1 major release and is really in a beta mode though it has been tested mainly with Oracle Business Intelligence based FMW environment and works exceedingly well, it does need to undergo several more testing stages before it can be officially promoted to a major alpha/GA release.  We hope to get your feedback from leveraging the tool so that we can refine the project in the upcoming weeks.  Any contributors will be properly acknowledge and given credit.

Compared to Some Other Existing Techniques

• RittmanMead Series
  • http://www.rittmanmead.com/2010/10/obiee-11gr1-security-explained-working-with-the-default-security-configuration/
  • http://www.rittmanmead.com/2011/04/oracle-bi-ee-11g-migrating-security-policy-store-part-2/
  • http://www.rittmanmead.com/2011/04/oracle-bi-ee-11g-migrating-security-credential-store-part-3/
• http://itnewscast.com/applications/migrating-security-policies-development-standalone-wls-11g
• http://jvzoggel.wordpress.com/2011/06/18/weblogic-security-realm-wlst-import-and-export/

I’ve been getting the question quite a lot lately about why the Oracle BI 11g client tools no longer includes the Catalog Manager application.  I have a very short list of reasons why I think the Oracle BI Dev Team removed this from the client tools installation.  At the top of that list is fact that Oracle BI client tools are there for development.  Specifically metadata modeling.  So, having the Catalog Manager which is really used only in the initial web catalog creation and for later migration purposes need not be at the whim of your standard Oracle BI metadata data modeler.

So, where does one get their hands on the Catalog Manager if they are only able to install the Oracle BI 11g client tools on their workstations.  Again, leave the Catalog Manager to your BI Administrator not your metadata modelers but if you need to get at the Catalog Manager it will be available with a full Oracle BI 11g Server installation.  And, what if you are running on a *Nix (Linux / Unix) environment?  How do you access it?  Must one have a Windows Server installation of Oracle BI 11g Server?

The answers to the those last few questions, in no particular order of emphasis are:

• No. You don’t need a Windows Server install of the Oracle BI 11g Server to access the Catalog Manager.
• If you are running a *Nix environment (highly recommended) you can access your Catalog Manager by connecting to your *Nix server via VNC.  If configured correctly this will give you a X-Windows graphical environment from which you can start the Catalog Manager by executing the ./runcat.sh command from the same path which the MS Windows version is launched (runcat.cmd).  I’ve tested this and it works very well.  You can even still open two Catalog Managers for legacy migration practices.

Another reason I think they dropped the Catalog Manager from the Oracle BI 11g client tools installation is that Oracle BI is moving towards a more scripted approach to creating and migrating core objects such as RPD Connection Pool information and Web Catalog objects, thus the integration of the “patching” concept which we all should be very familiar with in Oracle BI 11g at this point.  That was a long sentence, but if you want to see what I am talking about with the Catalog Manager patching and command-line options, take a look at my previous post on the topic here.

OBIEE 11g’s new graphing and charting engine defaults to Adobe Flash (previously Macromedia Flash) . This is fine and dandy as the rendering looks great and demos really well to clients.  I refer to it as the shiny spoon when relaying new features of OBI 11g to technical folks.  But, this offers a new paradigm for infrastructure administrators within an organization.  Basically all users of OBI 11g “must” have Adobe Flash installed on their browsers.  And, on each browser that they use.  Yes, that’s right, for those non-Flash educated readers.  Flash is browser compliant and must be installed on each browser individually.  So, for those corporations that lock down or push software to their corporate user base this may be a quick tug of war but ultimately as most of use know, Flash helps more than hurts, so this really isn’t a beefy argument at all is it?

So, where does that leave us? First, as an OBI implementer, make sure that everyone can either download and install flash on their respective browser(s) or an administrator can bulk push Adobe Flash to all users. Okay, now that that is done, let’s talk about some other options, (just in case the bulk release of Adobe Flash offends the distributive capabilities of your software administrator).
Read the full story