Esquema Portuno

El modelo de base de datos se muestra en la siguiente imagen:

1. Variables del sistema

Las variables del sistema se configuran en la tabla app_configuration y son cargadas por cada módulo (Kerno, Hermes, Minerva...) en el arranque.

Estas variables permiten identificar, por ejemplo, caracteres separadores de valores o ARIs, valores máximos o mínimos para las validaciones por defecto de los atributos de plantilla, la periodicidad de ejecución de los procesos batch…

Estructura de la tabla

Cada variable registrada se caracteriza por los siguientes elementos:

• id: identificador único de la tabla.

• internal: boolean utilizado para indicar si una propiedad se puede ver desde la API pública en claro (si internal es ‘false’ no debe verse en claro).

• config_key: propiedad a configurar.

• value: el valor que adquiere la propiedad.

• application: módulo al que aplica la propiedad. 

Puede ser ‘kerno’, ‘hermes’, ‘minerva’, ‘zeus’ o  tener valor nulo, en cuyo caso aplica a todos los módulos.

• label: campo informativo que permite organizar las variables.

• profile: perfil de ejecución en el que aplica la propiedad con su valor.

Es necesario que dicha tabla tenga las siguientes propiedades, siendo:

• config_key la misma config_key que se incluye en la tabla

• value el valor por defecto que Anjana proporciona y que se puede ser modificado

• application el mismo valor que application en la tabla

• descripción, que no existe en la tabla y es una mera explicación de cada propiedad

Excepciones en configuración

Debido a limitaciones de la base de datos o el propio funcionamiento del atributo, hay casos en los que es necesario indicar un límite en algunos componentes y priorizar el valor configurado de la tabla appConfigurations ante la configurada en templateAtributtesValidations.

Si el valor de templateAtributtesValidations es mayor al valor que hay en appConfigurations, se priorizará el valor de appConfigurations.

Los casos son los siguientes:

• MAX: Si el valor MAX de template_attribute_validations es superior a MAX_INTEGER de appConfigurations, se priorizará MAX_INTEGER de appConfigurations.

• MIN: Si el valor MIN de template_attribute_validations es inferior a MIN_INTEGER de appConfigurations, se priorizará MIN_INTEGER de appConfigurations.

• MAX_DECIMAL_PRECISION: Si el valor MAX_DECIMAL_PRECISION de template_attribute_validations es superior a MAX_DECIMAL_PRECISION de appConfigurations, se priorizará MAX_DECIMAL_PRECISION de appConfigurations.

• MIN_DECIMAL_PRECISION: Si el valor MIN_DECIMAL_PRECISION de template_attribute_validations es inferior a MIN_DECIMAL_PRECISION de appConfigurations, se priorizará MIN_DECIMAL_PRECISION de appConfigurations.

• MAX_LENGTH: Si el valor MAX_LENGTH de template_attribute_validations es superior a MAX_LENGTH_TEXT_EDITOR o MAX_LENGTH_TEXT_BD de appConfigurations, se priorizará MAX_LENGTH_TEXT_EDITOR en el caso de los TEXTAREA o MAX_LENGTH_TEXT_BD si es un input text o los textarea de los modales de workflows y adherencias.

• MIN_LENGTH: Si el valor MIN_LENGTH de template_attribute_validations es inferior a MIN_LENGTH_TEXT_EDITOR de appConfigurations, se priorizará MIN_LENGTH_TEXT_EDITOR de appConfigurations. 

Visión de Administrador

El alta de una nueva variable desde el panel de administración de Anjana Data se realiza en appConfigurations:

Al acceder se muestra una tabla que contiene todas las variables de la aplicación de la configuración actual. 

La creación de una nueva variable se realiza mediante el botón New:

A continuación, se muestra cómo crear un parámetro de configuración:

Visión de Desarrollador

Para añadir las variables de configuración hay que configurar la tabla app_configurations del esquema Portuno. Para ello, hay que rellenar un sql como el siguiente:

NOTAS:

• Puesto que las variables se cargan en el arranque, Portuno debe estar arrancado antes que el resto de servicios para obtener correctamente las propiedades indicadas. Si algún servicio se iniciara antes que Portuno se quedará a la espera de que Portuno esté disponible para poder cargar esta configuración y terminar su inicialización.

• En caso de que una variable esté configurada en app_configuration y en un fichero yml, la configuración que aplica es la de app_configuration.

1. Traducciones

Las traducciones disponibles para el portal en los distintos idiomas configurados en Anjana se encuentran almacenadas en la tabla translations. Por ello, cuando se añaden nuevos textos o se incorpora un nuevo idioma a la aplicación, es necesario incorporar aquí esas nuevas traducciones. 

Cualquier cambio en esta tabla requiere la actualización de los ficheros de traducciones desde Portuno para poder hacer uso de los nuevos textos en la aplicación.

Estructura de la tabla

Cada traducción registrada se caracteriza por los siguientes elementos:

• id_translations: identificador único de la tabla.

• config_key: clave de traducción. Cada clave debe aparecer en esta tabla tantas veces como idiomas haya configurados.

• language: idioma de traducción en código i18n. Debe coincidir con el campo i18n_code de la tabla languages.

• value: texto traducido al idioma indicado.

• used_for: texto que permite segregar las traducciones por uso. Es informativo.

• internal: boolean que permite indicar si la traducción se corresponde con un texto propio de la aplicación (internal = 'true') o si, por el contrario, se corresponde con una traducción propia de la configuración utilizada como nombres de atributos, roles… (internal = 'false').

Visión de Administrador

El alta de las traducciones se realiza en el panel de administración de Anjana Data en Translations:

Al acceder se muestra una tabla que contiene todas las traducciones usadas por el portal de Anjana. 

La creación de una nueva traducción se realiza mediante el botón New:

Mediante el wizard de creación se asignan valores a los elementos anteriormente descritos:

Visión del Desarrollador

Para añadir las traducciones hay que configurar la tabla translations del esquema Portuno. Para ello, hay que rellenar un sql como el siguiente:

NOTAS:

• Es necesario que se configuren las traducciones siguiendo este criterio:

  • internal='true': traducciones internas de Anjana, necesarias para la correcta visualización de la aplicación

  • internal='false': traducciones de textos propios de la configuración, es decir, textos relacionados con atributos de las plantillas, menús, secciones, roles, OUs… que son configurables y varían en función del entorno y su parametría.

• No se debe añadir en la tabla de portuno.translations dos claves de traducción distintas con el mismo texto traducido para dos atributos o para dos valores de un mismo atributo.

• No es recomendable establecer como clave de traducción los nombres de los diferentes subtipos de objetos puesto que supondrá que estos aparezcan traducidos en el portal a pesar de que no tienen traducción.

• Para los atributos Infraestructura, Tecnología y Zona:

  • Todas las claves de traducción de los valores posibles de dichos campos deben ser iguales que las distintas partes que componen la tripleta con la que se configura la conexión con los plugins de Tot. 

Por ejemplo: Si una tripleta en el plugin de tot de Azure se configura como azure/azure analytics/production entonces las clave de traducción del valor azure en infrastructure debe ser “azure”, para el valor de azure analytics en technology debe ser “azure analytics” y para el valor production de zone debe ser “production”.

• Los valores de estos atributos deben no contener ‘:’, ‘#’, ‘(‘ o ‘)’ para no interferir con los identificadores internos de Anjana. 

• Para las traducciones de los roles, la clave de traducción ha de ser el texto “ROLE.” concatenado del nombre del rol establecido en la tabla zeus.role en la columna role_name. Por ejemplo: ROLE.developer

• Para las traducciones de los nombres de los idiomas, la clave de traducción ha de ser el código i18n del idioma en la tabla languages.

Traducciones internas deAnjana

Hay valores de traducciones internas que se repiten en diferentes claves, ya que estas se han generado según la funcionalidad o pantalla en la que se encuentren. En caso de querer cambiar una traducción interna de Anjana se tendrá que tener en cuenta que habrá que cambiar el valor de varias claves en la tabla de Translations de Portuno. 

Por ejemplo, en caso de querer cambiar la traducción de un atributo obligatorio de una entidad como Infraestructura, habrá que cambiar tanto el valor de la clave de Infraestructura del wizard de creación como la de los filtros, el atributo de la plantilla o el del tooltip de la cabecera de un objeto.

A continuación se desglosan las claves de traducción de los atributos obligatorios de las plantillas de entidades/relaciones:

Nombre:

• COMMON.NAME

• NEW_WIZARD_ASSISTANT.CARD_NAME

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘name’ en anjana.attribute_definition

Infraestructura:

• NEW_WIZARD_ASSISTANT.INFRASTRUCTURE

• TOOLTIP.INFRASTRUCTURE

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘infrastructure’ en anjana.attribute_definition

Tecnología:

• NEW_WIZARD_ASSISTANT.TECHNOLOGY

• TOOLTIP.TECHNOLOGY

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘technology’ en anjana.attribute_definition

Zona:

• NEW_WIZARD_ASSISTANT.ZONE

• TOOLTIP.ZONE

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘zone’ en anjana.attribute_definition

Localización:

• NEW_WIZARD_ASSISTANT.PATH

• TOOLTIP.PATH

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘path’ en anjana.attribute_definition

Unidad Organizativa:

• CONTAINER

• GRAPH.NODE_ORGANIZATIONAL_UNIT

• MODAL.ORGANIZATIONAL_UNIT

• TOOLTIP.ORGANIZATIONAL_UNIT

• FILTERS.ORGANIZATIONAL_UNIT

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘organizationalUnit’ en anjana.attribute_definition

Posición:

• COMMON.POSITION

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘position’ en anjana.attribute_definition

Nombre físico:

• COMMON.PHYSICAL_NAME

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘physicalName’ en anjana.attribute_definition

Origen:

• COMMON.SOURCE

• FORM_RELATION.SOURCE

• RELATION.SOURCE

• SOURCE

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘source’ en anjana.attribute_definition

Destino:

• FORM_RELATION.DESTINATION

• RELATION.DESTINATION

• FILTERS.DESTINATION

• DESTINATION

• labelTranslationKey y placeHolderTranslationKey del atributo con name = ‘destination’ en anjana.attribute_definition