![](/cvo_files/imgs_sap_abap/logos/logo_cvo_academy_it.png)
✒️La estructura de los sistemas SAP
La estructura de los sistemas SAP
![La estructura de los sistemas SAP La estructura de los sistemas SAP](https://www.cvosoft.com/cvo_files/imgs_sap_abap/og-images/153.jpg)
Tema 3
Estructura de Sistemas SAP
En esta lección veremos la estructura de datos de un sistema SAP^. Terminos como cliente, customizing (adaptación) dependiente de cliente y customizing inter-cliente (cross-client), datos maestros y de transacciones, datos de usuario y repositorio de objetos serán descriptos.
Por ultimo las opciones para modificar y crear objetos de repositorio serán parte de la lección también.
El software de SAP necesita ser adaptado a los requerimientos específicos de las compañías. ¿Cómo podemos transferir esas adaptaciones desde le sistema de desarrollo al sistema de producción? El esfuerzo de trabajo extra debemos procurar que sea mínimo cuando importamos Support Packages o durante un posible upgrade del sistema. Veremos cómo se relacionan estos en SAP.
Estructura de Datos en un Sistema SAP
Conocer la estructura de datos de un sistema SAP es igualmente importante tanto para los usuarios, desarrolladores y administradores para entender de qué manera un sistema SAP funciona.
Imagen, estructura de datos de un sistema SAP
Cliente 100
Maestro y datos de la transacción.
Cliente dependiente de la customización
Los datos de usuario.
Cliente 200
Maestro y datos de la transacción.
Cliente dependiente de la customización
Los datos de usuario.
Customización transversal del cliente
Repositorio
Los sistema SAP tiene una estructura de datos especifica. Adicionalmente a las configuraciones de negocio (cutomizing) que son relevante únicamente para ciertos clientes del sistema SAP, también contiene configuraciones y el repositorio de objetos que son inter-clientes (cross-client)
El repositorio es el lugar de almacenamiento central para todos los objetos de desarrollo de Workbench ABAP y es inter-cliente. Los objetos de repositorio se almacenan en paquetes (packages)
Los paquetes son contenedores para objetos de desarrollo relacionados semánticamente. Diferentes objetos de desarrollo (programas, tablas, pantallas, módulos de función, clases, etc) pueden estar contenidos dentro de un paquete.
Los paquetes están caracterizados por ciertas propiedades:
Anidado (nesting)
Interfaces (interfaces)
Visibilidad (visibility)
Accesibilidad (accesibility)
Transaccion SPAK, los paquetes son creados y mantenidos con Package Builder, la transacción SPAK.
El grabado y transporte de modificaciones de objetos está controlado por el sistema de Transportes y cambias, que por sus siglas en inglés se denomina CTS (Change and Transport System) utilizando la asignación de objetos de repositorios a paquetes.
Customizing
El termino customizing, que se podría traducir como adaptaciones, describe las configuraciones de negocio de un sistema SAP. Las funciones provistas tantos generales de una compañía como aquella que pueden ser específicas para una industria son adaptadas a los requerimientos específicos de la empresa en el proceso de customizing.
El customizing comprende cosas simples y básicas como la definición de plantas y almacenes hasta cosas más complejas como funciones de compras basadas en planificaciones de producción o liquidación de nómina.
Una gran cantidad de Customizing estándar tal como definiciones de país, lenguaje, uso horario están incluidas por SAP como parte de las instalaciones.
El sistema SAP diferencia entre Customizing dependiente de cliente y Customizing inter-clientes.
Customizing inter-clientes contiene configuraciones que son independientes de una unidad de negocio particular y tienen un validez general. Entre otros incluye el calendario, configuraciones de impresión o el acceso a la ayuda que vimos previamente en una unidad.
clientes
Los sistemas SAP están divididos entre unidades de negocio o clientes, que también se conoce como mandantes.
Un cliente es una unidad comercial, organizaciones y técnica contenida en una sistema SAP y consiste de configuraciones de negocio (customizing dependiente de cliente), sus propios datos maestros y transaccionales y sus propios datos de usuarios.
Los datos de un cliente se conocen como datos dependientes de cliente o específicos de cliente.
Los tipos de datos que son dependientes de un cliente están relacionados entre sí. Por lo tanto, cuando ingresamos información en una aplicación, el sistema verifica si la información ingresada concuerda con la configuración especifica de ese cliente (Customizing) Si hay inconsistencias, la información ingresada en la aplicación es rechazada. Esto nos dice que la información de una aplicación es significativa en términos del negocio solamente en el cliente con el Customizing correspondiente.
Ejemplos de customizing dependiente de cliente son los códigos de compañía, plantas y almacenes.
Datos Maestros y de Transacciones son dependientes del cliente también. Son únicamente validos en el cliente. Esto incluye por ejemplo registros maestros de materiales, órdenes y facturas. Los datos de usuario también son dependientes de cliente.
Varios roles de clientes son utilizados en un sistema SAP. Un cliente de Customizing puede ser configurado para las configuraciones que sean dependientes de cliente en el sistema de desarrollo. En un sistema de calidad, un cliente puede crearse para propósitos de pruebas y en un sistema de producción, un cliente para trabajo productivo. Los roles se asignan a los clientes desde la transacción SCC4.
Repositorio de objetos.
Imagen: ajustes a las estructuras de datos
Customizing
Cliente 100
Maestro y datos de la transacción.
Cliente dependiente de la customización
Los datos de usuario.
Customización transversal del cliente
Repositorio: Modificacion, Enhancement, Desarrollo de cliente.
Así como el Customiziing dependiente de cliente e inter-cliente, es posible realizar ajustes adicionales a la estructura de datos de un sistema SAP también. Se pueden realizar cambios o mejoras en el repositorio de objetos. Los cambios o mejoras al repositorio pueden realizarse en diferentes formas:
Extensión del repositorio: a través de desarrollos del cliente (customer developments) en el sistema SAP, es posible crear objetos de repositorio propios tales como tablas, programas, transacciones, etc.
Todos los desarrollos del cliente son usualmente realizados en el espacio de nombres del cliente y deben comenzar con la letra Y o Z, entre otras cosas. Es posible, de todas formas, también requerir un nombre de espacio propio a SAP que empiece y termine con el carácter / Este tendrá un máximo de ocho caracteres incluyendo /, tal como / Firma/
Todos los objetos que se crean bajo el nombre del espacio tendrán un nombre que empezará con / Firma/, tal como /Firma/Evaluacion1.
Mejoras de cliente (custome enhancement): el repositorio es suplementado por sub-objetos del cliente aquí, por ejemplo, un programa estándar de SAP puede ser suplementado con código propio del cliente en puntos predefinidos en el código conocidos como customer exits (salidas de cliente) las estructuras de tablas pueden se ampliadas con campos propios utilizando appends (agregados)
Modificaciones al estándar del sistema SAP: cambios a objetos estándar de SAP (programas, tablas, estructuras) se conocen como modificaciones. El repositorio de objetos que vienen junto con el sistema SAP en este caso no es extendido sino directamente modificado.
Varios tipos de modificaciones son posibles, dependiendo de tipo de objeto:
Modificaciones manuales
Modificaciones con el asistente de modificaciones
Modificaciones con el asistente de notas.
Landscape de Tres Sistemas
SAP recomienda un landscape de sistemas múltiples basado en la conformación de la estructura de datos de un sistema SAP, en la que existe solos un repositorio de objetos por sistema. Nunca se debe desarrollar en un sistema SAP que se utiliza también como productivo. En circunstancias normales un landscape de tres sistemas es suficiente para la operación.
Imagen Ladscape de tres sistemas
Escenario del sistema: DEV, TES PROD no hay un retorno de ejecución estable – los cambios ponen en peligro la operación de producción.
Escenario del sistema: DEV TEST No hay un retorno de prueba estable, PROD No hay un retorno de ejeccion estable.
Escenario del sistema: DEV, DEV – TEST,QAS – PROD,PRD
Modificacion Enhancement Desarrollo del cliente.
Como el repositorio de objetos es inter-cliente, SAP recomienda que no se desarrolle en un sistema que al mismo tiempo se utiliza para trabajar en forma productiva, ya que esto conlleva un riesgo de una posible inconsistencia de datos. Si se van a realizar cambios al repositorio, SAP recomienda que se utilice al menos dos, pero idealmente tres sistemas separados. Un sistema para desarrollos, un segundo sistema para pruebas y aseguramiento de la calidad y un tercer sistema productivo.
Un landscape de tres sistemas facilita el siguiente proceso recomendado:
Se realizan desarrollos propios de cliente en el repositorio de objetos y las configuraciones (Customizing) requeridas en el sistema de desarrollo. Las configuraciones de Customizing realizadas, así también como todos los cambios (desarrollos, mejoras y modificaciones) al repositorio se registran en el sistema de desarrollo.
Estos cambios son luego transportados al sistema de calidad y se verifican allí, sin influenciar la operación de producción. Una prueba de aceptación usualmente no es posible realizarse en el sistema de desarrollo, ya que los datos reales no están disponibles en este sistema para una prueba real.
La razón principal, de todas formas, es que el sistema de desarrollo no ofrece un ambiente estable para una prueba comprensiva e integral: muchos desarrolladores trabajan en un número de diferentes proyectos al mismo tiempo.
Luego de que se han probado satisfactoriamente, todos los objetos y configuraciones en el sistema de calidad pueden ser transportados al sistema de producción. Diferentes clientes pueden ser creados para propósitos específicos. Si realizamos un Customizing dependiente de cliente en el sistema de desarrollo y queremos verificarlo antes de transportarlo a los demás sistemas, puede utilizarse un cliente de prueba en el mismo sistema de desarrollo para tal propósito.
Clientes con roles específicos son usualmente creados en cada sistema: un cliente de desarrollo en el sistema de desarrollo, un cliente para pruebas en el sistema de calidad y un cliente productivo en el sistema de producción.
Generalmente, los clientes principales de cada sistema tienen el mismo número ya que por defecto cuando transportamos el cliente origen es igual al cliente destino. Esto último de todas formas no es obligatorio.
 
 
 
Sobre el autor
Publicación académica de Lina Marcela Zapata Suarez, en su ámbito de estudios para la Carrera Consultor Basis NetWeaver.
Lina Marcela Zapata Suarez
Profesión: Ingeniera Informática. - Colombia - Legajo: AB47Z
✒️Autor de: 109 Publicaciones Académicas
🎓Egresado de los módulos:
Presentación:
Ingeniera informática.
Certificación Académica de Lina Zapata