✒️ABAP / El landscape de SAP Por Mauricio Solis Ibañez

1 | El landscape de SAP

Al implementar el sistema SAP en una empresa, los administradores del sistema (usualmente llamados SAP BASIS) establecerán lo que se conoce como el Landscape del sistema SAP.

El Landscape en sí es la disposición y la configuración de los servidores SAP. Es decir, la arquitectura, la cantidad de servidores y sus propósitos.

Una vez establecidos los landscapes, los administradores del sistema van a definir Ambientes, también llamados sistemas en SAP. Nótese que: Ambiente = Sistema = Servidor en donde se instala SAP.

Usualmente se definen 3 Ambientes:

• Ambiente de desarrollo: Es el que es usado para la programación, configuración del sistema y la modificación de programas estándar a través de las herramientas de SAP. Este ambiente también puede ser usado por los consultores funcionales para realizar configuraciones del sistema.
• Ambiente de pruebas o testing: Como su nombre lo indica, en este se hacen las pruebas, los desarrolladores ABAP acceden para realizar las pruebas unitarias y los funcionales acceden para hacer las pruebas integrales. Adicionalmente, este ambiente se usa también para realizar capacitaciones a los usuarios de SAP, ya que este ambiente es el que tiene datos que posibilitan las pruebas y los ejercicios de capacitación (nótese que usualmente el ambiente de producción es copiado sobre el ambiente de testing de forma periódica para mantener un entorno con un comportamiento similar al ambiente de producción).
• Ambiente de producción: Este es en donde los usuarios finales usan tanto las transacciones estándar y las transacciones Z (nótese que se les dice así porque las transacciones desarrolladas por entidades ajenas a SAP tienen que comenzar su nombre con la letra Z). Usualmente el acceso a este entorno está restringido para casi todos los usuarios porque los datos que están dentro de este servidor son propiedad del cliente.

Sobre el último ambiente: Ocasionalmente los consultores funcionales accederán al mismo para realizar pruebas sobre algún error cuya reproducción no fue posible en el ambiente de pruebas. Adicionalmente, los programadores ABAP también pueden acceder al ambiente si es que hay incidencias o errores que requieren la presencia de un programador para resolverse.

1.1 | Las distintas opciones de landscapes de SAP

El diseño varía para cada empresa que use SAP. Hay 3 ejemplos que nos permiten ver las deficiencias y ventajas de cada extremo:

• Landscape de 1 ambiente: O en otras palabras, Producción, Entrenamiento, Testing y Desarrollo en un solo servidor. La única ventaja de este diseño es el bajo costo de hardware y soporte. Mientras tanto, viene con las siguientes desventajas: Los datos de diferentes grupos de trabajo (por ejemplo, de desarrollo y capacitación) pueden mezclarse y causar conflictos; los paquetes de soporte (Actualizaciones oficiales) y las notas de SAP (Parches personalizados y implementados a mano hechos con las instrucciones de SAP) se aplican directamente en el sistema de producción.
• Landscape de 2 ambientes: En esta, se separa el ambiente de producción del resto. Esto ofrece una estabilidad significativamente mejor a un precio decente. Sin embargo, los datos de los desarrolladores y los datos de las actividades de capacitación y testing todavía se pueden mezclar. En general, este landscape sería suficiente para empresas que: No realicen actividades significativas de testing, capacitación y/o desarrollo al mismo tiempo; No tengan muchas modificaciones al estándar SAP; Tengan un número limitado de usuarios concurrentes (es decir, usuarios conectados al mismo tiempo al ambiente de desarrollo y QA).
• Landscape de 3 ambientes: De esta forma todas las actividades quedan aisladas entre sí (excepto testing y capacitación), gracias a esto se logra la mejor estabilidad posible. Aunque tiene como desventaja un mayor costo de infraestructura y administración.

2 | Los mandantes

Cada landscape tiene ambientes, y cada ambiente tiene mandantes (También conocidos como clientes), los cuales son instancias que se usan para la configuración, desarrollo, capacitación o pruebas. Un ejemplo de una posible configuración de mandantes puede ser la siguiente:

Dentro del ambiente de desarrollo tenemos:

• El mandante 101, que se utiliza para la configuración y programación.
• El mandante 102, de sandbox, es decir, para pruebas inusuales.
• El mandante 103, que se usa para pruebas unitarias.

Dentro del ambiente de pruebas tenemos:

• El mandante 210, que se usa para pruebas integrales realizadas tanto por 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.

Si deseamos ver los mandantes existentes podemos ejecutar la transacción estándar SCC4.

El 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 solo es una unidad organizativa divisoria de la empresa que existe para que distintos usuarios trabajen en el mismo sistema sin que interfieran entre sí, ya que cada usuario solo dispondrá de acceso para visualizar y manipular los datos de aplicación de la empresa que estén asociados al mandante que está usando. Esto es así porque en el sistema SAP existen dos tipos de datos diferentes:

• Datos dependientes del mandante: Aquí se engloban los datos de aplicación de la empresa (datos de clientes, proveedores, pedidos, facturas, etc.) así como la mayoría de los datos de parametrización de la empresa. Reciben este nombre porque sólo son accesibles desde el mandante en el que se crearon; son los tipos de datos más habituales en un sistema SAP.
• Datos independientes del mandante: Aquí se engloban ciertos datos de parametrización de la empresa que son accesibles desde cualquier mandante creado. Cada vez que se está por realizar una modificación a estos datos el sistema da un mensaje de aviso recordándonos que la modificación afectará a todos los mandantes. Por la naturaleza de estos datos es menester modificarlos con cuidado.

Desde el punto de vista físico: La base de datos de SAP está compuesta por tablas. Cuando un usuario navega por las pantallas de SAP, el sistema accede a dichas tablas para conseguirle y mostrarle al usuario la información pedida. El mandante (MANDT) es el primer campo clave de la mayoría de las tablas que conforman la base de datos de SAP, nótese que si en el campo de la clave no hay un campo de mandante se considera que la tabla es independiente de mandante.

Algo a aclarar es cómo funciona el acceso a los mandantes: Los usuarios se conectan a un mandante y ahí es cuando el sistema le asigna el valor del mandante en cuestión y le permite el acceso a los datos que estén restringidos al mandante que acaba de elegir. Sin embargo, si una tabla es independiente de mandante, esta puede ser accedida desde cualquier mandante al que se conecte el usuario.

Otros comportamientos y propiedades a destacar son:

• Los usuarios se conectan con el sistema SAP a través de mandantes.
• Varios usuarios pueden conectarse simultáneamente al mismo mandante.
• SAP no tolera que varias personas intenten modificar un archivo simultáneamente, solo la primera persona en abrir el archivo puede modificarlo, cualquier otra persona que lo abra mientras se modifica solo podrá visualizar el archivo.
• Teniendo en cuenta que los mandantes están lógicamente separados, estos no pueden acceder a la misma información. Por ejemplo, si dos usuarios en dos mandantes diferentes intentan acceder a un mismo dato en una tabla ellos verán el registro compuesto por sus mandantes. Es decir, verán los datos creados por el mandante al que los usuarios están conectados.

2.1 | Los mandantes estándar

Hay dos tipos de mandantes, este es el primero. Son los mandantes que vienen por defecto en el sistema, hay 3:

• Mandante 000: Es el mandante de referencia. No tiene datos de parametrización empresarial y por lo tanto se usa para hacer copias que serán usadas para crear otros mandantes. Durante los cambios de versión los datos de mandante se actualizan automáticamente en el 000 y los cambios al resto de mandantes se tienen que hacer desde aquí. Nótese que este mandante no se tiene que modificar en ningún aspecto.
• Mandante 001: En esencia es un mandante 000 que puede ser cambiado y que no es afectado por actualizaciones de SAP. Por esto, sirve como una referencia de cómo era la instalación inicial.
• Mandante 066: Este es el mandante del servicio EarlyWatch, el cual existe para garantizar la confidencialidad de los datos reales en el productivo. Es un mandante aislado que será controlado por empleados de SAP cuando se les pide que realizen un servicio de detección de problemas de rendimiento, por esto tienen las autorizaciones justas para desempeñar esta función. Por lo tanto, este mandante tampoco tiene que ser manipulado.

2.2 | Los mandantes propios

El otro tipo de mandantes que se hacen a partir de las copias al mandante 000. El límite de cuantos de estos pueden haber está definida por las capacidades técnicas de la infraestructura y por el diseño en mente, ya que pocos mandantes puede causar conflictos durante la parametrización y muchos mandantes aumentan el tamaño de la base de datos, empeoran el rendimiento y complican la administración del sistema.

Usualmente la mayoría existe para el ambiente de desarrollo, luego una cantidad menor está a disposición del ambiente de testing y solo se deja uno para el ambiente de producción.

El conjunto habitual de mandantes son los siguientes (nótese que: Los números son solo de ejemplo, ya que en la práctica se puede elegir a gusto y conveniencia):

• Mandante 200 - Desarrollo y parametrización: Es el área principal de desarrollo donde los consultores técnicos y funcionales trabajan. En este no hay datos maestros ni transacciones que permitan hacer pruebas, por lo que es necesario pasar los cambios al mandante 220.
• Mandante 210 - Sandbox: Es el área de pruebas de carácter altamente experimental. En caso de que las pruebas den buenos resultados se tiene que repetir a mano en el mandante 200 para que los cambios queden registrados en una orden de transporte (concepto que se explicará más adelante) y se pueda pasar al mandante 220.
• Mandante 220 - Pruebas unitarias: Después del desarrollo y parametrización se efectuarán las pruebas unitarias en este mandante. Aquí si tenemos datos maestros y transaccionales, aunque no son tan fiables, ya que la parametrización puede cambiarse.
• Mandante 300 - Pruebas integrales y control de calidad: Similar al 220, pero en este efectuamos pruebas que evalúan la interacción entre diferentes módulos, el rendimiento y la aprobación del usuario. En este mandante 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 ordenes a producción también lo sea.

3 | Las clases de desarrollo o paquetes

Las clases de desarrollo (o "paquetes") son una forma de organizar todos los nuevos objetos que se crean en SAP, clasificándolos generalmente por módulos o áreas funcionales del sistema. Estas se hacen a través de la transacción SE80.

Poniendo un ejemplo, un objeto sería un archivo y la clase de desarrollo sería la carpeta en la que está dicho archivo.

Existe la clase de desarrollo $TMP, la cual es utilizada para los objetos temporales que no se transportan entre ambientes. O en otras palabras es utilizado para hacer pruebas.

Al momento de crear un nuevo objeto, SAP creará una pantalla para que le asignemos su paquete de pertenencia.