1 | EI landscape de SAP
Cuando se implementa el sistema SAP en una empresa los administradores del sistema, también llamados SAP BASIS establecen 10 que se conoce como landscape del sistema SAP.
Landscape del sistema SAP
Es la disposición y configuraciones de los servidores de SAP en una empresa que implementa el sistema, es decir cómo será la arquitectura, cuantos servidores se van a utilizar, para que se va a utilizar cada uno de estos, entre otras cuestiones.
Dentro de un landscape de SAP, los administradores del sistema, van a definir Ambientes, también llamados sistemas en SAP.
Ambiente
Es un servidor donde ha sido instalado eI sistema SAP.
En conclusión:
Ambiente = Sistema = Servidor en donde se instala SAP
Básicamente existen tres ambientes diferentes en SAP, veamos para que se utiliza cada uno de ellos en una empresa:
- Ambiente de desarrollo: es utilizado principalmente para programación y configuración del sistema.
Aquí es donde se crean los nuevos programas ABAP que son solicitados a los programadores, ya que el sistema estándar no satisface las necesidades específicas de la empresa. También aquí se modifican los programas estándar del sistema utilizando alguna de las herramientas disponibles por SAP.
EI ambiente de desarrollo también es utilizado por los consultores funcionales para realizar configuraciones del sistema.
- Ambiente de pruebas o testing: este ambiente es utilizado principalmente, como su nombre lo indica, para realizar pruebas.
Los programadores acceder al ambiente de testing para realizar las llamadas pruebas unitarias de sus desarrollos. También acceden a este ambiente los consultores funcionales para realizar las llamadas pruebas integrales de cada uno de los requerimientos. Cuando se realizan capacitaciones o entrenamiento a usuarios de SAP se utiliza este ambiente para trabajar con datos actualizados.
- Ambiente de producción: es donde el usuario final utiliza las transacciones estándar del sistema y aquellas transacciones Z creadas a medida que han sido desarrolladas y probadas satisfactoriamente.
En la Práctica
Los datos existentes en el ambiente de producción son sumamente sensibles para la empresa, por eso se restringe al máximo el acceso a todos los usuarios.
En ocasiones los consultores funcionales acceden al ambiente productivo para realizar pruebas puntuales sobre algún error que haya surgido en el sistema y que no se pueda reproducir en el ambiente de pruebas. Menos frecuentemente el ambiente de producción es accedido por los programadores ABAP, en caso de que se haya reportado alguna incidencia o error, que requiere ser detectado y solucionado desde el punto de vista técnico.
"Cada una X cantidad de tiempo la polémica verificada entre todos los actores intervinientes en el sistema los datos en la base de datos en el ambiente de prueba o testing son actualizado con los datos de la base de datos en el ambiente de producción, es decir se pisan tanto las configuraciones como los registros existentes en cada una de las tablas de la base da datos en el ambiente de pruebas o testing con información almacenda en el ambiente de producción, esto se conoce con el nombre de refresh del ambiente de prueba o testing de esta forma se garantiza la integridad de los datos del ambiente ya que con el uso de los datos para realizar pruebas la información almacenada en las tablas de la base de datos se va corrompiendo"
1.1 | Las distintas opciones de landscapes de SAP
Ahora que sabemos que son los landscapes y los ambientes, analicemos a continuación, las diferentes opciones de landscapes que se pueden implementar en SAP:
- Landscape de SAP con 1 ambiente o sistema
EI más básico de todos los landscapes consiste en implementar todo el sistema SAP en un solo servidor o equipo, en donde todos los roles están alojados en el mismo sistema.
En esta opción, las operaciones de desarrollo, pruebas y producción se ejecutan en paralelo en un solo sistema.
La ventaja de esto radica principalmente en la reducción de los costos de hardware y soporte, y que el hardware existente puede ser utilizado, pero implica algunos problemas y riesgos serios.
Con todas las actividades en un solo sistema, toda la personalización y el desarrollo se realizan en el sistema de producción, y los nuevos paquetes de soporte y las notas de SAP se aplican directamente en producción.
Las pruebas y la capacitación también tienen lugar en el sistema de producción.
Los datos de prueba y capacitación se mezclan con los datos de producción y existe un alto riesgo de conflictos.
- Landscape de SAP con 2 ambientes o sistemas
Otra posibilidad consiste en implementar un landscape con dos ambientes o sistemas, es decir todo el sistema SAP se encuentra instalado en dos servidores diferentes.
Esta opción de dos ambientes o sistemas supera algunos de los riesgos inherentes a la opción del sistema único, al dividir la producción de los entornos de prueba y desarrollo.
Las pruebas y la capacitación ahora están separadas de la producción, 10 que resulta en la separación de los datos de prueba y capacitación de los datos de producción.
Los nuevos requisitos, las tareas de optimización y los paquetes de soporte y las notas de SAP también se crean primero en el entorno de desarrollo.
Este enfoque conduce a un sistema más estable y proporciona una infraestructura de soporte de mayor calidad para el cliente.
Los inconvenientes de esta opción son que las actividades de prueba y capacitación tienen lugar en el sistema de desarrollo.
No es posible separar completamente las actividades de desarrollo y los datos de las actividades de prueba y capacitación.
Ejemplo
- Un escenario o empresa para la que el landscape de dos ambientes sería suficiente es aquella en donde:
- No se producen actividades significativas de desarrollo, pruebas y capacitación al mismo tiempo en el sistema combinado de desarrollo y calidad QA.
- Hay muy pocas modificaciones al estándar SAP.
- Hay un número limitado de usuarios concurrentes, es decir que acceden al mismo tiempo, en el ambiente de desarrollo y calidad QA
Landscape de SAP con 3 ambientes o sistemas
En esta disposición del landscape, todas las actividades de desarrollo, capacitación, prueba y productivas, y sus datos, están completamente separados, en sistemas o ambientes dedicados.
Esta opción presenta el menor riesgo, ya que todas las actividades se pueden realizar en paralelo en sus respectivos ambientes o sistemas.
EI nuevo desarrollo está separado de los entornos de prueba y producción.
EI tiempo de inactividad del sistema de producción se minimiza.
La desventaja de esta opción son los mayores costos de infraestructura y administración.
Sabias que
SAP recomienda utilizar el landscape de tres ambientes o sistemas para empresas en donde los procesos comerciales se utilizan a diario.
"En muchas empresas grandes utilizan el sistema SAP para gestionar el corazón del negocio se suele implementar un ladscape de cuatro ambientes o sistemas en donde existe el ambiente de desarrollo donde se realiza la programación y la configuración, el ambiente de testing donde se realizan las pruebas de los nuevos desarrollos y las modificaciones realizadas al sistema, luego tenemos el ambiente de QA donde se realizan las pruebas más integrales se prueba el volumen, se realizan pruebas de estrés y los distintos tipos de pruebas de concurrencia y por ultimo el ambiente de producción es donde accede el usuario final para trabajar en el día a día con el sistema"
2 | Los mandantes
Dentro de cada ambiente o sistema de SAP, existen distintos mandantes, siendo independientes los datos que se visualizan en cada mandante dentro del mismo ambiente.
Mandante
Es una instancia creada dentro de un ambiente, que se utiliza para configuración, desarrollo, capacitación o pruebas.
Se lo conoce también en SAP con el nombre de cliente.
Veamos un ejemplo de una posible distribución de ambientes y mandantes en una empresa:
Dentro del ambiente de desarrollo tenemos:
- EI mandante 101 que se utiliza para configuración y programación.
- EI mandante 102 de sandbox que se utilizará para pruebas inusuales.
- EI mandante 103 que se utiliza para pruebas unitarias de programación.
Dentro del ambiente de pruebas tenemos:
- EI mandante 210 que se utiliza para pruebas integrales, realizadas tanto por los consultores como por los usuariosclave de la empresa.
- EI mandante 220 que se utiliza para la capacitación de los recursos humanos.
Dentro del ambiente de producción tenemos:
- EI mandante 410 que es donde acceden los usuarios finales del sistema para realizar las operaciones del día a día de la empresa.
Si deseamos ver los mandantes existentes en SAP podemos ejecutar la transacción estándar SCC4 tal como vemos a continuación:
EI concepto de mandante se puede definir desde 2 puntos de vista distintos pero complementarios: la Visión lógica, y la Visión Física.
- Desde el punto de vista lógico: el mandante no es más que una unidad organizativa divisoria de la empresa, que permite que distintos usuarios estén trabajando en el mismo sistema, sin ningún tipo de interferencia mutua, ya que cada usuario sólo dispondrá de acceso para visualizar y actualizar los datos de aplicación de la empresa, que estén asociados al mandante al cuál están conectados.
Esto es así, porque en el sistema SAP existen dos tipos de datos diferentes:
.- Datos dependientes de mandante: se engloban aquí los datos de aplicación de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc.) así como la mayoría de los datos de parametrización de la empresa.
Sabias que
Se llaman dependientes de mandante porque sólo son accesibles desde el mandante en el que se crearon. Estos tipos de datos son los más habituales en un sistema SAP.
.- Datos independientes de mandante: se engloban aquí ciertos datos de la parametrización de la empresa que son accesibles desde cualquier mandante creado. Este tipo de datos son los menos numerosos.
Cada vez que se va a proceder a la modificación de este tipo de datos, el sistema avisa con un mensaje informativo informándonos de que la modificación afectará a todos los mandantes. Se debe ser especialmente cuidadoso al modificar la parametrización independiente de mandante.
.-Desde el punto de vista físico: la base de datos de SAP está formada por tablas. Cuando el usuario navega por las
pantallas de SAP, es el sistema el que accede a dichas tablas para mostrarle al usuario la información pedida. EI mandante es el primer campo clave de la mayoría de las tablas que conforman la base de datos de SAP.
Las tablas de la base de datos que contienen al campo mandante como primer campo dentro de su clave son las llamadas dependientes de mandante.
Las tablas que no contienen al campo mandante dentro de su clave se llaman independientes de mandante.
Cuando un usuario se conecta a un mandante, el sistema le está asignando en ese momento el valor del mandante elegido, con lo que el usuario sólo podrá acceder a visualizar o modificar los datos de cada tabla que tengan como mandante el que ha elegido en tiempo de conexión.
Sin embargo, si una tabla es independiente de mandante, esta puede ser accedida desde cualquier mandante al que se conecte el usuario. Esto se consigue de manera transparente para el usuario e incluso para el desarrollador ya que es el propio sistema el que traduce los accesos a las tablas.
Veamos unos ejemplos para aclarar lo explicado:
.- Situación 1: los usuarios user1 y user2 están ambos conectados al mandante 015 de un mismo sistema. Mientras el usuario user1 está modificando la factura 1000, el usuario user2 sólo podrá acceder en modo visualización ya que la factura está siendo bloqueada por el usuario user1; sin embargo, cuando el usuario user1 termine de modificarla, user2 podrá ver la modificación realizada por user1, e incluso podrá realizar cualquier modificación posterior.
.-Situación 2: el usuario user1 está conectado al mandante 015 y el usuario user2 está conectado al mandante 016 del mismo sistema. Ahora los dos usuarios no pueden acceder a la misma información ya que sus conexiones al sistema están lógicamente separadas; el usuario user1 accede a la factura 1000 de su mandante y el usuario user2 puede acceder al mismo tiempo a la factura 1000 (si ésta existe) de su mandante, si bien los datos son completamente distintos ya que la factura 1000 del mandante 015 no es la misma que la factura 1000 del mandante 016.
Lo que realmente ocurre es que para poder los usuarios acceder a la factura 1000, el sistema está accediendo a la tabla de facturas, pero en cada caso accede al registro compuesto por el mandante de conexión del usuario y el número de factura:
Así entonces, cuando el usuario user1, conectado al mandante 015, solicita la factura 1000, el sistema le muestra la factura con descripción X, mientras que si el usuario user2 se conecta al mandante 016 para solicitar la factura 1000, el sistema le mostrará la factura con descripción Z.
"Reforzamos la definición de mandante ya que es un término que no suele quedar claro tal como mencionamos en los servidores donde se instala el sistema SAP se dividen en ambiente o Sistemas de modo que todo landscapes de SAP se instale en dos habientes o sistemas para asegurar la integridad de la información y el uso correcto del sistema a su vez cada servidor donde se encuentra instalado SAP, es decir cada uno de estos ambientes o sistemas se vuelve a dividir en mandantes. Cuando decimos que la división de los mandantes es lógica y no física nos referimos a que no es como en el caso de los habientes que son servidores que podemos ver y tocar si no que solo accedemos a los mandantes a través del sistema. Cuando analizamos como es el login en el sistema SAP vimos que el el SAP logon hacemos clip en una conexión esa conexión apuntaba a un ambiente o sistema de SAP y luego en la siguiente pantalla en logon debíamos ingresar parte de nuestro usuario y password el cliente usuario o mandante al cual teníamos que acceder, es decir siempre que nos vamos a conectar al sistema SAP vamos acceder a un mandante en particular, por último vale la pena volver a mencionar que los datos existentes en las tablas de las bases de datos son diferentes para cada mandante y esto se debe a que los datos son dependientes del mandante".
2.1 | Los mandantes estándar
Dentro del mundo de los mandantes, podemos decir que existen dos tipos bien diferenciados: por lado tenemos los mandantes estándar, que son aquellos que ya vienen con SAP cuando se instala inicialmente el sistema y luego tenemos los mandantes propios que son aquellos mandantes creados por el usuario, es decir por los administradores de SAP de la empresa cliente
Cualquier sistema SAP se instala inicialmente con tres mandantes estándar.
Las funciones de los mandantes estándar son las siguientes:
- Mandante 000: es el mandante de referencia. No contiene datos de parametrización empresarial y por lo tanto las creaciones de mandantes propios se deben hacer como copias de este para asegurarnos que empezamos la parametrización desde cero.
Durante un cambio de versión de SAP los datos dependientes de mandante se actualizan automáticamente en el 000 y los cambios al resto de mandantes se deben hacer desde aquí.
Precauciones
No debe modificarse o borrarse ningún aspecto del mandante estándar 000.
- Mandante 001: es el mandante de ejemplo. Inicialmente es idéntico al 000 y salvo que lo cambiemos nosotros, ninguna actualización de SAP lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalación inicial, aunque SAP no impone ninguna prohibición de cambiarlo o borrarlo.
- Mandante 066: es el mandante del servicio EarlyWatch, cuyo objetivo es garantizar la confidencialidad de nuestros datos reales en productivo. Este mandante está aislado y es al cual se conecta SAP cuando le pedimos que nos realice un servicio de detección de problemas de rendimiento. Los usuarios de este mandante tienen las autorizaciones mínimas para poder ejecutar el informe de rendimiento. Este mandante tampoco debe ser borrado ni modificado nunca.
2.2 | Los mandantes propios
A partir del mandante de referencia 000 podemos crear tantos mandantes como queramos (siempre que el tamaño de nuestra base de datos nos lo permita). En el ambiente de desarrollo se suelen crear varios mandantes, en pruebas o testing algunos menos y en el ambiente de producción solo debe existir un mandante propio.
A continuación, vamos a describir los mandantes que se crean habitualmente y cuáles son sus funciones. Aunque vemos que tienen un número asignado, esto se ha hecho para facilitar la diferenciación entre ellos.
Ideas
Cada empresa que utiliza SAP puede asignarle el número que quiera a cada mandante propio.
Es posible implementar SAP con más o menos mandantes de los indicados, pero hay que buscar el equilibrio entre muchos y pocos. Con pocos mandantes podemos tener conflictos durante la parametrización, el desarrollo de programas o las pruebas, pero con muchos mandantes estaremos aumentando el tamaño de la base de datos y empeorando el rendimiento además de requerir un mayor esfuerzo en los procedimientos de administración de sistemas.
Las funciones de los mandantes propios son las siguientes:
- Mandante 200 Desarrollo y Parametrización: aquí se crean los desarrollos a medida que sean necesarios. Los consultores técnicos y funcionales trabajan en este sistema. No tendremos datos maestros ni transaccionales de manera que la pruebas las realizaremos en el mandante 220 después de pasar todos los cambios hechos aquí.
- Mandante 210 Sandbox: las pruebas inusuales de parametrización las realizaremos en el 210 de manera que no interrumpamos el trabajo normal del mandante 200. Los cambios que hagamos aquí no se registran en ningún sitio de manera que si probamos algo en 10 que nos va bien debemos repetirlo a mano en el 200 para que quede grabado en una orden de transporte (concepto que veremos más adelante) y se pueda pasar al mandante de pruebas unitarias. Periódicamente y para mantener el mandante limpio se hará una copia o refresh desde el mandante 220.
- Mandante 220 Pruebas unitarias: los responsables de desarrollo y parametrización efectuarán aquí las pruebas unitarias de los programas. Aquí sí que tendremos datos maestros y transaccionales, aunque no serán muy fiables debido a que le parametrización puede cambiarse.
- Mandante 300 Pruebas integrales y control de calidad: la función de este mandante es similar a la del 220 pero con le diferencia de que las pruebas incluyen la interacción entre los diferentes módulos, el rendimiento y la aprobación del usuario. También se comprueba que el paso de las órdenes de transporte desde el ambiente de desarrollo sea correcto como garantía de que el paso de esas mismas órdenes a producción también lo sea.
- Mandante 310 Formación a usuarios finales o capacitación: una vez superadas las pruebas correspondientes al mandante 300, pasamos el prototipo aquí para que los usuarios finales reciban los cursos de formación y tengan un sitio donde poder seguir practicando después. De esta manera, los datos maestros y transaccionales que crean no nos interfieren en nuestro trabajo habitual.
- Mandante 320 Maestro de parametrización: este mandante se usa únicamente como referencia para poder consultar la parametrización que tenemos en productivo, sin tener que acceder al sistema productivo, no obligándonos a dar acceso a la misma, a personal no autorizado.
Para que cumpla su función se deben transportar los cambios al mandante 400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.
- Mandante 400 Productivo: aquí es donde se lleva a cabo la explotación real del sistema. Este es el único mandante propio que debe existir en el ambiente productivo. Antes del arranque en productivo realizaremos aquí las cargas iniciales de datos maestros, movimientos e históricos.
3 | Las clases de desarrollo o paquetes
Clase de desarrollo
La Clase de Desarrollo o también llamada "Paquete", es una forma de organizar todos los nuevos programas que se crean en SAP, clasificándolos generalmente por módulos o áreas funcionales del sistema.
Poniendo un ejemplo, un objeto sería un archivo y la clase de desarrollo sería la carpeta donde guardamos el archivo. Existe la Clase de Desarrollo $TMP, que se utiliza para los objetos temporales que no se van a transportar entre ambientes, es decir para pruebas.
Al momento de crear un nuevo objeto en el sistema, SAP nos proporcionará la pantalla que vemos a continuación para que le asignemos el Paquete al que pertenece. En este caso, el paquete es Z_WEB SERVICE.
Transacción SE80
Las clases de desarrollo o paquetes se crean a través de la transacción estándar SE80.