PROMO AGOSTO en CVOSOFT United States Of America: 💎Calidad, 🔥Bonificaciones, 🥶Precios Congelados y MÁS!

 X 

✒️El landscape de SAP

El landscape de SAP

El landscape de SAP

Lección 1. El landscape de SAP

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

El landscape, es la disposición y configuraciones de los servidores de SAP en una empresa determinada, es decir, como será la arquitectura, cuantos servidores se van a utilizar, para que se va a utilizar cada uno, etc.

Dentro de un landscape, se van a definir Ambientes, también llamados Sistemas. Un ambiente es un servidor donde se ha instalado el sistema SAP.

Ambiente = Sistema = Servidor donde se instala SAP.

Básicamente existen 3 ambientes diferentes en SAP:

· Ambiente de desarrollo (DU): es usado para la programación y configuración del sistema. Aquí es donde se crean los nuevos programas ABAP que se solicitan a los programadores. Aquí también se modifican los programas estándar del sistema, usando alguna de las herramientas disponibles. También es usado por los consultores funcionales.

· Ambiente de pruebas o testing (PU): se usa para realizar pruebas unitarias de sus desarrollos. También acceden los consultores funcionales para realizar pruebas integrales. Cuando se realizan capacitaciones o entrenamiento a usuarios de SAP, se usa este ambiente para trabajar con 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. Los datos del ambiente PA son sensibles para la empresa, por eso se restringe al máximo el acceso a todos los usuarios. En ocasiones los consultores funcionales acceden a este sistema para realizar pruebas puntuales sobre algún error que no se pueda reproducir en el ambiente de pruebas. Aun menos frecuentemente, este ambiente es usado por los programadores ABAP.

Cada una X cantidad de tiempo, los datos de la base de datos del ambiente de pruebas, son actualizados 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 datos de la base de datos del ambiente de prueba con la información almacenada en el ambiente de producción. Esto se conoce con el nombre de refresh del ambiente de pruebas. 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.

Las distintas opciones de landscapes de 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, prueba y producción se ejecutan en paralelo en un solo sistema. La ventaja de esta radica en la reducción de los costos de hardware y soporte, y que el hardware existente puede ser utilizado, pero también implica algunos problemas o riesgos.

Con todas las actividades en un solo sistema, toda la personalización y el desarrollo se realizan en el sistema de producción, los nuevos paquetes de soporte (modificaciones legales) y las notas de SAP (son soluciones que responden a las preguntas que reportan los usuarios de SAP) se aplican directamente en producción. Las pruebas y capacitaciones también tienen lugar en el ambiente de producción. Los datos de prueba y capacitación se mezclan con los datos de producción y existe alto riesgo de conflictos.

Landscape de SAP con 2 ambientes

Todo el sistema SAP se encuentra instalado en 2 servidores diferentes.

Esta opción 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, lo que resulta en la separación de los datos tambié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. Todo esto conduce a un sistema más estable y a una infraestructura de mayor calidad. Los inconvenientes de esta opción son que las actividades de prueba y capacitación tienen lugar en el ambiente de desarrollo. No es posible separar las actividades.

Una empresa para la cual un landscape de dos ambientes será suficiente es aquella en donde:

· No se producen actividades significativas de desarrollo, pruebas y capacitación al mismo tiempo

· Hay muy pocas modificaciones al estándar de SAP

· Hay un número limitado de usuarios concurrentes en el ambiente de desarrollo y calidad, es decir que acceden al mismo tiempo

Landscape de SAP con 3 ambientes

En esta opción, todas las actividades de desarrollo, capacitación, prueba y producción, y sus respectivos 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. El nuevo desarrollo está separado de 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.

Para empresas en las cuales los procesos comerciales se utilizan a diario, SAP recomiendo un landscape de 3 ambientes.

En muchas empresas grandes, se suele implementar un landscape de 4 ambientes o sistemas.

Los mandantes

Dentro de cada ambiente o sistema de SAP, existen distintos mandantes, siendo independietnes los datos que se ven en cada mandante dentro del mismo ambiente.

Los mandantes son instacias creadas dentro de un ambiente, que se usan para la configuracion, desarrollo, capacitacion o pruebas. Se lo conoce en SAP con el nombre de cliente.

Ejemplo de posible distribucion de ambientes y mandantes en una empresa:

imagen

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

El concepto de mandante se puede definir:

Desde el punto de vista logico: no e smas que una unidad organizativa divisoria de la empresa, que permite que distintos usuarios esten trabajndo en el mismo sistema, sin ningun tipo de interferencia mutua, ya que cada usuario solo dispondra de acceso para ver y actualizar los datos de aplicacion de la empresa que esten asociados al mandante al cual esten conectados. Esto es asi ya que en SAP existen 2 tipos de datos:

Datoa dependientes de mandante:se engloban aqui los datos de aplicacion de la empresa (datos de clientes, proveedores, pedidos, facturas, cuentas contables, etc) asi como tambien la mayoria de los datos de parametrizacion de la empresa. Estos datos solo sona ccesibles desde el mandante en el que se crearon. Son los tipos de datos mas habituales en un sistema SAP.

Datos independientes de mandante: se engloban aqui ciertos datos de la parametrizacion de la empresa que son accesibles desde cualquier mandante creado. Este titpo de datos son los menos numerosos. Cada vez que se va a proceder a la modificacion de este tipo de datos, el sistema avisa con un mensaje informativo que la modificacion afectara a todos los mandantes. Se debe ser especialemnte 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, es el sistema el que accede a dichas tablas para mostrarle al usuario la infromacion pedida. El mandante es el primer campo clave de la mayoria de las tablas que conforman la base de datos de SAP. Las tablas que contienen al mandante como primer campo dentro su clave son llamadas dependientes de mandante, las tablas que no contienen al campo mandante dentro de su clave son llamadas nidependiente de mandante.

Cuando un usuario se conecta aun mandante, el sistema le esta asignando en es emomento el valor del mandante elegido, con lo que el usuario solo podra acceder a ver o modificar los datos de cada tabla que tenga como mandante el que ha elegido en su tiempo de conxion.

Sin embargo, si una tabla e sindependiente de mandante, puede ser accedida desde cualquier mandante alq ue se concecte un usuario. Esto se consigue de manera transaparente para el usuario e incluso para el desarrollador ya que es el propio sistema el que traduce los accesos a las tablas.

Ejemplos:

Situación 1: los usuarios user1 y user2 estan ambos conectados al mandante 015 de un mismo sistema. Mientas user1 esta modificando la factura 1000, user 2 solo podra acceder en modo visualizacion ya que la factura esta siendo bloqueada por user1, sin embargo, cuando user1 termine de modificarla, user2 podra ver la modificacion de user1 y modificarla si quiere luego.

Situacion2: user1 esta conectado al mandante 015 y user2 al 016 del mismo sistema. Ahoa ambos usuarios no pueden acceder a la misma informacion ya que sus conexiones al sistema estan separadas, user1 accede a la factura 1000 de su mandante y user2 puede acceder al mismo tiempo a la facturra 1000 de su mandante (si existe), 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 esta accediendo a la tabla de facturas, pero en cada caso accede al registro compuesto por el mandante de conexion del usuario y el numero de factura.

imagen

Asi entonces, cuando user1, conectado al mandante 015 solicite la factura 1000, el sistema le muestra la factura con descripcion X, mientras que si user2, conectado al mandante 016 solicita la factura 1000, el sistema le mostrara la factura con descripcion Z.

Los mandantes estandar

Podemos decir que existen dos tipos de mandantes bien diferenciados: los estándar y los propios.

Cualquier sistema SAP se instala incialmente con 3 mandantes estandar:

Mnadante 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 amndante 000.

Mandante 00: es el mandante de ejemplo. Inicialemtne 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 restriccion de cambiarlo o borrarlo.

Mandante 066: es el mandante del servicio EarlyWatch. Su objetivo es garantizar la confiedncialidad de nuestros datos reales en productivo. Este mandante esta aislado y es al cual se conecta SAP cuale 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. Este mandante tampoco debe ser borrado ni modificado nunca.

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 produccion solo debe existir un mandante propio.

A continuacion vamos a describir los amndantes que se crean habitualemtne y cuales son sus fucniones. Aunque veremos que tienen un numero asignado, las empresas pueden asignarle el nombre que ellas quieran.

Es posible eimplementar SAP con mas o menos mandantes de los indicados, pero hay que buscar el equilibrio entre muchos mandantes y pocos. Con pocos, podemos tener conflictos durante la parametrizacion, el desarrollo de programas o las pruebas, con muchos, estaremos aumentaño eñ tamaño de la base de datos y empeorando el rendimiento, ademas de requerir un mayor esfuerzo en los procedimeintos de administracion de sistemas.

Mandante 200, Desarrollo y Parametrizacion: aqui 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 ene l mandante 220 depsues de pasar por todos los cambios hechos aqui.

Mandante 210, Sandbox: las pruebas inusuales de parametrizacion las realizamos aqui de manera que no interrumpamos el trabajo normal del amndante 200. Los cambios que hagamos aqui no se registran en ningun sitio e manera que si probamos algo en lo que nos va bien, debemos repetirlo 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 mandate 220.

Mandante 220, Pruebas Unitarias: los responsables de desarrollo y parametrizacion efectuaran aqui las pruebas unitarias de los progrmas. Aqui si que tenremos datos maestros y transaccionales, aunque no seran muy fiables debido a que la parametrizacion puede cambiarse.

Mandante 300, Pruebas integrales y control de calidad: la funcion de este mandante es similar a la del 220 pero con la diferencia de que las pruebas incluyen la interaccion entre los diferentes modulos, el rendimiento y la aprobacion del ussuario. 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 lo sea.

Mandante 310, Formacion a usuarios finiales o capacitacion: una vez superadas las pruebas correspondientes al amdnante 300, pasamos el prototipo aqui para que los usuarios finales reciban 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.

Mandante 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 al personal no autorizado. Para que se cumpla su funcion se deben transportar los cambios al mandante 400 y al 320 al mismo tiempo y mantenerlos siempre sincronizados.

Mandante 400, Productivo: aqui es donde se lelva a cabo la explotacion real del sistema. Este es el unico mandante propio que debe existir en el ambiente productivo. Antes del arranque en productivo realizaremos que las cargas inciales de datos maestros, movimientos e historicos.


 

 

 


Sobre el autor

Publicación académica de Ornella Mollani Norverto, en su ámbito de estudios para el Carrera Consultor Basis NetWeaver.

SAP Senior

Ornella Mollani Norverto

Profesión: Ingeniera Química - Argentina - Legajo: MA29J

✒️Autor de: 38 Publicaciones Académicas

🎓Egresado del módulo:

Disponibilidad Laboral: FullTime

Presentación:

Soy ing. química (utn-frc, argentina). quisiera formar parte de una empresa dónde poder crecer en el ámbito it, integrando con mis conocimientos ingenieriles y mis aptitudes de liderazgo e innovación.

Certificación Académica de Ornella Mollani