✒️SAP / El landscape de SAP Por Gisela Flores

Landscape de SAP

Al implementarse el sistema SAP en una empresa se establecen lo que se conoce como landscape del sistema SAP. ES la disposición y configuración que implementa al sistema, el cómo será la arquitectura, cuantos servidores se van a utilizar, para que se va a utilizar, entre otras cuestiones. También se van a definir ambientes (servidor donde ha instalado el sistema sap), llamados sistemas en SAP.

AMBIENTE = SISTEMA = SERVIDOR DONDE SE INSTALA SAP

Existen 3 ambientes diferentes en SAP:

_Ambiente de desarrollo DU: utilizado para programación y configuración del sistema. Aquí se crean nuevos programas ABAP que son solicitados a los programadores, también se modifican los programas estándar del sistema utilizando alguna de las herramientas disponibles por SAP. Además, es utilizado por los consultores funcionales para realizar configuraciones del sistema.

_Ambiente de pruebas o testing PU: los programadores lo utilizan para hacer pruebas unitarias de sus desarrollos. Los consultores funcionales lo utilizan para realizar las pruebas integrales de cada uno de los requerimientos. Cuando se realizan capacitaciones o entrenamientos a usuarios de SAP se utiliza este ambiente para trabajar con los datos actualizados.

_Ambiente de producción PA: 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. 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 algunas 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 pueda producir en el ambiente de pruebas. O por los programadores ABAP, en caso de alguna incidencia o error, que requiere ser detectado y solucionado desde el punto de vista técnico.

Distintas opciones de Landscapes de SAP

Ø Landscape de SAP con 1 ambientes o sistema: es el más básico. Consiste en implementar todo el sistema SAP en un solo servidor o equipo, donde todos los roles están alojados en el mismo sistema. Aquí las operaciones de desarrollo, pruebas u producción se ejecutan en paralelo en un solo sistema. Su ventaja es la reducción de costos de hardware y soporte, y que el hardware existente puede ser utilizado, esto implica algunos problemas y riesgos serios.

Ø Landscape de SAP con 2 ambientes o sistema: Todo el sistema SAP se encuentra instalado en dos servidores diferentes. Esta opción de 2 ambientes o sistemas supera algunos 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 separados 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, tareas de optimización y los paquetes de soporte y las notas de SAP también se crean primero en el entorno de desarrollo. Los beneficioso es el tener un sistema estable y una infraestructura de soporte de mayor calidad. Los inconvenientes es que no es posible separar las actividades de desarrollo y los datos de las actividades de prueba y capacitación.

v Tener en cuenta que un escenario o empresa para la que landscape de dos ambientes sería suficiente es aquella 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 pocas modificaciones al estándar SAP

_Hay un número limitado de usuarios concurrente, que acceden al mismo tiempo, con el ambiente de desarrollo y calidad QA.

Ø Landscape de SAP con 3 ambientes o sistema: Aquí 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 menor riesgo, ya que todas las actividades se encuentran separadas.

_El nuevo desarrollo está separado en los entornos de prueba y producción.

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

Los mandantes

Es una instancia creada dentro de un ambiente, que se utiliza para configuración, desarrollo, capacitación o pruebas. Se lo conoce también con el nombre de cliente.

Ø Dentro del ambiente de desarrollo tenemos:

· Demandante 101 que se utiliza para configuración y programación.

· Demandante 102 de sandbox que se utilizara para pruebas inusuales.

· Demandantes 103 que se utiliza para pruebas unitarias de programación

Ø Dentro del ambiente de prueba 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.

Para ver los mandantes existentes de SAP podemos ejecutar la transacción estándar SCC4.

El concepto de mandante se puede definir desde 2 puntos de vista: la visión lógica y visión física.

Ø Visión lógica: aquí se permite que distintos usuarios trabajen con el mismo sistema, sin ningún tipo de interferencia, ya que cada usuario solo dispondrá de acceso para visualizar los datos de aplicación de la empresa, que estén asociados al mandante al cual están conectados.

Se da de esta manera porque en el sistema SAP existen dos tipos de datos diferentes:

· Datos dependientes de mandante: datos de aplicación de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc.) al igual que los datos de parametrización de la empresa.

_Dependientes de mandante porque solo 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 ciertos datos de parametrización de la empresa que son accesibles desde cualquier mandante creado. Cada vez que se precede a la modificación de este tipo de datos, el sistema avisa con un mensaje informativo de que la modificación afectara a todos los mandantes. Se debe tener cuidado al modificar la parametrización independiente de mandante.

Ø Punto de vista físico: La base de datos de SAP está formado por tablas, cuando el usuario navega por las pantallas, el sistema accede a dichas tablas para mostrarle al usuario la información pedida. El mandante es el primer campo clave.

_las tablas de la base de datos que contienen al campo mandante como primer campo dentro de su clave son llamadas dependientes de mandante.

_las tablas que no contienen al campo mandante dentro de su clave se llama independientes de mandante.

Cuando un usuario se conecta a un mandante, el sistema le esta asignando el valor del mandante elegido, con lo que el usuario solo podrá visualizar o modificar los datos de cada tabla en el momento elegido en conexión.

Si una tabla es independiente de mandante, puede ser accedida desde cualquier mandante al que se conoce el usuario.

Los mandantes estándar

Hay dos tipos de mandantes, por un lado, los mandantes estándar que son los ya predeterminados por SAP y se instalan inicialmente al sistema, y luego los mandantes propios que son los creados por el usuario (creado por los administradores de SAP de la empresa cliente).

Hay 3 mandantes estándar

_Mandante 000 de referencia

_Mandante 001 de ejemplo

_Mandante 066 EarlyWatch

Ø Mandante 000: de referencia, No tiene datos de parametrización empresarial, por lo tanto, hay que crear mandantes propios y la parametrización desde cero. Cuando hay cambios de versiones 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í.

v De ninguna manera debe modificarse o borrarse el mandante estándar 000.

Ø Mandante 001: mandante de ejemplo, idéntico al 000, salvo que lo cambiemos nosotros, ninguna actualización de SAP lo va a modificar, distinto al 000. SAP no impone prohibición de cambiarlo o borrarlo.

Ø Mandante 066: su 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 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.

v Este mandante no debe ser borrado ni modificado nunca.

Mandantes propios

A partir del mandante 000 podemos crear tantos mandantes como queramos (según el tamaño de nuestra base de datos). En el ambiente de desarrollo se suelen crear varios mandantes, en pruebas o testing algunos menos y en ambiente de producción solo debe existir un mandante propio.

_Mandante 200 desarrollo y parametrización

_Mandante 210 Sandbox

_Mandante 220 pruebas unitarias

_Mandante 300 pruebas integrales

_Mandante 310 Formación a usuarios finales

_Mandante 320 Maestro de parametrización

_Mandante 400 Productivo

Cada empresa que utiliza SAP puede asignarle el número que quiera a cada mandante propio. A su vez es posible implementar SAP con más o menos mandantes, pero hay que buscar un equilibrio ya que si son pocos podremos tener conflictos durante la parametrización, el desarrollo de programas o las pruebas. Si sin muchos 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.

Ø 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 no transaccionales de manera que la prueba la realizaremos en el mandante 220 después de pasar todos los cambios hechos aquí.

Ø Mandante 210 Sandbox: las pruebas de parametrización las realizamos en el 210 de manera que no interrumpamos el trabajo normal del mandante 200. Los cambios de aquí no se registran en ningún sitio lo cual debemos repetirlo en el 200 para que quede grabado en una orden de transporte.

Ø Mandante 220 pruebas unitarias: los responsables de desarrollo y parametrización efectuaran aquí las pruebas unitarias de los programas. Aquí si que tendremos datos maestros y transaccionales, aunque no sean muy fiables debido a que la parametrización puede cambiarse.

Ø Mandante 300 pruebas integrales y control de calidad: este es similar al 220, con la diferencia de que las pruebas incluyen la interacción entre los diferentes módulos, el rendimiento y la aprobación del usuario.

Ø Mandante 310 formación a usuarios finales o capacitación: una vez que en el mandante 300 salió todo ok, 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: solo es utilizado para 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 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í 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 el productivo realizaremos aquí las cargas iniciales de datos maestros, movimientos e históricos.