handling hierarchy authorizations in sap bex bo integration

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

© 2011 SAP AG 1

Handling Hierarchy Authorizations

in SAP BEx BO Integration

Applies to:

SAP BW BO Integration. For more information, visit the Business Objects homepage.

Summary

This document talks about ways and means of achieving an expanded hierarchy view in the BO reports

similar to the BW hierarchy along with restricted authorizations as in BW.

Authors: Amit Jain and Sapna Singh

Company: Infosys Ltd.

Created on: 31st October, 2011

Author Bio

Amit Jain is a Software Engineer, working with Infosys for two and a half years. Amit has worked on various SAP BW-BO – implementation projects and currently working on SAP BW – BO project.

Sapna Singh is a Software Engineer, working with Infosys for two and a half years. She has worked on various BI projects and now working on SAP BW – BO implementation project.

https://www.sdn.sap.com/irj/boc

Handling Hierarchy Authorizations in SAP BEx BO Integration


© 2011 SAP AG 2

Table of Contents

Introduction ......................................................................................................................................................... 3

Purpose of Document ......................................................................................................................................... 3

Problem Statement ............................................................................................................................................. 3

Proposed Solution .............................................................................................................................................. 3

SAP Standard tables for Authorization used to create view ............................................................................... 5

AGR_USERS - “Assignment of Roles to Users" .......................................................................................... 5

AGR_1251- Assignment of authorization data to Roles (Activity Group) ..................................................... 5

RSECVAL- Authorization Value Status ........................................................................................................ 6

Creating a view from the Standard Authorization Tables ................................................................................... 6

Steps in ABAP program to fetch the Access level .............................................................................................. 7

Implementing Expanded Hierarchy along with Authorizations ........................................................................... 9

Creating Custom Hierarchy in Universe Designer ....................................................................................... 9

Implementing Expanded hierarchy in WebI ................................................................................................. 9

Limitations ......................................................................................................................................................... 10

Related Content ................................................................................................................................................ 11

Disclaimer and Liability Notice .......................................................................................................................... 12



© 2011 SAP AG 3

Introduction

For any business, data security is of utmost importance. In SAP Business Objects data level authorizations flow in from SAP BW’s authorization concepts. As such there is very little flexibility in defining authorization specifically for BO (WebI) reports.

Purpose of Document

This document talks about ways and means of achieving an expanded hierarchy view in the BO reports similar to the BW hierarchy along with restricted authorizations as in BW.

Problem Statement

In SAP BW, if we have a hierarchical view of the master data, without having a proper hierarchy maintained

(Hierarchy Object ), the data is restricted based upon the authorizations on Master data Objects and thus we can achieve the same achieved with a hierarchy Object.

Let’s say, a Destination having attributes: Area, Region.

The Destination Master data is maintained in such a way, so as to enable mapping of each Destination to Area and Area mapping to Region. This view is same as maintaining a Destination Hierarchy.

In this way, SAP BW provides solutions which are helpful depending upon the requirements. However, the same cannot be achieved in SAP BO Web-Intelligence without having a hierarchy maintained at the backend.

Proposed Solution

For achieving the aforesaid scenario, we can have a solution in which we pull the authorization/access level for a user from backend to frontend i.e. from BW to BO. In this way, it is possible to have a hierarchical view and its corresponding node levels based upon the authorization of the user.

Suppose we have hierarchical view on Master data – Location City as:

Country

State

District

Location City

For a Country Level User, the node/Access level starts from Country and he is authorized only to see country data and below levels.

For a State level User, the node/Access level starts from State and he is authorized only to see State data and below levels.

Thus, it’s a three step process as:

1. Based upon the Roles for a user, fetch the analysis authorizations set, and based upon the Master

data Info Objects (representing hierarchy) in those Analysis authorizations, fetch the access level.

2. Creating a customized hierarchy in BO Universe to implement a hierarchical view as in BW (This

step is done as we don’t have any proper hierarchy object)

3. Fetching the access level from BW and using it in BO, implement the Restricted Hierarchical View

same as BW. Display the Hierarchy and below node levels, based upon the Access level of a user.

Below is a Flowchart depicting the Steps involved to implement this.



© 2011 SAP AG 4

Get the list of users

• Get the list of users from the view into a dummy internal table

Create a View

• Create a View with a Join from the standard authorization tables

Fitler Data Access Roles

• Keep only the data access role for these users in the internal table.

Exctract TCTLOW value

• Based upon each Analysis authorization set for a user, extract the characteristic values for the field – TCTLOW

Stage the Access level

• Store and Stage the users with respective Access levels for further reference

User BADIs

• Using BADIs populate the access levels for users in the customer exit variables in BEx queries.

Pull KF in BO Universe

• Pull the access level in BO Reports through Universe

Implement Expanded hierarchy

• Display the Expanded hierarchy in BO using the Access levels as dimension



© 2011 SAP AG 5

SAP Standard tables for Authorization used to create view

AGR_USERS - “Assignment of Roles to Users"

In SAP, access is granted based on user profiles that are placed into roles. These roles are assigned to user IDs and maintained in this table which is used to determine which roles have been assigned to which users. Fields which make up this table are below.

AGR_1251- Assignment of authorization data to Roles (Activity Group)

Analysis authorizations are not based on authorization objects. The authorizations are based on BI-objects instead: so called info objects. These authorizations are then assigned to roles. The role assignment is generally not mandatory, but recommended for a conceptual approach. Assignment of authorization data to Roles is maintained in this table. Fields which make up this table are below.

OBJECT defines the Authorization Object, FIELD defines the OBJECT’s Fields, and LOW defines the components which are restricted.

In case of Analysis Authorization, SAP has provided an authorization Object – S_RS_AUTH and FIELD – BIAUTH. In the LOW field we define the name of the Analysis authorization assigned to the role.



© 2011 SAP AG 6

RSECVAL- Authorization Value Status

The Definition of Analysis authorization is maintained in this table. It gives the details of the Analysis authorization (TCTAUTH), the corresponding Authorization relevant InfoObjects/characteristics (0TCTIOBJNM), the values for which they are restricted (TCTLOW).

Fields which make up RSECVAL are:

Creating a view from the Standard Authorization Tables

Using Join, we derive the users, Analysis authorization, InfoObject values in that authorizations in the view as depicted below:

MANDT Client ID of Current User

AGR_NAME Role Name

UNAME User Name in User Master Record

FROM_DAT Date of validity

TO_DAT Date of validity

EXCLUDE Exclusive

CHANGE_DAT Date of menu generation

CHANGE_TIM Time when the menu was generated last

CHANGE_TST UTC Time Stamp

ORG_FLAG Flag

COL_FLAG Flag

MANDT Client ID of Current User

AGR_NAME Role Name

COUNTER Menu ID for BIW

.INCLUDE Profile generator: fields

OBJECT Auth. Object

AUTH Authorization name

VARIANT Variants for Profile Generator

FIELD Field name of an authorization

LOW Authorization value

HIGH Authorization value

.INCLUDE Internal status of profile maint.

MODIFIED Object status

DELETED ID whether object is deleted

COPIED ID whether object is copied

NEU ID whether object is new

NODE Internal: Node ID

TCTAUTH Authorization name

TCTIOBJNM InfoObject

TCTSIGN SIGN field

TCTOPTION Operator in Select Options and other Expressions

TCTLOW Field for a User-Defined Characteristic Value

TCTHIGH Field for a User-Defined Characteristic Value



© 2011 SAP AG 7

This view - Z_VIEW_AUTH acts as a source for the ABAP program which fetches the authorization levels.

Steps in ABAP program to fetch the Access level

1. Get List of required users from the view in a dummy internal table I_TAB. This table is used as a

master table for the rest of the program.

2. Now, we have both functional roles and data access roles in the table I_TAB. The authorizations

which are set for a user on particular data, is represented only by data access roles.

3. Filtering out functional roles can be done in two ways –

4. If Analysis authorizations are not based on info providers, then remove records with infoprovider

0TCAIPROV (Infoprovider) entry in TCTIOBJNM field. This will remove the functional roles set

against infoproviders.

5. If Analysis authorizations are based on infoproviders, then functional roles can be removed based

upon the naming conventions set for roles.

Once all the filtering is done, based upon the Analysis authorizations set for a user, fetch the characteristic

value in TCTLOW. For example – For Hierarchy levels as:

Country

State

District

City

The value in TCTLOW is maintained only for that level for which the user is authorized to see the data. As shown below for USER 1, the authorization is on District. Hence we derive the TCTLOW value for the required InfoObjects in the hierarchy. Based upon this value, we find the Access level for a user.

User Name

Analysis authorization

Hierarchy Objects TCTLOW

User 1 ABC00EDXXXX1 Country *

User 1 ABC00EDXXXX1 State *

User 1 ABC00EDXXXX1 District 1

User 1 ABC00EDXXXX1 City *

Hence in this case, User 1 has Access level as District.



© 2011 SAP AG 8

In case we have multiple analysis authorizations, then the levels are fetched looping on each analysis

authorization.

Through this approach we can find the Access levels of all the required users and populate them in the

output table. For Instance, if there are 4 users and each have a different authorization levels, then our

output table stores:

Using the output table as the extract structure, stage the Access levels to make it available for further use.

Here we can even apply transformation and routines.

Using BADIs, we can populate the customer exit variables with the Access level values in the BEx Queries

used in BOBJ reports. By defining Access level KF, we pull the values from these variables.

To Implement the Expanded hierarchy logic in BOBJ reports, we need to create customized hierarchy in

Business Objects Universe using the same InfoObjects for which access levels are defined.

Hierarchy Level

Country level User

State level User

District level User

City level User

User Hierarchy Level Access level

User 1 CN 1

User 2 ST 2

User 3 DIST 3

User 4 CTY 4



© 2011 SAP AG 9

Implementing Expanded Hierarchy along with Authorizations

Creating Custom Hierarchy in Universe Designer

Structure of custom hierarchy in the BO Universe is shown below:

Region (Eg: APAC) Parent node

Area (Eg: ASIA ) Next level to Region

Country (Eg: INDIA) Next level to Area

Using the Access level Key Figure as a dimension in WebI, we can slice and dice the Region Hierarchy and also show the immediate levels for the node level.

Implementing Expanded hierarchy in WebI

Applying a simple formula using IF ELSE statements, we can slice the dimension value according to KF value. This is shown as below:

In this particular scenario – User 1 has an Access level as 1 i.e. access on REGION=ASIA PACIFIC. Hence he can see data for next immediate levels in hierarchy.

For User 2, the Access level is 2 i.e. access on LOCATION = SOUTH ASIA. Hence he can only see data for next immediate level which is Country.



© 2011 SAP AG 10

Thus in this way, according to the User’s BW authorizations, and custom hierarchy at universe level, it is possible to show the hierarchical view in BO WEBI reports.

Limitations

The ABAP program for fetching the access levels is dependent on how authorizations are maintained in BW.

If number of expanded hierarchy levels increased/changes, it becomes difficult to handle the complicity involved in formula used for implanting Expanded hierarchy in BO.



© 2011 SAP AG 11

Related Content

For more information, visit the Business Objects homepage.

https://www.sdn.sap.com/irj/boc



© 2011 SAP AG 12

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

handling hierarchy authorizations in sap bex bo integration

Documents

implementing

customer exit

nodeaccess

business objects

standard authorization

bo reports

handling hierarchy

analysis authorizations