Thursday, June 12, 2014

OBIEE 11g : Using IFrame with OBIEE 11g

Using IFrame with OBIEE 11g
OBIEE 11g Object/Webpage embeding in dashboard


We can make use of HTML and Javascript very effectively when it comes to the UI customizations of OBIEE.

In this post I will explain about how we can use HTML <iframe> tag with OBIEE 11g for UI customizations.
An iframe is used to display a web page within a web page.
Syntax for iframe is,

                     <iframe src="URL" width="200" height="200"></iframe>

In OBIEE 11g we can use IFrame tag to in HTML code to display an object from within OBIEE such as analysis created, reports etc. or we can embed any webpage within dash board.

I have created a table which I need to display on my dashboard page using iframe.


To fetch the URL of this particular analysis I need to go to catlog and open this analysis.
On opening this analysis we get URL in browser address bar.



 We need to add this URL in iframe tag as follows,

Add text object in ‘IFrame Demo’ tab of Test dashboard. Add following script to dashboard and select ‘contains HTML markup’.

<iframe frameborder="0" MARGINWIDTH="0"  MARGINHEIGHT="0" scrolling="no" width="100%" height="1200"   src="http://slc02oky.oracle.com:7780/analytics/saw.dll?PortalGo&Action=prompt&path=%2Fshared%2FPrashant%2FIFrame_Demo_table"></iframe>

In src property we need to add URL of this particular analysis.

Now execute the dashboard.
On executing the dashboard, you will be able to see Child dashboard being merged into parent dashboard. But we do not wish to see the OBIEE header getting displayed with analysis.


To remove these links from embedded analysis add narrative view in analysis edit section and select ‘contains HTML markup’. Then add following script,




<script type="text/javascript">
var tds = document.getElementsByTagName('table');
for (var td = 0; td < tds.length; td++) {
if (tds[td].className != 'HeaderTopBar' && tds[td].className != 'HeaderSecondBar' ) {
continue;
}
if (tds[td].className == 'HeaderTopBar') {
var x = tds[td].parentNode;
x.removeChild(tds[td]);}
if (tds[td].className == 'HeaderSecondBar HeaderSecondBarPadding' || tds[td].className == 'HeaderSecondBar HeaderSecondBarMargin') {
var x = tds[td].parentNode;
x.removeChild(tds[td]);}
}
</script>

This script disables the header objects of child dashboard.

getElementsByTagName() method accesses all elements with the specified tagname.

'HeaderTopBar' and HeaderSecondBar' are the class names of header bars.
So using this javascript code we are disabling the header bars.

Run the dashboard and you will be able to see the analysis embedded within dashboard page.





Same way  we can embed a web page or web page object on dashboard.
In following example I am embedding http://www.bseindia.com/  on dashboard page.

<iframe frameborder="0" MARGINWIDTH="0"  MARGINHEIGHT="0" scrolling="no" width="100%" height="1200"   src="http://www.bseindia.com/"></iframe>



In this example we don’t need to add javascript to disable header.
Set width and height as per requirement.

Tuesday, June 10, 2014

OBIEE 11g: Object Level Security Implementation

Object Level Security Implementation


Object Level Security in OBIEE deals with access restriction to various OBIEE objects for different application roles and users.
Object level security controls the access to different objects based on user roles.

Object level security is achieved by granting or denying access to application role or user. The properties applied to application role gets  applied to all the users under it.
We have already seen the Application role, Groups and Users management in my previous post here.

We can restrict access to following objects using object level security,
        1.  Presentation Tables
        2.  Presentation table columns
        3.  Subject area
        4.  Reports
        5.  Dashboards
        6.  Dashboard Pages
        7.  Catlog Folders

If a user is a direct member of an application role, they will have access to the reports allowed by that application role. If a user is not a member of an application role, they will not have access to the reports allowed by that application role.

Object level security can be implemented at presentation layer of repository and web catlog.

Repository Level :

We can set object level security at repository on presentation layer.
We can grant/deny access to user/application roles to access subject area, table or column.

Object level security applied on columns is also called as Column Level Security.

In presentation layer go to properties of a subject area,table or column.
Select permissions.
Select ‘Show all users/application roles’
Here you can see all the users and application roles and properties such as read, read/write, no access and default.
You can set these properties as per your requirements and achieve object level security.




  


Web Catlog Level:

We can set object level security at web catlog level on folders, dashboards, dashboard pages and reports. User can only see object for which it possess authorization.
Similar to object level security on repository level, we can set permissions for application role or users.

Select any folder, dashboard, dashboard page or report.  
Go to its Permissions.

  

Here you can see the list of application roles/users and permissions set for them.
Following is the list of permissions we can set,


We can also set the custom permissions.


Following are the Permissions and their description.

Permission
Description
Read
Use this option to give authority to access, but not modify, the object.
Write
Use this option to give authority to edit the object.
Delete
Use this option to give authority to delete the object.
Traverse
Use this option to give authority to access objects in folders within the selected folder when the user does not have permission to the selected folder. For example, if you grant usersTraverse Folder permission to the /Shared Folders/Test folder, they cannot access objects in the/Shared Folders/Test folder but can access objects stored in lower-level folders, such as the /Shared Folders/Test/Guest folder.
Run Publisher Report
Use this option to give authority to read, traverse the folder that contains the object, and regenerate the report so that it includes the most recent data.
Schedule Publisher Report
Use this option to give authority to read, traverse the folder that contains the object, and schedule the report.
View Publisher Report
Use this option to give authority to read, traverse the folder that contains the object, and view, but not regenerate the report.
Execute
Use this option to give authority to run an object, such as an action, agent, or a briefing book.
Change Permissions
Use this option to give authority to change the object's permissions.
Set Ownership
Use this option to give authority to reassign ownership of the object.
Full Control
Use this option to give authority to perform all tasks (modify and delete, for example) on the object.
No Access
Use this option to deny access to the object. Explicitly denying access takes precedence over any other permission.
Modify
Use this option to give authority to read, write, and delete the object.
Open
Use this option to give authority to access, but not modify, the object. If you are working with an Oracle BI Publisher object, this option enables you to traverse the folder that contains the object.
Custom
Use this option to display the Custom Permissions dialog, where you grant read, write, execute, and delete permissions.
Granted
Use this option to give authority to access a section in a dashboard. This permission can be set in the dashboard, only. This permission overrides any catalog permissions set on the section's objects that would prevent the corresponding roles, Catalog groups, and users from accessing them (for example, No Access).
Denied
Use this option to deny access to a section in a dashboard. This permission can be set in the dashboard, only. This permission overrides any catalog permissions set on the section's objects that would allow the corresponding roles, Catalog groups, and users to access them.

Here we can see more options such as,

Apply effective permissions - It applies set permission to role/user.
Replace with parent’s folder permissions – It inherits the permissions of parent folder.



Apply permissions to sub-folders allows permissions to get applied on all sub folders under that folder.
Apply permissions to items within folders  allows permissions to get applied to the objects under that folder.



Also we can add more application roles and users as,




Relevant Links :


Monday, June 9, 2014

OBIEE 11g: Deploying & Developing a Custom Skin Part 2

Developing a Custom Skin


1.   Once the custom skin folder ‘analyticRes’ is deployed and tested successfully, we can create custom skin.

2.   To create custom skin we will copy one default skins, either blafp or FusionFX.
These skins are located at,

<ORACLE_HOME>/OracleBI1/bifoundation/web/app/res 

3.   We will copy ‘FusionFX’ skin for our development.
We can see 2 forlders at these locations as s_FusionFX and sk_FusionFX
Here 's' represents style and 'sk' represents skin.

4.   We will rename these folders within AnalyticRes folder as per the requirement.
      Now whatever changes we need to do we will be doing in these copied skin folders.
      For example, our skin name is 'TestSkin' and 2 copied folders will be s_TestSkin and sk_TesSkin.

5.   Now we need to set this skin as a default skin for our dashboard.
For this we need to add a XML code within instanceconfig.xml file located at,

<ORACLE_INSTANCE>/config/OracleBIPresentationServicesComponent/coreappliation_obips1

At the bottom of the file but within the <ServerInstance> grouping, enter the following code:

 <URL>
 <CustomerResourcePhysicalPath>/u01/Middleware/instances/instance1/bifoundation/OracleBIPresentationServicesComponent/coreapplication_obips1/analyticsRes
</CustomerResourcePhysicalPath>

<CustomerResourceVirtualPath>/analyticsRes</CustomerResourceVirtualPath>

  </URL>

 <UI>
      <DefaultStyle>TestSkin</DefaultStyle>
      <DefaultSkin>TestSkin</DefaultSkin>
 </UI>


Here <CustomerResourcePhysicalPath> sets the path of the skin.
<CustomerResourceVirtualPath> sets the virtual path for path mentioned within <CustomerResourceVirtualPath> tag.
<DefaultStyle> sets the default style and will map to folder s_TestSkin.
<DefaultSkin> sets the default skin and will map to folder sk_TestSkin.


6.    Now restart the Presentation Services from EM.

7.   Once the services are restarted you can check the default skin being set under dashboard properties.



In my further posts I will explain further customizations for the custom skin we created.


Relevant Post :
Deploying & Developing a Custom Skin Part 1

OBIEE 11g: Deploying & Developing a Custom Skin Part 1


Deploying a Custom Skin Folder

We can completely customize the OBIEE appearance and design our own custom skin.
OBIEE comes with 2 default skins which can be applied from dashboard properties.
These skins are nothing but ‘blafp’ and ‘FusionFX’.
You can find these default skins at,

<ORACLE_HOME>/OracleBI1/bifoundation/web/app/res 

This directory should not be modified  it will get overwritten with any new installation.
So its suggested to create a new Static Directory for new custom skin.

In this post I will explain how to deploy and develop  the custom skin.

Creating a Static Directory in WebLogic Server

1 .
The default installation for Oracle BI EE 11g creates a default directory that can be used for customization.This directory is,

<ORACLE_INSTANCE>/bifoundation/OracleBIPresentationServicesComponent
/coreappplication_obips1/analyticsRes

To expose this directory, you must open the WebLogic Administration Console.
Open a browser window and in the address bar, enterhttp://<hostname>:7001/console/login/LoginForm.jsp (for example, http://localhost:7001/console/login/LoginForm.jsp). The WLS Login window appears.





2 .
Select Deployments from the Domain Structure pane on the left.


The "Summary of Deployments" pane appears on the right.



3 .
In the Change Center pane on the left (directly above the Domain Structure pane), 
click Lock & Edit.


All applications are made available for update within the table and the Install button is enabled. Note that the "Lock & Edit" button is now disabled.



4 .
In the "Summary of Deployments" pane on the right, click the Control tab and then click Install, enabling you to install a new web application. The Install Application Assistant pane appears.



5 .
a. Select the appropriate folders within the Install Application Assistant pane to navigate to<ORACLE_INSTANCE>/bifoundation/OracleBIPresentationServicesComponent
/coreappplication_obips1.
The path is automatically entered for you.
b. Select the option button for analyticsRes. This is a valid application for deployment.




6 .
Click Next and accept the default value "Install this deployment as an application."



7 .
Click Next. In "Optional Settings - Source accessibility", select the radio button for I will make the deployment accessible from the following location and accept the default path.



8 .
Click Next to review the summary. In the "Additional configuration" section, ensure that the radio button for Yes, take me to the deployment's configuration screen is selected, and then click Finish.


9 .
The "Settings for analyticsRes" pane appears. Click Save.

A confirmation message appears above the "Settings for analyticsRes" pane.


10.   
  In the Change Center pane on the left, click Activate Changes.
A second confirmation message appears above the "Settings for analyticsRes" pane.

11. 
Select Deployments in the Domain Structure pane.

12 .
Click the Control tab and then select the check box for the analyticsRes application. Notice that the state for analyticsRes appears asPrepared. You need to start the application.

13 .
Click Start and then select Servicing all requests.



14 .
Click Yes in the Start Application Assistant pane.

15 .
The "Summary of Deployments" pane reappears with a confirmation message. Note that analyticsRes now shows a state of Active.

16 .
Open a browser window and enter http://<hostname>:7001/analyticsRes/test.txt (for example,http://localhost:7001/analyticsRes/test.txt). Your test file should appear in the browser window.



That completes our custom skin folder deployment.
In my next post I will write about developing custom skin.