Herramientas de usuario

Herramientas del sitio


plugins:microcomponents

¡Esta es una revisión vieja del documento!


Soporte para desarrollo de microcomponentes

Las modificaciones aquí detalladas aplican tanto para el desarrollo de micro componentes como para componentes tradicionales. La metodología aplicada en cada caso definirá la semántica del componente.

Definición general

Micro componentes refiere a desarrollos con tiempo de vida acotado, encapsulando modificaciones de LY CORE específicamente (CORELEVEL = 0), sobre una base de datos independiente y un proyecto en Eclipse independiente que referencia a org.libertya y que modifica clases de CORE exclusivamente.

Los micro componentes nacen de requerimientos para LY CORE o bien a partir de necesidades de modificaciones de CORE sobre una instancia en producción de un cliente en particular; pero que luego estos cambios eventualmente serán parte de LY Standard (bbdd libertya_core y proyecto org.libertya).

Un micro componente implica:

  • Ítem de lista desordenadaCreación de una BBDD exclusiva para su desarrollo y de un componente (con CORELEVEL 0) con un prefijo que denote la finalidad del desarrollo
  • Ítem de lista desordenadaCreacion de un proyecto en Eclipse que referencia a org.libertya y solo modifica clases de CORE (además del preinstall, etc).

Los micro componentes se incorporarán a LY Standard cuando se considere necesario, mediante merge de fuentes y el uso de COPYTOCHANGELOG para metadatos. Los UIDs serán únicos desde el momento de su creación y para siempre, bajo una nueva definición de los mismos. Por consiguiente bajo la nueva metodología, no exisitrá mapeo de UIDs. Un micro componente incorporado a LY Standard deja de existir inmediatamente. El tiempo de vida de los micro componentes debería ser acotado, cuanto más tiempo pase, más complejo será incorporarlo a CORE Standard, o bien más complejo de mantener en el tiempo debido a eventuales modificaciones posteriores en CORE.

Una instancia en producción que requiera actualizar su versión de CORE y que tenga micro componentes necesitará “certificar” la instancia en cuestión, realizando los merges necesarios si es que dichos micro componentes deben mantenerse en la instancia. En caso de no poseer micro componentes, la “certificacion” simplemente implica una actualización tradicional.

Cabe destacar la diferencia de una redefinición específica de una clase de CORE alojada en un componente tradicional (plugin de customización) con respecto a los desarrollos en un micro componente. Por ejemplo: un componente puede redefinir varias clases de CORE modificadas debido a requerimientos específicos del cliente. Esta redefinición responde a requerimientos particulares y exclusivos para cumplimentar necesidades ad-hoc de dicho cliente. Es por esto que en principio no corresponde que estas redefiniciones se alojen en un micro componente en particular que eventualmente se llevará al master de desarrollo de Libertya.

Nueva ventana para prefijos de micro componentes

Existe una nueva ventana Prefijos de Micro Componentes para la reserva de prefijos.

Los prefijos tendran una longitud de 10 caracteres y deberán ser únicos. Existe una Unique Key que impide prefijos duplicados.

La descripción que acompaña al prefijo deberá ser una intuitiva, a fin de dar una idea sobre la funcionalidad y alcance del micro componente que se está desarrollando.

Estos prefijos luego se referencian desde la ventana de Componentes. Si se indica que el componente es de tipo Micro, debe indicarse un prefijo existente y activo en la ventana de prefijos de micro componentes.

Desarrollando un micro componente

El inicio del desarrollo es similar al desarrollo de un componente tradicional.

Sin embargo, si al iniciar el desarrollo se detectan entradas en la bitácora (AD_Changelog) registradas para este micro componente, se presentará un warning a modo de aviso, indicando que ya hubo desarrollo previo para dicho micro componente, por ejemplo:

WARNING: Existes 3675 entradas en el changelog con el prefijo de microcomponente EXAMPLE

Nuevo formato para AD_ComponentObjectUID

El nuevo formato de los AD_ComponentObjectUID se conforma de la siguiente manera:

  • Prefijo del micro componente
  • Nombre de tabla
  • Timestamp
  • 6 dígitos adicionales: 3 nanotime Y 3 random

Esto garantiza unicidad ante cualquier tipo de desarrollo en paralelo. Por ejemplo, dado un micro componente ABCDEFGHIJ creando una nueva entrada en AD_Message:

ABCDEFGHIJ-AD_Message-20191206142716886-780778

Este valor no cambiará nunca, y se mantendrá el mismo al momento de incorpora el desarrollo del micro componente a CORE (mediante CopyToChangelog). No habrá necesidad de mapear UIDs, por lo cual dicha funcionalidad quedará desactivada por defecto (aunque se podrá activar si así se desea con un nuevo modificador en el manifest.properties de cualquier archivo jar de instalación, más de ésto luego).

Nuevas columnas en AD_Changelog

Se incorporan dos nuevas columnas en AD_Changelog:

  • ChangeLogUID: Esta conformado por el prefijo y el ChangelogID
  • ChangeLogGroupUID: Esta conformado por el prefijo y el ChangelogGroup_ID

Gracias a dichos campos UID, es posible tener un seguimiento a un desarrollo de un micro componente más allá de la evolución de los IDs del master de libertya_core, resolviéndose así eventuales problemas de seguimiento en lo referente a - por ejemplo - qué parte del changelog fue instalado y qué queda pendiente por instalar, dado que siempre podremos contrastar los UIDs en la bbdd de desarrollo del micro componente.

Esta será la información relevante al exportar el micro componente y al instalarlo. La nueva funcionalidad incluye el soporte para considerar dichos campos, tal como se detallará posteriormente.

Para dar un ejemplo, la información resultante a guardar en la tabla AD_ChangeLog ante la creación de un registro en la tabla de mensajes será (además de otros campos):

  • AD_ChangeLog_ID: 2449364
  • ChangeLogGroupID: 1234859
  • ChangeLogUID: ABCDEFGHIJ-2449364
  • ChangeLogGroupUID: ABCDEFGHIJ-1234859
  • AD_Column_ID: 198
  • AD_ComponentObjectUID: ABCDEFGHIJ-AD_Message-20191206142716886-780778
  • NewValue: Insertando un nuevo mensaje de ejemplo

Incluso luego de instalado en el master de Libertya, la información de los campos ChangeLogUID y ChangeLogGroupUID es rastreable hasta la BBDD de desarrollo del micro componente ABCDEFGHIJ.

Exportando un componente

Al exportar un componente, se incorporará la siguiente información (en negro la nueva información):

# Manifest del plugin El abecedario loco
VERSION = 1
PREFIX = ABCDEFGHIJ
PACKAGENAME = org.libertya.core.micro.r1234.abcdario
PUBLICNAME = Micro componente de ejemplo
AUTHOR = null
CORELEVEL = 0
MICROCOMPONENT = Y
FIRST_CHANGELOG = 2449355
LAST_CHANGELOG = 2449420
FIRST_CHANGELOG_UID = ABCDEFGHIJ-2449355
LAST_CHANGELOG_UID = ABCDEFGHIJ-2449420
FIRST_CHANGELOG_GROUP_UID = ABCDEFGHIJ-1234859
LAST_CHANGELOG_GROUP_UID = ABCDEFGHIJ-1234863
EXPORT_TIMESTAMP = 2019/12/06-14:55:17.675

# AUTOGENERADO - NO MODIFICAR
COMPONENTUID = ABCDEFGHIJ-AD_Component-1010188
COMPONENTVERSIONUID = ABCDEFGHIJ-AD_ComponentVersion-1010202

# DESCOMENTAR SI SE DESEA INCORPORAR A OTRO COMPONENTE (POR EJEMPLO CORE). INDICAR COMPONENT Y COMPONENTVERSION ADECUADOS!
# COPYTOCHANGELOG = Y
# MAPTOCOMPONENTUID = 
# MAPTOCOMPONENTVERSIONUID = 
# DESCOMENTAR SI SE DESEA MAPEAR LOS AD_ComponentObjectUIDs (ejemplo FOO2CORE) EN COPYTOCHANGELOG. DESACTIVADO POR DEFECTO (MICROCOMPONENTS YA NO LO UTILIZA)
# MAPUIDS = Y

La semántica de los campos es la siguiente:

plugins/microcomponents.1582297120.txt.gz · Última modificación: 2021/04/30 19:21 (editor externo)