Roles en SAP

Nomenclatura de Roles

A esta altura repasamos ya en el blog varios temas básicos, y hasta tuvimos un pantallazo de la transacción PFCG para poder crear y modificar roles (grupos de autorización o papeles).

Pero ahora hay un tema bastante importante que tratar, porque tiene implicancias bastante serias para el éxito o fracaso de un proyecto de seguridad SAP. Este tema es, justamente, el NOMBRE que les vamos a asignar a estos roles, siendo que el mismo está acotado a 30 caracteres como máximo.

El tema es bastante crítico y existen pocas reglas universales a aplicar al momento de bautizar a los pequeños roles, pero vamos a tratar de enumerar algunas pautas importantes:

1 - La única regla universal… TODOS los roles deben empezar con la letra Z (a lo sumo con la Y)… Esta notación nos va a servir como en cualquier ámbito de SAP para diferenciar lo que nosotros creamos, de lo que es estándar de SAP. Adicionalmente. si trabajamos con los roles estándar sin modificar su nombre y el día de mañana actualizamos la versión de SAP (cosa probable), es también altamente probable que sean sobrescritos por los nuevos, entre otros problemas.

2- Se acabaron las reglas universales… y a partir de ahora arranca la creatividad del diseñador de la seguridad para hacer un buen trabajo. Si aunque parezca mentira, algo de creatividad podemos aplicar en este trabajo ;-)

3- Si existe el requerimiento organizacional que la seguridad sea descentralizada tenemos que preocuparnos por los primeros caracteres que vienen después de la Z. Por ejemplo… si tenemos que crear una seguridad en donde cada oficina de cada país que acceda a SAP va a tener un administrador propio, podríamos empezar nuestro roles como: “ZAR” para Argentina, ZUY para Uruguay, y así sucesivamente.

De esta manera podemos hacer que cada administrador de seguridad esté limitado a gestionar los roles que comiencen con las siglas de su país. Esto se logra limitando a los administradores de seguridad en el objeto S_USER_AGR. Cómo podrán imaginar esta restricción puede hacerse para muchas cosas y por muchos motivos distintos, por ejemplo, para restringir la modificación de roles de base, restringir la modificación de los roles de seguridad, y un largo etc.

El hecho es que solo vamos a poder hacerlo por el principio del nombre de los roles, con lo cual es importante determinar este requerimiento apenas comenzamos a definir la nomenclatura.

4- Otra alternativa es definir, después de la Z, el módulo sobre el que “mayoritariamente” los roles van a dar acceso. Aunque no soy particularmente afecto a esto ya que depende el criterio que se use para construir los roles puede que este no respete los “límites de los módulos de SAP”. En este caso nuestros roles serían algo como “ZAP*”, “ZTR”, etc.

También puede hacerse uso de criterios que nos ayuden a identificar el proceso al que pertenecen los roles (si se encuentran tipificados en la organización)

5- Las posibilidades para las primeras letras son númerosas y mucho va a depender de las necesidades organizacionales. En algunas ocasiones para facilitar la lectura puede utilizarse un separador, pero siempre tengamos en cuenta que la cantidad de caracteres que tenemos para nomenclar un rol son relativamente escasos. Ejemplo: “ZMM:CMPR”, “ZUY:SLCT”

6- Ahora ya utilizamos los primero para la Z, los segundos para el país y hasta a lo mejor alguno más, y nos encontramos parados después de un separador. El resto va a depender mucho de como construyamos en si los roles, si nos enfocamos en puestos de trabajo, en actividades, etc.

En un próximo artículo vamos a tratar especificamente esto, pero hoy escapa un poco a lo que es la nomenclatura. Lo ideal independientemente de esto sería generar nomencladores estandar de 4 letras (+ o - según las variantes) por ejemplo de manera que un rol se llame: “ZAR:CMPR_SLCT”. Así estaríamos creando un rol propio (Z), para Argentina (AR), el cual pertenece al circuito de COMPRAS (CMPR) y su función es la de SOLICITANTE (SLCT).

7- Hasta aquí identificamos un rol, pero nos faltaría identificar en el mismo las variantes, ya que por ejemplo en este caso podrían existir roles separados por Centro, Organización de Compra, etc. Con lo cual el rol si el centro es A001 podría pasar a llamarse “ZAR:CMPR_SLCT-AR01″. De esta manera si utilizamos roles con herencia (Padre e Hijo) podriamos llamar al padre ZAR:CMPR_SLCT y los sucesivos hijos para cada centro serían *-AR01, *-AR02, etc. Podría seguir extendiendose para posibles variantes con Organización de compra hasta que los caracteres alcancen.

Es importante tomar conciencia que la nomenclatura es sumamente importante a la hora de definir los roles, y que adicionalmente es muy importante instalar el tema, incluso, al momento de realizar las definiciones más “grandes” del proyecto. Ya que la complejidad o simplicidad de la seguridad puede verse muchas veces afecta por la nomenclatura que utilizan los Analistas Funcionales a la hora de definir cosas tan globales para SAP como las Sociedades, Centros, Organización de Compras, Tipos de Documento, Divisiones, y un largo Etc.

Roles Derivados (Padres e Hijos, Herencia)

Ya sabemos que existen roles simples (los grupos de autorización o papeles que ya conocemos), otros que pueden ser compuestos (los roles que contienen roles simples, una suerte de grupo), pero hasta ahora no habíamos oído hablar de Roles Derivados o Herencia de Roles.

Los Roles Derivados son un concepto muy vinculado con los niveles organizacionales. Ya que básicamente nos permiten definir un Rol como Padre, y después un conjunto de Hijos que van a heredar de este algunas características.

Entre estas características los hijos van a heredar los códigos de transacción que el padre posea, como así también (si están definidos) los valores de los objetos de autorización. Pero ahí se encuentra la diferencia con una simple copia de roles… Van a heredar todos los valores MENOS los que estén definidos como niveles organizacionales, estos últimos van a variar de cada hijo en hijo. Esto resulta muy util a la hora de crear permisos abiertos por locación geográfica o por departamento dentro de la organización, o por cualquier criterio para el que se hayan definido criterios como Sociedad, División, Centro, Organización de Compras, etc. De esta manera estos roles compartiran por ejemplo, las actividades que pueden realiarse sobre una Sociedad, pero no la Sociedad sobre las que pueden realizarse.

Por ejemplo: Podríamos tener un rol de nombre Z:ANLS_CBLE como padre, y dos hijo llamados Z:ANLS_CBLE-1000 y Z:ANLS_CBLE-2000 cada uno con permisos a una sociedad distinta. El día de mañana en caso de necesitarse una modificación en la funcionalidad, solo se tocarían los roles padre y la misma se distribuiría en los roles hijos.

Cuando estén trabajando con este tipo de roles, podrán apreciar que en los hijos no pueden realizarse inclusiones de nuevas transacciones, ya que SAP limita esto y solo pueden realizarse en el padre y heredadas en los hijos.

En un próximo post explicaremos paso a paso la creación de un rol derivado de otro y como se trabaja con los mismos ya que tienen algunas diferencias particulares.

Fuente: Seguridad SAP I, II

Suscríbete a nuestro Boletín