Sistema de transporte

El sistema R/3 dispone de una herramienta que nos permite pasar objetos de un entorno (por ejemplo, desarrollo) a otro (por ejemplo, producción ). Los objetos a pasar pueden ser definición y contenido de tablas nuevas, programas nuevos, datos de customizing e incluso modificaciones al estándar.

Este traspaso de información entre un sistema R/3 y otro nos facilita el mantenimiento del sistema productivo ya que con ello evitamos tener que duplicar el trabajo de programación o repetir la inclusión de datos de customizing. Todo ello redunda en una mayor productividad y en una minimización de riesgos ya que la información, antes de ser insertada en el sistema productivo, es probada en el sistema de desarrollo y su traspaso no

será realizado hasta que el responsable del proyecto dé el visto bueno. La herramienta que permite este traspaso de información entre sistemas R/3 es el llamado sistema de transportes.

Órdenes de transporte

El sistema de transporte se emplea, generalmente, para trasladar objetos desde el sistema de desarrollo hasta el sistema de producción; obviamente si no existe tal separación de sistemas, es decir, si sólo se dispone de un único sistema la utilidad del sistema de transportes se reduce a traspasar información dependiente de mandante de un mandante a otro dentro del mismo sistema. El sistema de transporte puede usarse para:

Borrado de objetos obsoletos en el sistema destino.

Inserción de nuevos objetos en el sistema destino.

Modificación de objetos ya existentes en el sistema destino.

Cuando se crea o modifica un objeto en el sistema de desarrollo, el sistema propone un código único para identificar la creación o modificación de ese objeto, siempre y claro está que el mandante donde se esté trabajando esté configurado para registrar cualquier modificación (ver capítulo 12). El código propuesto conforma lo que se denomina Orden de Transporte y a ella se asociarán los objetos que el usuario cree o modifique, de tal manera que el sistema bloqueará, dependiendo de la naturaleza de la orden, esos objetos para que nadie más que el propietario de esa orden de transporte pueda modificar esos objetos mientras la orden no esté liberada, es decir preparada para ser transportada.

La nomenclatura de una orden de transporte es:

<SID>K9nnnnn

donde <SID> es el nombre de la base de datos del sistema donde estamos trabajando y 9nnnnn es un número secuencial que irá creciendo desde 900000 hasta 999999 a medida que vayamos creando nuevas órdenes de transporte.

El sistema de transportes no asocia directamente los objetos creados o modificados a una orden de transporte sino que lo hace a través de las tareas; las tareas deben obligatoriamente pertenecer a una única orden de transporte y al igual que ellas siguen el mismo código secuencial de tal manera que nunca pueden existir varias órdenes o tareas con el mismo código. Las tareas, al igual que las órdenes, están asignadas a un usuario y su finalidad es mejorar la gestión de los cambios introducidos en el sistema ya que una orden puede albergar varias tareas pertenecientes o no al mismo usuario.

Ejemplo: Supongamos un sistema SAP R/3 de desarrollo cuyo SID es D10 en el cual el usuario USUARIO1 crea un nuevo programa llamado ZPROGRAMA y una nueva tabla llamada ZTABLA. Supongamos que es la primera orden de transporte que se genera en ese sistema por lo que su código será D10K900000, y que se usa la misma orden para englobar los dos objetos.

Supongamos el mismo sistema pero el caso de introducir cada objeto en una orden distinta, por ejemplo D10K900000 y D10K900002.

La diferencia básica entre un caso y otro será que el transporte al sistema productivo de la primera orden conllevará el transporte de los dos objetos – programa y tabla – a la vez, mientras que en el segundo caso el transporte de una orden conllevará el transporte sólo del objeto asociado.

Será tarea del propietario de la orden el decidir de cuantos objetos se va a componer cada orden de transporte. No se deberá crear una orden para cada objeto a modificar o crear ya que esto complicará de manera excesiva nuestra labor de gestión de las órdenes de transporte; tampoco se deberá asignar una única orden de transporte a todos los objetos que vayamos a crear o modificar ya que ello puede llegar a hacer inmanejable la orden debido a su tamaño.

Se deberá, por lo tanto, llegar a un término intermedio de tal forma que incluyamos en una orden los objetos que puedan estar relacionados, bien debido a su naturaleza, bien porque pertenezcan al mismo proyecto.

Clases de desarrollo

Cuando nos disponemos, en el sistema de desarrollo, a crear nuevos objetos con las herramientas de desarrollo apropiadas, el sistema antes de asignarle una orden de transporte nos pedirá asociar el nuevo objeto por crear a una Clase de Desarrollo.

Las clases de desarrollo no son más que agrupaciones lógicas de objetos que, además, tienen asignada internamente una ruta de transporte, es decir, un sistema origen y un sistema destino de transporte. Al asociar un objeto a una clase de desarrollo estaremos, implícitamente, asignándole la ruta de transporte a seguir cuando la orden asociada a ese objeto sea transportada. Todos los objetos estándar del sistema SAP R/3, ya sean programas, tablas, ayudas de búsqueda, etc, tienen asociado una clase de desarrollo estándar de SAP.

Los objetos nuevos a crear deberán asociarse a clases de desarrollo nuevas, que se distinguirán de las estándar por el primer carácter de su identificación, que siempre deberá ser una ”Z” o también para los casos de report una “Y”. Como caso excepcional podremos asignar a nuestros objetos la clase de desarrollo $ TMP, la cual es denominada temporal o local y tiene como particularidad el hecho de que los objetos a ella asociados no son transportados a ningún sistema destino, y por lo tanto el sistema no le asigna ninguna orden de transporte. Esta clase de desarrollo se deberá asignar a objetos que sean de pruebas y que no deseemos que vayan a pasar nunca a formar parte del sistema de producción. Hablamos entonces de objetos locales privados o temporales.

Tipos de órdenes de transporte

El sistema SAP R/3 provee distinto tipo de órdenes de transporte para cada tipo de cambio que se desee realizar en el sistema:

Órdenes de customizing A la hora de implementar el modelo de empresa en SAP R/3 se necesita establecer ciertos datos en la parametrización del sistema. La parametrización afecta primordialmente a los procesos de negocio y es, por ello, dependiente de mandante. Si un mandante ha sido establecido con grabación automática de cambios, una tarea y una orden de customizing son creadas automáticamente cuando un usuario en un sistema R/3 realiza cambios de customizing.

Ordenes de modificación transportables A la vez que cambios en el customizing, será también necesario desarrollar nuevas aplicaciones que se ajusten perfectamente a las necesidades de la empresa. Esto permite moldear el sistema R/3 a cualquier necesidad. Estos cambios, pertenecientes al área de desarrollo y que afectarán básicamente a programas y tablas, son independientes de mandante; esto significa que tienen efecto en todo el sistema. La creación de nuevos objetos, o la modificación de los que proporciona SAP son grabados, de manera similar al customizing, en tareas asignadas a órdenes de modificación transportables.

Órdenes de modificación locales También se pueden realizar cambios locales; se distinguen de los anteriores en que estos cambios no pueden ser transportados a otros sistemas.

Estados de una orden de transporte y sus tareas

Desde que se crean una orden de transporte y sus correspondientes tareas hasta que son liberadas (fase previa para el transporte de dicha orden a otro sistema), éstas pasan por dos estados:

Modificable Cuando la orden o tarea es creada para ser asociada a objetos de desarrollo o de customizing, ésta aparece con status modificable; es decir, permite la inclusión y eliminación de objetos asociados. Si se trata de una orden, ésta permite la asignación o borrado de tareas; si se trata de una tarea, esta permite la asignación o desasignación de objetos del sistema.

Liberada El paso previo del transporte consistirá en la liberación de la orden y sus tareas asociadas. Para poder liberar una orden, se deberá primero liberar todas sus tareas asociadas. La liberación de una tarea consiste en cerrarla para posteriores modificaciones; es decir, no se podrá asignar nuevos objetos a esa tarea ni desasignar los ya existentes.

La liberación de una orden consiste en cerrarla para posteriores tareas; no se podrá crear ninguna nueva tarea asociada a esa orden ni se podrán borrar las ya existentes.

Una orden puede permanecer en status Modificable aunque todas sus tareas asociadas estén en estado liberado; ello nos permitirá asignarle nuevas tareas con status modificable para poder seguir trabajando con ella hasta que liberemos la orden.

La liberación de una orden de transporte además de bloquearla para cualquier modificación futura, realiza el export de la orden. El export de la orden consiste en la creación de dos ficheros a nivel de sistema operativo – fichero data y fichero cofiles –. En estos ficheros se produce la exportación de los datos fuera de su base de datos, de tal manera que puedan ser transportados al sistema destino. Así pues, el transporte no es más que la exportación de información fuera de la base de datos de origen a fichero del sistema operativo y la importación de dicha información en la base de datos destino.

Los dos ficheros creados en la exportación de una orden de transporte tienen la siguiente ubicación en el sistema operativo:

Fichero data

Ubicado en /usr/sap/trans/data; es el que contiene toda la información asociada a la orden de transporte; cuantos más objetos estén asociados a la orden de transporte a liberar, mayor será el fichero data a crear y mayor el tiempo que llevará su creación, es decir, la exportación. La nomenclatura del fichero data, siendo la de la orden liberada <SID>K9nnnnn, puede ser:

D9nnnnn.<SID>

R9nnnnn.<SID>

Fichero cofiles

Ubicado en /usr/sap/trans/cofiles; es un fichero de control necesario para el transporte; su tamaño es mucho menor que el data ya que no contiene los datos de la orden. La nomenclatura del fichero cofiles, siendo la de la orden liberada <SID>K9nnnnn, es: K9nnnnn.<SID>

Customizing organizer y workbench organizar

Para gestionar las órdenes de transporte y sus tareas podremos usar el customizing organizer – CO – y el Workbench Organizer – WBO –. Tanto uno como otro se pueden acceder a través de las transacciones SE09 como SE10 y desde ellas se puede gestionar las órdenes de transporte relativas a desarrollo (órdenes de modificación tanto locales como transportables; esta herramienta la usarán los desarrolladores) y las de Customizing (herramienta que usarán los consultores).

En ambas herramientas la pantalla de selección dispone como parámetro principal del usuario, que por defecto está relleno con el nombre del usuario con el que nos hemos conectado al sistema. Todas las órdenes que visualicemos con esta herramienta serán las asociadas al usuario arriba indicado. Como parámetros adicionales podemos elegir visualizar las órdenes modificables y las liberadas o sólo uno de los dos tipos. Además, también podemos restringir por fechas para evitar que el listado sea demasiado largo si es que hemos trabajado con muchas órdenes de transporte. En el caso del customizing organizer tenemos, además, la posibilidad de visualizar sólo las órdenes de customizing o sólo las de workbench o ambas a la vez. Una vez elegidos los parámetros de selección del CO o del WBO pulsaremos el botón de visualización y accederemos a una pantalla.

Desde esta pantalla podremos identificar qué objetos están asociados a qué órdenes de transporte sin más que ir desplegando la estructura en árbol presentada. Esta estructura en árbol nos muestra en un primer nivel la orden de transporte, en un segundo nivel las tareas asociadas a esa orden y en un tercer y último nivel los objetos asociados a esa tarea.

Tanto el primer como segundo nivel tienen asociado un propietario que es mostrado a la derecha de la orden y tarea. El propietario de la orden no tiene por qué coincidir con el propietario de las tareas asociadas ya que el propietario de esa orden puede crear tareas asociadas y repartir la propiedad de ellas entre los usuarios que considere adecuados. Esto puede ser de utilidad en el caso del desarrollo de una nueva aplicación donde el jefe de proyecto crea una única orden, si así lo considera oportuno, y crea una tarea asociada a esa orden por cada desarrollador involucrado en el proyecto asignando la propiedad de cada tarea a cada uno de los desarrolladores. De esta manera, cada desarrollador irá asignando sus objetos a su tarea con lo que no se producirá solapamiento. Una vez que los desarrolladores acaben su trabajo, el jefe de proyecto les indicará que liberen sus tareas (la liberación sólo la puede realizar el propietario), pero el jefe de proyecto será el que tenga la decisión de cuándo liberar la orden, de la cual él es propietario. La exportación de la orden a fichero no se producirá hasta que el propietario de la orden ejecute la liberación de la misma.

Desde esta pantalla podremos ejecutar la liberación de cualquier orden de la que seamos propietarios. La liberación debe llevar siempre esta secuencia:

Ejecutar la liberación de todas las tareas asociadas a esa orden

Ejecutar la liberación de la orden

Además de la liberación podremos borrar asignaciones de objetos a tareas con estatus modificable. Esta opción nos permite eliminar la asignación de un objeto dentro de una tarea sin más que posicionar el cursor en el objeto deseado y pulsar a continuación la opción de borrar. Esta opción no borra físicamente el objeto, sólo su asignación a una tarea, y deberá ser usado cuando, por error, hayamos incluido un objeto en una tarea no deseada. Esta opción de borrado también puede ser útil para eliminar tareas con estatus modificable de órdenes, la única restricción que nos impone el sistema es que esas tareas deben estar vacías. La opción de borrado – bien de objetos o de tareas – sólo es aplicable cuando la orden y la tarea asociada tienen el estatus modificable, es decir, que no se ha liberado todavía. Una tarea ya liberada no permite la desasignación de sus objetos mediante la opción de borrado. En esta pantalla, además, podremos cambiar el texto descriptivo asociado a una orden con el botón de modificar.

Otra opción muy importante disponible tanto en la pantalla inicial del WBO y del CO así como en las pantallas donde se muestran las órdenes de transporte seleccionadas de los dos organizers es la opción crear orden. Eligiendo esta opción el sistema nos muestra  una  pantalla de diálogo.

Como campo principal se nos pide que introduzcamos una descripción para la orden a crear cuya codificación la dará automáticamente el sistema al crearla. El sistema, además, crea la orden con una única tarea cuyo propietario es el mismo que el que ha creado la orden; esta opción se puede cambiar. Podremos introducir tantas tareas como queramos sin más que asignar nuevos empleados a las tareas a introducir en la orden – el sistema introducirá tantas tareas en la orden como empleados se haya especificado –.

A esta opción de creación de órdenes de transporte también se puede acceder desde fuera de la transacción SE09 y SE10 cuando modificamos o creamos un nuevo objeto de desarrollo. El sistema nos pide asignarle una orden ya creada o crear una nueva.

Transporte manual de órdenes

Una vez que una orden ha sido liberada, ésta se encuentra preparada para ser importada al sistema destino.

El programa de control del transporte se encuentra a nivel del sistema operativo; es el llamado tp.exe que está junto con el resto de programas ejecutables de SAP que componen el Kernel en la ruta /usr/sap/<SID>/SYS/exe/run, donde <SID> es el directorio que tiene igual nombre que la base de datos de SAP instalada en el servidor.

El programa tp se debe ejecutar desde la ruta /usr/sap/trans/bin, en el servidor y directorio adecuado dependiendo del sistema operativo:

En sistemas UNIX, este directorio del transporte deberá estar compartido vía NFS para todos los entornos que conforman la ruta del transporte. Es por ello por lo que podremos acceder a este path desde cualquier servidor al que nos conectemos desde el sistema operativo (por ejemplo vía telnet).

En sistemas Windows NT, este directorio de transporte deberá estar configurado como compartido para que desde todos los entornos esté disponible, sin embargo sólo será local para uno de ellos.

Accederemos a través del emulador MSDOS en el servidor donde la ruta es local.

Presentamos a continuación la estructura en árbol del sistema operativo

UNIX que es necesaria para el transporte y explicaremos para qué sirve cada directorio:

/usr/sap/trans/bin Directorio desde donde se lanza el programa de control del transporte, tp.

/usr/sap/trans/data Directorio donde se almacenan los ficheros data generados en la exportación de datos desde la base de datos que se realiza durante la liberación de una orden.

/usr/sap/trans/cofiles Directorio donde se almacenan los ficheros cofiles generados en la exportación de datos desde la base de datos que se realiza durante la liberación de una orden.

/usr/sap/trans/log Directorio donde se almacenan en ficheros los logs de cada una de las órdenes de transporte que se importan al sistema destino.

/usr/sap/trans/buffer Directorio donde se almacena un listado con todas y cada una de las órdenes de transporte que han sido liberadas desde el sistema origen.

Antes de poder importar al sistema destino, el programa de control del transporte chequea que la orden solicitada se encuentra en el listado mencionado y que está todavía sin transportar; si es así, se ejecuta el transporte al sistema destino. Las órdenes, por defecto, al ser liberadas son añadidas al ”buffer” por lo que no será necesario incluir ninguna orden en este listado a no ser que expresamente hayamos eliminado su entrada de dicho listado o que la orden ya haya sido transportada y queramos volver a ejecutar su transporte.

Veamos a continuación cómo deberemos usar el programa de control para gestionar el transporte de las órdenes ejecutándolo desde el directorio bin mencionado antes:

tp showbuffer <SID>

Nos muestra el listado de órdenes incluídas en el buffer. En lo que sigue, <SID> se refiere al nombre del sistema destino del tranporte. Las órdenes que ya han sido transportadas al sistema destino aparecen con el texto already imported.

Todas las ejecuciones del comando tp, independientemente del argumento asociado, devuelven un código de retorno cuyos valores pueden ser:

0 ! Operación ejecutada con éxito

4 ! Operación ejecutada con advertencias

8 ! Operación ejecutada con errores.

Un valor mayor que 8 también indicará que la operación no se ha realizado con éxito.

tp delfrombuffer <orden> <SID>

Elimina del listado del directorio buffer la referencia a la orden de transporte seleccionada. No borra la orden físicamente, pero impide que se pueda transportar esa orden.

tp addtobuffer <orden> <SID>

Añade la orden seleccionada al buffer, dejando la orden preparada para ser transportada. Esta operación, por defecto, no es necesario ejecutarla a no ser que una orden sea eliminada con el comando anterior y deseemos posteriormente transportarla.

tp import <orden> <SID>

Importa al sistema destino la orden seleccionada, y lo hace en el mandante cuyo nombre es el mismo que en el sistema origen. Si el mandante destino de la orden no coincide con el mandante origen de la orden, se deberá obligatoriamente especificar el mandante destino con la opción client=<mandante destino> añadida después del <SID>.

tp import all <SID>

Importa al sistema destino especificado todas las órdenes que hayan sido liberadas y que, por tanto, se encuentran en el buffer. Las órdenes son importadas por orden de aparición en buffer, por lo que primero se transportarán las órdenes que han sido liberadas primero. Si el mandante destino no coincide con el origen, se deberá usar la opción especificada en el

caso anterior.

No se recomienda el uso de esta opción ya que podemos desear importar al sistema destino en un orden distinto al que han sido liberadas las órdenes que se encuentran en el buffer, y este comando tiene un orden de transporte preestablecido.

tp import <orden> <SID> client=<nnn> u1

La opción u1 es el modo incondicional de sobreescritura. Habrá que especificarlo obligatoriamente si deseamos transportar al sistema destino una segunda vez una orden. Esto es así porque el sistema chequea que la orden ya ha sido transportada previamente y no vuelve a ejecutar la importación. Para obligarle a sobrescribir la misma orden que se ha transportado previamente, será necesario especificar la opción u1.

Veamos a continuación un ejemplo. Supongamos un sistema de desarrollo D10 en un servidor NT llamado devsap10 y un sistema de producción P10 en otro servidor NT llamado prodsap10. En ambos entornos está establecida la ruta del transporte D10 ! P10 a través de la clase de desarrollo ZDEV. Estableceremos el directorio de transporte C:\usr\sap\trans localmente en el servidor de producción, prodsap10.

Supongamos que creamos en el mandante 101 de D10 un programa ZREPORT que queremos pasar al mandante 110 de producción. Al crearlo, le asignaremos la clase de desarrollo ZDEV y el sistema nos propondrá un código para su orden de transporte, por ejemplo D10K902010.

Al liberar esta orden, el sistema de desarrollo se conecta a : file://prodsap10/usr/sap/trans para crear en los subdirectorios data y cofiles los ficheros D902010.D10 y K902010.D10 correspondientemente. Abriendo una ventana de MSDOS en el sistema de producción, sistema destino del transporte, ejecutamos:

C:\usr\sap\trans\bin\tp showbuffer P10

para comprobar que la orden D10K902010 se encuentra en el buffer; si acaba de ser liberada, aparecerá la última del listado. Una vez comprobado que la orden se encuentra en el buffer del sistema de producción ejecutaremos el transporte al mandante 110. Como el mandante destino y origen no coinciden deberemos usar la opción client=<SID>. C:\usr\sap\trans\bin\tp import D10K902010 P10 client=110 Una vez que este comando ejecute la importación y su código de retorno sea 0, el programa ZREPORT estará disponible en el sistema de producción.

Existe la opción más amigable de utilizar la transacción STMS (Transport Management System) para realizar los transportes. Los pasos para realizar un transporte una vez lanzada la transacción son:

1: Ir a la cola de transporte correspondiente.

2: Refrescar la cola pulsando el botón “Refresh”.

3: Al final de la lista seleccionamos nuestra orden y hacemos clic en el botón “Transportar” (aquí hay que fijarse en que el botón debe ser el de transporte individual y NO es de transportar todo).

4: Nos saldrá una ventana donde deberemos introducir el mandante destino. En la pestaña Fecha marcar “Inmediatamente” y en la pestaña Opciones desmarcar todo.

5: Nos aparece un pop up preguntando si deseamos realizar el import, elegimos Sí.

6: Posteriormente nos aparecerá una ventana para completar con el usuario y clave del mandante destino.

7: Por último, deberemos actualizar o refrescar nuestra orden hasta que quede marcada con un tic verde (esto significa que el import se ha realizado correctamente).

Log del transporte

Existe dentro del sistema SAP R/3 una herramienta que nos proporciona mucha más información sobre el transporte de una orden que el simple código de retorno devuelto por el comando tp. Tal código de retorno nos informa si el transporte se ha ejecutado correctamente, o si por el contrario ha ocurrido algún problema; sin embargo no nos informa qué tipo de problema ha ocurrido. La herramienta del log del transporte está disponible tanto en la transacción SE09 como en la SE10. Podemos pulsar el botón de visualización individual – aparece asociado a un icono de gafas – en la barra de aplicaciones si conocemos el número de orden cuyo log queremos consultar:

También podemos rellenar los parámetros de selección explicados en la sección del WBO y CO para, posteriormente, buscar la orden en el listado que nos aparezca en pantalla y una vez posicionado el cursor sobre la orden deseada, pulsar la opción log del transporte – asociado a una hoja y gafas – dentro de la barra de aplicaciones.

Las dos opciones nos llevan a la misma pantalla. En ella, podemos ver desde qué sistema se ha producido el export así como el import en el sistema destino con cada uno de sus pasos.

La importación se realiza en varios pasos, dependiendo su número del tipo de objeto a transportar. Desglosando la estructura en árbol del log podemos obtener distintos niveles de información, cada vez más detallados.

Una vez que hemos visto en qué paso del transporte se ha producido un error, haremos doble clic sobre esa línea para acceder a un listado completo del log en ese paso. Esto nos sirve para saber por qué razón se ha producido un error en el transporte y cómo habrá que resolverlo. Los errores más comunes son de información incompleta en el sistema destino para poder activar las modificaciones recién transportadas.

Un ejemplo puede ser que el código fuente de un programa que queramos transportar al sistema destino del transporte haga referencia a una tabla cuya definición se encuentra en otra orden de transporte, todavía sin transportar. Si transportamos primero la orden del código fuente, la importación fallará devolviendo un código de retorno 8. Si visualizamos el log del transporte de dicha orden veremos que el paso que ha fallado ha sido la generación del código fuente por hacer referencia a una tabla que todavía no existe en el sistema destino. Lo que deberemos hacer será, pasar la orden donde se encuentra la definición de la tabla a la que se hace referencia en el programa y, posteriormente, transportar de nuevo la orden que ha fallado – primero deberemos añadirla manualmente de nuevo al buffer –.