✒️El landscape de SAP

El Landscape de SAP

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

Es la disposicion y configuraciones de los servidores de SAP en unaempresa que implementa el sistema, es decir, como sera 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, tambien llamados sistemas en SAP. El Ambiente es un servidor donde ha sido instalado el sistema SAP.

Ambiente=Sistema=Servidor en donde se instala SAP

Basicamente existen 3 ambientes diferentes en SAP:

• Ambiente de desarrollo: es utilizado principalmente para programacion y configuracion del sistema. Es donde se crean los nuevos programas ABAP que son solicitados a los programadores, ya que el sistema estandar no satisface las necesidades especificas de la mepresa. Tambien aqui se modifican los programas estandar del sistema utilizando alguna de las herramientas disponibles por SAP. Tambien es utilizado por los consultores funcionales para realizar configuraciones del sistema.
• Ambiente de pruebas o testing: es utilizado principalmente para realizar pruebas. Los programadores acceden al ambiente de testing para realizar las llamadas pruebas unitarias de sus desarrollos. Tambien 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 produccion: es donde el usuario final utiliza las transacciones estandar del sistema y aquellas transacciones Z creadas a medida que han sido desarrolladas y probadas satisfactoriamente. Los datos existentes en el ambiente de produccion son sumamente sensibles para la empresa, por eso se restringe al maximo el acceso a todos los usuarios. En ocasiones los ocnsultores funcionales acceden al ambiente productivo para realizar pruebas puntuales sobre algun error que haya surgido en el sistema y que no se pueda reproducir en el ambiente de pruebas. Menos frecuentemente el ambiente de produccion 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 tecnico.

Las distintas opciones de landscapes de SAP

• Landscape con 1 ambiente o sistema: consiste en implementar todo el sistema SAP en un solo servidor o equipo, en donde los roles estan alojados en el mismo sistema. Las opciones de desarrollo, pruebas y produccion se ejecutan en paralelo en un solo sistema. La ventaja es la reduccion 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 personalizacion y el desarrollo se realizan en el sistema de produccion, y los nuevos paquetes de soporte y las notas de SAP se aplican directamente en produccion. Las pruebas y capacitacion tambien tienen lugar en el sistema de produccion. Los datos de prueba y capacitacion se mezclan con los de produccion y existe un alto riesgo de conflictos.
• Landscape con 2 ambientes o sistemas: todo el sistema SAP se encuentra instalado en dos servidores diferentes. Supera algunos de los riesgos inherentes a la opcion del sistema unico, al dividir la produccion de los entornos de prueba y desarrollo. Los inconvenientes son que las actividades de prueba y capacitacion tienen lugar en el sistema de desarrollo. No es posible serparar completamente las actividades de desarrollo y los datos de las actividades de prueba y capacitacion. Una empresa que el landscape de dos ambientes seria suficiente seria aquella donde no se producen actividades significativas de desarrollo, puebas y capacitacion al mismo tiempo en el sistema combinado de desarrollo y calidad QA, hay muy pocas modificaciones al estandar SAP, hay un numero limitado de usuarios concurrentes, es decir que acceden al mismo tiempo en el ambiente de desarrollo y calidad QA.
• Landscape con 3 ambientes o sistemas: todas las actividades de desarrollo, capacitacion, prueba y productivas, y sus datos, estan completeamente separados en sistemas o ambientes dedicados. Representa el menor riesgo ya que todas las actividades se pueden realizar en paralelo a sus respectivos ambientes o sistemas. La desventaja de esta opcion son los mayores costos de infraestructura y administracion. SAP recomienda usar el landscape de 3 ambientes para empresas en donde los procesos comerciales se utilizan a diario.

Los mandantes

Dentro de cada ambiente de SAP, existen distintos mandantes, siendo independientes los datos que se visualizan en cada uno dentro del mismo ambiente.

Es una instancia creada dentro de un ambiente que se utiliza para configuracion, desarrollo, capacitacion o pruebas. Se lo conoce tambien en SAP con el nombre del cliente.

Si deseamos ver los mandantes existentes en SAP podemos ejecutar la transaccion estandar SCC4.

El concepto de mandante se p uede definir desde 2 puntos de vista distintos pero complementarios: Vision Logica y Vision Fisica.

Desde el punto de vista Logico: el mandante no es mas que una unidad organizativa divisoria de la empresa, que permite que distintos usuarios esten trabajando en el mismo sistema, sin ningun tipo de interferencia mutua, ya que cada usuario solo dispondra de acceso para visualizar y actualizar los datos de aplicaciones de la empresa que esten asociados al mandante al cual estan conectados.

Esto es asi porque en el sistema SAP existen 2 tipos de datos diferentes:

• Datos dependientes de mandante: se engloban los datos de aplicacion de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc) asi como la mayoria de los datos de parametrizacion de la empresa. Se llaman dependientes de mandante porque solo son accesibles desde el mandante en el que se crearon. Estos tipos de datos son lo mas habituales en un sistema SAP.
• Datos independientes de mandante: se engloban los datos de la parametrizacion 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 modificacion de estos datos, el sistema avisa con un mensaje informativo de que la modificacion afectara a todos los mandantes, se debe ser especialmente cuidadoso al modificar la parametrizacion independiente de mandante.

Desde el punto de vista fisico: la base de datos de SAP esta formada por tablas. Cuando el usuario navega por las pantallas de SAP, el sistema accede a dichas tgablas para mostrarle al usuario la informacion pedida. El mandante es el primer clampo clave de la mayoria de las tablas que conforman la base de datos de SAP. Las tablas que contienen al campo mandante como primer campo dentro de su clave son las llamadas dependientes de mandante. Las 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 esta asignando en ese momento el valor del mandante elegido, con lo que el usuario solo podra acceder a visualizar o modificar los datos de cada tabla que tengan como mandante el que ha elegido en tiempo de conexion. 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.

Los mandantes estandar

Existen 2 tipos de mandantes bien diferenciados: los mandantes estandar, que son los que ya vienen con SAP ucando se instala el sistema, y los mandantes propios, que son los creados por el usuario, es decir por los administradores de SAP de la empresa cliente.

Cualquier sistema SAP se instala inicialmente con tres mandantes estandar:

• Mandante 000: es el mandante de referencia. No contiene datos de parametrizacion empresarial y por lo tanto las creaciones de mandantes propios se deben hacer como copias de este para asegurarnos que empezamos la parametrizacion desde cero. Durante un cambio de version de SAP los datos dependientes de mandante se actualizan automaticamente en el 000 y los cambios al resto de mandantes se deben hacer desde aqui. No debe modificarse o borrarse ningun aspecto del mandante estandar 000.
• Mandante 001: es el mandante de ejemplo. Es identico al 000 y salvo que lo cambiemos nosotros, ninguna actualizacion de SAP lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalacion inicial, aunque SAP no impone ninguna prohibicion de cambiarlo o borrarlo.
• Mandante 066: es el mandante del servicio EarlyWatch, cuyo objetivo es garantizar la confidencialidad de nuestros datos reales en productivo. Esta aislado y es al cual se conecta SAP cuando le pedimos que nos realice un servicio de deteccion de problemas de rendimiento. Los usuarios de este mandante tienen las autorizaciones minimas para poder ejecutar el informe de rendimiento. Tampoco debe ser borrado ni modificado nunca.

Los mandantes propios

A partir del mandante de referencia 000 podemos crear tantos mandantes como queramos. En el ambiente de desarrollo se suelen crear varios mandantes, en pruebas o testing algunos menos y en el ambiente de produccion solo debe existir un mandante propio. Cada empresa que utiliza SAP puede asignarle el numero que quiera a cada mandante propio.

Mandantes que se crean habitualmente (numeros de ejemplo):

• 200 Desarrollo y parametrizacion: se crean los desarrollos a medida que sean necesarios. Los consultores tecnicos y funcionales trabajan en este sistema. No tendremos datos maestros ni transaccionales de manera que las pruebas las realizaremos en el mandante de pruebas unitarias despues de pasar todos los cambios hechos aqui.
• 210 Sandbox: las pruebas inusuales de parametrizacion se realizan aqui de manera que no interrumpamos el trabajo normal del mandante 200. Los cambios que hagamos aqui no se registran en ningun sitio de manera que si probamos algo en lo que nos va bien debemos repertirlo a mano en el 200 para que quede grabado en una orden de transporte y se pueda pasar al mandante de pruebas unitarias. Periodicamente y para mantener el mandante limpio se hara una copia o refresh desde el mandante 200.
• 220 Pruebas unitarias: los responsables de desarrollo y parametrizacion efectuaran aqui las pruebas unitarias de los programas. Aqui si que tendremos datos maestros y transaccionales, aunque no seran muy fiables debido a que la parametrizacion puede cambiarse.
• 300 Pruebas integrales y control de calidad: la funcion es similar a la del 220 pero con la diferencia que las pruebas incluyen la interaccion entre los diferentes modulos, el rendimiento y la aprobacion del usuario. Tambien se comprueba que el paso de las ordenes de transporte desde el ambiente de desarrollo sea correcto como garantia de que el paso de esas mismas ordenes a produccion tambien lo sea.
• 310 Formacion a usuarios finales o capacitacion: una vez superadas las pruebas correspondientes al mandante 300, pasamos al prototipo aqui para que los usuairos finales reciban los cursos de formacion y tengan un sitio donde poder seguir practicando despues. De esta manera los datos maestros y transaccionales que crean no nos interfieren en nuestro trabajo habitual.
• 320 Maestro de parametrizacion: se usa unicamente como referencia para poder consultar la parametrizacion que tenemos en productivo, sin tener que acceder al sistema productivo, no obligandonos a dar acceso a la misma a personal no autorizado. Para que cumpla su funcion se deben transportar los cambios al mandante 400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.
• 400 Productivo: es donde se lleva a cabo la explotacion real del sistema. Es el unico mandante propio que debe existir en el ambiente productivo. Antes del arranque en productivo realizaremos aqui las cargas iniciales de datos maestros, movimientos e historicos.