Solved: SAP BW

Former Member · ‎03-12-2007

Hi,

I wouls like to now regarding :

1. Using a Colon ( as an Authorization Value

2. Using a Pound Sign (#) as an Authorization Value

3.Using $ as an Authorization Value

Thanks

Former Member · ‎03-12-2007

Hi,

Using a Colon ( as an Authorization Value

Once you associate your custom reporting authorization object with an InfoCube, every query that executes against that InfoCube will check your custom reporting authorization object, even though the query definition may not contain the secured InfoObjects. In general, for each authorization for your custom reporting authorization object, you should include a colon ( as a field authorization value. Without the colon value in the authorization, the user will fail the authorization check on any queries against the InfoCube that do not use the secured InfoObject(s). If the InfoCube has sensitive data, it could be that you do not want the user to see any summarized data.

For example, let us assume you have an InfoCube that has sensitive forecasting data. In this business scenario you have chosen to secure by InfoObjects (for example, Company Code). If you do not want a user with access to Company Code 1000 to see ANY data from other company codes, then you might not give this user the colon ( value in the authorization. This would mean that ANY queries on your InfoCube that do not use the Company Code InfoObject will fail for this user.

Caution: Once you associate your reporting authorization object with an InfoCube, ALL queries for that InfoCube will check access to your reporting authorization object. Every query that does not use the secured InfoObject(s) in your authorization object will fail if

the user does not have a colon value in their authorization.

Using a Pound Sign (#) as an Authorization Value

When data is loaded into SAP BW, some fields may be marked as no value assigned (posted with INITIAL). If you have secured an InfoObject that has data that is unassigned in the InfoCube, you may choose to give the user a pound sign (#) in order to avoid an authorization error at runtime. The #character is interpreted as authorization for the display of the value Not assigned (posted with INITIAL).

Using $ as an Authorization Value

In our example, we are using the authorization value to fill the variable for the division at query runtime. This means that we will need as many roles as there are different divisions. Using the $ as the value for division would eliminate the need for so many roles. When you use the $ as an authorization value, you must provide code that will check to verify the division being used.

The following example illustrates how variables can be used to streamline the maintenance effort for the administrator:

Assume Company X needs two different query access scenarios:

• User A has access to all data for all divisions

• Users B and C are allowed to see only data from division 01 and 02, respectively.

By using Enhancement RSSBR0001 (here we are dealing with the function module EXIT_SAPLRRBR_001) in the variable maintenance functionality, one can define a variable DIV and assign the appropriate division value to each user by defining the following authorization:

• DIVISION = $DIV (DIV refers to a name of a variable.)

The authorization check itself would then use the same customer exit to check the necessary authorization value against the value defined for this user.

Bye

Former Member · ‎03-12-2007

Hi,

Using a Colon ( as an Authorization Value

Once you associate your custom reporting authorization object with an InfoCube, every query that executes against that InfoCube will check your custom reporting authorization object, even though the query definition may not contain the secured InfoObjects. In general, for each authorization for your custom reporting authorization object, you should include a colon ( as a field authorization value. Without the colon value in the authorization, the user will fail the authorization check on any queries against the InfoCube that do not use the secured InfoObject(s). If the InfoCube has sensitive data, it could be that you do not want the user to see any summarized data.

For example, let us assume you have an InfoCube that has sensitive forecasting data. In this business scenario you have chosen to secure by InfoObjects (for example, Company Code). If you do not want a user with access to Company Code 1000 to see ANY data from other company codes, then you might not give this user the colon ( value in the authorization. This would mean that ANY queries on your InfoCube that do not use the Company Code InfoObject will fail for this user.

Caution: Once you associate your reporting authorization object with an InfoCube, ALL queries for that InfoCube will check access to your reporting authorization object. Every query that does not use the secured InfoObject(s) in your authorization object will fail if

the user does not have a colon value in their authorization.

Using a Pound Sign (#) as an Authorization Value

When data is loaded into SAP BW, some fields may be marked as no value assigned (posted with INITIAL). If you have secured an InfoObject that has data that is unassigned in the InfoCube, you may choose to give the user a pound sign (#) in order to avoid an authorization error at runtime. The #character is interpreted as authorization for the display of the value Not assigned (posted with INITIAL).

Using $ as an Authorization Value

In our example, we are using the authorization value to fill the variable for the division at query runtime. This means that we will need as many roles as there are different divisions. Using the $ as the value for division would eliminate the need for so many roles. When you use the $ as an authorization value, you must provide code that will check to verify the division being used.

The following example illustrates how variables can be used to streamline the maintenance effort for the administrator:

Assume Company X needs two different query access scenarios:

• User A has access to all data for all divisions

• Users B and C are allowed to see only data from division 01 and 02, respectively.

By using Enhancement RSSBR0001 (here we are dealing with the function module EXIT_SAPLRRBR_001) in the variable maintenance functionality, one can define a variable DIV and assign the appropriate division value to each user by defining the following authorization:

• DIVISION = $DIV (DIV refers to a name of a variable.)

The authorization check itself would then use the same customer exit to check the necessary authorization value against the value defined for this user.

Bye

Former Member · ‎03-12-2007

Hi,

Adding to Pradeep there is one more use for (, which is as follows:

Enable summary data to be reported for characteristic levels where user doent have authorizations to access detailed data.

I.e., It is feasible that a sales manager is allowed to

view the respective total sales figures for all sales organization, but is

only authorized to break down their specific sales organization (0001)

according to the individual sales employees. In this case, the following

authorizations, which are grouped together, would be created and

assigned to the sales manager:

Authorization 1

Sales organization (field) -

* (value)

Sales employee (field) -

: (value)

Key figure (field) -

Sales figures (value)

Authorization 2

Sales organization (field) -

0001 (value)

Sales employee (field) -

* (value)

Key figure (field) -

Sales figures (value)

Hope it helps.

Please award points if it is useful.

Thanks & Regards,

Santosh

WolfgangJanzen · ‎03-12-2007

Those characters do not have any special meaning (for AUTHORITY-CHECK in general). Some applications might interpret them - but not the system itself.

Regards, Wolfgang