Posts Tagged ‘mandante’

Protección de Mandantes

Wednesday, May 6th, 2009

Un tema sumamente importante que solo fue tratado brevemente en este blog es el tema de la protección de los mandantes. Los disintos niveles de protección que SAP nos brinda para los mismos tienen una importancia mayúscula dentro del marco general de seguridad del sistema y gestión de ambientes.

Por ejemplo, dentro de los parámetros a definir se puede establecer que el mandante sea modificable, la posibilidad de copiar el mismo, realizar modificaciones independientes de mandante, etc.

Desde la transacción SCC4 podemos consultar y/o modificar la configuración de los mandantes, y dentro de las mismas se nos presentan varias opciones que es importante que nos queden claras y bien definidas.

1- Modificar objetos dependientes de mandante:

- Permitir libremente las modificaciones sin realizar órdenes de transporte automáticamente (No recomendado su uso, solo factible para ambientes Sandbox con rutas cerradas de transporte)
- Permitir modificaciones pero realizar automáticamente las órdenes de transporte respectivas (para reforzar la nivelación de ambientes hacia adelante, y la ejecución del proceso transporte, recomendable para ambientes de parametrización o customizing)
- No permitir modificaciones (o lo que se conoce como mandante cerrado, recomendable para ambientes productivos… y no solo recomendable… indispensable para mantener “cierto” control)
- Permitir las modificaciones de customizing pero anular las posibilidades de transporte incluso manuales (no recomendable, solo para entornos cerrados de pruebas)

2- Modificaciones de objetos independientes de mandante:

- Permitir todos los cambios (Recomendable para ambientes de desarrollo)
- Permitir solo cambios de Repository o workbench (Son solo modificables los programas, reportes, diccionario de datos, etc.)
- Permitir solo cambios de Customizing independiente de mandante (Solo el customizing y no el workbench)
- No permitir ningún cambio independiente de mandante (Ambientes de producción)

3- Protección contra copias de mandante:

- Sin restricciones
- Sin posibilidad de sobrescribir el mandante (habitual para la mayoría de los mandantes, salvo excepción puntual)
- Eliminar la posibilidad de tomarlo como origen de una copia de mandante (Es para evitar que un mandante que tiene información confidencial pueda ser copiado a otro mandante)

3- Protección contra uso de CATTS:

- Las herramientas de CATT o ECATT pueden ser utilizadas para realizar cargas masivas de datos en el sistema y por lo tanto se recomienda que se limite la posibilida de su uso en los ambientes productivos.

Es importante destacar que estas configuraciones son solo aproximaciones a lo que debería ser, y que sin embargo muchas veces ocurren excepciones a las reglas aquí definidas, ya que se habilitan temporalmente las posibilidades de copiar mandantes de producción para realizar pruebas (deberían anonimizarse sus datos), o copiar ambientes de desarrollo, etc.

VN:F [1.8.2_1042]
Rating: 4.8/5 (5 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

¿Como funciona SAP? Logon y Mandantes

Tuesday, May 29th, 2007

En la anterior entrada de este blog, explicamos como era un landscape típico de SAP, pero nos quedaron pendientes un par de cuestiones necesarias para entender como funciona SAP.

Una de ellas es la respuesta a ¿Qué es un mandante?

Ya vimos que básicamente pueden existir tres ambientes (Desarrollo, Calidad, y Producción) y para que servían cada uno de los mismos. Ahora podemos ahondar un poco más…

Los ambientes dijimos que normalmente están ubicados en equipos (computadoras/servidores) distintos, cada ambiente en su respectivo servidor (generalizo para simplificar), el hecho es que cada ambiente, o sistema puede a su vez contener otras divisiones dentro de si mismo.

A modo de ejemplo, un ambiente de desarrollo, puede contener una subdivisión que sea la que va a poseer las parametrizaciones propiamente dichas, otra que haga las veces de ambiente de pruebas unitarias (para que los mismos desarrolladores o parametrizadores prueben el funcionamiento de lo que definen), etc

Estas subdivisiones se llaman Mandantes en SAP

Los mandantes poseen nombres numéricos, siendo a modo de ejemplo un ambiente de SAP de nombre DEV (por Development), y mandante 200, otro mandante en el mismo equipo puede ser UNI (por Pruebas Unitarias) y mandante 210. Otro ambiente puede ser QAS y el número de mandante el 300, y el ambiente productivo PRD y mandante 400.

Los mandantes poseen maestros de usuario distintos, esto quiere decir que en un mismo sistema (DEV) un usuario puede tener acceso al mandante 200 pero no al 210, o puede acceder a los dos pero con distintos permisos.

La información operativa que se cargue en un mandante no es compartida con el otro, a pesar de que la información por pertenecer a un mismo sistema, se aloja en una misma base de datos. Las tablas con las que trabaja SAP poseen normalmente un indicador de mandante, por lo que SAP siempre lee este campo primero y solo muestra la información del mandante en el cual el usuario se autenticó. Estas tablas se llaman tablas DEPENDIENTES de mandante.

Existen otras tablas especiales, con datos de configuración del sistema en su mayoría que son llamadas INDEPENDIENTES de mandante, y que son compartidas por todos los mandantes de un mismo sistema. Espero en una próxima entrada poder ejemplificar esta información con un paso a paso en SAP, para que puede quedar más claro. Mientras tanto no duden en preguntar en los comentarios del post que cualquier cosa les voy a contestar.

Pero ahora, cuando les digan: “Entrá a DEV al mandante 210 y fijate un poco que hay por ahí…” por lo menos van a tener una idea de les están hablando…

En una próxima entrada vamos a ver un ejemplo práctico de ingreso a SAP y seguiremos viendo algunos conceptos básicos como ser las Transacciones.

VN:F [1.8.2_1042]
Rating: 5.0/5 (2 votes cast)
VN:F [1.8.2_1042]
Rating: +3 (from 3 votes)