SAP Business Intelligence - Autorizaciones SAP BW 7

ORKBW3

SAP BUSINESS INTELLIGENCE
FORMACIÓN AVANZADA SAP BW
AUTORIZACIONES BW 7.0

MANUAL CURSO ORKBW3
VERSIÓN: 1103
DURACIÓN: __H

SAP Business Intelligence
Formación avanzada – SAP BW

1. INTRODUCCIÓN................................................................................................................... 3

1.1. PRERREQUISITOS PARA UTILIZAR EL NUEVO CONCEPTO DE AUTORIZACIÓN A DATOS ............................4
1.1.1. MARCAR EL CONCEPTO QUE ACTUARÁ EN EL SISTEMA......................................................................4
1.1.2. ACTIVARLAS TRES CARACTERÍSTICAS ESPECIALES ..........................................................................5

2. EJEMPLO ............................................................................................................................. 5

2.1. FLAG RELEVANTE PARA AUTORIZACIÓN ..........................................................................................6
2.2. CREACIÓN DE LOS USUARIOS .........................................................................................................7
2.3. CREACIÓN ROL ZBW_REPORTING.............................................................................................7
2.4. CREACIÓN DE LAS AUTORIZACIONES...............................................................................................8
2.5. CREACIÓN ROLES DE ACCESO A DATOS ........................................................................................10
2.6. ASIGNACIÓN DE ROLES A LOS USUARIOS .......................................................................................10
2.7. EJECUCIÓN DE LOS INFORMES .....................................................................................................11
2.8. EJERCICIO II ..............................................................................................................................14

3. ANEXO I – TRANSACCIÓN RSECADMIN ........................................................................ 15

4. ANEXO II – OBSERVACIONES ......................................................................................... 20

4.1.1. DIFERENCIA PRINCIPAL AUTORIZACIONES BW 3X VS BI 7.0............................................................20
4.1.2. AUTORIZACIONES PARA ATRIBUTOS SIN RESTRINGIR EL INFOOBJETO. ..............................................20
4.1.3. S_RS_ICUBE, S_RS_MPRO, S_RS_ISET, S_RS_ODSO ......................................................20
4.1.4. OBJETOS DE AUTORIZACIÓN: S_RS_* .........................................................................................20
4.1.5. NOTAS OSS ..............................................................................................................................22

5. ANEXO III – FLAG ‘RELEVANTE PARA AUTORIZACIÓN’............................................. 22

6. ANEXO IV – ENTRANDO EN UN POCO MÁS DE DETALLE… ...................................... 22

6.1.1. …CARACTERES ESPECIALES .......................................................................................................22
6.1.2. …AUTORIZACIONES PARA RATIOS ................................................................................................22
6.1.3. …AUTORIZACIONES EN NODOS DE JERARQUÍAS .............................................................................23
6.1.4. …0BI_ALL...............................................................................................................................23
6.1.5. …MIGRACIÓN DE AUTORIZACIONES...............................................................................................24

Autor: Oreka IT Fecha: 10.03.2011
Versión: 1103 Página 2 de 24


1. INTRODUCCIÓN

Las autorizaciones determinan el nivel de acceso de un usuario en un sistema.

Las autorizaciones en un sistema SAP BW se complementan con respecto a las
autorizaciones de un sistema transaccional SAP R/3 añadiendo el concepto de
autorización de análisis (o a dato).

La gestión de las autorizaciones a dato (“qué puedo ver”) se realiza principalmente
desde la transacción RSECADMIN.

Esto es debido a que a pesar de que dos usuarios puedan ver informes (autorización a
qué acción pueden realizar, al estilo de SAP R/3) también se puede filtrar a nivel de
autorización el contenido del informe que cada usuario puede ver (autorización a nivel
de dato). Por ejemplo cada usuario únicamente podrá ver datos de su centro de trabajo
para un informe concreto.

En general cuando hay que dar de alta a un usuario hay que plantearse las siguientes
preguntas:
- ¿qué actividades puede hacer? roles al estilo de SAP R/3 (reporting,
planificación, desarrollo, parametrización, …)
- ¿qué información puede ver (y dónde se encuentra dicha información)?
autorizaciones a dato e infoprovider
- ¿a qué menús puede acceder? menús en roles

Respecto a las autorizaciones de acceso a datos, en un sistema SAP BW 7.0 se puede
mantener el viejo concepto de autorización o bien utilizar el nuevo.

Para la nueva versión SAP BW 7.3 únicamente se podrá utilizar el nuevo concepto de
autorizaciones a datos gestionado a través de la transacción RSECADMIN.



1.1. Prerrequisitos para utilizar el nuevo concepto de autorización a datos

1.1.1. Marcar el concepto que actuará en el sistema.

Transacción SPRO / IMG referencia SAP
Guía de implementación de customizing SAP / SAP Netweaver / Business Intelligence /
Parametrizaciones de reporting y análisis / Autorizaciones de análisis: Seleccionar
concepto.



1.1.2. Activarlas tres características especiales

Activar a partir del Business Content de SAP BW las siguientes tres características:
0TCAACTVT - Actividad en autorizaciones de análisis
0TCAIPROV - Autorizaciones para InfoSitio
0TCAVALID - Validez de una autorización

Además marcarlas como relevantes para autorización.

Esas tres características se utilizan como características especiales a la hora de crear
una autorización ya que nos va a determinar:
- actividad que se puede hacer sobre el dato (visualizar, modificar, …)
- infositio al que tenemos acceso (cubo concreto, …)
- validez de la autorización en el caso de que necesitemos que la autorización sea
dependiente de la fecha (sólo tener autorización a esos datos los dos primeros
meses del año, …)

2. EJEMPLO

Vamos a trabajar sobre un ejemplo concreto, para explicar el nuevo concepto de
autorizaciones.

Imaginemos que tenemos un cubo con los datos de ventas por cliente. Y tenemos
tres tipos de usuarios:
- usuario responsable del cliente 1 [USU_1]
- usuario responsable de los clientes 2 y 3 [USU_2]
- usuario responsable de ventas globales [USU_T]

De manera que el usuario USU_1 únicamente podrá ver datos referentes al cliente
1, el USU_2 sólo tendrán acceso a los datos de los clientes 2 y 3. El usuario USU_T
tendrá acceso a los datos completos.

Los tres usuarios tendrán las mismas autorizaciones a nivel de qué pueden hacer
(visualizar informes).

Para llegar a montar el escenario deseado haremos:
Creación de los usuarios USU_1, USU_2, USU_T
Creación del rol ZBW_REPORTING
Marcar el flag relevante para autorización
Creación de autorizaciones
Creación de roles
Asignación de roles
Creación de variable de autorización



2.1. Flag relevante para autorización
Primero marcaremos el flag de relevante para autorización en la característica
cliente (JCC_CLTE):

Con el nuevo concepto, una vez tengamos una característica marcada como
relevante para autorizaciones, el usuario deberá contener una autorización que
restringa dicha características (o bien pueda acceder a todo ‘*’). En versiones
anteriores hasta que no se creaba el objeto de autorización el flag aunque estuviese
marcado no entraba en juego.

En un proyecto de cambio al nuevo concepto lo primero que se tendrá que hacer es
revisar cuáles de las características marcadas en el sistema son tenidas en cuenta
desde el punto de vista de autorizaciones y cuales es necesario desmarcar porque
realmente no se utilizan.



2.2. Creación de los usuarios
Creamos los tres usuarios:

2.3. Creación rol ZBW_REPORTING

Utilizamos como modelo S_RS_RREPU - Rol BI: Usuario reporting

Asociamos a dicho rol los tres usuarios creados

Quitamos la autorización a todo el contenido de los cubos



2.4. Creación de las autorizaciones
Creamos las autorizaciones ZCLI_1, ZCLI_2 y ZCLI_T

En la transacción RSECADMIN, en la pestaña de “Autorizaciones”, botón “Act.”

Añadimos las características especiales (0TCAACTVT, 0TCAIPROV, 0TCAVALID))

mediante el botón



Le damos el valor correspondiente a nuestro cubo en la autorización para InfoSitio

Añadimos la característica de Cliente y le asignamos la autorización al cliente 1.

Idem para las autorizaciones a los clientes 2 y 3; y para la autorización a todos.



2.5. Creación roles de acceso a datos
Creamos los roles asociados a las autorizaciones recién creadas.
Para ello utilizamos el objeto de autorización: S_RS_AUTH

2.6. Asignación de roles a los usuarios
Usuario Rol acción Rol contenido
USU_1 ZBW_REPORTING ZBW_REP_CLI_1
USU_2 ZBW_REPORTING ZBW_REP_CLI_2
USU_T ZBW_REPORTING ZBW_REP_CLI_T



2.7. Ejecución de los informes

Vamos a ejecutar la misma query por los tres usuarios.

La ejecución para un usuario con acceso completo es la siguiente

Para Junio de 2010

Ejecución para usuario USU_1 (/orekait)

Al intentar ejecutar la query tal y como está ahora aparece un error de autorización
ya que se está intentando acceder a todos los datos.



Para que únicamente salgan los datos a los que está cada usuario autorizado hace
falta añadir una variable que los filtre.

Para ello en la query se añade una variable de autorización.

Pantalla de selección al ejecutar el libro de trabajo

Resultado



Usuario USU_2

Usuario USU_T



2.8. Ejercicio II

Vamos a complicar un poco el escenario. Supongamos que queremos que el
usuario T no tenga acceso a los importes. Únicamente debe poder ver las
cantidades.

Para ello utilizar la característica 0TCAKYFNM en la autorización que utiliza el
usuario USU_T.

Ejecución resultante USU_T

USU_1

USU_2

Resumiendo:
- creación de autorización
- asignación de la autorización a un rol mediante el objeto S_RS_AUTH
- asignación del rol a usuario
- utilización de variables de autorización en las queries



3. ANEXO I – TRANSACCIÓN RSECADMIN

Se utiliza la transacción RSECADMIN para la gestión del nuevo concepto de
autorización de análisis (o autorizaciones a datos).

En la primera pestaña “Autorizaciones” utilizaremos el siguiente botón para la
creación y mantenimiento de ‘autorizaciones’ de análisis.

El botón de “Generación” se utiliza para generar automáticamente las
autorizaciones a partir de los datos contenidos en un ODS. El ODS ha de ser
especial y contener los campos (0TCTUSERNM, 0TCTAUTH, 0TCTADT0) y
valores necesarios para dicha generación.

Mediante el botón de “Transp.” asignamos las autorizaciones que queremos
transportar a una orden.



A la hora de crear las autorizaciones existen unas características especiales a tener
en cuenta:

De manera que nos restringirán el acceso por actividad, infoárea, infoprovider,
fecha de validez y ratios, respectivamente.

En la pestaña “Usuario” encontramos aquellos botones que nos permitirán:

- asignar las autorizaciones directamente a los usuarios (sin necesidad de
incluirlas en un rol a través del objeto S_RS_AUTH).



- transportar las asignaciones de autorizaciones a usuarios creadas
- acceso a la transacción SU01
- acceso a la transacción PFCG

La última pestaña son las herramientas de análisis:

En este punto podemos ejecutar una query como si fuésemos otro usuario de
manera que lleguemos a comprobar a qué tiene acceso y a qué no. Es la mejor
manera de probar las autorizaciones a datos recién creadas.



Ejecutaremos como el usuario que queremos probar, marcaremos el flag de log.

Seleccionamos la query a ejecutar

En caso de que dicha query tenga pantalla de selección introduciremos los valores
necesarios

Se visualiza el resultado de la ejecución tal y como la vería el usuario que hemos
seleccionado



Se crea un log donde aparecerán las características relevantes para autorización
que había en dicha ejecución así como el resultado debido a las autorizaciones que
tenía el usuario.

Valores a los que el usuario tiene autorización

Resultado del cruce entre petición y autorización



4. ANEXO II – OBSERVACIONES

4.1. Diferencia principal autorizaciones BW 3x vs BI 7.0
En BW 3.x las autorizaciones se activan a nivel de InfoCubo (RSSM obsoleta)
mientras que en BI 7.0 la autorización está a nivel del infoobjeto (en concreto a nivel
de característica), una vez marcado como relevante aplica a todos los infoproviders.

en una migración los objetos marcados como relevantes para autorización pero
que no están siendo mantenidos en BW 3.x ahora o bien se mantienen o se les ha
de quitar el flag de relevantes para autorización.

4.1.1. Autorizaciones para atributos sin restringir el infoobjeto.
Por ejemplo con la versión 7.0 se puede mantener autorizaciones a nivel de
atributos (para 0EMPLOYEE el sueldo) sin necesidad de buscar otras soluciones
como en versión BW 3.x (hacer un ZEMPLOYEE que contuviese los atributos que
se querían restringir. Eso daba problemas a la hora de utilizar luego multiproviders).

4.1.2. S_RS_ICUBE, S_RS_MPRO, S_RS_ISET, S_RS_ODSO
Los objetos de autorización S_RS_ICUBE, S_RS_MPRO, S_RS_ISET,
S_RS_ODSO no se comprueban en reporting pero son necesarias para tareas de
mantenimiento y desarrollo

4.1.3. Objetos de autorización: S_RS_*
Objetos de autorización interesantes para SAP BI: aquellos que empiezan por
S_RS_*



Por ejemplo:

S_RS_BCS
(SAPBusinessExplorer, orBEx, SAP Business Explorer, or Ex, Broadcasting
Authorization to Schedule) enables users to distribute their reports to other users
and themselves. As shown in the example, you can set S_RS_BCS to all activities
and full authorization. Don’t allow users to distribute only specific reports; rather,
consider restricting confidential reports from being automatically distributed by
entering only the usable BI report IDs.

S_RS_BTM (BEx Web Templates)
enables users to run queries, such as the following, in a Web environment: single
reports or complex reports that you integrate with your SAP NetWeaver Portal and
that Internet Explorer accesses. You can set this option to Display and Execute so
that the users of this role cannot change a WebReport or its design. They can only
be report consumers.

S_RS_COMP (Components)
creates queries, structures, variables, and any query components. Here you can
grant users the rights to execute queries and to view them, so users can’t create
queries, structures, variables, or any query component unless they have the
appropriate rights. To create a power user (a user who can maintain, create, delete,
or modify existing queries), you must grant the user all rights to queries, structures,
variables, and any query components. Authorization is granted to queries, query
views, and Display and Execute activities.

S_RS_COMP1 (Components: Enhancements to the Owner)
enables users only to execute, display, or change (depending on your settings)
queries or views that a specific user created. (The person who creates a report is
defined as the owner in SAP terms.) You can enable the same settings as
S_RS_COMP, but you must enter the “all access” but you must enter the “all
access” indicator (*) in the owner (person responsible) field. You can allow access to
only the particular user who can change the query, or you can assign the role to all
users and restrict a specific user from changing the query. Using this setting you can
separate the activities maintained in S_RS_COMP (for all users) from those of the
query owner in S_RS_COMP1.
For example, I can’t change a query that my colleague created, but I can change my
own queries if I have permission to write them.

S_RS_ERPT (Enterprise Reports)
grants users privileges to run or create reports.
For example, you can set this option to Display and Execute only, so the user can
view and run only those reports that have been created with SAP Report Designer.
The user in user group A needs to be able to execute the report with display-only
access.



4.1.4. Notas OSS
820183: New Authorization Concept in BI
964905: New concepts and generation of analysis authorizations

5. ANEXO III – FLAG ‘RELEVANTE PARA AUTORIZACIÓN’
en reporting pestaña Business Explorer en las características
en atributos pestaña Atributos en las características (en la nueva versión existe
la posibilidad de fijar autorizaciones a nivel de atributos)
en datos maestros pestaña Datos maestros (posibilidad de verificar la
actualización de datos maestros)

6. ANEXO IV – ENTRANDO EN UN POCO MÁS DE DETALLE…

6.1.1. …caracteres especiales
* (asterisco) denota un sistema de caracteres arbitrarios
+ (más) delimita exactamente un carácter (ZMPUC0+)
sólo se puede usar en medio con 0TCAVALID (01/++/2008 permite sólo
el acceso al primer día de cualquier mes de 2008)
: (dos puntos) permite el acceso sólo agregado a la información (por ejemplo para
permitir el acceso a todas las áreas de ventas a nivel agregado pero no
permite el desglose para ver cada área)

6.1.2. …autorizaciones para ratios
Incluir 0TCAKYFNM como característica en la autorización.

Nota: una vez definida la autorización relevante 0TCAKAYFNM los ratios son
chequeados para cada infoprovider.



6.1.3. …autorizaciones en nodos de jerarquías

Tipos de autorizaciones en jerarquías:

6.1.4. …0BI_ALL
Se utiliza para dar acceso completo a datos (al estilo de un SAP_ALL para acciones)

Al marcar nuevos flags de objetos relevantes para autorización se tiene que actualizar
la autorización 0BI_ALL. Se hace a través de la transacción PFCG, “Detalles /
Actualizar autorización 0BI_ALL”.



6.1.5. …migración de autorizaciones
Programa RSEC_MIGRATION

Para más información, comentarios, correcciones, … puedes contactar con nosotros
en el mail: area-bi@orekait.com


SAP Business Intelligence - Autorizaciones SAP BW 7

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a SAP Business Intelligence - Autorizaciones SAP BW 7

Similar a SAP Business Intelligence - Autorizaciones SAP BW 7 (20)

Más de Oreka IT

Más de Oreka IT (12)

Último

Último (15)

SAP Business Intelligence - Autorizaciones SAP BW 7