Las modificaciones aquí detalladas se encuentran disponibles a partir de la revisión r2819 y 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.

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 la versión master de 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 al master de Libertya 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 al master de Libertya 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 al master, 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.

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.

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

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).

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.

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:

Las tablas AD_Plugin y AD_Plugin_Detail ahora contienen también las nuevas 4 columnas:

• component_first_changelog_uid
• component_last_changelog_uid
• component_first_changelog_group_uid
• component_last_changelog_group_uid

Las mismas serán de utilidad para determinar qué intervalo de registros de un componente / micro componente se encuentran instalados.

Las siguientes vistas han sido modificadas para incorporar los 4 nuevos campos previamente mencionados:

• ad_changelog_dev
• ad_plugin_v
• ad_plugin_detail_v

Se detallarán a continuación los pasos para el desarrollo de un micro componente.

1. Creación de un nuevo prefijo. El primer paso es crear en el master libertya_core un nuevo prefijo a utilizar, el cual debe ser orientativo y relacionado con el desarrollo a realizar, más allá que el campo descripcion de la tabla período permite detallar con claridad el alcance del mismo. Por ejemplo, prefijo EJEMPLOMC.
2. Copiado de BBDD para desarrollo de micro componente. Una vez reservado el prefijo en cuestión, se deberá clonar la BBDD para el desarrollo del componente, generando una BBDD que permita identificar el contenido de la misma, por ejemplo libertya_micro_PACKAGENAME, donde PACKAGENAME es el nombre del package que se definirá en el nuevo micro componente, pero sin org.libertya.core.micro (dado que todos los micro componentes iniciarán con dicho prefijo).
3. Creación de un nuevo micro componente. Acto seguido se debe crear la entrada del nuevo micro componente en la ventana de Componentes, indicando “Es micro componente”, e indicando además el packagename correspondiente. Nuevamente, debería ser un nombre intuitivo, y respetando las relgas previamente definidias (org.libertya.core.micro.rXXXX…. , donde XXXX refiere a la revisión de CORE sobre la cual nos estamos apoyando.). De todas maneras este package name se utilizaría de manera acotada, dado que las clases de CORE tendran su packagename original dentro del proyecto.
4. Inicio de bitácora. Como en los componentes tradicionales, se debe crear un componentversion e iniciar el registro de la bitácora.
5. Creación de proyecto en Eclipse. El proyecto referenciará al master org.libertya y contendrá de manera exclusiva clases modificadas del CORE de Libertya. Únicamente contendrá clases dentro del packagename definido en el componente para casos particualres, como por ejemplo las clases PostInstall. Adicionalmente contendrá el archivo preinstall.sql para incluir las modificaciones a nivel SQL.
6. Desarrollo sobre el componente tanto sobre clases como BBDD. El desarrollo es similar al de un componente tradicional, salvo el tema de la redefinición completa de clases de CORE.
7. Eventual incorporación al master libertya_core / org.libertya. La incorporación no representa cambios metodológicos con respecto a un componente tradicional que es llevado a CORE. Simplemente se indican los campos de COPYTOCHANGELOG / MAPTOCOMPONENT / MAPTOCOMPONENTVERSION, sin indicar MAPUIDS. Ante cualquier error detectado, lógicamente la instalación se rollbackeará. Para las clases a incorporar se requerirá realizar el merge de fuentes correspondiente.
8. Finalización de desarrollo. El micro componente incorporado al master ya no podrá ser más utilizado. Para nuevos cambios, deberá crearse un nuevo micro componente, con otro prefijo, etc. iniciando así el paso 1.