Embed Size (px)
Citation preview
Área SAP
ÓRDENES DE TRANSPORTE
Definición de metodología para órdenes de transporte en los desarrollos SAP
Factoría Lleida
Lleida, enero de 2013
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
1. Contenido del documento
1. Contenido del documento.....................................................................................................1
2. Control de Cambios...............................................................................................................2
3. Objetivos del documento......................................................................................................3
4. Descripción del proceso.......................................................................................................4
4.1 Cuestiones a tener en cuenta..............................................................................................4
4.1.1 Nomenclatura de órdenes...............................................................................................4
4.1.2 Cabeceras de creación/modificación en programas.......................................................4
4.2 Metodología de trabajo con órdenes de transporte..............................................................5
4.2.1 Metodología de trabajo con órdenes de transporte de Workbench.................................5
4.2.1.1 Objetos Web Dynpro, Formularios y Workflow............................................................8
4.2.2 Metodología de trabajo con órdenes de transporte que contengan datos o de Customizing............................................................................................................................. 9
4.3 Responsable de la orden original.........................................................................................9
1
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
2. Control de Cambios
Versión Páginas Fecha Modificación Motivo del cambio
01 Todas 20/09/2009 Creación del documento
02 10/05/2012 Revisión de la metodología
03 15/01/2013 Metodología de trabajo con objetos Web
Dynpro, Formularios y Workflow.
Metodología de trabajo con órdenes de
transporte que contengan datos o de
Customizing.
2
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
3. Objetivos del documento
Este documento tiene como objetivos:
Definir el procedimiento de gestión de órdenes de transporte en SAP.
Establecer una metodología única a seguir para realizar el transporte de un entorno a otro.
Este procedimiento es de obligado cumplimiento para todas las personas que trabajen en el
entorno SAP.
3
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
4. Descripción del proceso
4.1 Cuestiones a tener en cuenta
4.1.1 Nomenclatura de órdenes
De forma general y que se aplica en todos los módulos la nomenclatura de las órdenes será la
siguiente:
MODULO – Nº de incidencia/petición – Descripción de la incidencia petición
Un ejemplo de descripción de orden sería:
SIGIRH - INC1203451 - Informe fotografía empleados
4.1.2 Cabeceras de creación/modificación en programas
De forma obligatoria cada vez que creemos/modifiquemos un programa se añadirán cabeceras para identificar el cambio.
CREACION DE PROGRAMA
Se añadirá al inicio del programa una cabera con los siguientes datos:
*---------------------------------------------------------------------** PROGRAMA: (nombre del programa)* TIPO: (tipo programa: report, module pool, función…)* REF. FUNCIONAL: (numero de incidencia/petición) * CREADO POR: (autor – usuario SAP)* FECHA CREACIÓN: (fecha)* DESCRIPCIÓN: (descripción de las acciones que se van a desarrollar)*---------------------------------------------------------------------*
MODIFICACION DE PROGRAMA
Se añadirá al inicio del programa una cabera con los siguientes datos:
*---------------------------------------------------------------------** INDRA_X ** MODIFICADO POR: (autor – usuario SAP) ** FECHA: (fecha) ** REF. FUNCIONAL: (numero de incidencia/petición) ** DESCRIPCIÓN: (descripción de las acciones que se van a desarrollar)*---------------------------------------------------------------------*
En todas las líneas del código que se añadan deberán estar identificadas con el tag INDRA_X y
el numero de petición/incidencia y todas las que se modifiquen NO se deberán borrar sino
comentarlas marcándolas con el tag INDRA_X y creando una nueva línea identificada igualmente
con el tag INDRA_X.
Esto nos permitirá tener localizado todo el código añadido/modificado debido al desarrollo de una
petición/incidencia.
4
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
4.2 Metodología de trabajo con órdenes de transporte
4.2.1 Metodología de trabajo con órdenes de transporte de Workbench
Para los objetos Web Dynpro, Formulario y Workflow se seguirá esta metodología en todos los
puntos excepto en el los que se indica que se debe comentar/descomentar el código. Para estos
objetos se deberá recuperar la versión de Producción de la forma que se indica en el apartado
4.2.1.1.
Se trabaja con el Método de trabajo con copias de órdenes al aportar las siguientes ventajas:
- El objeto original está siempre bloqueado en el sistema origen, si alguien con otro usuario
modifica ese objeto, verá que ya contiene otras modificaciones.
- Evita el tener que restaurar versiones anteriores, ya que sobre la orden original se puede
comentar el código que no interesa (perteneciente a otras modificaciones), y copiar el
objeto en una orden que será la que se transporte a test.
- Evita olvidar objetos a transportar ya que la orden original los contiene todos y se
transportan todos una sola vez.
- No se machacan incidencias/modificaciones en los transportes ya que la orden original las
contiene todas.
Como complemento de trabajo con esta metodología, se incluye un documento interno de control de órdenes de transporte por incidencia/petición llamado 3P (plantilla adjunta).
Paso 0 – pasos a realizar previos para los objetos ya modificados
Se realizará este proceso para integrarlos en el procedimiento modificado.
Se comprueba el log de transporte de la orden activa del objeto en el entorno de desarrollo:
- Si la orden está en producción el objeto es idéntico y se puede comenzar a trabajar con él.
- Si la orden no está transportada a producción, se recomienda hacer un un COMPARE
con test y producción del contenido del objeto que vamos a tratar. Las capturas de esta
comparación se añadirán en la pestaña correspondiente del checklist de transporte. Si el
objeto está igual en los tres entornos, crear inmediatamente después de la comparación
una orden para bloquear el objeto. Si no está igual se mirará a quién pertenece la última
versión, acordando con el propietario el bloqueo de la orden y el comentario de las
diferencias para comenzar a trabajar en una tarea suya.
NOTA IMPORTANTE: crear una orden que bloquee el objeto inmediatamente después de haber
hecho el compare con los sistemas de test y producción porque si no, algún otro usuario y en
paralelo, podría entrar a modificar ese objeto sin que se tuviese conocimiento de ello.
5
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
Paso 1 – comienzo de la modificación
Si al modificar el objeto, se solicita una nueva orden de transporte:
- Crear un documento 3P donde marcaremos en el checklist las acciones realizadas y
anotaremos la nueva orden de transporte.
- Empezar la modificación
Si se informa de la creación de una tarea en otra orden de transporte:
- Mirar en qué orden está este objeto
- Hablar con el propietario de esta orden y comunicarle que se va a crear una tarea en su
orden. EN ESTA TAREA SOLAMENTE ESTARÁ EL OBJETO COMÚN, EL RESTO DE
TRABAJO DEL SEGUNDO DESARROLLADOR ESTARÁ EN LA ORDEN
CORRESPONDIENTE A SU PETICIÓN O INCIDENCIA.
- Añadir al documento 3P de la petición en la que ya está el objeto un comentario
explicando que se crea una nueva tarea que provocará modificaciones en los objetos
existentes en la orden
- Crear un documento 3P donde marcaremos en el checklist las acciones realizadas.
- Anotar en el 3P, la orden donde hemos añadido la tarea (orden original) indicando que
tiene objetos que llevan modificaciones de otra petición y que, en la mayoría de los casos,
no todos los objetos de la orden pertenecen a la petición/incidencia que estamos
desarrollando.
- Empezar la modificación.
Paso 2 – probar la modificación
Las pruebas unitarias se realizarán en el entorno de desarrollo.
Las pruebas integradas tanto para incidencias como para modificaciones deben de ser SIEMPRE
en el entorno de test.
Si somos propietarios de la orden original y solo lleva las modificaciones de la petición en curso:
- crearemos una copia de la orden original con todos los objetos.
- la transportaremos a test.
- no hará falta incluirla en el 3P porque es copia de una orden que ya tenemos anotada en
el 3P de esa petición/incidencia.
Si no somos propietarios de la orden original:
- en los objetos afectados por nuestra petición/incidencia y por alguna otra, comentaremos
todo el código que no esté en test/producción (haciendo COMPARE) y que no sea de
nuestra petición/incidencia. 6
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
- crearemos una copia de la orden original con todos los objetos que afecten a nuestra
petición/incidencia. En la descripción de la orden pondremos nuestra incidencia/petición,
no la incidencia/petición de la orden “madre”.
- NOTA: no serán todos los objetos de la orden origen sino solo aquellos que afecten a
nuestra petición/incidencia.
- IMPORTANTE: El transporte a test del objeto común para el no propietario se realizará
incluyendo en la copia de su orden original la copia de la tarea que contiene los objetos
comunes.
- incluirla en el 3P de la incidencia/petición que estamos tratando.
- probar en test el funcionamiento.
- si funciona de forma correcta, descomentar el código comentado en los objetos de la
orden original (no hace falta crear una nueva orden) y liberar la tarea.
- si no funciona de forma correcta, realizar las modificaciones oportunas y crear de nuevo
una nueva copia añadiéndola al 3P.
Para identificar las órdenes “copia” en la descripción de la orden, se nombrarán como se indica a
continuación:
MODULO – Nº de incidencia/petición – Descripción de la incidencia petición cpN
siendo N, un número correlativo para las copias que vayamos haciendo.
Un ejemplo de copia de orden sería:
SIGIRH - INC1203451 - Informe fotografía empleados cp1
SIGIRH - INC1203451 - Informe fotografía empleados cp2
Paso 3 – paso a producción
Cuando se solicite el paso a producción de la petición/incidencia se realizarán las siguientes
acciones
transportar la orden original del 3P.que esté como ok en el checklist
- Verificar que no se ha hecho ningún transporte anterior de los objetos afectados por la
orden petición y que no esté contemplado en nuestra orden ya que si no “machacaríamos”
esa modificación.
- Si se da el caso del punto anterior, hay que añadir a la última versión del objeto
transportada a producción.
- Se solicitará el transporte a producción incluyendo las órdenes de Customizing y
Workbench que sean necesarias.
- Una vez nos ha llegado la notificación de Remedy indicando que se ha realizado el
transporte, comprobar las órdenes una a una (visualizando el log) para verificar que el
transporte ha sido correcto.
NOTA: para poder transportar las órdenes a producción, deben estar liberadas e importadas
correctamente en test.
7
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
4.2.1.1 Objetos Web Dynpro, Formularios y Workflow
En el diseño de las Web Dynpro, los Formularios y el Workflow no existe código que se pueda
comentar. Si es necesario modificar un objeto que ya se está modificando, el procedimiento a
seguir será el siguiente:
Paso 0 – pasos a realizar previos
- Comparar la versión del objeto en Desarrollo con las versiones en Test y en Producción. Anotar
la versión que tenemos en cada uno de los entornos.
Paso 1 – modificación
- Recuperar la versión de Producción.
- Implementar la resolución de la incidencia.
- Transportar la orden a Producción.
Paso 2 – restauración de las versiones correctas en los entornos de Test y Desarrollo
A. Test
- Valorar la opción que tenga menos coste para conseguir en Test la resolución de la incidencia y
la versión que había inicialmente:
- 1. Implementar de nuevo lo que ya se había realizado en la versión de Test sobre la
versión transportada que lleva la resolución de la incidencia.
- 2. Recuperar la versión de Test e implementar sobre ésta la resolución de la incidencia.
- Sea cual sea la opción preferida se deberán probar la versión que había en Test y también la
incidencia.
- Transportar a Test la nueva orden (versión anterior de Test + resolución de la incidencia).
B. Desarrollo (sólo si en el Paso 0 la versión de Test no era la misma que la versión de Desarrollo)
- Valorar la opción que tenga menos coste para conseguir en desarrollo las dos modificaciones: la
resolución de la incidencia y lo que estaba desarrollado:
- 1. Implementar de nuevo lo que ya se había realizado en Desarrollo sobre la versión
transportada (versión de Test + resolución de la incidencia).
- 2. Recuperar la versión que había inicialmente en Desarrollo e implementar sobre ésta la
resolución de la incidencia.
- Sea cual sea la opción preferida se deberá probar también la incidencia antes de su transporte
para asegurar el correcto funcionamiento.
8
Met
odol
ogía
órd
enes
tran
spor
te /
V.2
.0
4.2.2 Metodología de trabajo con órdenes de transporte que contengan datos o de
Customizing
El procedimiento a seguir antes del transporte de órdenes que contengan datos es el siguiente:
- Revisión del contenido de la orden a transportar.
- Si la orden contiene datos, comparar estos datos con el contenido de la tabla en el sistema
destino.
- Si la orden a transportar contiene únicamente registros nuevos se puede transportar
- Si la orden a transportar contiene registros que se van a borrar verificar que
efectivamente se deben borrar en el sistema destino.
- Si la orden a transportar contiene la modificación de registros ya existentes verificar que
todo lo que se va a transportar es correcto y que no ha habido cambios en producción
posteriores a la generación de la orden que puedan ser sobrescritos al transportar.
En el momento de la liberación de la orden, si ésta contiene datos de alguna de las tablas a
controlar identificadas en la tabla ZCONTROLTDATOS:
- Si el usuario de SAP tiene permiso para la liberación, se informará de que la orden contiene
datos a controlar y se permitirá la liberación.
- Si el usuario de SAP no tiene permiso para la liberación, se informará de las tablas de datos que
contiene la orden y del responsable de cada una de ellas. Será necesario dirigirse a este
responsable para la liberación de la orden.
4.3 Responsable de la orden original
El responsable de la orden original será el titular de la misma y será el encargado de liberarla y
hacer el transporte a integración y de asegurarse de que el transporte a producción se realiza
correctamente (esto solo aplica a quien pide transportes a producción).
9
