✒️SAP BASIS / Órdenes de transporte de desarrollo Por Fernando Escola

Órdenes de transporte de desarrollo

Planificación de la gestión de cambios para el desarrollo

Objetivo Principal y Buenas Prácticas

El enfoque central se resume en el lema: "Menos órdenes, más control". Antes de iniciar cualquier desarrollo en un sistema SAP, es fundamental planificar cómo se controlará, verificará y probará cada cambio, utilizando herramientas clave como el Transport Organizer (SE09/SE10).

Para lograr una gestión eficiente, la estrategia se divide en cuatro pilares principales:

1. Pilar Técnico (Restringir Cambios y Definir Estándares)

• Entorno único: Se debe realizar todo el desarrollo en un único sistema y configurar adecuadamente las opciones de cambio de sistema y de mandante.

• Seguridad y Accesos: Controlar estrictamente qué usuarios pueden crear, modificar o liberar órdenes de transporte mediante la asignación de autorizaciones de usuario adecuadas (como el objeto de autorización S_TRANSPRT).

• Agrupación Lógica: Utilizar paquetes para agrupar los objetos de repositorio que estén funcionalmente relacionados. Esto permite que compartan una misma ruta de transporte predefinida a través de la capa de transporte.

• Versiones: Establecer estándares claros de desarrollo, documentación y mantener un control estricto de las versiones.

2. Pilar Organizacional (Equipos y Roles)

• Capacitación: Proporcionar formación a todos los equipos de proyecto sobre las herramientas de gestión de cambios.

• Roles claros: Asignar líderes a los proyectos que se encarguen de definir y asignar las tareas y las órdenes de transporte a los miembros del equipo.

• Documentación obligatoria: Al liberar una orden de transporte, es un requisito indispensable documentar tanto su propósito como el estado de los cambios realizados.

3. Pilar Estratégico (Gestión de Órdenes de Transporte)

• Bloques completos: Utilizar proyectos para agrupar las órdenes de transporte. La importación y aprobación debe realizarse por proyectos completos (Proyecto CTS) hacia el sistema destino, garantizando la consistencia de los sistemas.

• Regla de oro: No se deben importar órdenes de transporte individuales.

• Excepción: La única excepción permitida para romper esta regla son las reparaciones de emergencia.

4. Reglas Esenciales a Definir

El procedimiento de gestión debe dejar claramente establecido mediante reglas:

1. Cómo y dónde se realizan los cambios.

2. Cómo y dónde se prueban.

3. Cómo se realiza la garantía de calidad (Quality Assurance).

4. Cómo y quién crea, libera e importa las órdenes de transporte dentro del panorama de sistemas SAP.

La configuración vs. El desarrollo

1. Herramientas de Configuración vs. Herramientas de Desarrollo

SAP distingue claramente las actividades de parametrización del sistema de las de programación, asignando herramientas específicas para cada una:

• Para la Configuración:

  • Guía de Implementación (IMG / Transacción SPRO): Es la herramienta principal. Al definir las funciones de negocio requeridas, genera automáticamente una lista jerárquica de pasos o transacciones para realizar la configuración.

  • Organizador de Órdenes de Transporte (Transacción SE09): Registra estos cambios de configuración en órdenes específicas para luego exportarlas a otros sistemas del panorama.

• Para el Desarrollo:

  • ABAP Development Workbench (Transacción SE80): Entorno tradicional que cubre todo el ciclo de vida del desarrollo de software para ampliaciones (enhancements) y desarrollos a medida.

  • ABAP Development Tools (ADT): Es el entorno de desarrollo moderno e integrado (IDE) basado en la plataforma Eclipse. Ofrece una interfaz de usuario potente y una gestión robusta del ciclo de vida de ABAP para escenarios complejos.

Tanto SE09 como SE80 registran sus modificaciones en el Organizador de Órdenes de Transporte, el cual está completamente integrado con el Sistema de Gestión de Transportes (TMS).

2. Tipos de Órdenes de Transporte según el Impacto

El Organizador clasifica los cambios en dos tipos de órdenes de transporte:

1. Órdenes de Configuración (Customizing): Almacenan objetos específicos del mandante (Client-specific). Los cambios de configuración consisten principalmente en entradas en tablas.

2. Órdenes de Workbench: Almacenan objetos inter-mandante (Cross-client), es decir, que afectan a todo el sistema independientemente del mandante en el que se trabaje.

Diferencias funcionales en el Organizador:

• Ambas herramientas comparten: Documentación de cambios y conectividad al TMS.

• Exclusivo de Configuración: Conexión a la administración del mandante y tabla histórica de cambios.

• Exclusivo de Desarrollo (Workbench): Gestión de paquetes, bloqueo de objetos y control de versiones.

3. Funciones y Vistas del Organizador de Transportes

El Organizador crea, gestiona, libera y analiza las órdenes de transporte mediante tres funciones principales:

• Mostrar las órdenes de transporte.

• Mostrar la información global de transporte.

• Proporcionar acceso a herramientas especiales.

Acceso y Transacciones:

• Para acceder a las funcionalidades extendidas y vistas detalladas se utilizan las transacciones SE09, SE10 o SE01.

• Las órdenes de Workbench se pueden filtrar y mostrar según criterios de selección específicos: usuario (propietario o tarea), tipo de orden, estado de la orden y fecha.

• Información Global (Global Information): Esta sección de la pantalla proporciona una vista general y rápida del estado de las órdenes que ya fueron transportadas, así como de las reparaciones realizadas.

El concepto del registro SSCR en Sap

Es el proceso de Registro de Cambios de Software de SAP que sirve para dar fiabilidad al desarrollo, agilizar la corrección de errores y garantizar la alta disponibilidad del sistema. Funciona limitando y controlando los accesos a través de dos tipos de registros gestionados de forma centralizada en el Portal de Soporte de SAP (https://support.sap.com/sscr o desde el Launchpad).

El proceso de registro se divide en dos categorías clave:

1. Registro de Desarrolladores

Cualquier usuario de un sistema basado en el Servidor de aplicación ABAP (AS ABAP) de SAP Business Suite que desee crear, modificar o eliminar objetos de repositorio debe estar registrado.

• Clave de acceso (Access Key): Al registrar al desarrollador, se le asigna una clave única que vincula su ID de logon (inicio de sesión) y el número de licencia del sistema SAP.

• Almacenamiento: Esta clave se solicita en el intento inicial de crear/modificar un objeto y se guarda automáticamente en la tabla DEVACCESS.

• Alcance: La clave sirve para todos los usuarios con el mismo nombre en todos los mandantes del mismo servidor SAP.

2. Registro de Objetos SAP (Modificaciones)

Se deben registrar todos los objetos de repositorio estándar de SAP (no los objetos creados por el cliente) que se vayan a modificar.

• Requisitos para el registro: Para registrar un objeto, se debe proporcionar su ID de programa, el tipo de objeto, el nombre del objeto, el número de licencia del sistema y la versión (release) de SAP.

• Almacenamiento: Tras aplicar la clave de acceso del objeto, esta se almacena en la tabla de la base de datos ADIRACCESS. Esto asegura que las modificaciones posteriores a dicho objeto no requieran ingresar la clave otra vez.

• Validez: Las claves de objeto registradas dejan de ser válidas (se vuelven inválidas) después de una actualización de versión (release upgrade). Solo sirven para la versión activa del sistema en el momento del registro.

Particularidad Crítica: El SSCR en sistemas S/4HANA

El comportamiento cambia drásticamente en las versiones de última generación:

• En los sistemas SAP S/4HANA Server, estas claves NO son verificadas y, por lo tanto, NO son necesarias.

• Notas de referencia importantes:

  • Nota SAP 2309060: Detalla que el procedimiento de solicitud de clave de licencia SSCR no es compatible ni soportado en SAP S/4HANA.

  • Nota SAP 2501703: Contiene las preguntas frecuentes (FAQs) que brindan información técnica adicional sobre el SSCR de SAP.

Los objetos del repositorio y sus atributos

1. Convenciones de Nomenclatura y Espacios de Nombres (Namespaces)

Para evitar conflictos al crear objetos de repositorio en SAP, los desarrolladores deben seguir reglas estrictas de nomenclatura:

• Objetos del Cliente: Los nombres de los objetos creados por el cliente deben comenzar obligatoriamente con la letra Y o Z.

• Campos del Cliente en tablas SAP: Deben comenzar con ZZ (no con una sola Z).

• Nombres numéricos: Si el objeto es un número, el espacio de nombres del cliente suele comenzar con 9.

• Socios de SAP (SAP Partners): Utilizan prefijos específicos asignados en sus espacios de nombres para identificar de forma única el software complementario que desarrollan.

• Nota SAP 16466: Contiene la visión general de los rangos de nombres de cliente para objetos SAP (Customer name range for SAP objects).

2. Gestión y Reserva de Espacios de Nombres (Vistas V_TRE8N y CTSRESNAME)

Cuando el panorama de sistemas SAP es complejo (múltiples líneas de sistemas), se requieren herramientas para reservar nombres y evitar colisiones antes de guardar los objetos:

• Vista V_TRE8N: Permite a los desarrolladores asignar y reservar un espacio de nombres específico a un paquete determinado. Si otro desarrollador intenta crear un objeto con ese mismo prefijo en un paquete diferente, el sistema emite un mensaje de error impidiendo la grabación y la asignación.

• Vista CTSRESNAME: Ofrece un mantenimiento de vistas simplificado en comparación con V_TRE8N. Su convención se basa exclusivamente en el ID de programa y el tipo de objeto. Solo se puede utilizar para espacios de nombres de desarrollo que ya cuenten con prefijos reservados mediante V_TRE8N (reservas específicas Y*/Z*).

• Reserva Centralizada: Tanto los socios de SAP como los clientes pueden solicitar prefijos de espacios de nombres a través de la aplicación Development Namespaces en SAP ONE Support Launchpad (https://support.sap.com/namespaces). Para más detalles, se puede consultar la Nota SAP 84282.

3. El Directorio de Objetos y sus Atributos (Tabla TADIR)

El Directorio de Objetos funciona como un catálogo que lista todos los objetos del sistema SAP (tanto los estándar como los desarrollados por el cliente).

Atributos Principales de un Objeto:

Cada objeto de repositorio tiene asignados cuatro atributos esenciales:

1. Paquete (Package)

2. Persona responsable

3. Sistema original

4. Idioma original

Almacenamiento y Modificación (Tabla TADIR):

• Todos estos datos se almacenan centralmente en la tabla TADIR, la cual es crítica para la consistencia del sistema.

• ¿Cómo modificar las entradas de TADIR? Nunca se debe hacer directamente; se deben usar únicamente las funciones estándar de SAP. Con la autorización apropiada, se puede cambiar el paquete o la persona responsable mediante:

  • La transacción SE03 (Menú: Herramientas del Organizador de Transportes $rightarrow$ Directorio de Objetos $rightarrow$ Modificar Entradas del Directorio de Objetos).

  • La transacción SE09 (Menú alternativo: Pasar a (Goto) $rightarrow$ Herramientas del Organizador de Transportes).

Estructura Técnica de las Entradas:

• Objetos Generados: Los objetos creados automáticamente por el sistema SAP como resultado de actividades de configuración aparecen marcados explícitamente en el directorio como "generados".

• Clave Primaria en TADIR: Cada entrada en la tabla se identifica de forma única mediante tres campos:

  • PGMID (Identificación del programa): Generalmente es R3TR.

  • Tipo de objeto: Por ejemplo, PROG (programa ABAP), DEVC (paquete), o TABL (definición de tabla).

  • Nombre del objeto.

Los paquetes

1. Concepto y Funciones de los Paquetes

El Repositorio de SAP se organiza mediante paquetes (packages), concepto que reemplaza a las antiguas "clases de desarrollo" (development classes). Sus tres funciones principales son:

• Proporcionar una agrupación lógica de objetos para coordinar las tareas de desarrollo.

• Definir la capa de transporte a la que pertenece un objeto de repositorio.

• Controlar la nomenclatura de los objetos que contiene.

Se pueden crear mediante el Navegador de Repositorio (Repository Browser) en la transacción SE80. Además, la vista V_TDEVC contiene el listado completo de todos los paquetes del sistema SAP.

2. Los Paquetes y las Capas de Transporte

Cada paquete se asigna a una capa de transporte específica. Esto determina de forma automática qué ruta de consolidación predefinida seguirán sus objetos modificados:

• Ruta de Consolidación estándar: Los objetos se transportan desde el sistema de desarrollo hacia el de aseguramiento de calidad (por ejemplo, de DEV a QAS). Todos los objetos estándar de SAP modificados siguen de forma fija la capa preinstalada llamada SAP.

• Objetos Transportables del Cliente: Si se asignan a una capa personalizada (ej. ZDEV), utilizarán esa ruta de consolidación específica hacia el sistema de calidad.

• Restricción de Transporte: Solo se pueden transportar objetos mediante órdenes de Workbench si su paquete tiene asignada una capa válida (SAP, ZDEV, ZTRN, etc.). Si la capa está en blanco o no tiene una ruta de transporte existente, el sistema impedirá su exportación.

Tipos de paquetes según su letra inicial:

• Y o Z: Indica un paquete para objetos del cliente que deben ser transportados.

• $: Indica paquetes para objetos temporales que no se transportan y, por ende, no requieren una capa de transporte asignada. El paquete genérico $TMP se utiliza por defecto cuando se guarda un objeto como local.

• TEST: Indica paquetes para objetos locales que cuentan con gestión de versiones, pero que no se transportan.

Al igual que con los objetos, las vistas V_TRE8N o CTSRESNAME sirven para especificar qué paquetes pueden asociarse a un espacio de nombres determinado y evitar conflictos de código.

3. Concepto Moderno de Paquetes (A partir de Web AS 6.10)

Los paquetes modernos extienden las capacidades de las antiguas clases de desarrollo mediante nuevos atributos técnicos que permiten modularizar, desacoplar el sistema y reducir los niveles de dependencia:

• Anidamiento (Nesting): Permite estructurar los paquetes de forma jerárquica, dividiendo las unidades grandes del sistema en subunidades más pequeñas.

• Interfaces de Paquete e Inclusión: Los paquetes utilizan interfaces y reglas de visibilidad para dar a conocer sus servicios a otros paquetes. Los elementos visibles en un paquete pueden ser consumidos por paquetes externos; los elementos invisibles quedan encapsulados y protegidos ante accesos no autorizados.

• Acceso de Uso (Use Access): Es el permiso explícito que se le otorga a un paquete para que pueda consumir los elementos visibles en la interfaz de un segundo paquete (la relación es unidireccional y no funciona a la inversa).