- Estructura de datos de un sistema SAP
- Opciones para modificar y crear objetos de repositorio
- Transferencia de adaptaciones de DEV a PRD
1. Estructura de Datos en un Sistema SAP
SAP tiene una estructura de datos específica. Adicionalmente a las configuraciones de negocio (customizing) para ciertos clientes de 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 packages)
Los paquetes son contenedores para objetos de desarrollo relacionados semánticamente. Objetos de desarrollo como programas, tablas, pantallas, módulos de función, clases, etc, están contenidos dentro de un paquete
Los paquetes están caracterizados por ciertas propiedades:
- Anidado (nesting)
- Interfaz (interfaces)
- Visibilidad (visibility)
- Accesibilidad (accesibility)
El grabado y transporte de modificaciones de objetos está controlado por el Sistema de Transportes y Cambios, CTS (Change and Transport System) usando la asignación de objetos de repositorios a paquetes
* SPAK. Los paquetes son creados y mantenidos con Package Builder, la transacción SPAK
2. Customizing
Describe las configuraciones de negocio de un sistema SAP. Las funciones provistas tantos generales como específicas son adaptadas a los requerimientos específicos 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 (definiciones de país, lenguaje, uso horario) están incluidas por SAP como parte de las instalaciones
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
3. 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, organizacional y técnica contenida en SAP y consiste de configuraciones de negocio, 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í. 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. Si hay inconsistencias, la información ingresada 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 y son únicamente validos en el cliente, por ejemplo registros maestros de materiales, órdenes y facturas. Los datos de usuario también son dependientes del cliente
Varios roles de clientes son usados en 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
4. Repositorio de objetos
Así como el Customizing dependiente de cliente e inter-cliente, es posible hacer ajustes adicionales a la estructura de datos de SAP. Se pueden hacer cambios o mejoras en el repositorio de objetos y se realizan en diferentes formas:
- Extensión del repositorio: a través de desarrollos del cliente (customer developments) en SAP, es posible crear objetos de repositorio como tablas, programas, transacciones, etc. Todos los desarrollos son usualmente realizados en el espacio de nombres del cliente y deben comenzar con la letra Y o Z. 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, 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. Las estructuras de tablas pueden se ampliadas con campos propios usando 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
5. Landscape de Tres Sistemas
SAP recomienda un landscape de sistemas múltiples basado en la conformación de la estructura de datos de 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
Como el repositorio de objetos es inter-cliente, SAP recomienda que no se desarrolle en un sistema que al mismo es productivo, ya que es un riesgo de inconsistencia de datos. Si se realizan cambios al repositorio, SAP recomienda que se use al menos dos, pero idealmente tres sistemas separados. Un sistema para desarrollos, un segundo para pruebas y QA y un tercero 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 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 no es posible en de desarrollo, ya que los datos reales no están disponibles en este sistema para una prueba real. La razón principal, 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 hacemos un Customizing dependiente de cliente en el sistema de desarrollo y verificamos antes de enviarlo a los demás sistemas, puede usarse un cliente de prueba en el mismo sistema de desarrollo para tal propósito.
Clientes con roles específicos son 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