Crear parches

Gestión de pantalla

Pestaña Pantalla de entrada

Tipos de elementos que se pueden parchear

Esta tabla permite completar la lista de objetos que hay que parchear. La lista se identifica por un tipo de objeto y un nombre. La definición de los distintos tipos y el significado del nombre se proporcionan más adelante. La columna Rango indica el orden en el que se ordenan los tipos de elementos en el fichero de parche (ver siguiente párrafo). Los elementos que contienen un rango 100en la tabla siempre se sitúan al final del parche (por orden alfabético de los códigos de los elementos).

Notas importantes

Transferencia total de los datos de una tabla

El código TABpermite transferir los datos de la tabla recargándola en la base con su estructura y sus datos. No obstante, los elementos del diccionario relativos a la tabla no se crean, de modo que puede no aparecer como visible. Este código también está adaptado cuando se quiere recargar una tabla ya creada en los dossieres por parchear que no ha cambiado de estructura. Si no es el caso, hay que insertar dos líneas en la definición del parche: la primera para la definición de la tabla (ATB XXXXX) y la segunda para el contenido (TAB XXXXX). Aunque no se introduzcan en este orden, la función del parche los reemplaza en este orden. En la integración del parche, la tabla se crea en el diccionario y en la base, si no existe (de lo contrario, la estructura se actualiza si ha cambiado). A continuación, la tabla se recarga con los datos.

Transferencia parcial de los datos de una tabla

Para transferir parcialmente el contenido de una tabla, introduce la abreviatura de la tabla en la columna Tipo e indica una condición lógica en la columna Nombre objetoque se utilizará para extraer el dossier de origen y llevar a cabo la integración en el dossier de destino. Hay que tener en cuenta que los datos extraídos pueden modificar los datos existentes con las mismas claves o crear nuevos datos. No obstante, por motivos de seguridad, los datos nunca se borran en la integración del parche. En el siguiente caso, por ejemplo, en la tabla de países (abreviatura TCY):

Si en el parche se introduce una línea con TCY y la condición CRY="AL", el parche solo va a contener la línea correspondiente a Albania y la integración del parche en el dossier de destino va a reemplazar AL de Alemania por AL de Albania.

Si en el parche se introduce una línea con TCY y la condición pat(CRY,"A*"), el parche va a contener las cuatro líneas AD, AE, AF y AR. En la integración, se van a crear las fichas AE de Emiratos Árabes Unidos y AR de Argentina, se va a reemplazar AL de Alemania por AL de Albania, y se van a mantener A de Afganistán y AU de Australia, que no se habían entregado, pero que existían ya en el dossier de destino.

Si en el parche se introduce una línea con TCY y la condición find(CRY,"AD","AE","AL"), el resultado sería el mismo, salvo AR de Argentina, que no se transferiría.

La única forma de borrar datos es:

• reemplazar globalmente el contenido de una tabla completa (parche de tipo TAB);
• entregar un script mediante el código EXE(ver más adelante). Por ejemplo, para garantizar que en los países que comienzan por A la lista solo contenga los países con los códigos AD, AE, AL, se habría entregado un script (llamado MAJPATCHnnn, por ejemplo) con las líneas descritas en el siguiente ejemplo.

Ejecución de un script

El código EXE, que permite indicar el nombre de un script por ejecutar, es un caso específico. A pesar de su número de rango, el script se ejecuta al final de la integración del parche (puede existir de antemano o entregarse en el propio parche, ya que la ejecución se realiza al final de la integración).

El script debe contener un subprograma PATCH con un parámetro correspondiente al código del dossier. Este es el subprograma que se ejecutará. Por lo tanto, para el ejemplo anterior, se obtendría el siguiente programa:

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+".TABCOUNTRY" [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0
Commit
End

Como se puede observar, hay que declarar las tablas en el subprograma teniendo en cuenta que deben declararse en un dossier que no es necesariamente el dossier en curso (lo garantiza la sintaxis Local File = NOMBREDOS + ".NOMBRETABLA").

Scripts genéricos por ejecutar

Cuando se realizan parches en elementos modelo de la interfaz de usuario (pantallas modelo utilizadas para crear ventanas de transacción), hay que revalidar las pantallas correspondientes.

La revalidación se puede ejecutar declarando la ejecución del script correspondiente en el mantenimiento. Estos son los scripts estándar que hay que lanzar en función del tipo de elemento parcheado:

Este tipo de funcionalidad también se puede realizar en un desarrollo específico (basta con añadir el subprograma PATCH indicado en el párrafo anterior).

Parche de documentación

La estructura de los datos de la documentación es algo diferente. Por defecto, se aplican las siguientes normas en la creación o revalidación de un dossier:

• Los textos y ficheros de la documentación (tablas ADOCBLB y ADOCCLB) se introducen en el dossier supervisor y no se transfieren a los dossieres dependientes (pero se pueden crear textos de ayuda local para un dossier que se almacenan localmente).
• La estructura de la documentación (vínculos de documentación, que son prácticamente elementos del diccionario, y estructura de los párrafos) se almacena en cada dossier y se copia en los dossieres inferiores en caso de revalidación (cumpliendo con los códigos de actividad verticales o específicos que se pueden haber definido en un dossier secundario).

Cuando se integra un parche de documentación (tipo ADO), el principio es el siguiente:

• La estructura de la documentación se puede integrar en todos los dossieres indicados en la aplicación del parche, independientemente del tipo de parche (en función de la lista de dossieres proporcionada en la integración).
• Los textos y ficheros solo se integran en el dossier supervisor si el tipo de parche es Supervisor(como en los parches de documentación estándar). Si el tipo de parche es otro, los textos y ficheros se pueden integrar en todos los dossieres.
• El parche de tipo ADF (vínculos) se puede integrar en todos los dossieres, aunque el parche sea de tipo Supervisor.

Nombre de los ficheros de parche

La integración del parche comprueba la secuencialidad de los ficheros de parche cuando incluyen una secuencia numérica en el nombre. Es recomendable asignarles un nombre definido con la fórmula X_yyyy_zzz.dat, compuesta por los siguientes elementos:

• "X" es un carácter (distinto a P, ya que P se utiliza en los parches estándar) que identifica el tipo de parche.
• "yyyy" es un número secuencial (que en principio comienza por 0001).
• "zzz" es un identificador de la versión que se va a integrar.

Si no se aplica esta norma, cuando se integra un conjunto de ficheros de parche en un directorio, se realizan los siguientes controles:

• No se mezclan ficheros de versiones diferentes en una misma integración.
• No se puede ignorar un número secuencial si ya se han integrado parches identificados por el mismo carácter y el mismo número de versión. Si, por ejemplo, se ha integrado el parche Z_0005_150.dat y se intenta integrar el parche Z_0007_150.dat sin haber integrado previamente Z_006_150.dat, aparece un mensaje en la integración.

Orden de los elementos en un fichero de parche

Cuando se crea un fichero de parche, la norma consiste en que los elementos incluidos en dicho parche formen un todo cuya aplicación deje un dossier coherente. Si se crea una nueva función por parche, ya esté definida por una acción, una ventana, una pantalla, una tabla o dos scripts, parece lógico que todos los elementos se incluyan en el parche.

Cuando se utiliza un conjunto de elementos para formar un fichero de parche, la función de creación los ordena por un orden específico de tipos para evitar errores de integración. Si, por ejemplo, se integra una ventana antes que las pantallas que la componen, se produce un error de Pantalla inexistenteen la validación. Por lo tanto, los tipos de datos se integran antes que las pantallas y las tablas, las pantallas antes que las ventanas, y así sucesivamente.

El orden que se utiliza en la generación del parche corresponde al rango indicado en la tabla anterior. También es el orden propuesto que aparece en la función Creación automática de parches.

No obstante, hay que tener en cuenta que no se pueden solucionar todos los conflictos posibles. Por ejemplo, un tipo de datos puede hacer referencia a una acción, que a su vez puede hacer referencia a una ventana, que a su vez puede hacer referencia a una pantalla, que a su vez puede hacer referencia a este tipo de datos. Para solucionar este tipo de conflicto (poco habitual), es posible que haya que descomponer el fichero de parche en dos ficheros (el primero para entregar todos los elementos con un tipo de datos que no haga referencia a la acción y el segundo para entregar el tipo de datos que integre la acción, por ejemplo).

Elementos del diccionario no parcheados

Al instalar un parche con los elementos del diccionario, se respetan algunos campos, considerados como elementos parametrizables del diccionario, independientemente de sus protecciones por código de actividad. Por ejemplo, un destino por defecto en un informe.

Un anexo técnico muestra los detalles de los campos correspondientes.

Formato específico de los elementos AAA

Un parche de tipo AAA corresponde a una línea procedente de un modelo de parametrización. Utiliza un formato específico para el código del elemento. El formato es uno de los siguientes:

MODELE~CODE_LEG~CODE_TRS~='FORMULE_SELECTION'

MODELE~CODE_LEG~CODE_TRS~CLE~SOUS_CLE~SOUS_SOUS_CLE...

En estas líneas:

• MODELE corresponde al modelo de datos utilizado para describir las tablas que se van a extraer.
• CODE_LEG corresponde al código de legislación, que puede estar en blanco (en ese caso, se mostrarán dos "~" seguidas).
• CODE_TRS corresponde al código de transacción, que también puede estar en blanco.
• FORMULE_SELECTION es una condición de filtro. Cualquier cadena de texto debe expresarse entre comillas dobles ("), ya que la fórmula se introduce entre comillas simples (').
• CLE~SOUS_CLE~SOUS_SOUS_CLE (el número de subclaves es variable) corresponde al caso específico en el que solo se quiere seleccionar un valor de clave correspondiente a la tabla principal del modelo. Este caso solo se puede dar cuando se llama a un modelo (código AAA) desde la creación del parche y se abre la ventana para seleccionar el modelo e introducir la clave por búsqueda directa.

Informes

Por defecto, los informes siguientes están asociados a la función :

 PRTSCR : Impresión pantalla

Pero esto se puede modificar por parametrización.

Tarea batch

Esta función puede lanzarse en Batch. La tarea estándar ZPATCHC esta prevista con este fín.

Botones específicos

Mensajes de error

Además de los mensajes genéricos, los mensajes siguientes de error pueden aparecer durante la captura :

... : directorio inexistente

La ruta de acceso al fichero de parche no existe.

Tipo de objeto erróneo

El tipo de objeto no corresponde ni a uno de los tipos de objetos predefinidos ni a la abreviatura de una tabla existente.

Diccionario de … XXX ficha inexistente

Se ha intentado extraer un objeto de un diccionario inexistente.

Valor incorrecto

La condición de extracción asociada a la extracción de los datos de una tabla no es sintácticamente correcta.

Tablas utilizadas

Consulta la documentación de Puesta en marcha