Los plugins de Anjana Data Platform son los componentes que permiten conectar la plataforma con tecnologías del ecosistema de datos y de identidades de la organización (cloud, on-premise, BI, data lakes, catálogos técnicos, etc.). Cada plugin está especializado en una tecnología concreta —por ejemplo, AWS S3, Azure Storage, GCP BigQuery, Entra ID, Denodo, Tableau o Power BI— y habilita capacidades de integración nativas con el modelo operativo de gobierno de Anjana Data Platform.
En esta sección se documentan los plugins disponibles en la versión 25.2 y su comportamiento funcional. La configuración técnica específica de cada tecnología se detalla en su página correspondiente.
Capacidades funcionales comunes de los plugins
Aunque cada plugin depende de la tecnología destino, la mayoría de integraciones de Anjana DataPlatform se apoyan en cuatro capacidades principales:
1. Extracción de metadatos
Permite descubrir e importar activos desde la tecnología origen a Anjana Data Platform (datasets/tablas, fields/columnas, procesos, vistas, informes, etc.).
Los metadatos extraídos se transforman a entidades del metamodelo operativo para que puedan gobernarse en el Portal de Datos.
Ejemplos: AWS Glue, JDBC Genérico/Oracle/SQL Server/Redshift, Denodo, Azure Storage, GCP BigQuery, Ranger.
2. Muestra de datos (sample data)
Algunos plugins permiten recuperar una muestra controlada del dato asociado a un dataset para visualizarlo desde la pestaña “Datos de muestra” del detalle del activo.
Esta capacidad está sujeta a permisos, limitaciones técnicas de la plataforma origen y reglas de seguridad del modelo operativo (Ver información sobre el atributo isGoverned y sampleData).
Ejemplos: Azure Storage, GCP Storage, BigQuery, motores JDBC.
3. Gobierno activo de permisos de acceso
Los plugins de gobierno activo de accesos materializan, en la tecnología externa, las decisiones de acceso a datos o informes establecidas en la capa de gobierno a través de los Data Sharing Agreements (DSA).
Dependiendo de la tecnología, el gobierno activo puede implicar:
-
Provisión de grupos o roles que representan un DSA.
-
Gestión automática de miembros/usuarios según adherencia y desadherencia.
-
Asignación o revocación de permisos sobre estructuras físicas gobernadas (tablas, vistas, buckets, rutas, etc.).
Ejemplos:
-
Identidades: Entra ID, AWS IAM, GCP IAM, LDAP/AD.
-
Datos: Azure Storage (vía Entra ID), AWS S3 (vía IAM), GCP Storage/BigQuery (vía IAM), Denodo (vía LDAP o Entra ID), Ranger.
Nota sobre provisión desacoplada de grupos y roles
La provisión de grupos y roles en los sistemas externos está desacoplada. Esto significa que, mediante configuración y metadatos del propio DSA, es posible omitir la creación y gestión automática de grupos por parte de Anjana Data Platform.
En concreto, si durante la creación de un DSA se informa el atributo physicalName con el identificador de un grupo ya existente en la organización, el plugin reutiliza ese grupo en lugar de crear uno nuevo. A partir de ese momento, la provisión de roles y permisos se realiza conforme al physicalName indicado, manteniendo el gobierno activo sobre los recursos sin necesidad de gestionar el ciclo de vida del grupo desde Anjana Data Platform.
Esta funcionalidad es especialmente atractiva en escenarios como:
-
Cuando la organización no desea delegar la creación/eliminación de grupos en el plugin de Anjana Data Platform, pero sí quiere aprovechar la gestión automática de miembros/usuarios (altas y bajas por adherencia/desadherencia).
-
Cuando las políticas corporativas de nomenclatura de grupos no encajan con la convención estándar de Anjana Data Platform (prefijo + nombre lógico del DSA + versión), y se requiere mantener nombres propios preexistentes o gestionados externamente.
-
Cuando existen grupos ya consolidados en el proveedor de identidades (por ejemplo, grupos departamentales o por producto) y el DSA debe apoyarse en ellos para evitar duplicidades y simplificar la administración.
-
Cuando la gestión de grupos está controlada por procesos internos o herramientas externas, y Anjana Data Platform debe integrarse sin interferir con ese ciclo de vida.
-
Cuando se quiere mantener continuidad histórica de accesos: reutilizar un grupo existente permite que auditorías, trazabilidad y dependencias en sistemas externos sigan referenciando el mismo identificador.
4. Sincronización / operaciones técnicas
Algunos plugins, además de extraer o gobernar, pueden realizar operaciones técnicas de sincronización para mantener consistencia: actualización de tags, políticas, etc.
Convención de nomenclatura de DSAs en sistemas de identidades
Cuando un plugin representa un DSA como grupo (Entra ID, AWS IAM, LDAP/AD) o como rol (GCP IAM), Anjana Data Platform genera por defecto estos artefactos siguiendo una convención homogénea de nombre:
<prefijo configurable>_<nombre lógico del DSA>_v<nº de versión del DSA>
Donde:
-
<prefijo configurable>identifica los grupos/roles gestionados por Anjana Data dentro del proveedor. -
<nombre lógico del DSA>es el nombre funcional del acuerdo tal y como figura en Anjana. -
v<nº de versión>permite distinguir versiones coexistentes (aprobadas, deprecadas o históricas) y mantener trazabilidad entre sistemas.
Esta convención aplica siempre que el DSA no indique un artefacto físico preexistente.
En escenarios donde se desea reutilizar un grupo ya gestionado por la organización, puede informarse el atributo physicalName durante la creación del DSA. En ese caso, el plugin no crea un nuevo grupo, sino que utiliza el identificado en physicalName y materializa el gobierno activo (roles/permisos y membresías) sobre ese artefacto.
Cada tecnología puede imponer restricciones adicionales de longitud o caracteres válidos para grupos o roles. Estas restricciones se detallan en la página específica de cada plugin.
Multi-conexión (desde la versión 25.1)
Desde la versión 25.1, los plugins que lo soportan permiten configurar más de una conexión por tecnología. Esto facilita integraciones por entornos (dev/prod), por regiones o por cuentas/proyectos distintos.
En la configuración funcional se define una lista de conexiones, cada una con su ARI y propiedades propias de la tecnología. La configuración técnica detallada y ejemplos YAML están disponibles en Nexus y en las páginas específicas de esta sección.
Consideraciones adicionales
Más información
Para información específica, consultar la documentación de cada plugin.
Para todos los plugins existen directrices comunes recogidas en los apartados de Configuración técnica y en Tot despliegue de plugins .
Además, para cada plugin se dispone de un YAML de ejemplo que facilita su puesta en marcha. Este fichero incluye la descripción de cada propiedad y sus valores por defecto, de modo que puede copiarse y adaptarse a la instalación del cliente.
Los plugins que lo soportan permiten configurar múltiples conexiones a distintas instancias de una misma tecnología (por ejemplo, diferentes cuentas, proyectos o entornos). Esta capacidad, así como su sintaxis, se ilustra también en los YAML de ejemplo correspondientes.