Esquema Zeus

La configuración de las tablas del esquema Zeus permite definir el modelo de gobierno a través de la definición de la jerarquía de unidades organizativas así como los roles y los permisos que estos tendrán en la aplicación.

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

1. Estructura organizativa y unidades organizacionales

El primer paso para aterrizar el modelo de gobierno de la organización es establecer la jerarquía de unidades organizativas. Las Unidades Organizativas representan dominios de datos que permiten establecer custodia y responsabilidad sobre los mismos.

Puede tratarse de una estructura “plana” o de un único nivel o, por el contrario, de una jerarquía de varios niveles.

Una vez definidos los niveles de la jerarquía de unidades organizacionales, se deben asignar nombres a cada uno de los niveles conforme al modelo de gobierno de la organización.

Las unidades organizacionales se configuran en la tabla organizational_unit y serán visibles dentro de Anjana Data en las pantallas de creación de objetos:

Estructura de la tabla

Cada unidad organizativa registrada se caracteriza por los siguientes elementos:

• id_organizational_unit: identificador único de la unidad organizacional.

• description: descripción de la unidad organizacional.

• module: módulo al que pertenece, indicar “BG” para Business Glossary, “DC” para Data Catalog o “ALL” si aplica a todo. Actualmente este campo se encuentra sólo a nivel informativo.

• alias:  alias de la unidad organizacional. 

Dicho alias es la clave de traducción de la unidad organizativa, por lo que se puede añadir una traducción en la tabla translations de portuno con la misma ‘config_key’ que el alias.

NOTA: 

El separador de los distintos niveles que componen una unidad organizativa, en esta tabla, siempre será “/”. Por ello, en caso de jerarquía plana (un único nivel) se debe evitar usar “/” en el alias.

En caso de utilizar otro separador de unidad organizativa en el proveedor de identidades utilizado para la autorización de los usuarios, es necesario detallarlo en la configuración como se indica en la documentación específica de las integraciones.

• parent: indica la unidad organizacional padre. En caso de ser una jerarquía plana o de tratarse de una unidad con nivel padre, este campo se dejará vacío.

• organizationalUnitType: campo informativo que indica el nivel de jerarquía al que pertenece la unidad organizativa.

Visión de Administrador

El alta de nuevas unidades organizacionales mediante el Panel de Administrador de Anjana Data se realiza en Organizational Unit:

Al acceder se muestra una tabla que contiene todas las unidades organizacionales existentes en la configuración actual. 

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

Mediante el wizard de creación se elige el alias que se asigna a la unidad organizacional, el módulo (Module) al que pertenecerá y se seleccionará la unidad organizacional padre de la que cuelga mediante el campo parent. También se asignará el tipo de unidad dentro de nuestra jerarquía en el campo organizationalUnitType. A continuación, se muestra como crear la unidad organizacional “SPA/Market” que cuelga de la unidad padre “SPA”.

Visión de Desarrollador

Para definir unidades organizacionales hay que configurar la tabla organizational_unit. 

Para configurar las unidades organizacionales de la imagen hay que rellenar un sql como el siguiente:

NOTAS: 

• El nombre y el alias de las unidades organizativas no deben contener los caracteres: “:” ni “#” para no interferir con los identificadores internos de Anjana.

• Cada una de las partes de las que se compone el alias de la unidad organizacional (concatenándolas con “/”) y será la clave de traducción en caso de querer traducir los nombres de las unidades a los idiomas de la aplicación. O, dicho de otro modo, el alias debe ser equivalente a la concatenación de las Unidades Organizativas padre desde el nodo raíz del árbol jerárquico hasta el nodo propio.

• Una vez creados objetos en Anjana, el cambio de las Unidades Organizativas o sus alias puede provocar que los objetos, permisos, workflows… asociados a las UO queden incoherentes.

• No se permiten dos UOs con el mismo alias.

1. Roles del modelo de gobierno

Una vez definidas las unidades organizacionales, se deben definir los roles que intervienen en el gobierno del dato.

Dentro de Anjana Data, deben definirse roles para el Catálogo de Datos y para el Glosario de Negocio en la tabla role. Los roles pueden estar asociados a unidades organizativas específicas o tratarse de roles transversales.

Estructura de la tabla

Cada rol registrado se caracteriza por los siguientes elementos:

• id: Identificador único del rol.

• module: módulo al que pertenece, indicar “BG” para Business Glossary, “DC” para Data Catalog o “ALL” si aplica a todo. Actualmente este campo se encuentra sólo a nivel informativo.

• name: nombre asignado al rol. 

Además, puede ser traducido a los idiomas de la aplicación usando “ROLE.” concatenado de este mismo nombre como clave de traducción en portuno.translations.

• description: descripción del rol.

• isCross: flag para indicar si el rol es transversal (cross).

Visión de Administrador

El alta de roles mediante el Panel de Administrador de Anjana Data se realiza en Roles:

Al acceder se muestra una tabla que contiene los roles existentes en la configuración actual. 

La creación de un rol se realiza mediante el botón New:

Mediante el wizard de creación se selecciona el módulo (Module) en el combo de selección, se introduce el nombre (Name) del rol, se marca el selector de isCross en caso de tratarse de un rol transversal y se introduce una descripción del rol. A continuación, se muestra cómo crear el rol de CDO, el cual es transversal.

Visión de Desarrollador

Para definir roles hay que configurar la tabla role del esquema Zeus. Para configurar los roles, rellenar un sql como el siguiente:

NOTAS: 

• El nombre asignado a los roles no debe contener caracteres que coincidan con el separador de unidades organizativas. 

• No se pueden configurar dos roles con el mismo nombre.

• En Anjana es posible asignar un rol a todos los usuarios que se registran en la aplicación por defecto. Para más detalle, acceder al apartado Rol por defecto.

1. Permisos asociados a cada rol

Una vez definidos los roles, se deben definir permisos asociados a cada rol conforme a las responsabilidades definidas en el gobierno del dato en la tabla permission.

Los permisos son los que habilitan a cada rol a realizar acciones a bajo nivel. Existen distintos permisos para el Catálogo de Datos y para el Glosario de Negocio debido a las particularidades de cada uno de los módulos y sus entidades. Además, estos permisos se configuran de forma individual para cada uno de los tipos de entidades definidos en el metamodelo.

Los distintos tipos de permisos a configurar por tipo de entidad y relación son los siguientes:

• AUTOMATIC_METADATA: que habilita la creación de entidades o relaciones en Anjana Data de forma asistida mediante el descubrimiento y la importación automática de metadatos de los sistemas origen.

• CHANGE_STATUS: que habilita a activar y desactivar entidades o relaciones no nativas.

• CHANGE_OU: que habilita a modificar la unidad organizativa de una entidad.

• CREATION_MODIF: que habilita a crear, modificar y enviar a validar entidades o relaciones creados o modificados.

• DELETE_ALL: que habilita al usuario a eliminar entidades o relaciones sea quien sea el creador y el estado que tengan.

• DELETE_MY_OBJ: que  habilita al usuario a eliminar entidades o relaciones creados por él mismo sea cual sea su estado.

• DEPRECATION: que habilita a deprecar manualmente entidades nativas.

• ORGANIZATIONAL_UNIT_OWNER: que habilita como propietario de aquellas entidades que se encuentren dentro de la unidad organizativa.

Además, algunos permisos afectan a toda la aplicación:

• ACCESS: que habilita el acceso a Anjana Data, la visualización de los objetos y el carrito para la solicitud de adherencias.

• ADMIN: que habilita el acceso al Portal de administración de Anjana.

• API_ADMIN: que habilita el uso de la API administrativa. Usuarios con este permiso, además, pueden editar masivamente objetos por el Portal de Anjana. Además permite acciones especiales de procesamiento desde el Portal de administración.

• CREDENTIAL_ADMIN: que habilita el acceso a las tablas de credenciales que desde el Portal de administración de Anjana se gestionan: appConfiguration, users y userOuRole.

• LINEAGE_ACCESS: que habilita la visualización del linaje.

• WIZARD: que habilita el acceso al wizard de creación de objetos de Anjana Data. Este permiso tiene sentido cuando el rol tiene algún permiso de CREATION_MODIF o AUTOMATIC_METADATA de alguna entidad o relación.

• WORKFLOW_ACCESS: que habilita la visualización (y, por tanto, también aprobación o rechazo) de los flujos (workflows) de validación.

Estructura de la tabla

Cada permiso se caracteriza por los siguientes elementos:

• id_permission: identificador único del permiso

• id_role: indica el rol al que se le están otorgando permisos

• permission_action: indica la acción para la cual se está dando permiso

• sub_type: indica el objeto sobre el que aplica el permiso

Las combinaciones de permission_action y sub_types posibles son:

(1): Name de la tabla object_subtype

(2): No se deben definir permisos para DATASET_FIELD ya que, para él, aplican los permisos de DATASET

(3): CHANGE_OU no puede ser utilizado para INSTANCE

Visión de Administrador

El alta de permisos mediante el Panel de Administrador de Anjana Data se realiza en Permissions:

Al acceder se muestra una tabla que contiene los permisos existentes en la configuración actual. 

La creación de un permiso nuevo se realiza mediante el botón New:

Mediante el wizard de creación se selecciona la acción, el subtipo de objeto al que aplica y el rol que tendrá el permiso a crear.

Visión de Desarrollador

Para definir permisos hay que configurar la tabla  permission del esquema Zeus. Para configurar los permisos, hay que rellenar un sql como el siguiente:

NOTAS: 

• Para evitar inconsistencias y debido a que los permisos de los usuarios se cachean en la aplicación, es necesario limpiar las cachés (Clear Cache) desde el Portal de Administración tras hacer cambios en la tabla de zeus.permission. Además, es conveniente que los usuarios cierren sesión para que empiecen a aplicar los cambios.

• No se permite repetir un permiso para un mismo subtipo y un mismo rol.

• No se puede configurar un permiso sin asignar un rol determinado.

1. Idiomas de la aplicación

La tabla languages contiene los lenguajes disponibles del sistema. 

Los textos de Anjana deben traducirse en cada uno de estos idiomas en la tabla de portuno translations para que los usuarios puedan utilizar la aplicación en todos ellos.

Estructura de la tabla

Cada idioma se caracteriza por los siguientes elementos:

• id: identificador único de la tabla.

• i18nCode: código i18n para el idioma.

• description: nombre del idioma.

En caso de querer visualizarlo en los distintos idiomas de la aplicación debe usarse el campo name como clave de traducción en la tabla de portuno de translations.

Visión de Administrador

El alta de un nuevo idioma en el panel de administración de Anjana Data se realiza en Languages:

Al acceder se muestra una tabla que contiene todos los idiomas existentes en la configuración actual.

La creación de un nuevo idioma se realiza mediante el botón New:

Mediante el wizard de creación se identifica el código i18n del idioma y la descripción.

Después de añadir un nuevo idioma hay que incluir las traducciones en la tabla translations del esquema de Portuno (en el apartado Traducciones se explica cómo se añade cada una de ellas.

La manera más sencilla de añadir todas las traducciones necesarias para el nuevo idioma es duplicar las que ya existen en uno de los idiomas que se encuentran precargados en Anjana como son el inglés o el español y después cambiar el valor de las columnas ‘language’ (por el código i18nCode creado) y la columna ‘value’ por la traducción en el idioma creado.

En Anjana hay traducciones que deben existir en esta tabla. Algunas de ellas se encuentran listadas en el apartado Traducciones internas de Anjana

A continuación se incluye un listado con los campos de las tablas de configuración de base de datos que contienen claves de traducciones:

• anjana

  • attribute_definition

    • description

    • label

    • place_holder

    • short_description

  • attribute_definition_value

    • value

  • attribute_relationships

    • destination_value

    • source_value

  • layer

    • layer_name

  • menu

    • name

  • sections

    • name

• hermes

  • notification

    • notification_type

    • subject

    • translation_key

• minerva

  • audit_log

    • action

    • action_description

    • organizational_unit

    • organizational_unit_changed

    • workflow_type

  • filter_conf

    • label

• portuno

  • translations

    • config_key

• zeus

  • languages

    • description

  • organizational_unit

    • alias

Una vez se han añadido todas las traducciones en la tabla translations de portuno es necesario actualizar los ficheros de traducción que se encuentran en Minio o en S3 seleccionando la opción ‘Upload Translations Files’ en el portal de administrador para que estén disponibles en el portal de Anjana.

Visión de Desarrollador

Para definir los idiomas hay que configurar la tabla languages del esquema Zeus. Para ello, hay que rellenar un sql como el siguiente:

NOTAS:

• No pueden crearse idiomas con el código i18n repetido.

• Si se desea eliminar un idioma de la aplicación, es necesario comprobar antes que no hay datos ni workflows en el repositorio de Anjana. En caso de que existan, no es posible eliminar el idioma.

1. Autenticación y autorización por base de datos

En Anjana la autenticación y autorización de los usuarios en base de datos es una opción configurable. De esta manera se dispone, en el esquema Zeus de base de datos, toda la información de los usuarios, sus contraseñas y los roles que tienen cada uno en las unidades organizativas de Anjana en estas dos tablas:

• users: Donde se incluye la información de los usuarios (email, teléfono, nombre, apellido y contraseña).

• user_ou_role: Tabla donde se asigna a los usuarios los roles en ciertas unidades organizativas.

IMPORTANTE: Para proteger la privacidad de la contraseña se usa la función de cifrado lento Bcrypt, en el siguiente enlace se dispone de más información de este algoritmo de encriptación :

https://www.devglan.com/online-tools/bcrypt-hash-generator

De esta forma no se incluye en claro la contraseña en la tabla ‘users’ sino que es necesario calcular un hash e introducirlo en la columna ‘password_hash’.

1. Usuarios

La tabla users contiene la información de los usuarios de Anjana cuando se autentican o autorizan por medio de base de datos.

Estructura de la tabla

Cada usuario se caracteriza por los siguientes elementos:

• id_user: identificador único del usuario en la tabla.

• user_name: identificador único del usuario en la aplicación. Nombre con el que los usuarios se registran en los portales de Anjana.

• first_name: nombre del usuario.

• last_name: apellidos del usuario.

• email: dirección de correo del usuario.

• is_service_user: boolean para indicar si se trata de un usuario de servicio utilizado para la securización de los microservicios. Este campo es informativo.

• phone: número de teléfono del usuario.

• title: título del usuario, no es necesario rellenarlo.

• password_hash: hash de la contraseña del usuario. Para obtenerlo se puede usar cualquier calculadora de Bcrypt de internet, el hash obtenido es único.

Visión de Administrador

El alta de permisos mediante el Panel de Administrador de Anjana Data se realiza en Users:

Al acceder a la tabla de Users se muestra una tabla que contiene todos los usuarios existentes en la configuración actual.

La creación de un nuevo usuario se realiza mediante el botón New:

Mediante el wizard de creación se identifica el username identificativo del usuario, su nombre y apellido, correo electrónico, teléfono, rol en la compañía y la contraseña cifrada.

Visión de Desarrollador

Se pueden incluir usuarios rellenado un sql similar al siguiente:

NOTAS:

• Para el valor del campo user_name se aplican las siguientes restricciones:

  • No debe contener ‘:’, ‘#’, ‘(‘ o ‘)’ porque interfiere con las ARI

  • No puede estar vacío o ser nulo.

  • Los caracteres ‘.’ (punto) , ‘_’ (guión bajo) , ‘-’ (guión) no pueden estar al inicio, al final, ni aparecer consecutivamente.

  • Longitud mínima 1 y máxima 50 caracteres.

• No es posible que dos usuarios tengan el mismo user_name, incluyendo mayúsculas y minúsculas (pepe, Pepe y PEPE se consideran el mismo usuario).

1. Rol y OU asignados a los usuarios

La asignación de usuarios a roles en unidades organizativas se configura en la tabla users_ou_role.

Estructura de la tabla

Cada asignación de usuario a rol se caracteriza por los siguientes elementos:

• user_id: identificador del usuario, es el campo id_user de la tabla de users.

• ou_id: identificador de la unidad organizativa, es el campo id_organizational_unit de la tabla organizational_unit.

• role_id: identificador del rol, es el campo id_role de la tabla role.

Visión de Administrador

El alta de permisos mediante el Panel de Administrador de Anjana Data se realiza en User-OU-Roles:

Al acceder a la tabla de User_ou_roles se muestra una tabla que contiene los usuarios de la aplicación con los roles y OUs que tienen asignados. 

La asignación de un nuevo rol a un usuario se realiza mediante el botón New:

Mediante el wizard de creación se identifica el username identificativo del usuario, la OU y el rol que se le asigna y que le otorga permisos.

Visión de Desarrollador

Para definir los roles de cada usuario en Anjana hay que configurar la tabla users_ou_roles del esquema Zeus. Para configurarlo, hay que rellenar un sql como el siguiente:

NOTAS: 

• Al ser todos los campos de esta tabla los que hacen único al registro, cuando se desee cambiar algún rol de algún usuario será necesario eliminar el registro original y crear uno nuevo.

1. Rol por defecto

Además de la asignación personal de usuarios a roles específicos, en Anjana es posible configurar un rol por defecto (sólo uno) con el fin de que cualquier usuario que se registre en la aplicación herede los permisos otorgados a este rol, sin necesidad de asignarlo uno a uno.

La variable que permite configurar este rol es anjana.role.defaultRole.

Este rol está dedicado a consulta de datos y solicitud de adherencias y, por ello, los permisos permitidos para él son: