✒️El landscape de SAP

Ambientes, Mandantes y Clases de desarrollo o Paquetes

1 Ambientes y Mandantes

Como en todos los ámbitos de desarrollo de software, se configuran en SAP tres ambientes; uno de desarrollo, uno de pruebas y otro de producción, que es donde se utilizan las aplicaciones desarrolaldas y probadas satisfactoriamente.

=> Un Ambiente es un servidor donde ha sido instalado el sistema SAP.

Por ejemplo: el ambiente de desarrollo se instala en el servidor 1, el ambiente de pruebas se instala en el servidor 2 y el ambiente de producción se instala en el servidor 3.

Los programadores tendremos acceso para desarrollar nuestros programas en el ambiente de desarrollo.

Accederemos al ambiente de testing o pruebas para probar de forma integral y con datos actualizados nuestros programas, y muy ocasionalmente ingresaremos al ambiente de producción en caso de que se haya reportado alguna incidencia o error que requiere de nosotros para ser detectado y solucionado.

A su vez, en cada ambiente existen distintos mandantes, siendo independientes los datos que se visualizan en cada mandante dentro del mismo ambiente. Por ejemplo, puede existir el mandante 100, que se utiliza para la configuración del sistema, el mandante 200 que se utiliza para el desarrollo de las aplicaciones y el mandante 300, que se utiliza para pruebas unitarias dentro del ambiente de desarrollo.

=> El Mandante es una instancia creada dentro de un ambiente, que se utiliza para configuración, desarrollo o pruebas.

Por último, existen dentro de cada mandante dos tipos de objetos: los que son independientes de mandante y los que son dependientes de mandante. Por ejemplo, un programa es independiente de mandante ya que si lo creamos en el mandante 200 el programa también va a existir en los mandantes 100 y 300.

Los datos de una tabla son dependientes de mandante, ya que si a esta tabla le ingresamos registros en el mandante 200, estos no van a existir en los restantes mandantes dentro del mismo ambiente.

Audio: Como mencionamos antes, cuando se instala SAP se crean 3 ambientes: desarrollo, testing y producción. Cada uno de estos ambientes se ubicarán en diferentes servidores por una cuestión de seguridad de la información. A su vez dentro de cada ambiente existe lo que se conoce como mandante. Por ejemplo, dentro del ambiente de desarrollo, existen los mandantes de configuración, desarrollo y pruebas. Cuando trabajamos como programadores, trabajeremos dentro del ambiente de desarrollo y dentro de este en el mandante de desarrollo. Ahora bien, como programadores podemos crear diferentes tipos de objetos: programas, tablas de base de datos, registros de tabla de base de datos, formularios, etc. Decimos que los programas son independientes de mandante, ya que si lo creamos en el mandante de desarrollo, automáticamente también se crea en los demás mandantes del mismo ambiente. Decimos que los registros de tablas base de datos son dependientes de mandante, ya que insertamos un registro de tabla de base de datos en el mandante de desarrollo y deseamos que ese mismo registro también exista en los demás mandantes del mismo ambiente, entonces debemos transportarlo, es decir, no se generará automáticamente.

En el gráfico que vemos a continuación tenemos una posible distribución de los mandantes y los ambientes dentro de una instalación de SAP.

<< imagen 1.1 >>

Los datos de las bases de dtos y los formularios son dependientes del mandante en el que fueron creados.

Audio: Expliquemos un poco los 3 perfiles de usuarios definidos en el gráfico anterior, y cuáles son las responsabilidades de cada uno de ellos. Nosotros como consultores desarrollaremos los programas en el ambiente de desarrollo, particularmente en el mandante 101. Una vez que finalizamos el desarrollo, ingresaremos al mandante 103 para realizar las pruebas unitarias de los programas que desarrollemos. Las pruebas unitarias consisten en probar que los programas realizan lo que decíamos que harían. Debido a que los programas son indepentientes de mandante, cuando entremos al mandante 103 veremos exactamente el mismo programa que realizamos en el mandante 101, si necesidad de transportarlo. Más adelante veremos como funciona el sistema de transportes de SAP. Tras concluir las pruebas unitarias, solicitaremos el transporte del programa al ambiente de testing, particularmente al mandante 210. En el mandante 210 de testting, los usuarios claves o los analistas funcionales, realizarán las pruebas integrales de los programas que desarrollamos. Los usuarios clave son los usuarios que mejor conocen los procesos o el funcionamiento de la empresa, es por eso que se los colocan en posiciones cruciales dentro de las implementaciones de SAP. Finalmente cuando las pruebas integrales concluyen, solicitaremos el transporte de los programas al ambiente de producción, particularmente al mandante 410 que es adonde lo utilizarán los usuarios finales. Un usuario final puede ser un cajero que atiende al público, o personal de cualquier área de la empresa que trabaja internamente.

2 Mandantes Estándar

Cualquier sistema SAP se instala inicialmente con tres mandantes estándar:

<< imagen 2.1 >>

Las funciones de los mandantes estándar son las siguientes:

- Mandante 000: es el mandante de referencia. No contiene datos de parametrización empresarial y por lo tanto las creaciones de mandantes propios se deben hacer como copias de este para asegurarnos que empezamos la parametrización de cero.

Durante un cambio de versión SAP los datos dependientes de mandante se actualizan automáticament en el 000 y los cambios al resto de mandantes se deben hacer desde aquí.

=> No debe modificarse o borrarse ningún aspecto del mandante 000.

- Mandante 001: es el mandante de ejemplo. Inicialmente es idéntico al 000 y salvo que lo cambiemos nosotros, ninguna actualización de SAP lo va a modificar, al contrario de lo que ocurre con el 000. Siempre lo podemos tener como ejemplo de la instalación inicial aunque SAP no impone ninguna prohibición de cambiarlo o borrarlo.

- Mandante 066: es el mandante del servicio EarlyWatch, cuyo 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 que nos realice 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. Este mandante tampoco debe ser borrado ni modificado nunca.

3 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 integración o testing algunos menos, y en el ambiente de producción solo debe existir un mandante propio.

A continuación vamos a describir los mandantes que se crean habitualmente y cuáles son sus funciones. En número asignado en el ejemplo se ha hecho para facilitar la diferenciación entre ellos, pero en nuestro sistema SAP nosotros podemos elegir libremente el número asignado a cada mandante propio.

<< imagen 3.1 >>

Es posible implementar SAP con más o menos mandantes de los indicados, pero hay que buscar el equilibrio entre muchos y pocos. Con pocos mandantes podemos tener conflictos durante la parametrización, el desarrollo de programas o las pruebas, pero con muchos mandantes 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.

Las funciones de los mandantes propios son las siguientes:

- Mandante 200: Desarrollo y parametrización en el sistema de desarrollo. Aquí iniciamos nuestro prototipo de empresa y creamos los primeros desarrollos a medida que sean necesarios. Los programadores y consultores de aplicación trabajan en este sistema. No tendremos datos maestros ni transaccionales de manera que las pruebas las realizaremos en el mandante 220 después de pasar todos los cambios hechos aquí.

- Mandante 210: se lo conoce como Sandbox. Las pruebas inusuales de parametrización las realizaremos en el 210 de manera que no interrumpamos el trabajo normal del mandante 200. Los cambios que hagamos aquí no se registran en ningún sitio de manera que si probamos algo que funciona correctamente debemos repetirlo a mano en el 200 para que quede grabado en una orden de transporte y se pueda psar al mandante de pruebas unitarias. Periódicamente y para mantener el mandante limpio se hará una copia de refresco desdel el 220.

- Mandante 220: Pruebas unitarias en desarrollo. Los responsables de desarrollo y parametrización efectuarán aquí las pruebas unitarias del prototipo que se está creando. Aquí si que tendremos datos maestros y transaccionales, aunque no serán muy fiables debido a que la parametrizació puede cambiarse.

- Mandante 300: Pruebas integradas y control de calidad en integración. La función de este mandante es similar a la del 220 pero con la diferencia de que las pruebas incluyen la interacción entre los diferentes módulos, 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. Una vez superadas las pruebas correspondientes al mandante 300, pasamos el prototipo aquí para que los usuario sfinales reciban lo 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. Este mandante se usa únicamente como referencia para poder consultar la parametrización que tenemos en productivo sin tener que acceder a la máquina de productivo, no obligándonos a dar acceso a la misma a personal no autorizado.

Para que cumpla su función se deben transportar los cambios al mandante 400 y 320 al mismo tiempo y tenerlos siempre sincronizados.

- Mandante 400: Mandante productivo. Aquí es donde se lleva a cabo la explotación real del software. Este es el único mandante propio que debe existir en el ambiente productivo. Antes del arranque en productivo realizaremos aquí las cargas iniciales de datos maestros, movimientos e históricos.

Audio: Lo que presentamos en esta lección es la estructura de como se compone la estructura de los ambientes y mandantes en un instalación de SAP. En todas las instalaciones vamos a encontrar separados los 3 ambientes de desarrollo, testing y producción, más el también ambiente de QA, es decir, de aseguramiento de la calidad, que se utilizará para pruebas de mayor nivel antes de pasar el desarrollo al ambiente de producción. Siempre por cuestiones de seguridad de la información, cada ambiente se instalará en un servidor diferente. Los números asignados a los mandantes propios son ilustrativos, es decir, en cada instalación se colocarán los números de mandantes que le parezca al equpo de implementación de SAP. En general siempre se tratará de crear la menor cantidad de mandantes, ya que cada mandante que se cree implicará su mantemiento, es decir cada tanto tiempo será necesario actualizar sus datos y configuraciones, o realizar alguna otra tarea de mantenimiento.

4 Clase de desarrollo o Paquete

=> La Clase de Desarrollo o también llamada Paquete, es una forma de organizar todos los nuevos objetos que se crean en SAP, clasificándolos generalmente por módulos.

Poniendo un 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, es decir para pruebas. Si posteriormente queremos que el objeto temporal pueda transportarse a otros ambientes habrá que asignarlo a una clase, lo cuál podemos hacerlo desde el menú: Pasar a >> entrada catálogo de objetos, y en este punto modificar la clase $TMP por la clase de desarrollo o paque correspondiente.

Al momento de crear un nuevo objeto en el sistema, SDAP nos proporcionará la pantalla que vemos a continuación para que le asignemos el Paquete al que pertenece. En este caso, el paquete es Z_WEB_SERVICE.

<< imagen 4.1 >>

Como vemos, se indicará el nombre del programa ABAP (u objeto que estemos creando), el Paquete o Clase de desarrollo al que asignar el programa, el ambiente asociado y el idioma de conexión, junto con el usuario responsable de la creación del objeto.

=> A través de la transacción SE80 se crean las Clases de Desarrollo o Paquetes.

Favorito:

Está publicación ha sido agregada a sus favoritos por: Lorena Amoretti