Herramientas de usuario

Herramientas del sitio


plugins:microcomponents

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
plugins:microcomponents [2020/02/21 14:01]
fcristina [Nuevo formato para AD_ComponentObjectUID]
plugins:microcomponents [2021/04/30 19:19] (actual)
Línea 1: Línea 1:
 ====== Soporte para desarrollo de microcomponentes ====== ====== 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.+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 ===== ===== Definición general =====
Línea 7: Línea 7:
 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. 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).+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: Un micro componente implica:
Línea 14: Línea 14:
   * Í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).   * Í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.+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. 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.
Línea 49: Línea 49:
   * 6 dígitos adicionales: 3 nanotime Y 3 random   * 6 dígitos adicionales: 3 nanotime Y 3 random
  
-Esto garantiza unicidad ante cualquier tipo de desarrollo en paralelo.  Por ejemplo:+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   ABCDEFGHIJ-AD_Message-20191206142716886-780778
Línea 60: Línea 60:
 Se incorporan dos nuevas columnas en **AD_Changelog**: Se incorporan dos nuevas columnas en **AD_Changelog**:
  
-  * ChangeLogUID: Esta conformado por el prefijo y el ChangelogID +  * **ChangeLogUID**: Esta conformado por el prefijo y el ChangelogID 
-  * ChangeLogGroupUID: Esta conformado por el prefijo y el ChangelogGroup_ID+  * **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 microcomponente 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.+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. 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 en el changelog ante la creación de un registro en la tabla de mensajes será:+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.
  
-  * AD_CHANGELOG_ID: 2449364 
-  * CHANGELOGGROUP_ID: 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 
  
plugins/microcomponents.1582293662.txt.gz · Última modificación: 2021/04/30 19:21 (editor externo)