Art of BI: Introducing Project Amelia – Easier Migration of OBI 11g Security
Christian Screen | | September 14, 2011
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.”
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.
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:
- Grab the source system-jazn-data.xml file (or locate it for reference if on the same machine)
- Grab the Project Amelia JAR file from the /dist folder of the open source project
- Run Project Amelia via command-line using > java -jar obiee11g_amelia.jar <arguments 1-6>
- The output python (.py) file will be placed in the output directory defined in argument #2
- Assess the .py script produced via Project Amelia (make tweaks, comment or uncomment commands, etc.)
- Start the WLST console from the FMW oracle_common path
- Execute (execfile()) or paste the script in the WLST console.
- Verify the updates in the Enterprise Manager Fusion Control console
We mentioned it is open source so we have chosen to host the project on Github. The project can be downloaded from,
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?
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.
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
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
It’s 2015 and you can now establish totally respectable MS SQL DBA credibility just by mentioning you have been in the game since SQL Server version 9. You may even get the same gasps of shock from some colleagues that used to be reserved for the version 6 veterans.