Nomenclatura de Roles

A esta altura repasamos ya en el blog varios temas bsicos, y hasta tuvimos un

pantallazo de la transaccin PFCG para poder crear y modificar roles (grupos de
autorizacin 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 mximo.

El tema es bastante crtico y existen pocas reglas universales a aplicar al

momento de bautizar a los pequeos 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 notacin nos va a servir como en cualquier mbito de
SAP para diferenciar lo que nosotros creamos, de lo que es estndar de SAP.
Adicionalmente. si trabajamos con los roles estndar sin modificar su nombre y
el da de maana actualizamos la versin de SAP (cosa probable), es tambin
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 diseador 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 despus de la Z. Por ejemplo si tenemos que crear una seguridad en
donde cada oficina de cada pas que acceda a SAP va a tener un administrador
propio, podramos 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 pas. Esto se
logra limitando a los administradores de seguridad en el objeto S_USER_AGR.
Cmo podrn imaginar esta restriccin puede hacerse para muchas cosas y por
muchos motivos distintos, por ejemplo, para restringir la modificacin de roles
de base, restringir la modificacin 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, despus de la Z, el mdulo 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 lmites de los mdulos de SAP. En este caso
nuestros roles seran algo como ZAP*, ZTR, etc.

Tambin puede hacerse uso de criterios que nos ayuden a identificar el proceso
al que pertenecen los roles (si se encuentran tipificados en la organizacin)

5- Las posibilidades para las primeras letras son nmerosas 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 pas y hasta
a lo mejor alguno ms, y nos encontramos parados despus 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 prximo artculo vamos a tratar especificamente esto, pero hoy escapa

un poco a lo que es la nomenclatura. Lo ideal independientemente de esto
sera generar nomencladores estandar de 4 letras (+ o - segn las variantes)
por ejemplo de manera que un rol se llame: ZAR:CMPR_SLCT. As estaramos
creando un rol propio (Z), para Argentina (AR), el cual pertenece al circuito de
COMPRAS (CMPR) y su funcin es la de SOLICITANTE (SLCT).

7- Hasta aqu identificamos un rol, pero nos faltara identificar en el mismo las
variantes, ya que por ejemplo en este caso podran existir roles separados por
Centro, Organizacin de Compra, etc. Con lo cual el rol si el centro es A001
podra 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 seran *-AR01, *-AR02, etc. Podra seguir
extendiendose para posibles variantes con Organizacin 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
ms 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, Organizacin 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 autorizacin o papeles

que ya conocemos), otros que pueden ser compuestos (los roles que contienen
roles simples, una suerte de grupo), pero hasta ahora no habamos odo hablar
de Roles Derivados o Herencia de Roles.
Los Roles Derivados son un concepto muy vinculado con los niveles
organizacionales. Ya que bsicamente nos permiten definir un Rol como Padre,
y despus un conjunto de Hijos que van a heredar de este algunas
caractersticas.

Entre estas caractersticas los hijos van a heredar los cdigos de transaccin
que el padre posea, como as tambin (si estn definidos) los valores de los
objetos de autorizacin. Pero ah se encuentra la diferencia con una simple
copia de roles Van a heredar todos los valores MENOS los que estn 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 locacin
geogrfica o por departamento dentro de la organizacin, o por cualquier
criterio para el que se hayan definido criterios como Sociedad, Divisin, Centro,
Organizacin 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: Podramos 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 da de maana en caso de necesitarse una
modificacin en la funcionalidad, solo se tocaran los roles padre y la misma se
distribuira en los roles hijos.

Cuando estn trabajando con este tipo de roles, podrn 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.