✒️El landscape de SAP

Cuando se implementa el sistema SAP en una empresa los administradores del sistema, llamados SAP BASIS establecen los que se conoce como landscape del sistema SAP.

Es la disposición y configuraciones de los servidores SAP en una empresa que implementa el sistema, es decir cómo es la arquitectura, cuantos servidores se van a utilizar y para que se va a utilizar cada uno.

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 el sistema SAP

AMBIENTE = SISTEMA = SERVIDOR EN DONDE SE INSTALA SAP

Existen tres ambientes diferentes en SAP

• Ambiente de desarrollo:

Es utilizado principalmente para programación y configuración del sistema.

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 se modifican los programas estándar del sistema.

• Ambiente de pruebas o testing:

Es utilizado para realizar pruebas.

Los programadores realizan las pruebas unitarias de sus desarrollos. También acceden a este ambiente los consultores funcionales para realizar 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:

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.

Diferentes opciones de lanscapes que se pueden implementar en SAP:

• Landscape de SAP con 1 ambiente o sistema

El 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.

Ventaja: 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 solo sistema, toda la personalización y el desarrollo se realizan en el sistema producción, los nuevos paquetes de soporte y las notas de SAP se aplican directamente en producción.

• Landscape de SAP con 2 ambientes o sistemas

Es decir todo sistema SAP se encuentra instalado en dos servidores diferentes.

Esta opción de dos ambientes o sistemas supera algunos riesgos inherentes a la opción del sistema único.

Las pruebas y la capacitación ahora están separadas de la producción, lo que resulta en la separación de los datos de prueba y capacitación de los datos de producción.

Los nuevos requisitos que se crean primero en desarrollo:

-Las tareas de optimización

-Los paquetes de soporte

-Las notas de SAP

Los inconvenientes de esta opción son que las actividades de prueba y capacitación tienen lugar en el sistema de desarrollo.

• 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 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.

El tiempo de inactividad del sistema de producción se minimiza

. La desventaja son los mayores costos de infraestructura y administración.

Existen distintos mandantes, siendo independientes los datos que se visualizan en cada mandante dentro del mismo ambiente.

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 del cliente.

Dentro del ambiente de desarrollo tenemos:

• El mandante 101 que se utiliza para configuración y programación
• El mandante 102 de sandbox que se utilizará para pruebas inusuales.
• El mandante 103 que se utiliza para pruebas unitarias de programación.

SANDBOX: Es un mandante del ambiente del Desarrollo que permite realizar experimentos e hipótesis a los consultores, modificando el Customizing o IMG sin tener que modificar el mandante propio de Desarrollo que impacta con una orden de transporte pendiente a liberar y enviar a otros mandantes.

Dentro del ambiente de pruebas tenemos:

• El mandante 210 que se utiliza para pruebas integrales, realizadas tanto por los consultores como por los usuarios clave de la empresa.
• El mandante 220 que se utiliza para la capacitación de los recursos humanos

Dentro del ambiente de producción tenemos:

• El mandante 410 que es donde acceden los usuarios finales del sistema para realizar las operaciones del día a día de la empresa.

Concepto de mandante se definir en 2 puntos:

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. 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.

En el sistema SAP existen dos tipos de datos diferentes:

Datos dependientes de mandante: se engloban los datos de aplicación de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc) así como la mayoria de los datos de parametrización de la empresa.

Se llaman dependientes de mandante porque sólo son accesibles desde el mandante en el que se crearon.

Datos independiente de mandante: se engloban los datos de la parametrización de la empresa que son accesibles desde cualquier mandante creado.

Se debe ser cuidadoso al modificar la parametrización independiente de mandante.

Desde el punto de vista físico: la base de datos de SAP esá formada por tablas. Cuando el usuario navega por las pantallas de SAP, es el sistema el que accede a dichas tablas para mostrarle la información pedida.

El 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.

Pocos mandantes podemos tener conflictos durante la parametrización, el desarrollo de programas o las pruebas.

Muchos mandantes estaremos aumentando el tamaño de la base de datos y empeorando el rendimiento.

• Mandante 200 Desarrollo y Parametrización: Se crean los desarrollos. Trabajan los consultores técnicos y funcionales. No tendremos datos maestros ni transaccionales de manera que las pruebas las realizaremos en el mandante 220 después de pasar lo cambios en dicho mandante.
• Mandante 210 Sandbox: Se realizan la pruebas inusuales de parametrización para no interrumpir 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 lo que nos va bien debemos repetirlo a mano en el mandante 200 para que quede grabado en una orden de transporte.
• Mandante 220 Pruebas unitarias: los responsables de desarrollo y parametrización efectuarán las pruebas unitarias de los programas. Tenemos los datos maestros y transaccionales, aunque no serán muy fiables debido a que la parametrización puede cambiar.
• Mandante 300 Pruebas integrales y control de calidad: la función es similar a la del 220 pero con diferencia de las pruebas incluyen la interacción entre diferentes módulos, el rendimiento y 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. Los datos maestros y transaccionales que crean no interfieren en nuestro trabajo.
• Mandante 320 Maestro de parametrización: Se usa únicamente como referencia para poder consultar la parametrización que tenemos en productivo, sin tener que acceder al sistema productivo. Para que cumpla su función se deben transportar los cambios al mandante 400 y al 320 al mismo tiempo. Mantenerlos siempre sincronizados.
  
• Mandante 400 Productivo: Se lleva a cabo la explotación real del sistema. Único mandante propio que debe existir en el ambiente productivo. Antes del arranque en productivo realizaremos las cargas iniciales de datos maestros, movimientos e históricos.

Es una forma de organizar todos los nuevos objetos que se crean en SAP, clasificándolos por módulos o áreas funcionales del sistema.

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, para pruebas.

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.

Pasos para crear un paquete o clase de desarrollo:

- TRX SE80 - Menú desplegable y elegimos la opción PAQUETE.

- Asignamos un nombre a nuestro paquete teniendo en cuenta que debe comenzar con Z.

- Escribimos una descripción breve:

- GRABAR y el sistema nos propone guardar en una Orden de transporte ya existente.

- Si deseamos guardar en una nueva orden de transporte para almacenar los cambios hacemos click en crear orden

Ejemplo:

Completamos la descripción y grabamos.

Seleccionando el objeto podemos visualizar su configuración.