Introduction

SAP Business Information Warehouse (SAP BW) as a core component of SAP

NetWeaver data warehousing functionality, provides both a business intelligence platform
and a suite of business intelligence tools. With the tool set provided, relevant business
information can be integrated into SAP BW and transformed and consolidated there. SAP
BW enables analysis and interpretation as well as the distribution of this information.
Based on this analysis, sound decisions can be made and goal oriented activities can be
initiated. With extensive predefined information models provided for the various roles in
a company (BI Content), SAP BW also increases the usability of these analyses and
enables a quick, cost-effective implementation.
Data warehousing in SAP BW represents the integration, transformation, consolidation,
cleanup and storage of data. It also signifies the extraction of data for analysis and
interpretation. The data warehousing process includes data modeling, data extraction and
the management of the data warehouse management processes.
SAP BW Authorization Specifics
In an SAP BW system there are two different types of authorization objects.
1. Standard authorization objects: This type of authorization objects is provided by
SAP and covers all checks for e.g. system administration tasks, data modeling
tasks, and for granting access to Info Providers for reporting. For this type of
authorizations the same concept and technique is used as in an SAP R/3 system.
2. Reporting authorization objects: For more granular authorization checks on an
InfoProviders data you need another type of authorization objects defined by the
customer. With these objects you can specify which part of the data within an
InfoProvider a user is allowed to see.
Both types of authorization objects use the same authorization framework. Technically
they are treated in the same way. However, the design of reporting authorizations is more
complex because you need to design the reporting authorization objects first. This is an
additional step that needs to be treated with care because the structure of the authorization
objects determines the possible use in regards to selections, combinations and granularity.
In your project you need expertise in the area of reporting authorizations; knowledge of
the basis authorization framework is not sufficient.
User Type in BW
There are different types of users in SAP BW. Most of your users will be the users who
execute queries and workbooks. These people could be considered "reporting users" or
"end users." To read more about how to secure reporting users click here

Reporting User Security

Authorization Objects Used Primarily by Reporting Users
In order to execute any query, you must have access to
S_RS_ICUBE, S_RS_COMP, S_RS_COMP1 and S_RS_FOLD.
S_RS_COMP is a powerful object that enables you to make choices on how to secure.
There is one field in S_RS_COMP that relates to the query, and another field that relates
to the InfoCube. This gives you the option to secure by query name, InfoArea, or
InfoCube.
Tips
InfoArea = group of InfoCubes
InfoCube = actual data
InfoObject=field (for example: company code, plant, or cost center)
There are also users who develop new queries. Some people may refer to them as "power
users" or "data analysts." The users who develop queries may also create new workbooks
and may be responsible for publishing that information to the right audience.
Then, there are users who create new objects like InfoCubes, InfoAreas, and InfoObjects.
They also schedule data loads, create update rules for InfoCubes, monitor performance,
and set up source systems. The users who do these tasks are normally referred to as
"administration users." read more about how to secure administrator users click here
Administrator
There are users who create new objects like InfoCubes,
InfoAreas, and InfoObjects. They also schedule data loads, create update
rules for InfoCubes, monitor performance, and set up source systems. The
users who do these tasks are normally referred to as "administration users."
Some of the common tasks performed by administration users are:

Set up and maintain different source systems and connections to SAP BW

Manage metadata and define new InfoObjects, DataSources, and InfoSources
Create transfer rules and update rules
DesignInfoCubes
Schedule and monitor data-loading processes

Administration authorization objects are primarily used when doing

anything in the Administrator Workbench (transaction codeRSA1). The
primary objects used are:

S_RS_ADMWB: Administrator Workbench - Objects

Authorization object S_RS_ADMWB is the most critical authorization
object in administration protection. When you do anything in transaction
code RSA1, object S_RS_ADMWB is the first object checked. There are two
fields in this object: Activity and Administrator Workbench Object. Each of
the two fields can have a variety of values.
The possible values for the Administrator Workbench field are:

SourceSys: Working with a source system

InfoObject:Creating, maintaining InfoObjects
Monitor: monitoring data brought over from the source systems
Workbench: Checked as you execute transaction code RSA1
InfoArea:Creating and maintaining InfoAreas
ApplComp: Limiting which application components you can access
InfoPackage: Creating and scheduling InfoPackages for data extraction
Metadata: Replication and management of the metadata repository

The following list shows possible values for the Activity field.

Maintain - 03
Execute-16
Administer document storage - 23
Update metadata - 66

Other Authoization objects for Admin user

Authorization object/
Technical name

Description

Administrator Workbench
-Objects S_RS_ADMWB

Authorizations for working with individual objects of the

Administrator Workbench. In detail, these are: source
system, InfoObject, monitor, application component,
InfoArea, Administrator Workbench, settings, metadata,
InfoPackage, InfoPackage group, Reporting Agent
settings, Reporting Agent package, documents (for
metadata, master data, hierarchies, transaction data),
document store administration, InfoSpoke.

Administrator Workbench InfoObject S_RS_IOBJ

Authorizations for working with individual InfoObjects

and their sub-objects
Until Release 3.0A, only general authorization protection
was possible with authorization object S_RS_ADMWB.
General authorization protection for InfoObjects still
works as in the past. Special protection with S_RS_IOBJ is
only used if there is no authorization for S_RS_ADMWB-

IOBJ.

Administrator Workbench - Authorizations for working with InfoSources with flexible

InfoSource (flexible update) updating and their sub-objects
S_RS_ISOUR
Administrator Workbench InfoSource (direct update)
S_RS_ISRCM

Authorizations for working with InfoSources with direct

updating and their sub-objects

Administrator Workbench InfoCube S_RS_ICUBE

Authorizations for working with InfoCubes and their subobjects

Administrator Workbench - Authorizations for working with MultiProviders and their

MultiProvider S_RS_MPRO sub-objects Until BW 3.0B, Support Package 1,
authorizations for MultiProviders were checked by using
the authorization object S_RS_ICUBE. As of BW 3.0B,
Support Package 2, this can be maintained, or you can
change the check over to the authorization object
S_RS_MPRO. To do this, choose in Customizing under
Business Information Warehouse General BW Settings
Settings for Authorizations.
Administrator Workbench
ODS object S_RS_ODSO

Authorizations for working with ODS objects and their

sub-objects.

Administrator Workbench InfoSet S_RS_ISET

Authorizations for working with InfoSets

Authorizations for working with hierarchies

Administrator Workbench hierarchy S_RS_HIER

Administrator Workbench
Master data maintenance

Authorizations for processing master data in the

Administrator Workbench

S_RS_IOMAD

BW InfoObject Security- Step by Step instruction.

BW InfoObject Security

Steps to Implement InfoObject Security (field-level security)

1. Make the InfoObject authorization-relevant.

The Authorization Relevant setting for an InfoObject made in the
InfoObject definition on the Business Explorer tab. The business
needs will drive which InfoObjects should be relevant for
security. Keep in mind that the people using SAP BWare running
queries to help make strategic decisions on how to better run the
business. The decision makers typically need to see more data on
SAP BW than they would need to see in SAP R/3.
2. Create a custom reporting authorization object.
Since there are no reporting authorization objects provided for
InfoObjects, you will have to create your own reporting
authorization object for any InfoObject you decide to secure. This
is done in transaction code RSSM. When creating your reporting
authorization object, you select which fields to put in the
authorization object from a list of authorization-relevant
InfoObjects. Only InfoObjects that have been marked
Authorization Relevant are eligible to be put in a reporting
authorization object.
3. Add your new authorization object to a role.
Once you have created an new reporting authorization object and
linked it to the appropriate InfoCube(s), users will need access to
your reporting authorization object. You will need to manually
insert your object into a role.
4. Add a variable to the query.
The reason the variable is required is sometimes unclear at first. If
we want a query to only provide results based on the division, for
example, then the query itself needs the ability to filter specific
division values. Before we can secure on division, the query must
be able to restrict data by division. The only way the query can
restrict data dynamically is through a variable.
5. Link the reporting authorization object to an InfoProvider.
Linking your reporting authorization object to an InfoProvider is a
very critical step. In this step, you will impact people currently
executing queries for the InfoProvider that is now related to your
reporting authorization object. This linkage forces your reporting
authorization object to be checked when ANY query tied to the
InfoProvider is executed.
Create a Reporting Authorization Object

6. In the SAP Easy Access screen of the SAP Business Information

Warehouse choose Business Explorer >> Authorizations>>
Reporting Authorization Objects.
7. Choose Authorization Object >> Create. Enter a technical name
and a description for the reporting authorization object. Save your

entries. On the right-hand side, you get an overview of all the

InfoObjects indicated as authorization-relevant.
Caution: Only those characteristics that have previously been
marked as authorization-relevant in InfoObject maintenance can
be assigned to a reporting authorization object as fields.
8. Assign the InfoObject fields to the reporting authorization object:
Select the characteristics for which an authorization check of the
selection conditions should be carried out.
Select the InfoObject key figure (1KYFNM) if you want to
restrict the authorization to a single key figure.
Select the InfoObject (0TCTAUTHH) if you want to check
authorizations for a hierarchy.
9. Save your entries

Using Workbooks model

Generally power user create query to suit their teams needs and save the results in a
workbook. They may want to save the workbooks to their Favorites folder for easy
retrieval later, or they may want to save the workbooks to a location where other users
can execute the same workbook. ..More
Using Workbooks model.
Generally power user create query to suit their teams needs and save the results in a
workbook. They may want to save the workbooks to their Favorites folder for easy
retrieval later, or they may want to save the workbooks to a location where other users
can execute the same workbook.
Difference between workbooks and queries
An SAP BW user spends more time on the results. They perform activities such as
drilling down to various levels in the data, rearranging the results to highlight certain
relationships in the data, and eventually saving the results to a workbook. Now that the
user has spent that time to format the results in a meaningful way, they would like the
results to be in the same format each time they retrieve the results. To accomplish this,
the user does not execute a query, but instead executes a workbook. The workbook
contains the results of the query in the formatted look and feel that the user requires. Data
in a workbook can either be static, refreshed manually, or refreshed automatically when
the workbook is retrieved.
Queries are actually inserted into workbooks so you can display them. A
workbook could contain several queries that are related in nature.

Thus, a query is more the technical definition of what the results should look like.
Workbooks are actual results that have been formatted and can be refreshed each time the
workbook is executed.

How the reporting user accesses workbooks, and security related to workbooks.
You must set up security to control who can save workbooks, where they can be saved,
and which workbooks appear in the BEx Browser for a specific user.
Workbooks can also be created in the BEx Analyzer. After executing a query, choose
Save Save as new workbook.
Securing Workbooks
In order to save a workbook, a user needs two authorization objects. The two objects
listed below are the minimum authorizations a user needs to save workbooks.

S_GUI: Authorization for GUI activities

S_BDS_DS: Authorizations for document set

Using both S_GUI and S_BDS_DS will enable a user to save workbooks to their
Favorites folder.
The authorization object S_GUI has one field, Activity. The activity field must be set to
60. For S_BDS_DS, the user needs activities 03 and 30. The Class Type field should be
set to OT.

Saving Workbooks to Roles

If a user wants to save aworkbook to a location where it can be easily accessed by others,
they need to save to a Role rather than saving the workbook in their own Favorites folder.
Saving to a Role means saving to a security role.
You may want to set up roles specifically for saving workbooks. You can then assign the
role to all parties who need to share workbooks.
Another option is to not allow users to save workbooks, but rather only allow power users
to save workbooks. This is done to maintain the roles and to ensure that the workbooks
are manageable. This also prevents users from changing workbooks saved by other users.
In order to save workbooks to roles, a user needs:

S_USER_AGR: Authorizations: Role check

S_USER_TCD: Transactions in roles

The authorization object S_USER_AGR has two fields:

Activity and Role Name.
Activity field -Must have at least values 01, 02 and If the user can delete workbooks, they
will also need value 06.
Role Name, you should enter the specific roles you have created for saving
workbooks. Use proper naming convention for roles so that the roles can be restricted
pretty easily. The role name is the name of a role that will be used to hold workbooks.
Saving a workbook to a role actually updates the Menu portion of a role, so object
S_USER_AGR is a required object.
Authorization object S_USER_TCD has one field
Transaction Code. The user needs value RRMX in this field.
Once a workbooks is saved, the data and the layout is saved in the workbook. For
security reasons, we recommend that users save workbooks without the data. To save the
workbook without the data, the users selects from following menu path from the BEx
Analyzer: Tools > All queries in Workbooks > Delete results.

Create Folder and Saving Workbook

Step by step instruction on Creating folders and saving workbook
1. Open the Favorites folder in the tree structure of the BEx Browser. Place the
cursor on the right side of the screen and create a new folder (New Folder).
Give it an appropriate name and specify how you want it presented by choosing
Select Color and Symbol.
2. Open the BEx Analyzer and execute the selected query. Save the workbook by
choosing Save Save as new workbook. Enter a name for the query and select
the sub-folder you created in your Favorites folder. Confirm with OK.
3. When you call the BEx Browser, you see the name of the query in your new
folder, shown as a sub-folder within your Favorites folder. Double-click on the
workbook name to retrieve the saved query results.
The following procedure explains how to create a simple query using the
BEx Query Designer. The results of the query can be displayed either in
Microsoft Excel using the BEx Analyzer or on the web.
Create a New Query
Step by step instruction on Creating a new query

1. In the BEx Analyzer, choose Open Queries from the BEx toolbar.
2. On the next screen, choose New. This brings you to a selection screen containing
all of the InfoCubes for which you can define a new query.
3. Select the InfoCube on which you want the query to be based by selecting it with
the mouse. You can see the technical name of the InfoCube by choosing Technical
Name (wrench icon).
4. After selecting an InfoCube, choose New to create the query.
5. The objects available for the InfoCube you have selected are shown as a tree
structure in the left-hand part of the BEx Query Designer. These objects include
the key figures of the fact table and the characteristics of the dimensions.
6. The right-hand part of the screen contains empty windows for filter selections,
rows, columns, and the free characteristics of the query. The bottom right-hand
part of the screen shows a preview of the query result area. This area is empty at
first.
7. By choosing the plus or minus symbols for the directories, you can expand or
compress the directory structure. By expanding the key figure node in the
InfoCube tree, for example, you can display a list of all the key figures for the
InfoCube.
8. You can drag the characteristics and key figures for the InfoCube into the
windows for the query definition (filter, rows, columns, and free characteristics).
9. When you have finished defining your query, choose Save Query. Choose Quit
and Use Query (check mark icon) to execute and start working with the query.

Maintaining Authorizations for Hierarchies

Maintaining Authorizations for Hierarchies

Before you can make authorizations for hierarchies, you must first transfer and activate
the Info Object 0TCTAUTHH from Content. Make sure that the indicator relevant for
authorization is set. You must also create an authorization object for which you want to
make the authorization.
1.
2.
3.
4.

Choose Business Explorer Authorizations Reporting Authorization Objects.

Choose Authorizations Authorization Definitions for Hierarchies > Change.
In the Definition, select the InfoObject, hierarchy, and node.
Select the Type of authorization:
0 - for the node
1 - for a subtree below the node
2 - for a subtree below the node up to and including levels for a subtree below the
node
3 - for the entire hierarchy
4 - for a subtree below the node up to and including levels (relative) (You must
specify a level that is defined relative to the node for this type. It makes sense to
specify a relative distance if an employee may only expand the hierarchy to a

certain depth below his initial node, but this node is moved to another level when
the hierarchy is restructured.)
5. Specify a technical name for this definition. If you do not enter a value, a unique
ID is set.
6. Now create an authorization for the new authorization object. To do this, enter the
technical name of the definition as a characteristic value for the characteristic
0TCTAUTHH. For the characteristic defined on the hierarchy, specify the
value" ." (blank). It often makes sense to also enter ":" (colon) so that queries
without this characteristic are also allowed.
Hint: If you enter the value "*" here (all characteristic values), the user is allowed
to view data for all characteristic values, regardless of whether a hierarchy is used
or a complete drilldown is carried out.
7. Optionally you can use the following fields:

Top of hierarchy: This option allows you to select the top of the hierarchy
instead of a node in the hierarchy.
If, for example, you want to authorize a user to work with a hierarchy
from the top node, down to a particular level, you can of course authorize
the user for the highest node in the hierarchy. If, on the other hand, the
hierarchy is used in the query without a filter set for this node, the user is
not able to execute the query.
This is because the node that is displayed at the highest level in the
hierarchy, is not actually the top of the hierarchy. For example, there is
the .All Other Leaves. node. This is an internal node, but a node in the
hierarchy nevertheless, and it is this node that is at the top of the hierarchy,
a level higher than the highest node that appears in the hierarchy display.
If the hierarchy is used in the query, and the top-level node has not been
specified explicitly, the system checks the authorization against the highest
node in
the hierarchy, meaning the internal node that is not displayed. This option,
therefore, allows you to determine the top-level node of the hierarchy
yourself, so that you can ensure that users are assigned the appropriate
authorizations.
Hierarchy level : Within the framework of the authorization check, you
can use this value to specify to which level the user can expand the
hierarchy.
Please note that this is an absolute value and refers to the entire hierarchy.
The highest node of a hierarchy stands at level 1.
If you have entered
the value 3 for the hierarchy level, for example, then the user can
expand/see the hierarchy up to level 3.
Validity period :
0: Name, Version, and key Date identical
1: Name and version identical

2. Name identical
3. All hierarchies
Node variable default value: If this option is chosen, this definition of a
hierarchy authorization is used as the default value for node variables.
If a user is allocated several authorizations for subareas of the same
hierarchy, one of these authorizations must be defined as the default value
in this way. Only one node can be chosen for a node variable in the
variable screen of a query. In order that this variable be filled from the
authorizations, the correct variable type must be chosen and an
authorization must be marked as the default value.

Linking BW to Enterprise Portal (EP) Step-by-step list, explaining how to link a BW

system to an EP system. ...More
Linking BW to Enterprise Portal (EP)

Summary
Step-by-step list, explaining how to link a BW system to an EP system. (Note: Those are
the personal notes an EP novice, they should not be used as a reference!)
Linking a BW System to the Enterprise Portal (EP6.0):
In the following article, I want to share my experience in linking a BW System (release
BW3.5) to an Enterprise Portal (release BW6.0SP2). Before diving into the subject
matter, I want to note that I am fairly technically experienced in the BW system, however
so far only had very limited exposure to the EP, or to J2EE platforms in general. Given
this, first I was ready to hand over the task of linking the two systems to an experienced
colleague. On a second thought, however, I said to myself "heck, lets give it a try".
After browsing through the documentation and some system settings, after about 2 hours
I had successfully built (and tested) the connection (again, with NO prior experience in
this area at all)! (Ok, I admit, 5 minutes counseling by an EP expert probably had helped
as well).
[Before I go into details, just a warning: The steps before worked for me. However results
may vary, things depend partially on your local IT infrastructure. Also, some of my
statements below *could* be incorrect. For any serious activities, you should make sure
to either receive the proper training, or to consult with an expert in the respective area.]
Those were the steps I had to take (btw, I had super user rights on the EP):
1. Once logged into the EP, choose "System Administration", then "System
Configuration", then "System".
2. You will see a screen "System Landscape Editor", and on the left to it "Portal
Content". Right-Click on "Portal Content", and choose New >> System".
3. The System Wizard comes up. Choose "SAP_R3_LoadBalacing" (if your system
is load balanced, like in my case). Click "next".
4. Enter the following:
System Name (here I choose the 3 digit system name from the logon, something like
BW1?)

System ID (here I choose the logical system ID, like BW1CLNTT003; you can get this
e.g. from table T000 in the BW system)
System ID Prefex (a prefix to find and group your settings, e.g. BW)
Then save as system. Click "next".
1. Choose "Property Category = Connector", and maintain the following fields:
Application Host (the address of the host; you can get this e.g. from the BW WAD from a
web query URL string; it?s what comes after http:// and before ?:[port]"; something like ?
usbw0101.xxx.com")
Logical System ID (you can get from table T000 in the BW system, something like
"BW1CLNT003")
SAP Client (BW client name)
SAP System Name (here I entered the 3 letter system name, like "BW1")
SAP System Number (you get this e.g. from the BW logon properties)
Server Port (this again you get e.g. from the query URL string mentioned above, it?s the
number which comes after the Application host; e.g. ?8100?)
System Template Name (here I used again the logical system ID from above)
System Type ("SAP_BW", of course)
1. Choose "Property Category = WAS", and maintain the following fields:
WAS description (same as System Name above, e.g. "BW1")
WAS host name (same as application host above, but together with port number from
above, i.e. something like "usbw0101.xxx.com:8100")
WAS path "/sap/bw/bex"
WAS protocol ("http")
1. Choose "Property Category = User Management", and maintain the following:
Logon Method ("SAPLOGONTICKET").
User mapping fields ("{003,800}Client;Language")
User Mapping Type ("admin, user")
Save all your settings.
1. Still from the same screen, choose "System Aliases". Create and save a new
"System Alias". Basically, I picked the logical system ID "BW1CLNT003" as
system alias, and saved this.
2. Almost finished: As a next step, I had to perform what?s called ?user mapping?
(so the EP can talk to the BW on behalf of a specific user). I went to "User
Administration", the "User Mapping". I searched (in this case) for my user in
"Users", then (under "Logon Data for System") selected the BW system, and
maintained the login settings.
Final Step: Now you are ready to test the system connection! For this purpose, go to
"System Administration", then "Support", from here to "SAP Application". Under "Tool"

select "BWReport", and push ?Run?. Select your BW system, and a BEx Web
Application Query String (you can use the string from the WAD URL above, basically
the piece which starts with "cmd"; e.g. like? cmd=ldoc&TEMPLATE_ID=LSTEMP?).
Execute, and you should see the query results right in your Portal!
Setting up RFC to R3 system BW RFC / ALE Setup.In SAP BW, you should create a
system (not a dialog) user called BWALE. BWALE should have the authorization profile
(not Role)S_BI-WHM_RFC. ...More
Setting up RFC
BW RFC / ALE Setup
In SAP BW, you should create a system (not a dialog) user called BWALE. BWALE
should have the authorization profile (not Role)S_BI-WHM_RFC.
You can convert this profile to a role, if you want.
This profile will give user BWALE the access needed to extract from
an OLTP system. The profile also provides the access required for staging
steps to get the data into InfoCubes.
SAP R3 RFC/ALE Set Up
You must set up a user on each SAP system sending data to SAP BW. For this example
we will use R3 system.
Create a system user called BWR3ALE.
This user should have the authorization profile (not Role) S_BI-WX_RFC.
This profile will give user BWR3ALE the access needed to connect
and send data to the SAP BW system.
Set up RFC destinations using SM59. If you dont know ask your Basis Admin to set this
up for you.

Transaction Code in BW

RRMX: Launches the BEx Analyzer, which is used to create and

execute queries
RSA1: Launches the Administrator Workbench, which is used by
SAP BW administrator

Important Notes
540720: FAQ Information on S_RS_COMP and S_RS_COMP1
150315: BW-Authorizations for Remote-User in BW and OLTP
315094: Recommendations for authorizations in BW Reporting 2.0B (even though the
note was written for 2.0B, it still applies to 3.x)
374297: Checking for referencing characteristics/navigation

Authorization Objects for Working in the Data Warehousing Workbench

Authorization Objects for Working in the Data Warehousing Workbench
S_RS_ADMWB: Administrator Workbench - Objects
Protects working with individual objects of the Administrator Workbench: source system,
InfoObject, monitor, application components, InfoArea, AdministratorWorkbench,
settings, metadata, InfoPackages, and InfoPackage groups.
This object is used throughout transaction code RSA1. It covers many administrative
tasks. It includes dealing with source systems, InfoObjects, InfoPackages, master data,
and transaction data.
Authorization object S_RS_ADMWB is the most critical authorization object in
administration protection. When you do anything in transaction code RSA1, object
S_RS_ADMWB is the first object checked. There are two fields in this object: Activity
and Administrator Workbench Object. Each of the two fields can have a variety of values.
The possible values for the Administrator Workbench field are:

SourceSys: Working with a source system

InfoObject:Creating, maintaining InfoObjects

Monitor: monitoring data brought over from the source systems
Workbench: Checked as you execute transaction code RSA1
InfoArea:Creating and maintaining InfoAreas
ApplComp: Limiting which application components you can access
InfoPackage: Creating and scheduling InfoPackages for data extraction
Metadata: Replication and management of the metadata repository

The following list shows possible values for the Activity field.
Maintain - 03
Execute-16
Administer document storage - 23
Update metadata - 66

S_RS_IOBJ: Administrator Workbench - InfoObect

Authorizations for working with individual InfoObjects and their sub-objects. Until SAP
BW 3.0A, only general authorization protection was possible with authorization object
S_RS_ADMWB. General authorization protection for InfoObjects stillworks as in the
past. This authorization object is checked only if the user is not authorized to maintain or
display InfoObjects (authorization object: S_RS_ADMWB-InfoObject, activity:
maintain/display).
If someone needs to update InfoObjects, but they do not need other administration
functions granted in S_RS_ADMWB, then you can give them S_RS_IOBJ in lieu of
S_RS_ADMWB. It will provide access to InfoObjects only.
This authorization object is checked only if the user is not authorized to maintain or
display InfoObjects (authorization object: S_RS_ADMWB-InfoObject, activity:
maintain/display). You use this authorization object to restrict how users work with
InfoObjects and their sub-objects.
Until Release 3.0A, only general authorization protection was possible with authorization
object S_RS_ADMWB. General authorization protection for InfoObjects stillworks as in
the past. Special protection with S_RS_IOBJ is only used if there is no authorization for
S_RS_ADMWB-IOBJ. The following table contains specific information about the fields
in S_RS_IOBJ and how they are used:

S_RS_ISOUR: Administrator Workbench - InfoSource transaction data

Authorizations for working with transaction data InfoSources and their sub-objects. You
can use this authorization object to restrict the handling of InfoSources with flexible
updating and their sub-objects.
You have an administrator who defines what data needs to be extracted from what source
systems. This object protects access to the source systems and managing the transfer
rules.
You can use this authorization object to restrict the handling of InfoSources with flexible
updating, and their sub-objects. It is primarily used to protect transaction data. This object
will be checked with creating new InfoSources and when maintaining the InfoSource and
drilling down to monitor the data brought in from source systems.

S_RS_ISRCM: Administrator Workbench - InfoSource - master data

Authorizations for working with master data InfoSources and their sub-objects. With this
authorization object you can restrict handling of InfoSources with direct updating (for
master data) or with their sub-objects
You have an administrator who defines what master data needs to be extracted from
specific source systems. This object protects access to the source systems and managing
the transfer rules.
With this authorization object, you can restrict handling of InfoSources with direct
updating (for master data) or with their sub-objects.

For a complete list of objects, go to transaction code SU03 and drill down
to the authorization object class Business Information Warehouse.
You will notice some objects we dealt with in reporting that are also used
here: S_RS_HIER, S_RS_ICUBE, S_RS_COMP, and S_RS_COMP1. If your
company is storing data in ODS objects, you will need to use S_RS_ODSO.
Note: Some companies use ODS objects to hold large amounts of
detailed data. An ODS object is another storage location for data,
similar in some respects to an InfoCube. If you are using ODS
objects, you will use object S_RS_ODSO in the same way that you
use object S_RS_ICUBE.

S_RS_ICUBE: InfoArea, InfoCube, InfoCube sub-object

Authorizations for working with InfoCubes and their sub-objects. For example,
protecting users who can define the InfoCube, applying update rules, and looking at the
data in the InfoCube.
Your SAP BW administrator creates InfoCubes. You have a user who needs access to the
data in one of the new InfoCubes. Although the authorization values will be different,
both the administrator and the user require access to S_RS_ICUBE. This object protects
all the essentials for working with InfoCubes.
Authorization object S_RS_ICUBE also protects the InfoArea and the InfoCube. The
difference between objects S_RS_ICUBE and S_RS_COMP is that authorization object
S_RS_ICUBE is more focused on the data in the InfoCube, while S_RS_COMP is more

focused on query execution. Authorization object S_RS_ICUBE is required for reporting

even if you have implemented object S_RS_COMP, because it grants access to actually
display the data held in the InfoCube. The following table lists the fields in authorization
object S_RS_ICUBE and how they are used.

S_RS_ODSO: Authorizations for working with ODS objects and their sub-objects.
In addition to InfoCubes, the SAP BW administrator may create ODS objects to handle
large amounts of transaction data. The user again needs access to the data in some of the
ODS objects. S_RS_ODSO is to ODS objects as S_RS_ICUBE is to InfoCubes.

S_RS_ISET : Authorizations for working with InfoSets

InfoSets are protected by the authorization object S_RS_ISET. This authorization object
protects the InfoSet by the InfoArea. Additional protection includes the activity and
protecting the InfoSet at definition time as well as access to the data. A reporting user will
need activity 03 with access to look at the data. The following fields are in S_RS_ISET:

InfoArea: InfoArea user should access

InfoSet: InfoSet user should access.
Activity: For a reporting user, should be display (03).
Subobject: For a reporting user, should be .DATA..

The fields for this object are similar to S_RS_ICUBE and S_RS_ODSO. They all access
by InfoArea, activity (display), and access to the data.

S_RS_HIER: Authorizations for working with hierarchies

Authorizations for working with hierarchies. This object is used to determine who can
create hierarchies, as well as who can run queries that use hierarchies.
In order to execute a query that uses a hierarchy, the user also needs access to
S_RS_HIER. This object protects all hierarchies in general. The user needs activities 03
(display) and 71 (analyze) in order to see the hierarchy results and execute a query that
uses a hierarchy. In the object, you can further limit the user to specific InfoObjects and
hierarchies.
S_RFC Authorization for GUI activities
Add following RFC_NAMEswith RFC_TYPE FUGR and ACTVT 16
RRXWS: BW Web Interface
RS_PERS_BOD: Personalization of BexOpen Dialog
RSMENU: Roles and Menus
S_GUI Authorization forGUIactivities. Add the activity 60 (upload

S_RS_COMP: Authorizations for using different components for the query definition.
This authorization object is very important for reporting
The authorization object S_RS_COMP restricts query component activities. For example,
it restricts if someone can create queries, change queries, or execute queries. You can
restrict query creation, change, and execution by the InfoArea and InfoCube. If your
company has one InfoCube for sales information and another for financial data, you can
restrict a user to only those queries written for the sales InfoCube or the financial
InfoCube.
You could also use S_RS_COMP if you want to protect by query name. For example, you
have an InfoCube for sales data. Every sales manager needs access to this InfoCube.
However, sales managers in different lines of business are not allowed to execute the
same query.
The following table contains specific information about the fields in S_RS_COMP and
how they are used.

S_RS_COMP1: Authorization for queries from specific owners. This object is new in
SAP BW 3.0. It can be used to limit, by the query owner, which queries a user can see.
For example, you can only see queries created by the power user for your area.
Authorization object S_RS_COMP1 secures the list of queries seen by the user via the
BEx Analyzer or Web-based reporting (this authorization object began with release
3.0A).With S_RS_COMP1, you can limit the list of queries by the query owner. For
example, you are a manager for a local sales team. You can only run queries created by
the power user for your geographic region. S_RS_COMP1 limits both what queries you
can see in the BEx Analyer tool, what queries you can display, and what queries you can

execute. The Owner field in S_RS_COMP1 works in conjunction with the fields
in S_RS_COMP.
If the special value $USER is entered as an authorization value for the Owner field, then
a user can only change their queries and cannot change any other queries. The $USER
will also limit the queries the user can see and display in the analyzer tool.
Authorization objects S_RS_COMP and S_RS_COMP1 are evaluated together. A user
must have access to both objects. The actions you can take related to a query in
S_RS_COMP are complemented by the owner field in S_RS_COMP1.
The following table details the fields in S_RS_COMP1 and how they are used.

S_RS_FOLD Display authorization for folder. This object is new in SAP BW 3.0
If you do not want InfoAreas to appear as an option, then use the authorization object
S_RS_FOLD. This object is not required. You only need to use it if you do not want users
to even see the InfoAreas listing of queries. The object has one field - Hide .Folder. Push
button. If this field is set to X (True), then the InfoAreas button will not appear in the BEx
Analyzer Open Queries dialog box
When a user brings up the BEx Analyzer or uses the Query Designer for Web-based
reporting, there are four categories from which they may choose existing queries:
History, Favorites, Roles, and InfoAreas. Authorization object S_RS_FOLD will allow
you to disable the InfoAreas category

More authorization Objects for Working in the Business Explorer

S_RS_COMP
New Authorizations Check for Variables in Query Definition
Object type is VAR
S_RS_COMP1
Is checked additionally with S_RS_COMP
Checks for authorizations on query components dependent on the owner (creator
RSZOWNER)
Authorizations are necessary, e.g. for creating queries
S_RS_FOLD
Suppress InfoAreaview of BExelements
Specify X (true) in the authorization maintenance for suppressing
S_RS_IOBJ
Authorization object for working with InfoObjects
Is checked if authorization is not available via S_RS_ADMWB
Additional checks for update rule authorizations
S_RS_ISET
For displaying / maintaining InfoSets(new object in BW)
S_RFC
Authorization for GUI activities
Add following RFC_NAMEswith RFC_TYPE FUGR and ACTVT 16
RRXWS: BW Web Interface
RS_PERS_BOD: Personalization of BexOpen Dialog
RSMENU: Roles and Menus
S_GUI
Authorization forGUIactivities. Add the activity 60 (upload)