Parametrización y desarrollo específico

Introducción

En el momento de la puesta en marcha de los productos en tecnología Sage X3, hay dos niveles de interveción sobre el objeto posibles.

El primer nivel es el de las parametrizaciones, que puede jugar de forma importante en la ergonomía de la aplicación y en sus funcionalidades; el segundo es el nivel de los desarrollos específicos. El hecho de que las aplicaciones desarrolladas en tecnología X3 integre un AGL y un motor de ejecución denominado adonix, permiten realizar desarrollos.

Teniendo un cuenta la flexibilidad de la herramienta, ciertos desarrollos específicos pueden parecer fáciles de realizar y parametrizar, dada la facilidad de su puesta en marcha. Pero conviene definir los actos de desarrollo como tales, y, por otro lado, hay ciertas parametrizaciones complejas que necesitan de un nivel técnico elevado.

La caracterización de las funciones procedente de cada uno de los niveles no está vinculada a su complejidad relativa, sino que se realiza de la forma siguiente:

• La parametrización se caracteriza por el hecho de que en principio no haya tenido relevancia en caso de cambio de versión menor o de parche de la aplicación. Esto quiere decir qeu no se ha realizado un esfuerzo extra de protección para que fueran perennes. Las operaciones de parametrización son accesibles, para un usuario con perfil de administrador, a través de los menúes denominados Parametrización, Explotación, y de los submenúes que dependen de ellos.
• El desarrollo debe hacerse permanente empleando medidas particulares (reglas de denomninación, uso de códigos de actividad dedicados) que necesita de un esfuerzo suplementario. Las reglas a respetar para que los desarrollos sean permanentes se definen en un documento anexo. Las operaciones de desarrollo son accesibles, para un usuario con perfil de administrador, a través del menú denominado Desarrollo, y del submenú que depende de él.

La consecuencia de esto es que las soluciones a base de parametrización son en principio menos limitantes, desde el punto de vista del mantenimiento, y debe por tanto dárseles preferencia, cuando sea posible, a los desarrollos específicos.

Por otro lado, puede realizarse una clasificación de operaciones de parametrización según su grado de dificultad y su accesibilidad a los usuarios avanzados. Lo mismo sucede con todas las operaciones de desarrollo. Esta clasificación se realiza en la continuación de este documento.

La parametrización puede conducir a una generación automatizada de código, pero esto es transparente para el usuario. Se supone en ciertos casos un conocimiento limitado de la lengua, en la medida en que se pueden emplear las fórmulas de cálculo (el equivalente aproximado de las fórmulas Excel™); pero un asistente permite simplificar su creación. De hecho, se puede considerar que existe un nivel simple de parametrización y un nivel más complejo. Ciertas operaciones de parametrización necesitad competencias de desarrollo.

El desarrollo puede implicar o no la escritura o código que utiliza AGL adonix. En ese momento, se pueden delegar ciertas operaciones de desarrollo sin escritura de código en consultores no programadores, con la condición de tener en cuenta la durabilidad.

La escritura de informes Crystal Reports™ puede compararse con la parametrización, pero para ello se necesita un conocimiento amplio de la base de datos de la aplicación. La presencia de ayudas en línea en la estructura de la base (MCD, diccionario en línea) debe simplificar el conocimiento de esta estructura. Sólo falta que ciertos informes (los que actualizan las flags de edición) suponen la escritura del código adonix, y que también la actualización del diccionario de los informes es un acto de desarrollo (relativamente simple).

Operaciones relevantes de parametrización

En el menú de parametrización, se encuentran sub menúes funcionales que dependen de la aplicación en tecnología X3. Estos menúes corresponden efectivamente a una parametrización en general sencilla. Para los submenúes Usuarios, Parámetros generales, Explotación es conveniente realizar una caracterización de las funciones que en ellos se encuentran. El menú Estructura general corresponde a una parametrización simple, como es también el caso del menú Workflow, cuya única parametrización compleja es la de las reglas de Workflow.

Actualización de las parametrizaciones simples

Estas funciones actualizan los parámetros o los datos en la base. Si se produce una mala implementación, puede haber consecuencias en el funcionamiento, pero éstas no tienen por qué ser irreversibles. Son las siguientes:

La función de actualización de los parámetros generales (ADPVAL) es un caso especial: Es claramente una función de parametrización, pero la modificación desconsiderada de ciertos parámetros del supervisor (capítulo SUP) y sobre todo del motor (capítulo ADX), puede ser peligrosa.

Parametrizaciones de segundo nivel

Estas parametrizaciones pueden considerarse como más complejas por diversos motivos:

Pueden implicar, para ser operativas, una fase de validación o de generación de código. Esto implica una revalidación en caso de copia de dossier a dossier. Incluso si los controles de validez se realizan en estos parámetros, una mala parametrización puede, en casos límites, provocar errores en la ejecución de la aplicación.

En esta categoría entran las funciones siguientes:

Todas las parametrizaciones de transacción de captura (en todos los módulos) entran en esta categoría (se crean pantallas y fuentes de tratamiento a partir de la parametrización).

Otra razón para la complejidad es que ciertas parametrizaciones pueden presuponer por parte del usuario un conocimiento de la base de datos, puesto que se van a definir como criterios campos de esta base. Esta categoría, que puede ser un poco más compleja de parametrizar, puede también implicar una generación de código asociada.

En esta categoría entran las funciones siguientes:

Ciertas parametrizaciones pueden necesitar recurrir a fórmulas de cálculo (que pueden estar guÍadas por asistentes de parametrización), o recurrir a conocer un contexto concreto (nombre de la pantalla a parametrizar). El conocimiento de la estructura de la base, del lenguaje de las fórmulas de cálculo y del contexto técnico de forma más general es a menudo necesario para realizar estas parametrizaciones.

En esta categoría entran las funciones siguientes:

Es importante tener en cuenta que entre estas operaciones de parametrización, hay algunas que si están mal hechas, pueden producir disfuncionamientos en los objetivos:

• La personalización de los objetos puede producir un mal funcionamiento de estos, por ejemplo si no se colocan en la lista izquierda del objeto todos los campos que componen la clave principal de este objeto.
• Una definición errónea de las estadísticas, sobre todo si éstas están definidas en tiempo real, puede provocar errorres en la ejecución de las creaciones y las actualizaciones, impidiendo de este modo el funcionamiento del objeto de inicio.
• La creación de peticiones, que crea a su vez una pantalla, tratamientos, puede en algunos casos producir peticiones erróneas si los vínculos están en forma explícita.

Por otro lado, la optimización de base de datos (GESANX) supone de unos buenos conocimientos técnicos en gestión de bases de datos; una mala parametrización puede ir al encuentro del objetivo buscado, para mejorar los rendimientos de explotación.

Parametrizaciones especiales

Dos series de funciones constituyen casos particulares, pero pertenecen a la parametrización:

La gestión de dossieres (GESADS), que tiene incidencias importantes en la explotación y la necesidad, al menos cuando se crea el dossier de explotación, de cierto nivel técnico.

La gestión de asientos automáticos (GESGAU) para la que es necesaria un buen conocimiento a la vez del lenguaje y el contexto, que producen una generación de código y, si están mál parametrizadas, crearán asientos contables desequilibrados que no estarán integrados.

Desarrollos específicos

De una forma simple, todo lo que procede, en los menúes estándar del perfil ADMIN, de las entradas del menú Desarrollo, es desarrollo específico. Otra forma de caracterizar el específico es decir que necesita el recurso de al menos un código de actividad que empieza por X, Y o para ser durable. Dependiendo de si el recurso del lenguaje de desarrollo sea o no necesario, se puede considerar que hay dos niveles de dificultad.

Específicos simples

Estos específicos no presuponen un nivel de conocimientos mayor que en las funciones precedentes (en ciertos casos, son incluso más simples que ciertas funciones complejas que se indican a continuación). No se trata obligatoriamente de funciones, sino de ciertos casos de uso limitado de ciertas funciones.

En cualquier caso, la primera regla a observar es la durabilidad de estos desarrollos. Si ésta no se da, cualquier revalidación del dossier producirá su pérdida. Esto supone la definición de la activación de al menos un código de actividad que comience por X, Y o Z y la adopción de una normalización de los nombres en ciertos elementos creados.

Las operaciones que pueden considerarse dentro de esta categoría son las siguientes:

Las funciones marcadas con un asterisco pueden ser consideradas como fáciles de poner en marcha en ciertas condiciones. Las condiciones simplificadores de la puesta en marcha son, entre otras, el añadir campos suplementarios a las tablas y a las pantallas existentes, la creación de objetos simples, de pantallas simples, de ventanas funciones por creación de objetos...

Ciertas funciones de desarrollo parecen, por la facilidad con que se ponen en marcha, una parametrización, pero pueden ser muy peligrosas porque actualizan los datos con un mínimo de controles y a veces de forma masiva. Estas son las funciones siguientes:

La definición de transacciones sistema (GESAMI) para actualizar los campos en masa es muy peligrosa si está hecha en campos calculados o con limitaciones de integridad que puedan activarse incorrectamente por esta función. Las funciones de mantenimiento permiten imponer limitaciones de integridad.

Por eso se puede considerar que lo que se encuentra en los útiles necesita de un nivel de conocimiento de tipo "específico ligero", incluso si ciertas de sus funciones pueden ser peligrosas. Esto incluye:

Los útiles de verificación (UTIBASE, ETAFIC, VERSYMB, AVERSION)

Los útiles de validación(VALDICO, ACOPDIC, ACOPTRS, ACOMPOBJ, AVALAFC, VALMENU, GENMSKTRT, COPTRT, GENMENULOC)

Los útiles de manteminiento de dossieres (CHDOS, DEVERROU, RAZDOS, IMPDOS)

Los útiles de búsqueda (RECHACT, RECHTYP, RECHACI, RECHMESS, RECHTXT)

Los útiles de salvaguarda (DOSEXTRA, DOSINTEG)

Los útiles de gestión de parches (PATCH, APATCH, GESAPT, APATCHA)

Los útiles diversos (AMIEXE, SYSTEME, LECTRACE, EXETRT, VISULIC, PSADX, ADXD, GENTXTTRA, MODCPT, ADELETE, RECUPLNK, ACTIVLNK).

Específicos complejos

Estos específicos suponen un conocimiento en profundidad del lenguaje de desarrollo, y por tanto un perfil de desarrollador avanzado. Afecta especialmente a todas las funciones de desarrollo precedentes, cuando actúan en pantallas generadas, todas las funciones en las que se emplea un punto de entrada, todas aquellas en las que es necesario escribir el código L4G adonix (por ejemplo en una pantalla compleja). Las operaciones que pueden ser complejas son:

La definición de tipos de datos (GESATY), las pantallas (GESAMK), las ventanas (GESAWI), las funciones (GESAFC), los objetos (GESAOB), cuando estas funciones se emplean en casos complejos

Las consultas (GESACN), las acciones y funciones vinculadas (GESACT,  GESASU, ADOTRT) puesto que el recurso al código adonix es necesario en todos los casos.

Los informes, cuando deben realizarse tratamientos preliminares.