OBIEE Free Tutorial
- tekslate
- Dec 20, 2014
- 3 min read
The most significant difference between Oracle Business Intelligence 10g and 11g, is:
the deployment to Oracle WebLogic Server,
and the integration of Oracle Business Intelligence with Oracle Fusion Middleware.
The administration is done using:
Oracle WebLogic Server Administration Console (Java Component) and Fusion
Middleware Control (non-Java components)
You no longer need to manually change configuration files for most administration tasks.
Central Configuration
Many configuration settings that affect repository development, including the default published repository, are now centrally managed in Fusion Middleware Control. You can no longer manually change these configuration settings such as the default ODBC DSN for the Oracle BI Server.
In Oracle Business Intelligence release 10g users and groups could be defined within a repository file using Oracle BI Administration Tool. In Oracle Business Intelligence release 11g users and groups can no longer be defined within a repository. Oracle Business Intelligence authenticates users and get groups using an Oracle WebLogic Server authentication provider against user information held in an identity store. In 11g any named user can be granted administrative permissions if desired. This compares to 10g where there was a single user with administrative permissions who was named Administrator.
Groups no longer exist in the repository as objects. Instead, you implement data access security based on the application roles to which a user belongs.
Application roles are managed in an external policy store. Application role objects exist in the repository, but these objects are pointers (references) to the externally managed roles.
Users are managed in an external authentication provider and are no longer managed in the repository. User objects exist in the repository, but these objects are pointers (references) to the externally managed users.
In Presentation Catalog, the Everyone group has been replaced with the AuthenticatedUser role
SA Subject System Area
Oracle BI Delivers now accesses information about users, their groups, and email addresses directly from the configured identity store. In many cases this completely removes the need to extract this information from your corporate directory into a database and configure SA Subject System Area to enable all Delivers functionality. SA System Subject Area is still supported for backward compatibility.
Systems Management API
The new BI Systems Management API Java programming interface includes a rich set of standards-based JMX MBeans to enable developers to automate administrative operations using Java and scripting technologies such as WLST (WebLogic Scripting Tool) and JPython. You can also use the BI Systems Management API to programmatically start and stop Oracle Business Intelligence. This feature is especially helpful for automating rolling restart of Oracle BI Servers in a cluster, to enable repository upgrade with zero end-user downtime.
Localization
This release introduces several enhancements for localizing your system, including:
lookup tables,
double column support
and alias tables: Often, members in Essbase cubes have separate aliases for each user
language to enable users to view member names in their own language. Typically, you define a session variable to dynamically select the appropriate alias upon user login.
Hierarchy Objects in the Presentation Layer
You can now define presentation hierarchies and presentation levels in the Presentation layer. These objects provide an explicit way to expose the multidimensional model in Oracle BI Answers and enables users to create hierarchy-based queries.
Presentation hierarchies expose analytic functionality such as:
member selection,
custom member groups,
and asymmetric queries.
support for Unbalanced (Ragged) and Skip-Level Hierarchies
Oracle Business Intelligence now supports:
unbalanced hierarchies (An unbalanced (or ragged) hierarchy is a hierarchy where the
leaves (members with no children) do not necessarily have the same depth.)
skip-level hierarchies (A skip-level hierarchy is a hierarchy where there are members that
do not have a value for a particular ancestor level. )
parent-child hierarchies. Parent-child hierarchies (also called value hierarchies) contain
members that all have the same type. For example, an organizational chart has a distinct parent-child hierarchy, but all members are employees hierarchies.
To Learn More Click On Below Link:
Comments