Thursday 1 December 2016

Oracle E-Business Suite Row Level Security in OBIA (BI APPS)



There are a lot of documents already about OBIA and E-Business suite integration, however I could not find much information on the real specifics i.e. How it actually works once EBS single sign-on has been configured! Therefore, I've written this post for myself really - to keep fresh in my mind the architecture.

I hope you find it useful too :)

EBS and OBIEE / OBIA: Row Level Security
Row-Level Security enables us to control access to rows in a database table based on the characteristics of the user executing a query (e.g., group membership or execution context).

In the context of Oracle E-Business Suite (EBS) Financial Analytics and Procurement Analytics, row level security is enforced for users based upon the EBS responsibility that they use to connect to EBS. The Oracle EBS responsibility has an associated fixed assets book, GL ledger, operating unit, inventory organization etc.

In the context of OBIA, row level security is enforced using Initialisation blocks that are executed when a user connects to OBIEE. These initialization blocks set variable values defined in the RPD (such as ledger, OU_Org etc). These variables are then used as data filters in the RPD to limit the data returned when a BI User queries a subject area e.g.

  • BI User connects to OBIEE using the responsibility ‘Financial Analyst’
  • During the connection, an initialization block runs in OBIEE that sets a session variable ‘LEDGER’.
  • This variable has been used in the RPD ‘data filters’ to add an additional filter (WHERE gl_ledger_id = LEDGER variable) to the analyses created by the User.

Looking at the standard Oracle OBIA solution for Oracle EBS ‘Operating Unit’ security in more detail:




 ‘Out of the box’ OBIA Row level security model

OBIA has a number of seeded Application roles that are granted to Users to access the system e.g. 


  • Role ‘Purchasing Buyer’ has access to the Purchasing Subject Areas. 
  • Role ‘Financial Analyst’ has access to the Financials Subject Areas

These application roles have:

  • Permissions to open and view subject areas.
  • Associated data filters that add SQL where clauses to any query executed using the application role. These data filters are used in OBIA to apply the ledger or fa book or inventory org or operating unit security to Users requests in OBIEE.
and also
  • Can be members of other application roles and inherit the permissions and data filters from these parent members.

To view application roles, open the RPD and navigate to ‘Manage, Identity’.

Role: Purchasing Buyer



NOTE: In this example, role ‘Purchasing Buyer’ is also a member of two other roles:

  • Operating Unit Org-based Security
  • OBIA_PROCUREMENT_CURRENCY_PREFERENCES


Click on Permissions:



Under Object Permissions, role ‘Purchasing Buyer’ has been granted direct access to read the list of Procurement subject areas. 

Therefore, if we create a new Purchasing responsibility and make it a member of ‘Purchasing Buyer’, our new role would also inherit this subject area access.

Click on the Data Filters tab for the Purchasing Buyer application role.



Note – this this is empty. Role ‘Purchasing Buyer’ does not have any data filters itself.

To repeat the key point here! ‘Purchasing Buyer’ is a member of the role ‘Operating Unit Org Based Security’ – so will inherit any permissions that have been created for role ‘Operating Unit Org Based Security’

Opening the permissions of ‘Operating Unit Org Based Security’, we see that this application role has no object permissions. However, it has a large list of data filters:



Therefore, when a BI Users accesses OBIEE using a role (such as Purchasing Buyer) that is a member of the role ‘Operating Unit Org Based Security’, any queries they generate will automatically have these data filters applied to them to restrict the records returned.

There are similar application roles for the other EBS row level constraints (Fixed Assets Book, GL Ledger, Inventory Organization etc) that have the required data filters to enforce the appropriate security on Users analyses, dashboards and queries.

In the case of the ‘Operating Unit Org Based Security’, the data filter restricts the records returned to Users by variable ‘OU_ORG’ e.g.

"Core"."Dim - Business Unit"."Business Unit Number" =  VALUEOF(NQ_SESSION."OU_ORG")

This filter using OU_ORG is added as extra filter to any analysis created by the BI User.

So what is OU_ORG?

OU_ORG is a variable that stores the list of operating units that the user is allowed to access. This variable is populated by an OBIEE Initialisation block called ‘Operating Unit Organizations EBS’ that is fired automatically when the user connects to OBIEE.

Initialisation Blocks:
Initialization blocks are used to initialize dynamic repository variables, system session variables, and nonsystem session variables.
To view the initialization blocks: Open the RPD and navigate to ‘Manage’,’Variables’:



Looking at the SQL code in the initialization block that populates the variable 'OU_ORG, we can see how it selects the operating unit (org_id) directly from Oracle EBS:

Note: Apologies for the SHOUTING in the SQL - that is the way it is 'out of the box' :)

SELECT DISTINCT 'OU_ORG____EBS', COALESCE (TO_CHAR(PER_ORGANIZATION_LIST.ORGANIZATION_ID) ,'-999999')
FROM PER_ORGANIZATION_LIST,
(SELECT FND_PROFILE.VALUE_SPECIFIC('XLA_MO_SECURITY_PROFILE_LEVEL', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID) PROFILE_ID
FROM
(SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_USER_ID) ELSE (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER') END)
AND RESPONSIBILITY_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)
)
)
WHERE
PER_ORGANIZATION_LIST.SECURITY_PROFILE_ID = PROFILE_ID

UNION

SELECT
DISTINCT 'OU_ORG____EBS', COALESCE (FND_PROFILE.VALUE_SPECIFIC('ORG_ID', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID)  ,'-999999') ORGANIZATION_ID
FROM
(SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_USER_ID) ELSE (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER') END)
AND RESPONSIBILITY_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)
)
WHERE NOT EXISTS
(SELECT DISTINCT 'OU_ORG____EBS', COALESCE (TO_CHAR(PER_ORGANIZATION_LIST.ORGANIZATION_ID) ,'-999999')
FROM PER_ORGANIZATION_LIST,
(SELECT FND_PROFILE.VALUE_SPECIFIC('XLA_MO_SECURITY_PROFILE_LEVEL', USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID) PROFILE_ID
FROM
(SELECT USER_ID, RESPONSIBILITY_ID, RESPONSIBILITY_APPLICATION_ID
FROM FND_USER_RESP_GROUPS
WHERE START_DATE < SYSDATE
AND (CASE WHEN END_DATE IS NULL THEN SYSDATE ELSE TO_DATE(END_DATE) END) >= SYSDATE
AND USER_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_USER_ID) ELSE (SELECT USER_ID FROM FND_USER WHERE USER_NAME = ':USER') END)
AND RESPONSIBILITY_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_ID) ELSE RESPONSIBILITY_ID END)
AND RESPONSIBILITY_APPLICATION_ID = (CASE WHEN 'VALUEOF(NQ_SESSION.EBS_SSO_INTEGRATION_MODE)' = 'Integrated'
THEN VALUEOF(NQ_SESSION.OLTP_EBS_RESP_APPL_ID) ELSE RESPONSIBILITY_APPLICATION_ID END)
)
)
WHERE
PER_ORGANIZATION_LIST.SECURITY_PROFILE_ID = PROFILE_ID
)


The following initialization blocks are key in driving the row-level security integration with Oracle EBS Financials:
Initialisation Block
Description
Ledgers EBS12
Populates the variable ‘LEDGER’ with the list of ledgers that the BI User is authorized to access in EBS
Inventory Organizations EBS
Populates the variable ‘INV ORG’ with the list of inventory organizations that the BI User is authorized to access in EBS
Operating Unit Organizations EBS
Populates the variable ‘OU ORG’ with the list of operating units that the BI User is authorized to access in EBS
Fixed Asset Book EBS
Populates the variable ‘ASSET BOOK CODE’ with the list of fixed asset books that the BI User is authorized to access in EBS
EBS Single Sign-on integration
Required for the single sign on for users from EBS
EBS Security context
Sets the EBS security context and cookie in memory

 That's the end of my summary :)

Wednesday 22 October 2014

OBIA Statement of Direction updated

Further to my last post on the ETL future of OBIA, Oracle have now posted an updated Statement of Direction for the BI Apps.

Here is the blog post linking to the Statement of Direction: OBIA SOD


 

Wednesday 8 October 2014

OBIA 11g - No more Informatica

I was interested to hear at Oracle Open World last week that Oracle have finished their development of the BI Apps using Informatica as the ETL tool. The last version of OBIA using Informatica is 7.9.6.4.

The message is clear : to upgrade to OBIA 11g, you will have to re-implement the ETL components using Oracle Data Integrator (ODI).

In my opinion, this isn't such a bad thing! ODI is a very powerful and incredibly flexible ETL tool that Oracle acquired from Sunopsis a few years back. The knowledge module functionality for example, is genius and have saved our team weeks of coding compared to developing the ETL using OWB! With the release of ODI 12c recently and the new 'mappings' functionality, Oracle have made big steps in also making the product a lot more user-friendly for traditional OWB developers. I'm guessing (hoping) that soon OBIA will be certified with ODI 12c also.

I've recently been working on a vanilla implementation of OBIA with ODI 11g and I can tell you that the ETL / DAC components are very different to the prior OBIA / Informatica setup. I'm assuming that Oracle must release a BI Apps 'Informatica to ODI migration'  utility at some point in the near future to ease the way forward so I am looking forward to seeing how that works.


Thursday 2 July 2009

Discoverer 11G Web Services

Great to read about the Oracle Discoverer Web Services that have been released for public consumption as part of Discoverer 11G and Fusion Middleware 11G:

Here and Here

To quote from the User Guide:

The Oracle BI Discoverer Web Services are part of an Application Programming Interface (API) that enables a client to do the following:
- Obtain Discoverer connections, workbooks, and worksheets
- Execute worksheet queries
- Obtain worksheet content using the SOAP protocol (version 1.1 with JAX-WS/document wrapped format)

I've worked on a number of sites that have made a big investment in Discoverer reporting. It will be interesting to see how this new functionality will be used in the future.

Wednesday 27 May 2009

BI Lessons Learnt

Spent an interesting day at a potential customer recently discussing:

- The lessons that I've learnt on recent Oracle BI projects

- How we could apply these lessons to develop an optimum OBIEE rollout strategy.

In no particular order, some of the key lessons that I highlighted and discussed in greater depth were:

1) Releasing too much functionality at once can overwhelm users and support processes.

2) Requirements for Reports and dashboards evolve as users gain more understanding of the tool capabilities.

3) Involve Users as early as possible in Development process.

- Especially if requirements are unclear or poorly understood.

- Report and Dashboard Prototyping often works well.

4) Ensure End Users understand OBIEE Report and Dashboard functionality and capabilities before the Design process starts e.g.

- View selectors, Column Selectors, Dashboard prompts, Delivery options, BI Publisher integration, and so on

5) Develop organization wide Dashboard and Report 'Look and Feel' standards and enforce them.

6) Review quality of data model regularly: e.g. ensure consistent mappings, conforming dimensions, and so on.

7) System performance and perceived 'acceptable' response time is key to end user acceptance.

8) Maintain a library of existing and re-usable solution.

9) End User Training should be focused and timely.


Reviewing my lessons learnt led on to a debate on iterative and agile development methodologies and how they could be best applied in an OBIEE implementation. I'll post some more on that on a future date.

Thursday 7 August 2008

Migrating a Discoverer EUL to OBI EE metadata

OBI EE 10.1.3.4 has been released today on OTN.

One of the areas of new functionality that I am very interested in is the ability to migrate certain components of Discoverer metadata to BI Server / Answers.

The New Features documentation states:

Release 10.1.3.4 includes a utility to accelerate the migration of Oracle BI Discoverer metadata (in the form of an EEX file) to Oracle BI Enterprise Edition Plus metadata (in the form of an RPD file). The utility is a command line executable file that can be found in the \OracleBI\Server\bin directory. An accompanying instruction document can be found in the \OracleBI\Server\Document directory. This release migrates only Discoverer metadata and only for relational data sources.


I'll be examining and hopefully posting further on the migration process in the next few days.

Wednesday 30 July 2008

OBI EE and .NET Framework V2

As promised to Chetan... I stumbled across a frustrating incompatibility whilst installing OBI EE 10.1.3.3.3 on a Windows machine earlier.

OBI EE requires Version 2 of MS .NET Framework.

During OBI EE installation, it also launches the installer for Microsoft .NET Framework V2.
However, if you already have a later version of .NET Framework loaded, the .NET Framework install will end with an 'Incompatibility' error.

The OBI EE installation completes successfully.

However, it fails to deploy the analytics application to the OC4J instance correctly.

My workaround was to deinstall the later .NET Framework from the machine and then, restart the OBI EE installation process.

Let me know if you have a better solution!