Introduction

SAP Business Information Warehouse (SAP BW) as a core component of SAPNetWeaver data warehousing functionality, provides both a business intelligence platformand a suite of business intelligence tools. With the tool set provided, relevant businessinformation can be integrated into SAP BW and transformed and consolidated there. SAPBW 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 beinitiated. With extensive predefined information models provided for the various roles ina company (BI Content), SAP BW also increases the usability of these analyses andenables 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 andinterpretation. The data warehousing process includes data modeling, data extraction andthe 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 bySAP and covers all checks for e.g. system administration tasks, data modelingtasks, and for granting access to Info Providers for reporting. For this type ofauthorizations the same concept and technique is used as in an SAP R/3 system.

2. Reporting authorization objects: For more granular authorization checks on anInfoProvider’s data you need another type of authorization objects defined by thecustomer. With these objects you can specify which part of the data within anInfoProvider a user is allowed to see.

Both types of authorization objects use the same authorization framework. Technicallythey are treated in the same way. However, the design of reporting authorizations is morecomplex because you need to design the reporting authorization objects first. This is anadditional step that needs to be treated with care because the structure of the authorizationobjects determines the possible use in regards to selections, combinations and granularity.In your project you need expertise in the area of reporting authorizations; knowledge ofthe 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 whoexecute 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

AdministratorThere are users who create new objects like InfoCubes,InfoAreas, and InfoObjects. They also schedule data loads, create updaterules for InfoCubes, monitor performance, and set up source systems. Theusers 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 doinganything in the Administrator Workbench (transaction codeRSA1). Theprimary objects used are:

S_RS_ADMWB: Administrator Workbench - ObjectsAuthorization object S_RS_ADMWB is the most critical authorizationobject in administration protection. When you do anything in transactioncode RSA1, object S_RS_ADMWB is the first object checked. There are twofields in this object: Activity and Administrator Workbench Object. Each ofthe 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-objectsUntil 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 isonly used if there is no authorization for S_RS_ADMWB-

IOBJ.

Administrator Workbench - InfoSource (flexible update) S_RS_ISOUR

Authorizations for working with InfoSources with flexible updating and their sub-objects

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 sub-objects

Administrator Workbench - MultiProvider S_RS_MPRO

Authorizations for working with MultiProviders and their 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

Administrator Workbench - hierarchy S_RS_HIER

Authorizations for working with hierarchies

Administrator Workbench – Master data maintenance

S_RS_IOMAD

Authorizations for processing master data in the Administrator Workbench

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. Ifwe want a query to only provide results based on the division, forexample, 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 avery 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 InformationWarehouse 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. Datain 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. Aworkbook 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 theworkbook 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 RolesIf 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 usersto 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 savingworkbooks. 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 theBEx Query Designer. The results of the query can be displayed either inMicrosoft 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 TechnicalName (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 forauthorization is set. You must also create an authorization object for which you want to make the authorization.

1. Choose Business Explorer → Authorizations → Reporting Authorization Objects. 2. Choose Authorizations → Authorization Definitions for Hierarchies > Change. 3. In the Definition, select the InfoObject, hierarchy, and node. 4. Select the Type of authorization:

0 - for the node1 - for a subtree below the node2 - for a subtree below the node up to and including levels for a subtree below thenode3 - for the entire hierarchy4 - 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 thetechnical 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 allowedto view data for all characteristic values, regardless of whether a hierarchy is usedor 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 hierarchyinstead 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 highestnode 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 ahierarchy 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, howeverso 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 resultsmay 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 aweb 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 SetupIn 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 froman OLTP system. The profile also provides the access required for stagingsteps to get the data into InfoCubes.

SAP R3 RFC/ALE Set UpYou 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 connectand send data to the SAP BW system.

Set up RFC destinations using SM59. If you don’t 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 andexecute queries

RSA1: Launches the Administrator Workbench, which is used bySAP 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 - 03Execute-16Administer document storage - 23Update 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 objectS_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 authorizationobject 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 fieldsin 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 objectwill be checked with creating new InfoSources and when maintaining the InfoSource anddrilling 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 downto the authorization object class Business Information Warehouse.You will notice some objects we dealt with in reporting that are also usedhere: S_RS_HIER, S_RS_ICUBE, S_RS_COMP, and S_RS_COMP1. If yourcompany is storing data in ODS objects, you will need to use S_RS_ODSO.Note: Some companies use ODS objects to hold large amounts ofdetailed data. An ODS object is another storage location for data,similar in some respects to an InfoCube. If you are using ODSobjects, you will use object S_RS_ODSO in the same way that youuse 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 thedata 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 willneed 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 InterfaceRS_PERS_BOD: Personalization of BexOpen DialogRSMENU: 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, youhave 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 fieldsin 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 usersto 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 BExAnalyzer 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_COMPNew Authorizations Check for Variables in Query DefinitionObject type is ‘VAR’

S_RS_COMP1Is checked additionally with S_RS_COMPChecks for authorizations on query components dependent on the owner (creator RSZOWNER)Authorizations are necessary, e.g. for creating queries

S_RS_FOLDSuppress InfoAreaview of BExelementsSpecify ‚X‘ (true) in the authorization maintenance for suppressing

S_RS_IOBJAuthorization object for working with InfoObjectsIs checked if authorization is not available via S_RS_ADMWBAdditional checks for update rule authorizations

S_RS_ISETFor displaying / maintaining InfoSets(new object in BW)

S_RFCAuthorization for GUI activitiesAdd following RFC_NAMEswith RFC_TYPE ‚FUGR‘ and ACTVT ‚16‘RRXWS: BW Web InterfaceRS_PERS_BOD: Personalization of BexOpen DialogRSMENU: Roles and Menus

S_GUIAuthorization forGUIactivities. Add the activity 60 (upload)