Estructura de datos en un sistema SAP
las configuraciones de negocio (customizing) relevate para cietos clientes del sistema SAP, tambien tiene configuraciones y el repositorio de objetos que son inter clientes (cross client)
El repositorio es el luagr de almacenamiento central para todos los objetos de desarrollo de Workbench ABAP y es inter cliente estos objetos se alamcenan en paquetes (packages)
Los paquetes son contenedores para objetos de desarrollo relacionados semanticamente. Pueden contener diferentes objetos de desarrollo por ejemplo programas, tablas, pantlalas, modulos de función, clases, etc.
Los paquetes estan caracterizados por ciertas propiedades
1. Anidado (nesting)
2. Interfaces (interfaces)
3. Visibilidad (visibility)
4. Accesibilidad (accesibility)
Transaccion SPAK
los paquetes son creados y mantenidos con package Builder
El grabado y transporte de modificaiones de objetos esta controlado por el sistema de transportes y cambios (CTS Change and Transport system)
Customizing
describe las configuraciones del negocio, las funciones provistas tanto generales como especificas de una compañia son adaptadas a sus requerimientos. (ejemplos: definiciones de pais, lenguaje, uso horario estan incluidas por SAP)
El customizing inter clientes contiene configuraciones que son independientes de una unidad de negocio particular y tuenen una validez general. (ejemplos: calendario, configuraciones de impresión, acceso a la ayuda
Clientes
conocidos tambien como mandantes, es una unidad comercial, organizaciones y tecnica y consiste en configuraciones de negocio (customizing dependiente de cliente que son los datos de un cliente), sus propios datos maestros y transaccionales y sus propios datos de usuarios.
los tipos de datos que son dependientes de un cliente estan relacionados entre si. Por lo tanto cuando ingresamos información en una aplicación, el sistema veriica si la información ingresada concuerda con la configuración especedifica de ese cliente, si hay inconsistencias la informacion ingresada en la apliacion es rechazada. Esto nos indica que la informacion de una apliacaion es significativa solamente en el cliente con el customizig correspondiente. Algunos ejemplos son los codigos de compañia, plantas y almacenes.
Datos maestros y de transacciones son dependientes del cleinte tambien, validos en el cliente, algunos ejemplos son registros maestros de materiales, ordenes y facturas. Los datos de usuario tambien son dependientes de cliente.
Desde la transaccion SCC4 se pueden crear varios roles de clientes (mandantes) para ser utilizados en diferentes propositos
Repositorio de objetos
Se pueden hacer mejoras al repositorio de las siguientes:
1. Extension del repositorio: a traves de desarrollos del cliente es posible crear objtos de repositorio propios tales como tablas, programas, trasacciones, etc.
Todos los desarrollos de clientes usualmente en sus nombres inician con la letra Y o Z. Es posible requerir un nombre de espacio propio que empiece y termine con el caracter / con limite de 8 caracteres.
2. Mejoras de cliente: el repositorio es suplementado por sub objetos del cliente, por ejemplo un programa estandar se SAP puede ser suplementado con codigo propio con codigos conocidos como customr exits. Las estructuras de las tablas pueden ser ampliadas com campos propios utilizano appends
3. Modificaciones al estandar: son cambios a objetos estandar de SAP, 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: manuales, con el asistente de modificaciones y con el asistente de notas.
Landscape de tres sistemas
SAP recomienda un landscape de sistemas multiples basado en la conformación de la estructura de datos de un sistema SAP, en la que existe solo un repositorio de objetos por sistema.
Nunca se debe desarrollar en un sistema SAP que se utiliza tambien como productivo.
Un landscape de tres sistemas (desarrollo, calidad y productivo) facilita el siguiente proceso recomendado:
1. Se realizan los desarrollos en el repositorio y configuraciones requeridas en el sistema de desarrollo, asi tambien como todos los cambios (desarrolos, mejoras y modificaciones)
2. Estos cambios son luego transportados al sistema de calidad y alli se verifican, sin influenciar en la operacion de producción. Una prueba de aceptación usualmente no es posible realizarse en el sistema de desarrollo, ya que los datos reales no estan disponibles para una prueba real en este sistema. La razon principal de este landscape es ofrecernos un ambiente estable apra una preuba comprensica e integral.
3. Lueggo que se han probado satisfactoriamente, todos los objetos y configuraciones en el sistema de claida pueden ser transportados al sistema de producción. Diferentes clientes pueden ser creados para propositos especificos. Si realizamos un customizing dependiente del cliente en el sistema desarrollo y queremos verificarlo antes de transportarlo a los demas sistemas, puede utilziarse un cliente de prueba en el mismo sistema de desarrollo.
Clientes con roles especificos son usualmente creados en cada sistema, un cliente por cada sistema.
Generalemnte los clientes principales de cada sistema tiene el mismo numero ya que por defecto cuando transportamos el cleinte original es igual al cliente destino.