Archive for the ‘introducción’ Category

1000 Pageviews Diarios

Friday, May 8th, 2009

Quería compartir con ustedes que llegamos a los 1000 pageviews diarios en el sitio, y considerando que este es un blog para un nicho específico, creo que es un buen logro alcanzar ese número.

Esperemos seguir creciendo, y les anticipo que en breve vamos a tener algunas de las siguientes novedades:

- Wiki de SAP, con información sobre los objetos de autorización, transacciones, etc.

- Herramienta de segregación de funciones

- Nuevo diseño del sitio

Y si también si ustedes tienen alguna sugerencia para incorporar, bienvenida sea.

Nos leemos en el próximo post!

Diego

VN:F [1.9.18_1163]
Rating: 4.5/5 (2 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

Tipos de Usuario en SAP

Thursday, May 7th, 2009

En todo sistema SAP tenemos 5 opciones para definir los tipos de usuario, con sus diferentes restricciones de acceso y condiciones a la hora de ingresar al sistema. Es importante establecer correctamente los tipos de usuario ya que no debería tener una configuración similar un usuario final, un usuario de interfaz, o uno de sistema, entre otras opciones.

Por eso pasamos a describir los 5 tipos de usuario distintos que podemos definir en SAP:

Usuarios de Diálogo – Dialog users (A)

Es el tipo de usuario con el que deben acceder normalmente los usuarios finales que necesitan interactuar con el sistema a través del SAP GUI. Todos los parámetros de logueo definidos son verificados al iniciar sesión, como así también las restricciones de loguins múltiples. Normalmente la mayoría de los usuarios de nuestra organización debieran estar encuadrados dentro de este tipo.

Usuarios de Sistema – System Users (B)

Los usuarios definidos bajo esta tipología son no interactivos, lo que significa que no pueden loguearse a través del SAP GUI al sistema. Comunmente son utilizados como usuarios de procesamiento por lotes, workflow, procesos ALE, etc. Su contraseña solo puede ser cambiada por el administrador del sistema y se permiten logueos múltiples. Uso interno dentro del mismo sistema.

Usuarios de Comunicación – Communication Users (C)

Utilizados para comunicación RFC entre sistemas, son los comunmente utilizados para las interfaces con otros sistemas. No es posible establecer logueos por parte de usuarios finales a través del SAP GUI.

Usuario de Servicio – Service User (S)

Es propicio para su utilización por parte de usuarios que requieren acceso anónimo. No respetan las normas de expiración de contraseña y la misma solo puede ser cambiada por el administrador del sistema. Las autorizaciones que se le otorguen al mismo deben ser mínimas y restringidas especificamente a la necesidad por la que se creo el usuario. Su uso no es recomendable salvo necesidad específica, ya que son logoneables mediante SAP GUI.

Usuario de Referencia – Reference User (L)

Este tipo de usuarios es poco utilizado en general. No admiten logons de diálogo y pueden ser utilizados para traspasar sus autorizaciones al usuario que lo tiene como referente.

Resumen

El esquema general de tipos de usuario es bastante simple, pero lo importante es aplicarlo correctamente restringiendo a los usuarios batch o de sistema para que no puedan tener logon directo al sistema, y a los usuarios de interfaz con su respectivo usuario de comunicación.

Esto es importante ya que muchas veces los permisos de estos usuarios son demasiado amplios (debieran restringirse, pero ese ya es otro tema), y sus contraseñas pueden estar comprometidas al tener que ser almacenadas en otros sistemas para su conexión.

VN:F [1.9.18_1163]
Rating: 3.0/5 (5 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

Creación de un rol – ejemplo

Thursday, April 23rd, 2009

La idea en este post es entender un proceso simple de creación de un rol,  cómo asignar una transacción a un usuario, los objetos de autorización correspondientes, etc.

Para hacer esto vamos a crear un ejemplo simple en donde vamos a crear un rol con permisos para administrar usuarios en SAP R/3.

1- Lo primero… Darle un nombre, los nombres de todos lo objetos personalizados o creados por el usuario final en SAP comienzan con la letra Z de manera estándar, la realidad es que podemos utilizar cualquier letra pero agrupar todo tras la Z es una buena manera de identificar los roles propios en caso de tener que realizar un upgrade o por cualquier motivo diferenciarlos del resto, por eso en nuestro caso el rol se llamará Z:PRUEBA (podría haber sido por ejemplo ZUSERS o Z_ABM_USUARIOS, etc). Hacemos click en el botón de Rol Simple y pasamos a la siguiente pantalla:

image

2- Una vez en la próxima ventana podemos asignar una descripción al rol y proseguir a la pestaña de “Menú”, en donde haciendo click en el botón “Transacción” incorporaremos una transacción al Rol y por consiguiente a su menú:

image

3- Una vez hecho el click nos disponemos a escribir el nombre de la transacción que queremos incorporar, también podemos hacer esto desde las opciones de Tomar Menús las cuales incorporaran las transacciones desde los menús estándar de SAP, utilizando su estructura predefinida, pero eso se los dejo para que experimenten ustedes.

image

4- Una vez incorporada la transacción al menú podemos ir a la pestaña de autorizaciones:

image

5- Una vez en el menú de autorizaciones hacemos click en Modificar Autorizaciones, y accederemos a una nueva pantalla, nos preguntará si queremos grabar el rol, esta acción es necesaria para poder tratar los objetos de autorización del mismo con lo cual contestaremos que si. La otra alternativa sería utilizar el “diskette” que se encuentra en la barra superior para grabar nuestro trabaja hasta el momento.

image

6- Una vez estemos en la nueva pantalla (a veces demora),  podemos ver los objetos de autorización agrupados por tipo de objeto.

image

7- Una vez que hacemos click en el símbolo [+] podemos ver el nombre del objeto de autorización (en este caso el primero es S_TCODE) y una breve descripción del mismo. Haciendo otra vez click en el [+] podemos ver los campos y sus valores. En este caso vemos el campo TCD y el valor SU01 que es la transacción que anteriormente agregamos en el menú y con la que automáticamente SAP carga el objeto. Resumiendo las transacciones que agregamos en el menú automáticamente son incluidas dentro de los valores del objeto S_TCODE.

image

8-Debajo de este objeto podemos encontrar 3 grupos más con sus respectivos objetos. Estos objetos de autorización son los que la transacción SU01 verifica en tiempo de ejecución (son los definidos en la transacción SU24, puede que existan más o menos chequeos que los aquí establecidos).

image

9- Tenemos que definir todos los valores de los objetos de manera de hacerlos acorde a la funcionalidad a otorgar. Por ejemplo si queremos brindar solo la posibilidad de visualizar usuarios deberíamos concentrarnos en los objetos S_ADDRESS1 (poder visualizar datos de dirección del usuario) y S_USER_GRP (permisos por grupo de usuarios) definiéndolos con la actividad 03 (visualizar) y la definición del grupo correspondiente o “*” para todos los grupos y el tipo de dirección Bc01.

image

10- Una vez realizadas todas las modificaciones se deben grabar las modificaciones (icono de diskette en la barra superior) y generar los perfiles de autorización correspondientes (ícono generar al lado del tacho de basura)

image image

11- Los otros objetos de autorización no brindan permisos adicionales en el caso de solo querer visualizar los datos de un usuario, pueden hacer la prueba y efectivamente van a ser capaces de usar la transacción SU01, pero hay funcionalidades adicionales que solo pueden ser brindados por estos otros, por ejemplo ver los permisos del usuario (roles) con los objetos S_USER_AGR, S_USER_AUT, S_USER_PRO, etc.

12- Una vez creado el rol puede definirse los usuarios que tendrán asignado el mismo desde dentro de la misma transacción PFCG o el proceso inverso desde la transacción SU01 (ingresando desde el usuario y definiendo los roles para el mismo. Una vez realizada la modificación en la PFCG se debe ejecutar la comparación de usuarios (botón) para que se actualicen efectivamente los permisos en los buffers de usuarios.

image

13- Si fuera el caso de requerir la funcionalidad de bloquear/desbloquear usuarios, por ejemplo, se otorgaría en el mismo objeto S_USER_GRP la actividad 05 y automáticamente una vez generado de nuevo el rol (y en ocasiones una vez que se comparen los roles) el usuario tendría el permiso a realizar esa acción.

El presente actúa a modo de ejemplo y podría tener muchas modificaciones para ser un rol de utilidad, pero la idea es entender como es el proceso de creación de un rol, y que el mismo aplica a roles más complejos y transacciones tanto de Base como de Negocio.

VN:F [1.9.18_1163]
Rating: 4.3/5 (8 votes cast)
VN:F [1.9.18_1163]
Rating: +2 (from 2 votes)

Tips: Bloqueo de Transacciones

Wednesday, April 22nd, 2009

Entre tantas opciones de seguridad que tenemos en la herramienta SAP ECC nos encontramos que tenemos la posibilidad de bloquear el uso de una transacción para todos los usuarios independientemente de sus autorizaciones (siempre y cuando no tengan autorización para desactivar el bloqueo), a través de la transacción SM01, en la misma podemos indicar el código de transacción a bloquear y a partir de confirmar el mismo no se permitirá la ejecución de esa transacción por ningún usuario hasta que no se vuelva a desbloquear.

Esta opción es útil para impedir la ejecución de transacciones que consideremos críticas y no querramos que en ese ambiente nadie ejecute, o tal vez para impedir temporalmente la ejecución de una transacción específica (ocurre durante la ejecución de algunos procesos en batch, o actualizaciones del sistema).

VN:F [1.9.18_1163]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)

El sistema de transporte en SAP

Wednesday, March 18th, 2009

El sistema de transporte en la plataforma SAP es de suma importancia para nosotros, desde el punto de vista de la seguridad. A través del mismo nos garantizamos la separación de los ambientes, y el control de cambios. En el presente post vamos a hacer una introducción a los principales aspectos del mismo.

Mediante el sistema de transporte nosotros vamos a realizar el pasaje de datos, estructuras, programas, parametrizaciones, roles, etc. entre los distintos ambientes, a través de lo que en SAP se conocen como órdenes de transporte.

Un breve pantallazo sobre los ambientes lo vimos anteriormente aquí.

Las órdenes de transporte son la estructura en la que se almacena la información a transportar, las mismas están constituidas por tareas individuales (pueden tener una sola) las cuales deben asociarse a usuarios individuales, los cuales adjuntaran sus modificaciones en las mismas.

Cuando uno modifica un objeto en el sistema (ABAP, Customizing, etc) el tipo de objeto es seleccionado automáticamente y se solicita una orden de transporte la cual si uno posee los permisos puede crearla, o simplemente asignarla a una orden ya creada que tengamos asignada con su correspondiente tarea.

Siempre dependiente de los permisos que poseamos (S_CTS_ADMI) podríamos reasignar ordenes de otros usuarios, crear ordenes para otros usuarios, etc.

Una vez creada la orden o asignadas las modificaciones a una tarea, la misma debe liberarse para que sea incluida en la orden y la misma pueda procesarse, la documentación que se desee debe incluirse antes de liberar la tarea. A su vez la orden también necesita ser Liberada por la persona con la responsabilidad y los permisos adecuados para hacerlo, para poder realizar esta tarea deben estar todas las tareas de la misma liberadas.

Cuando la orden es liberada, el sistema se encarga de guardar el versionado de los objetos involucrados, desbloquear los objetos tomados por la orden, y guardados los archivos de datos en el directorio correspondiente del sistema operativo, a su vez se marca la orden como import en el sistema destino.

Dentro del “Transport Organizer” (SE09) se realizan todas las tareas de liberación y monitoreo de las órdenes. Adicionalmente puede utilizarse como sistema de consulta la transacción SE03.

Dentro del workflow de transporte debe incluirse la verificación de tablas, programas, y demás objetos modificados, para verificar que los cambios que se realizan no afectan la seguridad e integridad del sistema.

Los objetos de autorización que principalmente regulan el comportamiento del usuario respecto al sistema de transportes son el S_CTS_ADMI para las funciones administrativas y el S_TRANSPRT, en lo referente a las autorizaciones de crear, modificar y liberar órdenes y tareas.

Este post no trata de ser más que una introducción a la temática del sistema de transporte el cual es mucho más amplio y el cual en breve cubriremos con más información.

VN:F [1.9.18_1163]
Rating: 4.7/5 (3 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 2 votes)

Roles Derivados (Padres e Hijos, Herencia)

Thursday, March 5th, 2009

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.

VN:F [1.9.18_1163]
Rating: 3.2/5 (5 votes cast)
VN:F [1.9.18_1163]
Rating: +1 (from 5 votes)

¿Qué es un nivel organizacional en SAP?

Tuesday, March 3rd, 2009

Como ya sabemos, en SAP nos encontramos con Roles (Grupos de Autorización o Papeles), Transacciones, Objetos de Autorización, Campos y Valores.

Ahora profundizando un poco en este último tema… los valores que le damos a los campos de los objetos de autorización.

Si estuvieron experimentando con SAP , seguramente ya notaron que ciertos valores de campos tienen un signo $ antes de un identificador y que al querer modificarlos manualmente SAP nos advierte que se trata de un nivel organizacional y si queremos romper la relación con el mismo.

¿Qué significa nivel organizacional?

SAP nos brinda esta herramienta para simplificar un poco la administración de los roles, ya que los campos denominados “nivel organizacional” son muchas veces campos que aparecen numerosas veces dentro de los objetos de autorización y que suelen tomar el mismo valor en todos los casos. De esta manera que haciendo click en el botón niveles organizacionales cambiamos todas las ocurrencias de ese campo a lo largo de todos los objetos de autorización de dicho rol.

Los niveles organizacionales son unos pocos campos como ser Sociedad, Centro, División, Organización de Compras, y varios más que hacen a la representación de la organización dentro de SAP.

Es habitual que cuando creemos un rol estemos autorizando a que las acciones que pueden realizarse mediante el mismo sean sobre un mismo “nivel organizacional” o grupo de niveles organizacionales.

Por ejemplo el campo “centro” puede utilizarse para definir distintas locaciones o almacenes de materiales, es probable que nosotros creemos un rol que sea “Comprador para el almacen AR01″ (Por Ejemplo: Z-CMPR_AR01) y varias transacciones hagan referencia a objetos de autorización que utilicen el campo centro, de esta manera definimos al nivel organizacional como AR01 y solamente lo cambiamos en un solo lugar y no en todos los objetos manualmente.

Adicionalmente a esto los niveles organizacionales tienen importancia a la hora de crear “roles derivados” o con herencia padre-hijo pero esto lo vamos a tratar en un próximo post.

VN:F [1.9.18_1163]
Rating: 4.0/5 (2 votes cast)
VN:F [1.9.18_1163]
Rating: 0 (from 0 votes)