Truco 124. Algunas cosas que deberiamos de conocer sobre las ordenes de transporte en SAP.


La orden de transporte es el elemento fundamental que nos permite «mover» la parametrización y los elementos de desarrollo o workbench (tablas, elementos de datos, dominios, programas, dynpros, clases, módulos de función, formularios, etc) desde el sistema de Desarrollo hasta los sistemas intermedios de pruebas (Test, Qas) y finalmente al sistema de Producción.

Es fundamental, aunque no seamos consultores técnicos, que tengamos unas nociones básicas sobre las ordenes y que también que seamos conocedores de los problemas más habituales que se producen con las ordenes por no gestionarlas correctamente.

Tipos de Ordenes.

Aunque existen otros tipos de ordenes (por ejemplo, los Hot Packages que utilizamos para las actualizaciones de SAP), normalmente un consultor o desarrollador trabaja principalmente con tres tipos de ordenes:

  • Customizing: ordenes del tipo W, son las que utilizamos para registrar los cambios en la parametrización que completamos en el sistema de desarrollo. Normalmente, la parametrización corresponde con entradas en tablas o vistas de actualización, donde guarda la parametrización del sistema realizada a través de la transacción SPRO. Y es una configuración dependiente del mandante en el que estemos conectados.
  • Workbench: ordenes del tipo K, son las utilizadas por los desarrolladores cuando realizar cualquier creación o modificación de los objetos de desarrollo (reports abap, clases, dynpros, formularios, objetos del diccionario de datos, ayudas de busqueda, cds, vistas, etc., etc.). Las ordenes de workbench registran objetos que son independientes de mandante. La parametrización de objetos que no depeden del mandante también se incluyen en ordenes de este tipo.
  • Transporte de copias: nos permite realizar el transporte de objetos de desarrollo o parametrización, incluidos en otras ordenes, sin necesidad de liberar las ordenes originales. Por ejemplo, puede ser útil para probar un desarrollo en un sistema de test sin liberar la orden en desarrollo donde estamos realizando todos los cambios. También se puede utilizar con ordenes de parametrización.

Cuando creamos una orden del tipo Transporte de copias, la orden se crea vacía y nosotros a continuación seleccionamos los objetos que queremos incluir en ella para su transporte para la realización de pruebas (normalmente los objetos incluidos en uno o varias ordenes adicionales que todavia no hemos liberado).

Elementos de una orden.

Normalmente, en una orden veremos al menos el número de orden principal y una o varias tareas (asociadas a los diferentes usuarios que intervienen en un proceso de parametrización del sistema o de creación de objetos de desarrollo).

Tanto la cabecera como las tareas pueden incluir objetos, aunque lo habitual es que esten en cada una de la tareas.

Para que un usuario pueda incluir sus objetos en una orden de transporte, habrá que crear una tarea para el dentro de la orden. Es tan sencillo como acceder a la transacción SE09/SE10, seleccionar la orden, y con el botón derecho seleccionar la opción «Añadir empleado».

El sistema nos solicitará el identificador del usuario que queremos incluir y se creará una tarea para el dentro de la orden.

Modificar el titular de una tarea o de la orden.

En ocasiones, las ordenes de transporte o sus tareas estan asociadas a usuarios incorrectos (usuarios borrados o que dejaron la compañia). En las ordenes o tareas que no esten liberadas, podremos modificar el titular sin problema desde la transacción SE09/SE10, seleccionando el elemento y, desde botón derecho, opción «Modificar titular». Esto vale tanto para la tarea como para la orden en si.

Que ocurre cuando liberamos una orden.

Para liberar una orden de transporte, primero hemos de liberar todas las tareas incluidas en ella, con el menú contextual (botón derecho) o pulsando la tecla F9.

A continuación, repetiremos la acción con la orden propiamente dicha, momento en el nos aparecerá un dialogo indicando que se ha realizado la liberación de la orden.

En este momento, se escribe, a nivel de sistema operativo, en el directorio de transporte, dos ficheros que incluyen todos los elementos incluidos en la orden. Los ficheros que se escriben son los siguientes:

  • Directorio data: fichero RXXXXXX.YYY, donde XXXXXX es el número de la orden y YYY el id de la instancia donde hemos realizado la creación de la orden. Es el fichero binario que incluye todos los cambios realizados.
  • Directorio cofiles: fichero KXXXXXX.YYY, con el mismo significado. Es el fichero de control.

Conocer la existencia de estos ficheros nos puede ser de utilidad para mover, por ejemplo, un desarrollo o parametrización a otro sistema que no este conectado al sistema de transporte (por ejemplo, un sandbox o un sistema de pruebas autonomo).

Igualmente, es importante entender que es el momento de la liberación cuando el sistema accede a la base de datos y lee la parametrización o desarrollos realizados, y se guarda una copia de esos elementos a nivel de fichero. Y esa copia será la que se transmita al sistema destino cuando hagamos la importación con la transacción STMS. Si entendemos bien esto, nos evitaremos muchos problemas. Por ejemplo, yo puedo haber realizado una parametrización del control de copia en la facturación (transacción VTFL) y haberla incluido en una orden. Si un compañero, antes de liberar la orden, realiza otro cambio sobre la misma configuración, aunque la incluya en otra orden, cuando yo libere mi orden me llevaré los cambios de mi compañero. Algo parecido ocurrirá con objetos de desarrollo (workbench), aunque en ese caso Sap no nos deja tocar el mismo objeto en dos ordenes abiertas a la vez (en ese caso siempre se incluyen todos los cambios, aunque sean de diferentes usuarios, en la misma orden, con una tarea para cada uno de los usuarios).

Ver los objetos que conforman una orden.

Cuando accedemos al detalle de la orden o tarea (SE09/SE10), podemos ver la lista de objetos incluidos en ella con sus nombre técnicos.

Para hacernos una idea, podemos ver en la imagen un ejemplo de objetos de una orden de parametrización.

En esta otra imagen una orden de workbench, con los objetos de desarrollo incluidos.

Cada uno de los objetos incluidos en la orden tiene un nombre técnico, que se identifica con tres elementos:

  • Id. Programa: normalmente veremos el valor R3TR, aunque cuando transportarmos traducciones de textos podremos ver el valor LANG o valores que nos indican comentarios.
  • Tipo de Objeto: identifica el tipo de objeto que estamos incluyendo en la orden. Hay más de mil tipos de objetos diferentes.

Algunos de los tipos de objetos más habituales para un consultor funcional serán TABU (contenido de una tabla de parametrización), VDAT (vista de parametrización), TDAT, CDAT (cluster de vistas de parametrización), ACGR (roles de autorizaciones), etc.

  • Nombre del objeto: el nombre que identifica al objeto incluido en la orden.

En la orden también puede aparecer el objeto de parametrización asignado a cada elemento de la orden (en el campo llamado Actividad IMG). Ademas para cada elemento incluido dentro de una orden, podremos ver, para los objetos asociados a contenido de tablas o vistas, los registros de datos asociados pulsando el icono de la Llave (Objeto con claves).

Es interesante conocer esto, pues lo que veamos en ese detalle serán los valores de configuración que realmente se van a transportar cuando liberemos la orden de transporte. Nos permite realizar chequeos o analizar problemas cuando algo ha fallado después del transporte de una configuración.

Fusionar ordenes.

Tanto en un proyecto como en las tareas de soporte habituales, es posible que hayamos creado varios ordenes de transporte donde hemos ido incluyendo elementos. Llegado el momento de gestionar el paso de los cambios a productivo, el disponer de varias ordenes puede ser confuso de cara a la importación de la orden en el destino (objetos dependientes, orden de la carga, etc).

Para evitar problemas, una solución puede ser el fusionar una o varias ordenes en una única orden, de forma que realizaremos el transporte completo de todos los objetos en un único «contenedor».

Para realizar la fusión de dos ordenes, usuaremos el menú contextual (opción «Fusionar ordenes»).

El sistema nos pedirá la orden origen y la orden destino (donde se realizará la fusión). La orden origen se eliminará una vez completado el proceso de fusión.

Esta opción se utiliza mucho en los proyectos cuando diferentes consultores han estado trabajando en la configuración con ordenes individuales y necesitamos incluir todos los objetos en la misma orden, dentro de las tareas de preparación de la subida de los cambios a productivo.

Incluir elementos de una orden en otra.

Además de la fusión de ordenes, otra opción muy útil es la de incluir en una orden de transporte objetos de otras. Esto lo realizaremos desde el menú contextual, con la opción «Incluir objetos».

Nos aparecerá un popup desde el cual dispondremos de diferentes opciones para incluir nuevos objetos en la orden:

  • Objetos de una orden.
  • Objetos de varias ordenes.
  • Selección libre de objetos.
  • Etc.

Cuando incluimos en una orden objetos de otra orden, podremos ver en la cabecera de la orden entradas de este tipo, que nos indican que se toman objetos de otra orden. Y estos objetos serán incluidos cuando liberemos la orden para el transporte.

De forma que vemos que realmente se esta guardando un «puntero» a la otra orden.

Incluir la ejecución de un programa tras el transporte de una orden.

Existen tareas de configuración del sistema, que pueden requerir la ejecución de un determinado programa una vez se transportan los cambios a los sistemas de test o de productivo. Por ejemplo, cuando creamos rutinas con la transacción VOFM (como rutinas de calculo de precio, condiciones, etc), una vez se pasan los cambios a productivo, hay que ejecutar el report RV80HGEN para la regeneración de los pools de programas y asi, de esta forma, la rutina puede ser utilizada en el sistema.

Si queremos evitar tener que hacer esta ejecución manualmente, podemos incluirla en la orden de transporte. Para ello, iremos a la orden de transporte (SE09/SE10), opción Modificiar, e incluiremos un nuevo objeto con los valores:

Cuando transportemos la orden al siguiente sistema, Sap ejecutará el programa indicado una vez completadas las tareas de importación de los elementos de orden.

Una forma fácil de no olvidarnos de tareas que son obligatorias, incluso puede valer para nuestros propios desarrollos.

Abrir una orden de transporte ya liberada.

Una orden de transporte ya liberada, ha generado ya los correspondientes archivos en el directorio de transporte (como hemos visto antes) y en principio no es posible volver asignar mas cambios en ella.

En el caso de que fuese necesario «revertir» la liberación de una orden, podriamos utilizar, desde la transacción SE38 el report RDDIT076. Indicaremos la orden de transporte y ejecutaremos.

Al acceder veremos la orden de transporte y sus tareas asociadas, con información de su estado. Una orden ya liberada estará en estado «R – Liberado».

Para volver abrir la orden, cambiaremos primero el status de orden, indicando el valor «D – Modificable». A continuación, repetiremos la acción para todas las tareas que incluya y grabaremos. Esta orden estará lista para seguir trabajando con ella e incluyendo objetos hasta que la volvamos a liberar, aunque será necesario modificar la orden con la transacción SE09/SE10 y eliminar el atributo EXPORT_TIMESTAMP, ya que sino no será posible volverla a liberar.

Nota: no se recomienda realizar esta tarea más que en casos excepcionales, por las implicaciones que podría tener incluir en una orden ya liberada (y puede que transportada), objetos nuevos y volver a realizar un ciclo completo de transporte sin verificar que pueda haber otras ordenes dependientes afectadas.

Borrar objetos o una orden.

En ocasiones hemos realizado pruebas en un sistema y hemos incluido cambios en una orden de tranporte, que finalmente no desearemos transportar a productivo.

Con cuidado, para no evitar inconsistencias, es posible borrar objetos de una orden desde la SE09/SE10. Buscaremos el lugar donde esta incluido el objeto, y pulsaremos la opción de modificar:

Una vez localizados los objetos a eliminar, los seleccionaremos y pulsaremos la opción de eliminar. De esta forma, estos objetos quedarán excluidos del transporte y no se moveran al sistema destino. Y como siempre, utilizar con mucho cuidado para no generar un problema cuando estamos intentando solucionar otro.

Buscar objetos en las ordenes.

Es muy habitual que se produzcan problemas cuando se transportan los cambios a productivo, tanto relacionados con customizing o objetos de desarrollo. Cuando ocurre esto, necesitamos una herramienta ágil para poder buscar los objetos en las ordenes y poder identificar cual es el problema que se ha producido.

Para ello, disponemos de la transacción SE03, que nos sirve de Menú para todas las tareas relacionadas con las ordenes.

En mi caso, voy a utilizar la opción «Buscar objetos en ordenes» para localizar las ordenes que han tocado una determinada tabla de parametrización.

Al seleccionar esta opción, nos aparece un report donde podemos indicar los objetos que queremos buscar y el ambito de la busqueda (tipos de ordenes, status de las ordenes, numeros de orden, fecha, usuario, etc).

Si tenemos un conocimiento mínimo de los objetos más habituales, podremos sacarle partido y encontrar el origen de problemas relacionados con el transporte. Cuando ejecutemos el informe, nos devolverá la lista de ordenes que cumplan las condiciones.

Problemas más habituales con las ordenes.

Por su propia forma de funcionamiento, las ordenes de transporte son una fuente continua de problemas, que normalmente se solucionan con unas buenas prácticas e intentando evitar determinadas cosas. Lo primero de todo, es entender dos cosas básicas:

  • Ordenes de parametrización: los valores que se exportan a los ficheros de las ordenes de transporte son los que tienen las tablas de configuración en el momento de realizar la exportación de la orden. Esto significa que yo puedo haber realizado una parametrización y haberla incluido en la orden (tendra su correspondiente objeto con sus valores de claves). Pero otra persona puede posteriormente haber cambiado esa configuración y haberla introducido en otra orden. Cuando yo libere la orden, me llevaré los cambios de la otra persona, no los valores que yo «pensaba» que se habian incluido.
  • Ordenes de workbench: normalmente, cuando transporte objetos de desarrollo, me llevaré el objeto de desarrollo completo en el momento de liberar la orden (por ejemplo, en un programa abap me llevo todo el código del programa).

Teniendo en cuenta estas dos cosas, algunos de los problemas más habituales son:

  1. Transportes incompletos: no nos llevamos todas las ordenes necesarias, y nos dejemos objetos dependientes sin transportar. Esto se puede producir tanto en ordenes de custo como de workbench.
  2. Secuencia de importación incorrecta: al importar las ordenes, no seguimos la secuencia correcta, lo que implica que se machaquen objetos con versiones anteriores, que al final dan como resultado que no tengamos en productivo/test la misma configuración que en el sistema de desarrollo. Normalmente volviendo a importar en el orden correcto se soluciona el problema.
  3. Transportes incorrectos: porque no estamos llevando la configuración realizada por nosotros o nos estamos llevando cambios de otros consultores incluidos en una orden. Esto es muy habitual, y puede producir problemas muy graves, pudiendo producir un fallo en la funcionalidad del sistema de productivo por transportes incompletos o erróneos.
  4. Transportes de calendarios o rangos de números: estos dos elementos son muy delicados y os recomiendo que ante que cualquier duda, consulteis a los consultores de Basis o los veteranos de vuestra empresa. Por ejemplo, los calendarios se transportan completos, si hay cualquier diferencia entre el sistema de DES y PROD, al transportar machacaremos la configuración de los calendarios (ver entrada del blog donde hablabamos de esto).
  5. Ordenes de transporte antiguas: es muy habitual que en el sistema de desarrollo vayan quedando ordenes de consultores que pasaron por la empresa, pruebas que se fueron realizando, funcionalidad que nunca se llego a subir a productivo. Es importante tener controladas esta ordenes e incluso intentar hacer limpieza para evitar problemas o errores en el futuro.
  6. Transporte de parametrización en desarrollo: algunas tareas funcionales, como la de abrir los periodos contables, es posible que el sistema nos pida orden de transporte en un entorno de desarrollo. Es importante no incluir estos cambios en una orden en la que estemos realizando parametrización, y lo incluyamos en una orden de las llamadas «No transportar». Asi también nos evitaremos algún susto.

Mi consejo, para evitar estos problemas, es intentar ser meticuloso y metódico, revisar bien las ordenes en caso de duda y sobre todo, disponer de unas buenas prácticas en la gestión del transporte de las que sean conocedores todas las personas que realizan cambios en nuestro sistema.

Bibliografía.

https://blogs.sap.com/2020/05/26/7-secrets-about-sap-transportation-request-that-every-functional-consultant-should-knows/

https://blogs.sap.com/2016/06/16/xpra-execute-abap-program-automatically-after-transport-request-import/

https://www.kodyaz.com/sap-abap/execute-abap-program-after-transport-request-import.aspx

Anuncio publicitario
Esta entrada fue publicada en Formacion, S/4HANA, Sap Basis y etiquetada , , , , , . Guarda el enlace permanente.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.