WikiLibertya

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Soporte para desarrollo de microcomponentes ======

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.

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


===== 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 [[plugins:copiadechangelog|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 [[plugins:creacionjar|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:

^ Campo      ^ Descripción       ^ 
| MICROCOMPONENT | Indica si el desarrollo es de tipo micro componente (Y / N). Por el momento solo es información de referencia, pero eventualmente podría ser de utilidad para otras funcionalidades. | 
| FIRST_CHANGELOG_UID | Valor del primer registro de la columna ChangeLogUID exportado.  Esta es la real referencia de instalación para saber qué rango de changelogs del micro componente contiene el archivo .jar. | 
| LAST_CHANGELOG_UID | Valor del último registro de la columna ChangeLogUID exportado. Esta es la real referencia de instalación para saber qué rango de changelogs del micro componente contiene el archivo .jar. | 
| FIRST_CHANGELOG_GROUP_UID | Valor del primer registro de la columna ChangeLogGroupUID exportado. Esta es la real referencia de instalación para saber qué rango de changeloggroupss del micro componente contiene el archivo .jar. | 
| LAST_CHANGELOG_GROUP_UID | Valor del último registro de la columna ChangeLogGroupUID exportado. Esta es la real referencia de instalación para saber qué rango de changeloggroupss del micro componente contiene el archivo .jar | 
| COPYTOCHANGELOG | Indica si se desea copiar el changelog al insertar. Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | 
| MAPTOCOMPONENTUID | Indica si se desea mapear el desarrollo a un component específico. Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | 
| MAPTOCOMPONENTVERSIONUID | Indica si se desea copiar el changelog a un componentversion. Si bien ya existía funcionalidad relacionada con este campo, ahora al exportar un componente, ya se inserta (comentado) en el manifest. | 
| MAPUIDS | Permite especificar si se desea mapear los UIDs (ejemplo FOO2CORE) o no. Bajo la nueva lógica de micro components __esto ya no es necesario__, y por lo tanto la lógica por defecto se encuentra desactivada. Sin embargo, es posible utilizar este feature descomentando la entrada. | 

===== Tablas AD_Plugin y AD_PluginDetail =====

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.

===== Cambios en vistas =====

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

  * ad_changelog_dev
  * ad_plugin_v
  * ad_plugin_detail_v

===== Desarrollando un micro componente =====

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

  - 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.
  - 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).
  - 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.
  - Inicio de bitácora.  Como en los componentes tradicionales, se debe crear un componentversion e iniciar el registro de la bitácora.
  - 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.
  - 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.
  - 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.
  - 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.
WikiLibertya

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
