Reglas de desarrollo

Los add-ons deben seguir un conjunto de reglas para evitar conflictos técnicos debidos a la coexistencia de extensiones.

En este capítulo:

• se detallan las principales reglas que se deben aplicar;

• se destacan las limitaciones que tener en cuenta;

• se ofrecen recomendaciones sobre cómo diseñar y probar extensiones.

Todos los elementos descritos están disponibles a partir de la versión 7.

Principales reglas de desarrollo que implementar

Acciones de campo

Las acciones en los campos de la pantalla se pueden definir desde la plataforma.

Hay una funcionalidad que permite utilizar una acción vertical (SPV) en los eventos (inicialización, control, etc.) de cada campo.

Sin embargo, solo puede haber una acción de este tipo por campo.

En el modo de add-on, todos los partners comparten el diccionario. Debes utilizar las acciones del diccionario para evitar conflictos.

El script vertical del diccionario de pantallas es un programa único y no se puede compartir fácilmente entre diferentes partners.

Los nombres de las acciones del diccionario deben comenzar por tu identificador y estar protegidos con un código de actividad.

Esta regla se aplica a todas las acciones que se añaden al campo de una pantalla estándar.

Si trabajas solo en un script vertical, puedes usar las acciones SPV para las pantallas que:

• están protegidas con un código de actividad;

• no incluyen ningún desarrollo vertical.

Utiliza solamente acciones del diccionario para las acciones de los campos.

No olvides definir el código de actividad para la acción. El nombre del código de actividad debe comenzar por un identificador único.

Gestionar una capa vertical con un modelo de objeto y puntos de entrada

Un script independiente gestiona cada una de las tres capas: específica, vertical y estándar.

En cada script, los desarrolladores utilizan los puntos de entrada que ofrecen los distintos modelos en los que trabajan.

El código fuente del modelo u objeto más utilizado no se proporciona.

En la documentación, se incluye una lista de los puntos de entrada disponibles y un conjunto de variables que se pueden utilizar para interactuar con la estándar.

Solo hay un script vertical por función.

Este es el motivo por el que diferentes usuarios no pueden compartir un script con facilidad; es necesario crear y utilizar un programa de conmutación gestionado manualmente para ejecutar los scripts de diferentes partners secuencialmente.

El procedimiento es el siguiente:

• Antes de la actualización 8, era necesario gestionar el programa de conmutación manualmente, lo que supuso muchos problemas.
• Desde la actualización 8, el supervisor gestiona automáticamente el programa de conmutación de objetos y puntos de entrada, lo que supuso una gran mejora.

Capa vertical con objetos

Antes, el nombre del script vertical se definía en el objeto y el nombre del programa de conmutación se utilizaba para autorizar las llamadas de varias capas verticales.

En la actualidad, hay una casilla en la definición del objeto que, si se marca, le añade al menos un procesamiento vertical.

Con el botón de información puedes consultar los nombres de todos los procesos verticales definidos para dicho objeto.

La definición de los scripts verticales que se van a utilizar en el objeto se configura en la tabla de los puntos de entrada.

El orden en el que se deben ejecutar los diferentes scripts también se define en esta tabla.

Ten cuenta los siguientes aspectos:

• La tabla Puntos de entrada se carga como un conjunto de variables globales cuando crea una sesión clásica. Si se modifica la lista de puntos de entrada, hay que desconectar y volver a conectar para que se aplique el cambio.
• Si la tabla está cargada en la memoria, se comprueba si existe el script adx definido en la lista de puntos de entrada. Si no existe en el dossier ni en ninguno de los dossieres principales, no se añade a la tabla de la memoria y, por tanto, no se ejecuta; ni siquiera si se añade después de haber creado la sesión. Desconecta y vuelve a crear la tabla en la memoria.

Entender el orden de ejecución de las diferentes capas

La misma lógica se aplica a cada punto de entrada.

El modelo llama a los siguientes elementos, si existen, en este orden:

• script específico
• todos los scripts verticales según su prioridad
• script estándar

Se utilizan dos variables globales para controlar la ejecución de varios scripts:

• GPV: si se establece en 1, impide la ejecución de la capa vertical.
• GPE: si se establece en 1, impide la ejecución de la capa estándar.

La capa estándar establece estas dos variables en 0 antes de ejecutar el bucle global.

A continuación:

• Si GPV se establece en 1 en un script específico, todos los scripts verticales se omiten y no se ejecutan. Este comportamiento se debe validar caso por caso en el entorno del cliente.

• Si GPE se establece en 1 en un script específico o en uno de los scripts verticales, la capa estándar no se ejecuta. Este comportamiento es excepcional; se suele adoptar cuando hay que ejecutar la capa estándar antes que la capa vertical o la específica. No omitas la capa estándar.

Casos complejos durante la ejecución del punto de entrada

Una de las capas verticales requiere que la capa estándar se ejecute primero.

$ACTION
Case ACTION
Done “PICKE”: Gosub ETIQP
………
Endcase
Return

$ETIQP
# Execute the standard code first
Gosub ACTION From SUBPTH

GPE=1 :# Avoid to reexecute the standard
# Vertical code
……
……
Return

En el entorno del cliente y según sus necesidades, define el orden de ejecución de las diferentes capas verticales.

Si una capa vertical requiere que la capa estándar se ejecute primero, hay que adaptar la orden de ejecución para que la capa vertical se ejecute al final.

Comprueba también que ninguna otra capa vertical:

• tenga la variable GPE establecida en 0 después de que el script la haya definido en 1 (de ser así, la capa estándar se ejecuta dos veces);
• se ejecuta antes que la estándar.

Parches de puntos de entrada a partir de la actualización 8

• Parches en los puntos de entrada:
  El orden de ejecución nunca se modifica con un parche. Sin embargo, cuando se aplica un parche a un punto de entrada, el orden de ejecución se establece si se ha definido.
• Revalidación en dossier:
  Si un objeto tiene un script vertical, este se inserta automáticamente en la tabla de los puntos de entrada.

Gestionar la capa vertical con otros modelos (programa de conmutación)

En el caso de los modelos para los que el programa de conmutación no se crea automáticamente, la conmutación se debe gestionar manualmente.

Esto es aplicable a:

• acciones
• consultas
• modelos de importación/exportación
• informes

Las consultas, los modelos de importación/exportación y los informes se suelen duplicar si hay que personalizarlos, pero el enfoque principal está en los scripts asociados a las acciones.

Estos elementos no tienen capa vertical.

El único script disponible es el definido en Script específico, que se utiliza como conmutador en todos los casos.

Procesamiento de conmutación y procesamientos de aplicación

Ejemplo: X1 y X2 se han desarrollado en la consulta base CSO.

Mantén un programa neutro como un script específico; por ejemplo, CNSCSOSPE.

Este programa no se parchea, pero se debe entregar por separado y gestionar manualmente.

Si necesitas el mismo orden de llamada para cada acción del modelo, utiliza esta sintaxis simple en el programa de conmutación:

Para diferenciar el orden de las llamadas según la acción, utiliza esta sintaxis:

De esta forma, puedes gestionar la llamada a cada script específico y vertical.

Gestionar la entrega de los procesamientos de conmutación

• Crea un parche para cada uno de los procesamientos de conmutación.
• En el parche principal, añade:
  • el código fuente de los procesamientos de conmutación en un directorio llamado ADDSRC;
  • en el fichero Readme, una lista de los nombres de todos los procesamientos de conmutación y los nombres de los procesamientos base correspondientes;
  • en el fichero Readme, una explicación del motivo de la modificación manual de cada procesamiento de conmutación a través del procesamiento del código fuente correspondiente entregado en el directorio ADDSRC si hay otros add-ons o recursos en la capa vertical.

Desarrollar informes

Los informes estándar se desarrollan en Crystal Reports.

Estos son algunos consejos para crear informes:

• Sigue las pautas del centro de ayuda en línea para utilizar Crystal Reports.
  Utiliza uno de estos modelos: ATEMPLATE_RPT1 o ATEMPLATE_RPT2.

• El nombre del informe debe comenzar por tu identificador y coincidir con el nombre del código de informe del diccionario.

• El origen de todos los informes debe ser ODBC.
• Los informes deben estar disponibles en los idiomas con los que trabajas como partner. El inglés es obligatorio.
• Los informes deben cumplir con la gestión de las reglas de desarrollo de autorizaciones.

Consulta el material formativo relacionado.

Limitaciones importantes

La plataforma tecnológica tiene algunas limitaciones conocidas que Sage intenta solucionar.

Ten en cuenta los siguientes puntos sobre las funciones clásicas:

Interacciones con la capa estándar

Evita hacer cambios funcionales en los elementos base, en particular en las ubicaciones. Estas funcionalidades están diseñadas para coexistir en el mismo dossier del cliente. Recuerda que un add-on es una solución que refuerza y amplía la funcionalidad base, no la ignora.

Puntos clave que recordar:

• No utilices un código de actividad para modificar o suprimir un elemento base.
• No deshabilites un botón, menú, campo, etc.
• No cambies el comportamiento de un botón o menú.
• Utiliza solo GPE = 1 para llamar a la funcionalidad base directamente, no para evitarla.
• Utiliza menú, en lugar de un botón, en una ventana base.
• Utiliza tu propia pantalla en una ventana base o crea tu propia ventana emergente adicional.
• Evita compartir el espacio disponible en las pantallas base con diferentes add-ons instalados en un dossier cliente.
• El equipo de implementación del proyecto se debe encargar de este tipo de conflictos.

Presta atención al completar una función base: si un add-on o recurso vertical utiliza una capa específica o vertical, no sobrescribas el procesamiento de conmutación existente de dicho add-on o recurso vertical.

En esta situación, y para futuros desarrollos, utiliza el procesamiento de conmutación que llama al procesamiento de aplicación.

• Para usar un punto de entrada, utiliza el procesamiento de conmutación para agilizar la actualización de los procesamientos de este tipo.
• Crea parches independientes para ellos. A continuación, añade un ejemplo de cómo debería ser el procesamiento de origen en el directorio ADDSRC incluido en el parche.
• Añade una referencia a los procesamientos de conmutación y a los procesamientos base correspondientes en el fichero Readme.

Pruebas

Para probar una función base, verifica:

• la funcionalidad global de la función base después de que los add-ons o recursos se hayan añadido;
• el procesamiento de conmutación en la capa vertical, en una capa específica de algunos diccionarios y en los puntos de entrada;
• el correcto funcionamiento de las acciones de campo coexistentes en una pantalla base;
• que los menús y botones funcionan para varios add-ons en una ventana base y evita utilizar el mismo código de menú para dos add-ons en la misma ventana base;
• que las capacidades de la plataforma no se hayan superado (número de campos en una tabla, número de pestañas en una ventana, etc.).