--- version: "26.1" language: "en" --- # Technical Solution ## Introduction This document aims to describe the technical solution of the ANJANA DATA tool. Throughout the document, each piece that makes up the solution's technological ecosystem is described, both at a general level and for each component. Anjana Data is built on a state-of-the-art modular architecture based on microservices, Big Data and Cloud native, API-first, with no vendor lock-in or black boxes, in a flexible, open, and extensible ecosystem offering full scalability and interoperability through the use of consolidated, state-of-the-art open-source technologies, as well as managed services. ![att_36_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_3c320a8c0ab969306392651ea5b547dab31d411011ef1d3ce6bb9b7933a4b587/att_36_for_172000159.png?cb=8ad624781c976e8dcc2b93f61202c2f1) One of Anjana Data's key differentiators lies in its **microservices-oriented architecture**, fully scalable and interoperable, with extended native integration across a multitude of data technologies and platforms, with particular focus on Big Data and Cloud-native technologies. Furthermore, thanks to the design of its architecture and the technologies used, Anjana Data offers a range of capabilities in terms of**flexibility, adaptability, customization, extensibility, scalability, and interoperability** that make it one of the most cutting-edge and innovative solutions on the market from a technical standpoint. Thus, Anjana Data allows the solution to be customized through parameterization without the need for code development, while also offering a resource kit for developing new plugins and agents for integration with other technologies, and it has different layers of APIs for bidirectional interaction with the solution's modules. ![att_30_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_1b851b1844cca8342b518e015f6983c26a2d4123f1da40e37275b70a4014021a/att_30_for_172000159.png?cb=92ba9085883af27afef0e4884f7ec014) ![att_34_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_4a9206f6449bca8288655e4fc7b94d0401d99d0091fe693eb3d3106f11f08c07/att_34_for_172000159.png?cb=ee7f99f77865d4077db581eb449e05d2) Thanks to the different, fully independent yet integrated and interconnected microservices, it is possible to decouple the capabilities of the solution's different layers and modules while ensuring complete consistency and a unified user experience across the entire platform. From an operational standpoint, **Anjana Data places data governance at the beginning of the data value chain**, turning it into the "single point of entry" from which the different processes needed on the corresponding pieces are orchestrated to ensure the correct management of a governed data ecosystem. That is why Anjana Data's integration vision with the different pieces of a data ecosystem goes far beyond basic integrations, and includes the following types of native integration that represent a paradigm shift in the understanding of a data governance solution. ![att_29_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_13eca50aa325bf0efebcb1994bf00fb9a7ef984ddca4cd1b8da07473728a0d78/att_29_for_172000159.png?cb=31831c5662634f9c2ceb88c428efef20) Thanks to all these integrations with different pieces of an organization's data ecosystem, and to Anjana Data's philosophy based on interoperability, it becomes possible to **automate a multitude of technical processes orchestrated in a governed manner based on demand management integrated into data governance, thereby abstracting data management and governance from the technologies of the storage, processing, and exploitation platforms**. ## Open-source technology inventory Below are the technologies used to implement each of the different modules that make up the Anjana Data solution. The programming language used was Java 17 for the Backend. |-----------------------------|----------------------------------------------------------------------------------------| | **Technology** | **More information** | | Angular | [++https://angular.io++](https://angular.io/) | | Spring Cloud | [++https://spring.io/projects/spring-cloud++](https://spring.io/projects/spring-cloud) | | Spring Boot | [++https://spring.io/projects/spring-boot++](https://spring.io/projects/spring-boot) | | LDAP | [++https://ldap.com++](https://ldap.com/) | | OAuth2 / SAML2 | [++https://oauth.net/2++](https://oauth.net/2/) | | PostgreSQL | [++https://www.postgresql.org++](https://www.postgresql.org/) | | MongoDB / Amazon DocumentDB | [++https://www.mongodb.com++](https://www.mongodb.com/) | | Apache SolR / OpenSearch | [++https://lucene.apache.org/solr++](https://lucene.apache.org/solr/) | | SeaweedFS / AWS S3 | [++https://github.com/seaweedfs/seaweedfs++](https://github.com/seaweedfs/seaweedfs) | | Valkey | [++https://valkey.io++](https://valkey.io/) | | RabbitMQ | [++https://www.rabbitmq.com++](https://www.rabbitmq.com/) | | Apache Zookeeper | [++https://zookeeper.apache.org++](https://zookeeper.apache.org/) | | Activiti | [++https://www.activiti.org++](https://www.activiti.org/) | | Swagger / OpenAPI | [++https://swagger.io++](https://swagger.io/) | | Grafana | [++https://grafana.com/++](https://grafana.com/) | --- version: "26.1" language: "en" --- # Architecture: Overview and Technology Stack Components The architecture designed allows Anjana Data Platform to **govern different technologies, clusters and environments** , and also makes it **independent from each vendor's product versions**: for each version there will be a microservice with the specific functions that may exist in each of them, and if needed it can be isolated to avoid incompatibilities or security issues. With this, Anjana Data Platform is the ideal tool to govern complex environments and architectures, such as multi-cloud, hybrid, big data, AI-Ready, etc., and it keeps the platform ready for new technologies and/or new uses of information technologies yet to come. In this way, Anjana Data Platform offers a versatility and agility of growth that allows new versions with expanded capabilities to be delivered in very short periods of time, as well as full customization capability for the functionalities mentioned above. Anjana Data Platform's technical architecture uses the **Spring Cloud** technology stack in its most recent versions, including the corresponding product modules (Springboot, Eureka, Config, Security). In order to achieve maximum independence from the technology/architecture, Anjana Data Platform also makes use of a **repository to store files or records**. In this regard, the technology stack can be grouped into the following blocks: ## **Microservices based on Spring Cloud technologies** * The **Spring Cloud** technologies used and the product's design make it feasible to implement **high availability** and **load balancing** at every point of the platform, many of which are de facto redundant due to the technology used and the platform's minimum requirements. * Thanks to **Spring Cloud + Eureka** as the registry and synchronization manager, a dynamic and redundant microservices structure is built, enabling a complete customization layer for the system that **allows the relocation and balancing** of practically all of its modules, both internal and public. * Through the agnostic approach offered by **Spring JPA** technology and the customization layer based on **Spring Boot microservices**, these pieces could easily be replaced by other technologies with similar functionality. * To **monitor** the microservices ecosystem, Anjana Data Platform uses a **Spring Boot Admin** web administration panel, through which the status and detailed metrics of each service can be known, observed, easily consumed by the user, or integrated into an external monitoring platform. * Regarding **scalability** , the use of highly efficient **multi-thread** technologies and the possibility of practically unlimited horizontal scaling in each of its critical components make the initial volume of concurrent users and governed datasets very high. In figures: with the recommended configuration, a volume of 700 users and 100,000 data assets can be served without the need for queuing. ### **Internal traffic with API gateway** * Anjana Data Platform uses the **API Gateway** to redirect internal traffic in a highly efficient way. For example, the controllers responsible for performing low-level system tasks (listing tables, creating directories, etc.) are not within the backends, but are invoked by the microservices. * This design allows the tool to evolve; if any controller becomes obsolete, the service in question can be dismantled and replaced in the most effective way. ### **Front-end with Angular** * Both the portal and the administration panel have their front-end layer built in Angular * The use of this technology makes it possible to generate a user-friendly interface that is fully operable by both technical and business users. * Fully integrable with the Back-end technology to offer all the functionalities that allow full control of Anjana Data Platform and its modules (data portal, lineage, audit, creation/modification, data marketplace, workflows, etc.) * Fully manageable administration portal that allows configuring Anjana Data Platform without the need to write code or access databases. ### **Storage technologies** * The use of well-established **open-source** technologies helps reduce costs while achieving high reliability, interoperability and evolution. Anjana Data Platform uses **PostgreSQL and DocumentDB** for the data persistence layer and **Apache SolR/OpenSearch** as the search engine. * Since **massive record storage** is carried out in **SolR/OpenSearch**, a specific technology based on redundancy and scalability, it is practically unlimited and easily configurable. * Document management, configuration files and translations are stored in **SeaweedFS or AWS S3**, a storage server that allows storing various types of structured and unstructured data. * Shared cache management is carried out with **Valkey**, a cache manager accessible by all microservices to reduce memory load and latency. * Asynchronous workload management is carried out with queues in **RabbitMQ** , a versatile and simple queue manager to avoid unnecessarily blocking processes**.** * Distributed process coordination is carried out in an agile and reliable way thanks to **Apache Zookeeper** technology. ### **Authentication and authorization** * Anjana Data Platform is designed so that the user can choose which provider to authenticate against, and authorization is handled through the internal database configuration, configurable from Portuno. * LDAP protocol: The Zeus module supports LDAP service, either with OpenLdap or Active Directory schemas. * OAuth2 protocol (OIDC Azure/AWS/GCP/Auth0). * SAML2 protocol (Azure/AWS/GCP/Auth0). ### BPM under the BPMN 2.0 standard Anjana Data Platform incorporates **Activiti** as an open-source BPM fully integrated into the solution, supporting the **BPMN 2.0** standard, thanks to which fully customized validation workflows can be designed and implemented: * **Workflows** are based on the configured **model of roles, organizational units and permissions**, and are also integrated with the alerts, messages and notifications module to foster collaboration among participants. * Predefined **workflows** are available in Anjana Data Platform, but **additional workflows** can also be created to validate the different actions performed in Anjana Data Platform (by object type, action type, role type, business area, etc.). * For each workflow, all **validation steps** can be configured (order and role/roles that validate), as well as customizing the **notifications** sent to the different participants at each step, or even adding **specific actions** supported by the standard (running a script, triggering another action, sending an email, calling APIs, etc.). * Additionally, **complex workflows based on the values** of an object's metadata attributes can be configured (e.g. different workflows for assets that include personal data). * All workflows, along with all their information (workflow steps, status, actions, users involved, etc.), are **tracked** and can be viewed through the Anjana Data Platform UI, where you can also filter to display only the workflows of interest and access the detail of each workflow. ### **Integration and interoperability mechanisms** Regarding **integration with various technologies**, Anjana Data Platform is fully integrable and interoperable and can connect with any technology through the following methods: * **Plugins and Agents** developed by the Anjana Data Platform Product team, which offer native integrations with various technologies, covering different operating modes and configuration options (see details in the component catalog by zone, below). * **Ad-hoc developed plugins and connectors**: An SDK (software development kit) is provided that allows both customers and partners to develop their own connectors autonomously, to implement specific required functionalities and uses without needing to alter the product. * By making use of the **different API layers** provided by Anjana Data Platform, both to import and export the desired information, as well as to execute specific actions in the application. In this regard, Anjana Data Platform has 3 API layers: public, administrative and configuration; each with a specific purpose and aimed at different profiles. * **MCP (Model Context Protocol)**: a module that allows an AI Agent to search, query and edit Anjana Data Platform entities, DSAs, adherences and audit logs in self-service mode (see details in AI , below). In addition, the ability to execute **custom actions in the application as well as to launch external scripts** is added, thanks to the following alternatives: * By using an internal **interceptor** and its corresponding SDK, which is provided with Anjana Data Platform * By using the **BPM module**, based on Activiti, following the BPMN 2.0 standard, from which any type of workflow can be defined, in whose steps the launching of said actions and/or scripts can be defined. * By making use of the **different API layers** provided by Anjana Data, in the same way as indicated above. In this regard, the use of the APIs can be orchestrated by an internal scheduler or executed from triggers. As for the Plugins, these allow Anjana Data Platform to execute actions on the governed systems, as well as to retrieve metadata and incorporate it into Anjana Data Platform, enabling assisted and automatic metadata import. ![Arq1_EN.png](https://wiki.anjanadata.com/__attachments/a_17c88ab3c6d7da529dd8d0b475fe1efc67711ffeb10d195cec7929ccc6773e57/Arq1_EN.png?cb=990d01bc1eb3c46a1a510fca903005c1) ### **RESTful API with Swagger** Finally, to ensure that Anjana Data Platform is 100% interoperable, the entire solution is fully API-enabled with RESTful API and Swagger. Thus, Anjana Data Platform has three layers of APIs that serve different purposes: * **Public**: The public API layer offers user functionalities to interact with Anjana; from this API layer you can access the different modules offered by the tool, such as: object creation/modification, lineage, history, audit, alerts and notifications, and data marketplace. * **Administrative**: Through the administrative API layer, the metamodel can be managed in administrator mode, that is, modifications can be made to the metamodel (creation/modification of objects) without having to go through the validations defined for users. * **Configuration**: This API configuration layer allows managing the tool's configuration in all its dimensions: * Management of Organizational Units, Roles and permissions. * User management. * Management of Objects, validation workflows and attribute templates * Management of attributes and attribute validations. * Management of search filters * Language management ### **Dashboarding** In terms of reporting capabilities, Anjana Data Platform incorporates Grafana as an open-source self-service and reporting tool fully integrated into its architecture stack. Dashboarding: Anjana Data Platform's data model is open, so the information contained in the tool can be extracted for use in any Dashboarding tool, such as Grafana, Azure PowerBI, Google Looker or Amazon QuickSight, among others. Dashboarding with Grafana: Anjana Data Platform, through its native integration with Grafana, offers the ability to build custom reports and dashboards autonomously and dynamically without the need to code, using functions such as clicks and drag \& drop. Additionally, Grafana provides the ability to perform time series analysis and configure real-time alerts that facilitate the monitoring and management of the implementation of data governance as well as data quality. ## **Solution components** The following describes how Anjana Data Platform's modules are grouped into functional zones. The underlying technologies of each have already been described in the previous sections. ![Arq2_EN.png](https://wiki.anjanadata.com/__attachments/a_d7b94cfee65656c30a2455c49e01e6183c73fc4d07d0a1fffadfd6d6074c5b90/Arq2_EN.png?cb=a25795842963e348979126167046130d) ### **Web Zone** #### **Portuno UI** It is a web-based solution built on a microservices architecture that makes use of well-established open-source technologies to offer an administration portal, which allows users to configure the Anjana Data Platform ecosystem. #### **Anjana UI** It is a web-based solution built on a microservices architecture that makes use of well-established open-source technologies, offering a wide range of functionalities focused on catalog management and data self-service, characterized by a very high accessibility criterion and a simplified, collaborative usage. ### **Control Zone** #### **Drittesta** This module is the tool for retrieving information about the work of the Anjana Data Platform ecosystem, in order to provide a response and support to the platform's customers. This data will be sent to an external infrastructure server. ### **Integrations Zone** #### **Zeus** A module that provides service authorization. In accordance with OAuth 2.0/SAML2, the specification defines a delegation protocol that is useful for transmitting authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication. #### **Tot** Module in charge of integration with different technologies to perform the following tasks: creation of data structures by exporting and loading the required metadata into the corresponding data platform, provisioning of roles and groups to the identity management platform, provisioning of the necessary permissions (grants and acls) at the locations of governed datasets, and basic on-the-fly query execution for displaying data samples. It also includes the necessary clients to automatically import and/or infer the metadata and static lineage of external information sources and load them into KERNO. In this way, the user is relieved of the manual task of entering metadata in Anjana Data Platform for all those sources and technologies for which the corresponding extractor has been developed and integrated. As it is an external service developed with Spring Boot microservices, different extractors for different sources and technologies can be added incrementally and independently. In addition, since it is integrated with KERNO through the REST API, third-party developments can be used for this purpose and feed ANJANA CORE, provided the information is supplied in the way KERNO expects to receive it. In some cases, the execution of these processes can take too long, so these operations are defined asynchronously, to avoid unnecessary waiting for the user in the application. The execution of these processes will be carried out by sending requests to the responsible module, which will connect to the source and, once the extraction and loading of the metadata is complete, the user will be notified. #### **TOT Plugins** TOT plugins are used to perform the actions carried out through TOT; each plugin acts on a logical partition, resolving a connection, and can trigger several actions depending on the technologies involved, and a technology can have more than one plugin depending on its possible uses. The available plugins can be configured and/or modified for specific purposes or ad-hoc implementations, while new plugins can be developed and deployed following the standards recommended by Anjana Data Platform. ### **API Zone** #### **Portuno** This is the module where all of Anjana Data Platform's configuration and the information for the Admin web front end are centralized. This module manages Anjana Data Platform's internal databases, where the instance configuration and the designed workflows that are later executed in Hermes are stored. #### **Hermes** This module is the validation workflow management tool and is based on the Activiti engine. Activiti is the leading lightweight, Java-centric open-source BPM engine, which supports real-world process automation needs. Following the BPMN 2.0 standard, it offers an engine for different processes, allowing different validation workflows to be configured. #### **Kerno** This is the basic module of the functional architecture, which includes the solution's main functionalities and the structures common to all modules. #### **Minerva** This module is the tool for centralizing, organizing and indexing all the metadata and audit information of the Anjana Data Platform ecosystem. #### **Marketplace** This module is the tool for centralizing, organizing and managing assets for access management. #### **Viator** Based on Spring Cloud Gateway, it is the entry point for any of Anjana Data Platform's APIs, both for any user as well as for the web front ends or internal communication between microservices. ### **Orchestration Zone** #### **Horus** It is a central configuration service that serves configurations from a Secret Manager, Databases, or from git during microservice startup. It is also based on Netflix Eureka, where microservices register at startup and from which the status of each one can be known. When a microservice needs to connect to another, Horus provides it with the hostname and current IP, so that the interaction between the architecture's microservices is self-orchestrated. ### **Storage Zone** Groups together the persistence, indexing, messaging and cache modules already described in the **Storage technologies** section above (S3/SeaweedFS, PostgreSQL/DocumentDB, SolR/OpenSearch, RabbitMQ and Valkey). ### **AI** #### **MCP** Anjana Data has committed to customer self-service for consuming metadata, audit information and lineage, and even modifying them, in ADP. For this purpose, there is a new module that, through different tools, allows an AI Agent to search for and query entities, DSAs and audit logs, explore an entity's lineage, manage adherences to DSAs, and create, edit and submit entities for approval. --- version: "26.1" language: "en" --- # IaaS/PaaS Mode: Infrastructure Requirements and Recommendations Anjana Data provides several installation kits: * 🆕 Interactive installer based on a Java service that guides you through the installation via a graphical interface. * Ansible deployment kit that facilitates the implementation of the solution by automating, step by step, the installation and startup of each microservice that makes up Anjana Data Platform. ⚠️ **Discontinued (End of support Q4 2026)** * Helm kit for container-based deployments on K8S. ## Technical and Deployment Requirements ### Supported Operating Systems and Technologies * **Operating Systems**: Ubuntu, RedHat. * **Relational Databases**: PostgreSQL, AWS RDS/Aurora PostgreSQL, AzureDB for PostgreSQL, GCP Cloud SQL for PostgreSQL, Embedded in VM. * **S3 Storage**: AWS S3, SeaweedFS. * **Indexer**: SolR. * **Other components**: Ansible, Python, Zookeeper. **Note** : Full details about the **supported versions** are available in the [Ansible documentation](https://wiki.anjanadata.com/es/instalacion/26.1/ansible-1) and in the [Kubernetes documentation](https://wiki.anjanadata.com/es/instalacion/26.1/kubernetes). ### Deployment Requirements * User with **SSH** access and **root** permissions on all provisioned machines and managed services. * **Required connectivity to:** * `https://releases.anjanadata.com` for downloading the installer, artifacts, and software packages. * `https://veltesta.anjanadata.com` for license activation and validation. * Between the nodes and the managed **RDS and S3** services, if applicable. * Between all provisioned nodes in **Standard and Balanced** architectures, via **SSH**. * From Anjana nodes (**Zeus** ) to/from the **identity management systems** . See [Authentication documentation](https://wiki.anjanadata.com/es/integraciones/26.1/autenticacion). * Software download from the **operating system repositories** (see list in the [Ansible kits documentation](https://wiki.anjanadata.com/es/instalacion/26.1/ansible-1)). * **Post-deployment access to portals:** * `443 → /login`, `/configpanel`, `/swagger/swagger-ui.html` * `8889 (SeaweedFS)` * `8983 (SolR)` * `9999 (Horus)` * In the case of a managed database: there must be a database called **anjana** and a user with creation permissions. * In the case of managed S3: there must be **7 buckets** (`CDN`, `DSA`, `IMPORTS`, `TEXTAREA`, `WORKFLOWS`, `ANJANABACKUPS`, `ANJANALOGS`). * Deployment is performed using an **Ansible kit** run from a central node. * The machine running the Ansible kit must have a **fixed outbound IP address to the Internet**. * Required architecture: **x86_64 (Intel/AMD 64-bit)**. * Disk space: everything mounted on the root directory, using `/opt` and `/tmp`. In **SaaS Hybrid** mode, the specific connectivity of the plugins machine (ports 15001+ to the governed data systems and the Tot module) is detailed in [SaaS Hybrid Mode: Infrastructure Requirements and Recommendations](https://wiki.anjanadata.com/en/solucion-tecnica/26.1/saas-hybrid-mode-infrastructure-requirements-and-recommendations.md). ## Recommended Architectures Anjana Data provides different recommended configurations based on (but not identical to) the SaaS environment types **Test, Base, Standard, and Balanced**, which allow the deployment to be adapted to different volumes of users and data. These architectures are designed to ensure: * Proper load distribution. * Scalability and redundancy according to the criticality of the environment. * Integration with managed database and S3 storage services. **NOTE:** all disk sizes indicated below include the space required for the installation of system packages, handling of temporary files, installation directories, etc... For the system to function correctly, the total space cannot be dedicated to the installation folder. E.g.: /opt ### Test-type Infrastructure (POCs) * 1 VM - 8 VCore \| 32 Gb RAM \| 64Gb SSD ### Base-type Infrastructure * 1 VM - 8 VCore \| 32 Gb RAM \| 64Gb SSD * Managed S3 - 64 Gb ### Standard-type Infrastructure * 1VM (Core) - 4VCore \| 20 Gb RAM \| 64 Gb SSD * 1VM (Plugins) - 2VCore \| 8Gb RAM \| 32 Gb SSD * 1VM (Indexer) 2VCore \| 4Gb RAM \| 32 Gb SSD * Managed S3 - 128 Gb * Managed RDB - 2VCore \| 2Gb RAM \| 50Gb SSD * Managed MongoDB - 1VCore \| 2Gb RAM \| 16Gb SSD (self-managed if there is no cloud equivalent) * Managed RabbitMQ - 1VCore \| 1Gb RAM \| 16Gb SSD (self-managed if there is no cloud equivalent) * Managed Valkey - 1VCore \| 512Mb RAM (self-managed if there is no cloud equivalent) **Note:**Requirements for the Ansible kit or Installer binary in case it is deployed on a separate VM, with minimum requirements of 2vCPU \| 2GB RAM \| 32GB SSD ### Balanced-type Infrastructure * 2VM (FrontBack) - 4VCore \| 20 Gb RAM \| 64 Gb SSD * 1VM (Plugins) - 2VCore \| 8Gb RAM \| 32 Gb SSD * 3VM (Indexer) - 2VCore \| 4Gb RAM \| 32 Gb SSD * Managed S3 HA - 128 Gb * Managed RDB HA - 4VCore \| 4Gb RAM \| 50Gb SSD * Managed MongoDB - 1VCore \| 2Gb RAM \| 16Gb SSD (self-managed if there is no cloud equivalent) * Managed RabbitMQ - 1VCore \| 1Gb RAM \| 16Gb SSD (self-managed if there is no cloud equivalent) * Managed Valkey - 1VCore \| 512Mb RAM (self-managed if there is no cloud equivalent) ## Certificates All connections between **Anjana Data** components are secured using **SSL/TLS** with certificates managed by the client. Full details on requirements, file naming conventions, and delivery procedures can be found in the official documentation: * 🔗 [Deployment Manual with Ansible Kit -- Environment Platforming](https://wiki.anjanadata.com/es/instalacion/26.1/manual-de-despliegue-1#Plataformado-de-entorno) * 🔗 [Certificate Mechanics in Anjana Data](https://wiki.portal.anjanadata.com/wiki/x/JgAVD) --- version: "26.1" language: "en" --- # SaaS Hybrid Mode: Infrastructure Requirements and Recommendations In **SaaS Hybrid** mode, Anjana Data hosts and operates the core of the platform (Core, Indexer, and managed services) in its SaaS environment. The client only deploys the **plugins machine** on its own infrastructure, responsible for connecting to the governed data systems of its organization. This page covers the specific requirements and recommendations for that plugins machine. For the rest of the general requirements for operating systems, databases, and complete architectures, see [IaaS/PaaS Mode: Infrastructure Requirements and Recommendations](https://wiki.anjanadata.com/en/solucion-tecnica/26.1/despliegue.md). ## Plugins machine: requirements and recommendations ### Recommended sizing * 1 VM (Plugins) - 2 VCore \| 8 Gb RAM \| 32 Gb SSD **Note:** this sizing matches the Plugins node of the Standard and Balanced profiles described in [IaaS/PaaS Mode: Infrastructure Requirements and Recommendations](https://wiki.anjanadata.com/en/solucion-tecnica/26.1/despliegue.md). ### Deployment requirements * Operating system: **Ubuntu** or **RedHat**. * Required architecture: **x86_64 (Intel/AMD 64-bit)**. * User with **SSH** access and **root** permissions on the plugins machine. * The machine must have **outbound Internet connectivity** to `https://releases.anjanadata.com` (artifact download) and `https://veltesta.anjanadata.com` (license activation and validation). ### Connectivity * From the plugins nodes (**ports 15001+** ) to the governed data systems and to the **Tot** module. See [TOT Plugins documentation](https://wiki.portal.anjanadata.com/wiki/spaces/doc/pages/171933699/Tot+Plugins?atlOrigin=eyJpIjoiYjI5YjJiZTMzMmE5NGYxN2JiMDRlMDNlMmM4ZmZmNzIiLCJwIjoiYyJ9). ### Certificates Connections to the plugins machine are also secured via **SSL/TLS** . See the full details on requirements, file naming conventions, and delivery procedure in the Certificates section of [IaaS/PaaS Mode: Infrastructure Requirements and Recommendations](https://wiki.anjanadata.com/en/solucion-tecnica/26.1/despliegue.md). --- version: "26.1" language: "en" --- # SaaS Modality: Technical Specification of the Service ## **1 Purpose and scope** This document describes the **technical specification** of the **Anjana Data Platform SaaS** service, including: * Infrastructure profiles (PRE, Base, Standard, Balanced) and their capabilities. * SaaS packages offered and environments included (PRO/PRE). * Security controls included by default (baseline) and isolation principles. * Additional connectivity/security options. * Backups, retention and recovery objectives (RPO/RTO). * Usual operating regions. * Provider and customer responsibilities. ![Servicio SaaS_recortado.png](https://wiki.anjanadata.com/__attachments/a_d09945dd364769f31a0c7efbb4ae129fc4314b49d8e2fecbc611e98103282861/Servicio%20SaaS_recortado.png?cb=2abe5a80fe1ef645987bd7e33004dac7) This document aims to provide **transparency** and **confidence**to the customer regarding the architecture and security of the service without exposing details that could compromise Anjana Data SL's security posture. ## **2 Definitions** * **Instance**: complete and independent deployment of Anjana Data Platform (components, configuration, endpoints and associated resources). * **Environment**: operational classification (PRO, PRE, POC, DEV, TEST). In SaaS, each environment is typically implemented as an independent instance. * **PRO**: production environment (infrastructure sized for production). * **PRE**: non-production environment (validation/pre-production). ## **3 SaaS service reference architecture** ### 3.1 **Main components (high level)** Anjana Data Platform SaaS is deployed on cloud infrastructure with a "layered" segmentation model: * **Controlled entry layer**: UI/API access is centralized through a managed entry point (load balancer when applicable) protected by security controls (WAF and DDoS mitigation). * **Application layer in private network**: the platform components operate in private subnets, not directly exposed to the Internet. * **Managed data layer**: object storage (S3) and database (managed DB) sized according to the infrastructure profile. * **Operation layer** : periodic backups and recovery mechanisms with defined RPO/RTO objectives (**section 9** ). ## **4 SaaS packages and included environments** ### 4.1 **Packages offered and mapping to infrastructure profiles** SaaS packages consist of one or two instances (environments), each deployed with an infrastructure profile: |------------------|--------------------------------|--------------------------------| | **SaaS Package** | **PRO Infrastructure Profile** | **PRE Infrastructure Profile** | | Start | N/A | Base | | Productive (S) | Standard | PRE | | Productive (L) | Standard | PRE | | Scale (S) | Balanced | Base | | Scale (L) | Balanced | Base | | Grow | Balanced | Base | *Note: The functional limits of the package (for example, governed objects, plugins, identity integrations) are defined in the Licensing Model. This document defines technical and operational capabilities of the service.* ## **5 Infrastructure profiles (PRE / Base / Standard / Balanced)** ### 5.1 **Capabilities by profile** The infrastructure profiles define the technical sizing and high-availability capabilities, as well as backup/retention parameters. |----------------------------|-----------------------|-----------------------|-----------------------|-----------------------|-------------------------| | **Infrastructure profile** | **POC** | **PRE** | **Base** | **Standard** | **Balanced** | | Tenant | Shared | Private | Private | Private | Private | | Load balancer | Shared | Private | Private | Private | Private | | Subdomain | anjanadata.org | anjanadata.net | anjanadata.net | anjanadata.net | anjanadata.net | | Singlenode | 4-8vCPU 32GB 64GB HDD | 4-8vCPU 32GB 64GB HDD | 4-8vCPU 32GB 64GB HDD | | | | Core Node | ❌ | ❌ | ❌ | 4vCPU 20GB 64GB HDD | (4vCPU 20GB 64GB HDD)x2 | | Plugins Node | ❌ | ❌ | ❌ | 2vCPU 8GB 32GB HDD | 2vCPU 8GB 32GB HDD | | Indexer Node | ❌ | ❌ | ❌ | 2vCPU 4GB 32GB HDD | (2vCPU 4GB 32GB HDD)x3 | | Cloud S3 | ❌ | 64GB | 64GB | 128GB | 128GB | | Cloud DB | ❌ | 2vCPU 1GB 20-50GB HDD | 2vCPU 2GB 20-50GB HDD | 2vCPU 2GB 20-50GB HDD | 4vCPU 4GB 20-50GB HDD | | Managed MongoDB | ❌ | ❌ | ❌ | 1vCPU 2GB 16GB HDD | 1vCPU 2GB 16GB HDD | | Managed RabbitMQ | ❌ | ❌ | ❌ | 1vCPU 1GB 16GB HDD | 1vCPU 1GB 16GB HDD | | Managed Valkey | ❌ | ❌ | ❌ | 1vCPU 512MB | 1vCPU 512MB | | Backup | Daily | Daily | Daily | Daily | Daily | | Retention | 3 days | 3 days | 7 days | 7 days | 7 days | | RTO | 24h | 24h | 24h | 24h | 24h | | RPO | 24h | 24h | 24h | 24h | 24h | | Concurrent users | 15 | 15 | 100 | 500 | 500 | ### 5.2 **Sizing principles** * **PRE**: environment oriented toward validation and pre-production. * **Base**: robust non-production environment or low-load production environment, depending on package design. * **Standard**: production environment with separation of responsibilities (nodes) and sizing for higher loads. * **Balanced**: production environment with increased capacity and redundancy (replication/LB as per table). *Note: The "concurrent users" values reflect the profile's technical capacity guidance.* ## 6 **Security included by default (baseline)** All SaaS deployments incorporate a set of baseline security controls aimed at protecting availability, reducing the exposure surface and strengthening access control. ### 6.1 **Attack protection and traffic control** * **DDoS mitigation (AWS Shield Standard)**: automatic protection against network and application layer attacks, aimed at preserving availability. * **Web application filtering and protection (AWS WAF)**: rules to mitigate common attacks (e.g., injection and scripting) and bot control, applied to HTTP/HTTPS traffic. * **Domain management (Route 53)**: management of the service's DNS routing. *Objective: ensure that incoming traffic passes through an inspection and mitigation layer before reaching the application.* ### **6.2 Network isolation and minimal exposure** * **Private subnets:**the platform components are deployed in a private network, with no direct exposure to the Internet. * **Security Groups / traffic control:** strict control of inbound/outbound traffic, enabling only what is necessary for the service. * **Centralized entry:** external access is concentrated at a controlled entry point (load balancer when applicable), where the above controls are applied. *Objective: reduce the attack surface and avoid unnecessary exposure of internal components.* ### 6.3 **Access control and identity integrations** * **Zeus (authentication and authorization):** authentication/authorization layer compatible with multiple identity providers (e.g., LDAP, AD, cloud providers and others). *Objective: provide robust and flexible access control, aligned with the customer's corporate integrations (according to the package contracted in the Licensing Model).* ### 6.4 **Whitelisting at the web server level (when applicable)** * **Web server with whitelist:**ability to restrict access by authorized domains/IPs (configurable according to customer needs and their connectivity package). *Objective: reinforce the "allow only what is necessary" principle.* *The full technical detail of these controls (Shield, WAF, Security Groups, Zeus, whitelisting) is described at* *.* ## 7 **Additional connectivity and security (optional packages)** In addition to the security baseline (section 6), Anjana offers 4 optional models of additional private connectivity, designed to integrate the customer's network with the SaaS or to access plugins/sources deployed on their infrastructure: * **No AWS / On-Premise (Site-to-Site VPN):** ideal for on-premise, legacy or multi-cloud customers. * **Standard (AWS Transit Gateway)**: connectivity package; not to be confused with the "Standard" infrastructure profile in section 5. Ideal for hybrid AWS architectures with centralized integration. * **Premium A (AWS PrivateLink, Zero Trust at L4 level):** ideal for deployments with high requirements for private connectivity to the customer's plugins/sources, keeping the UI/API frontend under the standard baseline (it remains exposed to the Internet via Shield/WAF). * **Premium B (AWS PrivateLink, UI/API + plugins):** ideal for organizations with strict isolation requirements and no-Internet-exposure policies (Enterprise Ready). The full technical detail of each model (diagrams, deployment requirements, updated comparison table, including encryption in transit, and responsibilities per model) is provided at . ## 8 Usual operating regions The SaaS service is offered as standard in the following usual operating regions: * Europe (Frankfurt) - eu-central-1 * Europe (Spain) - eu-south-2 * US East (N. Virginia) - us-east-1 * US West (N. California) - us-west-1 * Europe (Ireland) - eu-west-1 (only WP) When the customer requests a different region, an "out-of-standard region" add-on may apply in accordance with the Licensing Model. Should the region come to be considered usual due to additional adoption, the cost-computation cessation policy defined in that model will apply. ## 9 Backups, retention and recovery (RPO/RTO) ### 9.1 **Backups and retention** Service backups are performed with the frequency and retention defined by the infrastructure profile (see table 5.1-A). ### 9.2 **Recovery objectives** * RPO (Recovery Point Objective): 24 hours. * RTO (Recovery Time Objective): 24 hours. The above objectives apply to the standard service. Higher requirements (lower RPO/RTO, extended retention or specific obligations) are treated as a special condition and/or add-on, subject to technical evaluation. ## 10 **Service operation (high level)** Anjana Data SL provides operation of the SaaS service in accordance with the scope defined in the Licensing Model (Managed Service), including: * Service operation and maintenance. * Planned updates. * Operational monitoring. *Note: Support details (channels, SLAs, hours) are governed by the current Support Policy (public document).* ## 11 **Customer responsibilities (SaaS)** The customer is responsible for: * Managing the use of the service in accordance with their licensing (governed objects, integrations, plugins, etc.). * Maintaining an administrative contact for operational notifications. * If contracting additional connectivity/security: meeting technical prerequisites under their control (e.g. configuration in their network/VPC or equivalent components). * Providing the information necessary for configuration (domains, [certificates](https://wiki.anjanadata.com/es/seguridad/26.1/mecanica-de-certificados) if applicable, identity systems) according to the contracted scope. * For specific responsibilities of each additional connectivity model contracted, see the responsibilities table at . --- version: "26.1" language: "es" --- # Solución técnica ## Introducción Este documento tiene por objetivo describir la solución técnica de la herramienta de ANJANA DATA. A lo largo del mismo se describen tanto a nivel general como por cada componente cada pieza que compone el ecosistema tecnológico de la solución. Anjana Data está construida sobre una arquitectura modular de última generación basada en microservicios, nativa Big Data y Cloud, API-first, sin vendor lock-in ni cajas negras en un ecosistema flexible, abierto y extensible ofreciendo total escalabilidad e interoperabilidad mediante el uso de tecnologías de código abierto consolidadas de última generación, así como servicios gestionados. ![att_36_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_a8e8836886275c29442e7dfe72dc074a7af6eab476af695be4cefde82c3ab71f/att_36_for_172000159.png?cb=8ad624781c976e8dcc2b93f61202c2f1) Uno de los valores diferenciales de Anjana Data radica en su **arquitectura orientada a microservicios**, totalmente escalable e interoperable con integración nativa extendida sobre multitud de tecnologías y plataformas de datos, con especial foco en aquellas tecnologías Big Data y nativas de Cloud. Además, gracias al diseño de su arquitectura y a las tecnologías utilizadas, Anjana Data ofrece una serie de capacidades en cuanto a**flexibilidad, adaptabilidad, customización, extensibilidad, escalabilidad e interoperabilidad** que la hacen una de las soluciones del mercado más punteras e innovadoras desde el punto de vista técnico. Así pues, Anjana Data permite la customización de la solución mediante parametría sin necesidad de desarrollo de código a la vez que ofrece un kit de recursos para el desarrollo de nuevos plugins y agentes para la integración con otras tecnologías y dispone de diferentes capas de APIs para la interacción bidireccional con los módulos de la solución. ![att_30_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_a0b954216be8628a0443634b5a875d4d1cca25382a0ff3ba72861f3dc8557a3f/att_30_for_172000159.png?cb=92ba9085883af27afef0e4884f7ec014) ![att_34_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_007780b4bf2fc03a5118f084e3ed0973993d653774d8e178b4bd448c539af4c3/att_34_for_172000159.png?cb=ee7f99f77865d4077db581eb449e05d2) Gracias a los distintos microservicios totalmente independientes pero integrados e interconectados entre sí, se consigue desacoplar las capacidades de las distintas capas y módulos de la solución a la vez que se garantiza una coherencia completa y una experiencia de usuario unificada para toda la plataforma. Desde el punto de vista operativo, **Anjana Data sitúa el gobierno del dato en el inicio de la cadena de valor del dato**, convirtiéndolo en la "ventanilla única" a partir de la cual se orquestan los diferentes procesos necesarios sobre las piezas correspondientes para garantizar la correcta gestión de un ecosistema de datos gobernado. Es por eso que la visión de integración de Anjana Data con las diferentes piezas de un ecosistema de datos va mucho más allá de las integraciones básicas y se incluyen los siguientes tipos de integración nativa que suponen un cambio de paradigma en el entendimiento de una solución de gobierno del dato. ![att_29_for_172000159.png](https://wiki.anjanadata.com/__attachments/a_3fb289fb19da296bab50830eb9a9203714b3641000e2639ac5a8c8e0cafcb5ef/att_29_for_172000159.png?cb=31831c5662634f9c2ceb88c428efef20) Gracias a todas estas integraciones con diferentes piezas del ecosistema de datos de una organización y a la filosofía de Anjana Data basada en la interoperabilidad, se pueden llegar a **automatizar multitud de procesos técnicos orquestados de forma gobernada a partir de la gestión de la demanda integrada en el gobierno del dato, abstrayendo así la gestión y el gobierno de los datos de las tecnologías de las plataformas de almacenamiento, procesamiento y explotación**. ## Inventario tecnologías open-source A continuación se detallan las tecnologías con las que se han implementado cada uno de los diferentes módulos que componen la solución Anjana Data. El lenguaje de programación utilizado ha sido Java 17 para el Backend. |-----------------------------|----------------------------------------------------------------------------------------| | **Tecnología** | **Más información** | | Angular | [++https://angular.io++](https://angular.io/) | | Spring Cloud | [++https://spring.io/projects/spring-cloud++](https://spring.io/projects/spring-cloud) | | Spring Boot | [++https://spring.io/projects/spring-boot++](https://spring.io/projects/spring-boot) | | LDAP | [++https://ldap.com++](https://ldap.com/) | | OAuth2 / SAML2 | [++https://oauth.net/2++](https://oauth.net/2/) | | PostgreSQL | [++https://www.postgresql.org++](https://www.postgresql.org/) | | MongoDB / Amazon DocumentDB | [++https://www.mongodb.com++](https://www.mongodb.com/) | | Apache SolR / OpenSearch | [++https://lucene.apache.org/solr++](https://lucene.apache.org/solr/) | | SeaweedFS / AWS S3 | [++https://github.com/seaweedfs/seaweedfs++](https://github.com/seaweedfs/seaweedfs) | | Valkey | [++https://valkey.io++](https://valkey.io/) | | RabbitMQ | [++https://www.rabbitmq.com++](https://www.rabbitmq.com/) | | Apache Zookeeper | [++https://zookeeper.apache.org++](https://zookeeper.apache.org/) | | Activiti | [++https://www.activiti.org++](https://www.activiti.org/) | | Swagger / OpenAPI | [++https://swagger.io++](https://swagger.io/) | | Grafana | [++https://grafana.com/++](https://grafana.com/) | --- version: "26.1" language: "es" --- # Arquitectura: Descripción general y componentes del stack tecnológico La arquitectura diseñada permite a Anjana Data Platform **gobernar diferentes tecnologías, clústeres y entornos** , y también la hace **independiente de las versiones de los productos** de cada fabricante: Para cada versión habrá un microservicio con las funciones específicas que puedan existir en cada una de ellas y en caso de necesitarlo se puede aislar para evitar incompatibilidades o problemas de seguridad. Con esto, Anjana Data Platform es la herramienta idónea para gobernar entornos y arquitecturas complejas, como puedan ser multi-cloud, híbridas, big data, AI-Ready, etc, y la hace estar preparada para las nuevas tecnologías, y/o nuevos usos de las tecnologías de la información que están por venir. De esta forma, Anjana Data Platform ofrece una versatilidad y agilidad de crecimiento que permite ofrecer nuevas versiones con capacidades ampliadas en periodos de tiempo muy cortos, así como una capacidad de personalización total para las funcionalidades mencionadas. La arquitectura técnica de Anjana Data Platform utiliza el stack de tecnología **Spring Cloud** en sus versiones más recientes incluyendo los módulos del producto correspondientes (Springboot, Eureka, Config, Security). Con el fin de lograr la máxima independencia con respecto a la tecnología / arquitectura, Anjana Data Platform también hace uso de un **repositorio para almacenar archivos o registros**. En este sentido, el stack tecnológico se puede agrupar en los siguientes bloques: ## **Microservicios basados en tecnologías Spring Cloud** * Las tecnologías de **Spring Cloud** utilizadas y la constitución del producto hacen viable la implementación de **alta disponibilidad** y **balanceo**en todos los puntos de la plataforma, muchos de los cuales son de facto redundantes debido a la tecnología utilizada y los requisitos mínimos de la plataforma. * Gracias a **Spring Cloud + Eureka** como gestor de registro y sincronización se constituye una estructura de microservicios dinámica y redundante, permitiendo una capa de personalización completa del sistema que **permite la deslocalización y el equilibrio** de prácticamente todos sus módulos, tanto internos como públicos. * A través del enfoque agnóstico ofrecido por la tecnología **Spring JPA** y la parte de personalización basada en **microservicios de Spring Boot**, estas piezas podrían sustituirse con facilidad por otras tecnologías con una funcionalidad similar. * Para **monitorizar** el ecosistema de microservicios, Anjana Data Platform utiliza un panel de administración web **Spring Boot Admin**, a través del cual se puede conocer el estado y las métricas detalladas de cada servicio, ser observado, fácilmente consumido por el usuario o integrado en una monitorización externa plataforma. * En relación a la **escalabilidad** , el uso de tecnologías altamente eficientes **multi-thread** y la posibilidad de escalado horizontal prácticamente ilimitado en cada uno de sus componentes críticos, hacen que el volumen inicial de usuarios concurrentes y conjuntos de datos gobernados sea muy alto. En cifras: con la configuración recomendada, se pueden servir un volumen de 700 usuarios y un número de 100.000 activos de datos sin necesidad de realizar colas. ### **Tráfico interno con api gateway** * Anjana Data Platform utiliza la**API Gateway** para redirigir el tráfico interno de una manera muy eficiente. Así, por ejemplo, los controladores encargados de realizar tareas de sistema de bajo nivel ( listar tablas, crear directorios, etc), no están dentro de los backends, sino que son invocados por los microservicios. * Este diseño permite evolucionar la herramienta, en caso de que cualquier controlador esté obsoleto, desmontando y reemplazando el servicio en cuestión de la forma más efectiva. ### **Front-end con angular** * Tanto el portal como el panel de administración presentan su capa de front-end construida en Angular * El uso de esta tecnología permite generar una interfaz amigable y totalmente operable por usuarios tanto técnicos como de negocio. * Completamente integrable con la tecnología de Back-end para ofrecer todas las funcionalidades que permitan un control completo de Anjana Data Platform y sus módulos ( portal de datos, linaje, auditoría, creación/modificación, data marketplace, workflows, etc..) * Portal de administración totalmente manejable que permite configurar Anjana Data Platform sin necesidad de escribir código o de acceder a bases de datos. ### **Tecnologías de almacenamiento** * El uso de tecnologías **open-source** bien consolidadas permite reducir costes logrando una alta fiabilidad, interoperabilidad y evolución. Anjana Data Platform utiliza **PostgreSQL y DocumentDB** para la capa de persistencia de datos y **Apache SolR/OpenSearch** como motor de búsqueda. * El **almacenamiento masivo** de registros al ser realizado en **SolR/OpenSerach**, una tecnología específica basada en una redundancia y escalabilidad, es prácticamente ilimitado y fácilmente configurable. * Gestión documental, ficheros de configuración y traducción almacenados en **SeaweedFS o AWS S3**, un servidor de almacenamiento que permite almacenar diversos tipos de datos estructurados y desestructurados. * La gestión de caches de forma compartida se realiza con **Valkey**, un gestor de caches accesible por todos los microservicios para reducir carga de memoria y latencias. * La gestión de carga asíncrona de trabajo se realiza con colas en **RabbitMQ** , un gestor de colas versátil y sencillo para no bloquear procesos innecesariamente**.** * La coordinación de procesos distribuidos se realiza de manera ágil y confiable gracias a la tecnología de**Apache Zookeeper**. ### **Autenticación y autorización** * Anjana Data Platform está diseñado para que el usuario pueda elegir sobre qué proveedor quiere autenticar y la autorización se hace con la configuración interna en base de datos configurable desde Portuno. * Protocolo LDAP: El módulo Zeus dispone de compatibilidad con servicio LDAP bien sea con esquemas OpenLdap o Active Directory. * Protocolo Oauth2 (OIDC Azure/AWS/GCP/Auth0). * Protocolo SAML2 (Azure/AWS/GCP/Auth0). ### BPM bajo estándar BPMN 2.0 Anjana Data Platform incorpora **Activiti** como BPM open-source totalmente integrado en la solución soportando estándar **BPMN2.0** gracias al cual se pueden diseñar e implementar workflows de validaciones totalmente customizados: * Los **workflows** se basan en el **modelo de roles, unidades organizativas y permisos** configurado y también está integrado con el módulo de alertas, mensajes y notificaciones para favorecer la colaboración entre los intervinientes. * En Anjana Data Platform están disponibles **workflows predefinidos** , pero también se pueden crear **workflows adicionales** para la validación de las distintas acciones realizadas en Anjana Data Platform (por tipo de objeto, por tipo de acción, por tipo de rol, por área de negocio, ...). * Para cada workflow se pueden configurar todos los **pasos de validación** (orden y rol/roles que validan) así como personalizar las **notificaciones** enviadas a los diferentes intervinientes para cada paso o incluso añadir **acciones específicas** soportadas por el estándar (ejecución de un script, lanzamiento de otra acción, envío de email, llamadas a APIs, ...). * Adicionalmente, se pueden configurar **workflows complejos basados en los valores** de los atributos de metadatos de un objeto (p.e. workflows distintos para activos que incluyan datos personales). * Todos los workflows con toda su información (pasos del workflow, estado, acciones, usuarios involucrados, etc) quedan **trazados**y pueden ser visualizados a través de la UI de Anjana Data Platform donde también se puede filtrar para visualizar sólo los workflows de interés y acceder al detalle de cada workflow. ### **Mecanismos de integración e interoperabilidad** En referencia a la **integración con diversas tecnologías**, Anjana Data Platform es completamente integrable e interoperable pudiéndose conectar con cualquier tecnología a través de los siguientes métodos: * **Plugins y Agentes** desarrollados por el equipo de Producto de Anjana Data Platform, los cuales ofrecen integraciones nativas sobre diversas tecnologías, cubriendo diferentes modalidades de funcionamiento y opciones de configuración (ver detalle en el catálogo de componentes por zona, más abajo). * **Plugins y conectores desarrollados ad-hoc**: Se proporciona un SDK (software development kit) que permite tanto a clientes como a partners desarrollar sus propios conectores de forma autónoma para implementar funcionalidades y usos requeridos específicos sin necesidad de alterar el producto. * Haciendo uso de las **diferentes capas de API** que proporciona Anjana Data Platform, tanto para importar como para exportar la información deseada así como para ejecutar acciones concretas en la aplicación. En este sentido, Anjana Data Platform cuenta con 3 capas de API: pública, administrativa y de configuración; cada una con un propósito específico y dirigida a unos perfiles diferentes. * **MCP (Model Context Protocol)**: módulo que permite a un Agente IA buscar, consultar y editar entidades, DSAs, adherencias y logs de auditoría de Anjana Data Platform en modo autoservicio (ver detalle en AI (BETA), más abajo). Además, se añade la capacidad de ejecutar **acciones personalizadas en la aplicación así como de lanzar scripts externos**, gracias a las siguientes alternativas: * Haciendo uso de un **interceptor**interno y su correspondiente SDK, el cual se provee con Anjana Data Platform * Mediante el uso del **módulo de BPM**, basado en Activiti, siguiendo el estándar BPMN 2.0, desde el cual, se puede definir cualquier tipo de workflow, en cuyos pasos se puede definir el lanzamiento de dichas acciones y/o scripts. * Haciendo uso de las **diferentes capas de API** que proporciona Anjana Data, de la misma manera que lo indicado anteriormente. En este sentido, el uso de las APIs puede ser orquestado por un planificador interno o ejecutarse a partir de triggers. En cuanto a los Plugins, estos permiten que Anjana Data Platform ejecute tanto acciones sobre los sistemas gobernados, como recuperar metadata e incorporar ésta en Anjana Data Platform permitiendo la importación asistida y automática de metadatos. ![Integración.svg](https://wiki.anjanadata.com/__attachments/a_5e42749ee55fbe7e49e10f6a5ab7e860eb1b2b7a56fb94a0c0460d8836d091d2/Integraci%C3%B3n.svg?cb=76ae0fa566e83673a32bebf3182f4f91) ### **API Restful con Swagger** Por último, para garantizar que Anjana Data Platform es 100% interoperable, toda la solución está totalmente Apificada con API Restful con Swagger. Así, Anjana Data Platform cuenta con tres capas de APIs que sirven a distintos propósitos: * **Pública**: La capa de API pública ofrece las funcionalidades de usuario para interactuar con Anjana, desde esta capa de API se puede acceder a los distintos módulos que ofrece la herramienta como son: Creación/modificación de objetos, linaje, histórico, auditoría, alertas y notificaciones y data marketplace. * **Administrativa**: Mediante la capa administrativa de API se puede gestionar el metamodelo en modo administrador, es decir, se pueden realizar modificaciones sobre el metamodelo (creación/modificación de objetos) sin necesidad de pasar por las validaciones definidas para los usuarios. * **Configuración**: Esta capa de configuración de API, permite gestionar la configuración de la herramienta en todas sus dimensiones: * Gestión de Unidades Organizativas, Roles y permisos. * Gestión de Usuarios. * Gestión de Objetos, workflows de validación y plantillas de atributos * Gestión de atributos y validaciones sobre atributos. * Gestión de filtros de búsqueda * Gestión de idiomas ### **Dashboarding** En cuanto a capacidades de reporting, Anjana Data Platform incorpora Grafana como herramientas open-source de autoservicio y reporting totalmente integradas en su stack de arquitectura. Dashboarding: El modelo de datos de Anjana Data Platform es abierto, de esta manera la información contenida en la herramienta se puede extraer para su uso en cualquier herramienta de Dashboarding, como Grafana, Azure PowerBI Google Looker o Amazon QuickSight, entre otras. Dashboarding con Grafana: Anjana Data Platform ofrece, en su integración nativa con Grafana la posibilidad de construir reportes y cuadros de mando a medida de forma autónoma y dinámica sin necesidad de programar mediante funciones como clicks y drag \& drops. Adicionalmente, Grafana aporta la capacidad de realizar análisis de series temporales y configuración de alertas en tiempo real que facilitan el seguimiento y gestión de la implantación del gobierno del dato así como de la calidad de los datos. ## **Componentes de la solución** A continuación se detalla cómo se agrupan los módulos de Anjana Data Platform en zonas funcionales. Las tecnologías subyacentes de cada uno ya se han descrito en las secciones anteriores. ![anjana_architecture_v7.svg](https://wiki.anjanadata.com/__attachments/a_ebc8a912246a1bddf3b1ab996c7711e09d50b77352785f221306a6aed502ecd2/anjana_architecture_v7.svg?cb=8b75db69a083119ac38e448da82c8bbc) ### **Web Zone** #### **Portuno UI** Es una solución basada en web construida sobre la arquitectura de microservicios que hace uso de tecnologías de código abierto bien consolidadas para ofrecer un portal de administración, el cual permite a los usuarios configurar el ecosistema de Anjana Data Platform. #### **Anjana UI** Es una solución basada en web construida sobre la arquitectura de microservicios que hace uso de tecnologías de código abierto bien consolidadas que ofrece una amplia gama de funcionalidades centradas en la gestión de catálogos y el autoservicio de los datos caracterizándose por un criterio de accesibilidad muy elevado y por un uso simplificado y colaborativo. ### **Control Zone** #### **Drittesta** Este módulo es la herramienta para recuperar información sobre el trabajo del ecosistema Anjana Data Platform, para proporcionar una respuesta y apoyo a los clientes de la plataforma. Estos datos serán enviados a un servidor externo de la infraestructura. ### **Integrations Zone** #### **Zeus** Módulo que proporciona autorización de servicios. De acuerdo con OAuth 2.0/SAML2, la especificación define un protocolo de delegación que es útil para transmitir decisiones de autorización a través de una red de aplicaciones y APIs habilitadas para la web. OAuth se utiliza en una amplia variedad de aplicaciones, incluido el suministro de mecanismos para la autenticación de usuarios. #### **Tot** Módulo encargado de la integración con diferentes tecnologías para la realización de las siguientes tareas: Creación de estructuras de datos exportando y cargando los metadatos requeridos en la plataforma de datos correspondiente, provisión de los roles y grupos a la plataforma de gestión de identidades, provisión de los permisos (grants y acls) necesarios en las ubicaciones de conjuntos de datos gobernados, ejecución básica de consultas al vuelo para visualización de muestreo de datos. También incluye los clientes necesarios para importar y/o inferir automáticamente los metadatos y el linaje estático de fuentes de información externas y cargarlos en KERNO. De esta forma, el usuario queda relevado de la tarea manual de imputación de metadatos en Anjana Data Platform para todas aquellas fuentes y tecnologías a partir de las cuales se ha desarrollado e integrado el correspondiente extractor. Como es un servicio externo desarrollado con microservicios en Spring Boot, se pueden agregar diferentes extractores para diferentes fuentes y tecnologías de forma incremental e independiente. Además, como está integrado con KERNO a través de la API Rest, los desarrollos de terceros se pueden utilizar para este propósito y alimentar a ANJANA CORE siempre que la información se proporcione de la forma en que KERNO espera recibirla. En algunos casos, la ejecución de estos procesos puede tardar demasiado, por lo que estas operaciones se definen de forma asincrónica, para evitar esperas innecesarias al usuario en la aplicación. La ejecución de estos procesos se realizará mediante el envío de solicitudes al módulo responsable, que se conectará a la fuente y cuando finalice la extracción y carga de los metadatos, se notificará al usuario. #### **TOT Plugins** Los plugins de TOT sirven para realizar las acciones que se desarrollarán a través de TOT, cada plugin actúa sobre una partición lógica resolviendo una conexión, puede lanzar varias acciones según las tecnologías implicadas y una tecnología puede tener más de un plugin según sus posibles usos. Los plugins disponibles pueden ser configurados y/o modificados para propósitos específicos o implementaciones ad-hoc a la vez que nuevos plugins pueden ser desarrollados y desplegados siguiendo los estándares recomendados por Anjana Data Platform. ### **API Zone** #### **Portuno** Es el módulo donde se centraliza toda la configuración de Anjana Data Platform y la información para el frontal web de Admin. En este módulo se realiza la gestión de las BBDD internas de Anjana Data Platform donde se almacena la configuración de la instancia y de los workflows diseñados que luego se ejecutan en Hermes. #### **Hermes** Este módulo es la herramienta de gestión de workflows de validación y está basado en el motor de Activiti. Activiti es el principal motor BPM de código abierto, ligero y centrado en Java, que respalda las necesidades de automatización de procesos del mundo real. Siguiendo el estándar de BPMN 2.0, ofrece un motor para diferentes procesos pudiendo configurar diferentes workflows de validación. #### **Kerno** Es el módulo básico de la arquitectura funcional, donde se incluyen las funcionalidades principales de la solución y las estructuras comunes a todos los módulos. #### **Minerva** Este módulo es la herramienta para centralizar, organizar e indexar todos los metadatos y auditoría del ecosistema de Anjana Data Platform. #### **Marketplace** Este módulo es la herramienta para centralizar, organizar y gestionar los activos para gestión de accesos. #### **Viator** Basado en Spring Cloud Gateway, es el punto de entrada de cualquiera de las APIs de Anjana Data Platform, tanto para cualquier usuario como para los frontales web o interna entre los microservicios. ### **Orchestration Zone** #### **Horus** Es un servicio de configuración central que sirve configuraciones desde un Secret Manager, Bases de Datos o desde git durante el arranque de los microservicios. Además está basado en Netflix Eureka donde se registran los microservicios al arranque y desde donde se puede conocer el estado de cada uno de ellos. Cuando un microservicio necesita conectar con otro, Horus le sirve el hostname y la IP actual de tal forma que se auto orquesta la interacción entre los microservicios de la arquitectura. ### **Storage Zone** Agrupa los módulos de persistencia, indexación, mensajería y cache ya descritos en la sección **Tecnologías de almacenamiento** más arriba (S3/SeaweedFS, PostgreSQL/DocumentDB, SolR/OpenSearch, RabbitMQ y Valkey). ### **AI** #### **MCP** Anjana Data ha apostado por el autoservicio de los clientes para consumir metadatos, auditoría y linaje, incluso alterarlos, en ADP. Para ello existe un módulo Beta que permite, con diferentes herramientas, que un Agente IA pueda buscar y consultar entidades, DSAs y logs de auditoría, explorar el linaje de una entidad, gestionar adherencias a DSAs, y crear, editar y enviar entidades a aprobación. --- version: "26.1" language: "es" --- # Modalidad IaaS/PaaS: Requisitos de infraestructura y recomendaciones Anjana Data proporciona varios kits de instalación: * 🆕 Instalador interactivo basado en servicio Java que guía en la instalación a través de una intefaz gráfica. * Kit de despliegue Ansible que facilita la implementación de la solución al tener automatizado paso a paso la instalación y levantamiento de cada microservicio que compone Anjana Data Platform. ⚠️ **Descontinuado (Fin de soporte Q4 2026)** * Kit Helm para despliegues basados en contenedores sobre K8S. ## Requisitos técnicos y de despliegue ### Sistemas Operativos y Tecnologías Soportadas * **Sistemas Operativos**: Ubuntu, RedHat. * **Bases de Datos Relacionales**: PostgreSQL, AWS RDS/Aurora PostgreSQL, AzureDB for PostgreSQL, GCP Cloud SQL for PostgreSQL, Embedded en VM. * **Persistencias S3**: AWS S3, SeaweedFS. * **Indexador**: SolR. * **Otros componentes**: Ansible, Python, Zookeeper. **Nota** : Todo el detalle acerca de las **versiones soportadas** está disponible en la [documentación de Ansible](https://wiki.anjanadata.com/es/instalacion/26.1/ansible-1) y en la [documentación de Kubernetes](https://wiki.anjanadata.com/es/instalacion/26.1/kubernetes). ### Requerimientos de Despliegue * Usuario con acceso **SSH** y permisos **root** en todas las máquinas y servicios gestionados provisionados. * **Conectividad requerida hacia:** * `https://releases.anjanadata.com` para descarga del instalador, artefactos y paquetes de software. * `https://veltesta.anjanadata.com` para activación y validación de licencias. * Entre los nodos con los servicios gestionados **RDS y S3**, si aplica. * Entre todos los nodos provisionados en arquitecturas **Standard y Balanced** , por **SSH**. * Desde nodos Anjana (**Zeus** ) hacia/desde los **sistemas de gestión de identidades** . Ver [documentación de Autenticación](https://wiki.anjanadata.com/es/integraciones/26.1/autenticacion). * Descarga de software desde los **repositorios del sistema operativo** (ver lista en la [documentación de los kits de Ansible](https://wiki.anjanadata.com/es/instalacion/26.1/ansible-1)). * **Acceso tras despliegue a portales:** * `443 → /login`, `/configpanel`, `/swagger/swagger-ui.html` * `8889 (SeaweedFS)` * `8983 (SolR)` * `9999 (Horus)` * En caso de BBDD gestionada: debe existir una base de datos llamada **anjana** y un usuario con permisos de creación. * En caso de S3 gestionado: deben existir **7 buckets** (`CDN`, `DSA`, `IMPORTS`, `TEXTAREA`, `WORKFLOWS`, `ANJANABACKUPS`, `ANJANALOGS`). * El despliegue se realiza mediante un **kit Ansible** ejecutado desde un nodo central. * La máquina que ejecute el kit Ansible debe disponer de **IP fija de salida a Internet**. * Arquitectura requerida: **x86_64 (Intel/AMD 64 bits)**. * Espacio en disco: todo montado en el directorio raíz, con uso de `/opt` y `/tmp`. En modalidad **SaaS Hybrid** , la conectividad específica de la máquina de plugins (puertos 15001+ hacia los sistemas de datos gobernados y el módulo Tot) se detalla en [Modalidad SaaS Hybrid: Requisitos de infraestructura y recomendaciones](https://wiki.anjanadata.com/es/solucion-tecnica/26.1/modalidad-saas-hybrid-requisitos-de-infraestructura-y-recomendaciones.md). ## Arquitecturas recomendadas Anjana Data proporciona diferentes configuraciones recomendadas basadas (pero no iguales) que tipos de entorno SaaS **Test, Base, Standard y Balanced**, que permiten adaptar el despliegue a distintos volúmenes de usuarios y datos. Estas arquitecturas están pensadas para garantizar: * Correcta distribución de cargas. * Escalabilidad y redundancia según la criticidad del entorno. * Integración con servicios gestionados de BBDD y almacenamiento S3. **NOTA:** todos los tamaños de disco indicados más abajo contemplan el espacio necesario para la instalación de paquetes del sistema, manejo de ficheros temporales, directorios de instalación, etc... Para el correcto funcionamiento del sistema, el total del espacio no puede dedicarse a la carpeta de instalación. Ex: /opt ### Infraestructura tipo Test (POCs) * 1 MV - 8 VCore \| 32 Gb RAM \| 64Gb SSD ### Infraestructura tipo Base * 1 MV - 8 VCore \| 32 Gb RAM \| 64Gb SSD * Managed S3 - 64 Gb ### Infraestructura tipo Standard * 1MV (Core) - 4VCore \| 20 Gb RAM \| 64 Gb SSD * 1MV (Plugins) - 2VCore \| 8Gb RAM \| 32 Gb SSD * 1MV (Indexer) 2VCore \| 4Gb RAM \| 32 Gb SSD * Managed S3 - 128 Gb * Managed RDB - 2VCore \| 2Gb RAM \| 50Gb SSD * Managed MongoDB - 1VCore \| 2Gb RAM \| 16Gb SSD (autogestionado si no hay equivalente en la nube) * Managed RabbitMQ - 1VCore \| 1Gb RAM \| 16Gb SSD (autogestionado si no hay equivalente en la nube) * Managed Valkey - 1VCore \| 512Mb RAM (autogestionado si no hay equivalente en la nube) **Nota:**Requerimientos para kit Ansible o binario Instalador en caso de que se despliegue en una VM aparte con requisitos mínimos 2vCPU \| 2GB RAM \| 32GB SSD ### Infraestructura tipo Balanced * 2MV (FrontBack) - 4VCore \| 20 Gb RAM \| 64 Gb SSD * 1MV (Plugins) - 2VCore \| 8Gb RAM \| 32 Gb SSD * 3MV (Indexer) - 2VCore \| 4Gb RAM \| 32 Gb SSD * Managed S3 HA - 128 Gb * Managed RDB HA - 4VCore \| 4Gb RAM \| 50Gb SSD * Managed MongoDB - 1VCore \| 2Gb RAM \| 16Gb SSD (autogestionado si no hay equivalente en la nube) * Managed RabbitMQ - 1VCore \| 1Gb RAM \| 16Gb SSD (autogestionado si no hay equivalente en la nube) * Managed Valkey - 1VCore \| 512Mb RAM (autogestionado si no hay equivalente en la nube) ## Certificados Todas las conexiones entre los componentes de **Anjana Data** se securizan mediante **SSL/TLS** con certificados gestionados por el cliente. El detalle completo de requisitos, nomenclatura de ficheros y procedimiento de entrega se encuentra en la documentación oficial: * 🔗 [Manual de despliegue con kit Ansible -- Plataformado de entorno](https://wiki.anjanadata.com/es/instalacion/26.1/manual-de-despliegue-1#Plataformado-de-entorno) * 🔗 [Mecánica de certificados en Anjana Data](https://wiki.portal.anjanadata.com/wiki/x/JgAVD) --- version: "26.1" language: "es" --- # Modalidad SaaS: Especificación técnica del servicio ## **1 Propósito y alcance** Este documento describe la **especificación técnica** del servicio **Anjana Data Platform SaaS**, incluyendo: * Perfiles de infraestructura (PRE, Base, Standard, Balanced) y sus prestaciones. * Paquetes SaaS ofrecidos y entornos incluidos (PRO/PRE). * Controles de seguridad incluidos por defecto (baseline) y principios de aislamiento. * Opciones adicionales de conectividad/seguridad. * Backups, retención y objetivos de recuperación (RPO/RTO). * Regiones habituales de operación. * Responsabilidades del proveedor y del cliente. ![Servicio SaaS_recortado.png](https://wiki.anjanadata.com/__attachments/a_f2aa0aec241f5f632b1acae1c346219a85ca555b453aed07c8156c410f1755f8/Servicio%20SaaS_recortado.png?cb=2abe5a80fe1ef645987bd7e33004dac7) Este documento tiene como objetivo dar **transparencia** y **confianza**al cliente sobre la arquitectura y seguridad del servicio sin exponer detalles que puedan comprometer la postura de seguridad de Anjana Data SL. ## **2 Definiciones** * **Instancia**: despliegue completo e independiente de Anjana Data Platform (componentes, configuración, endpoints y recursos asociados). * **Entorno**: clasificación operativa (PRO, PRE, POC, DEV, TEST). En SaaS, normalmente cada entorno se implementa como una instancia independiente. * **PRO**: entorno productivo (infraestructura dimensionada para producción). * **PRE**: entorno no productivo (validación/preproducción). ## **3 Arquitectura de referencia del servicio SaaS** ### 3.1 **Componentes principales (alto nivel)** Anjana Data Platform SaaS se despliega sobre infraestructura cloud con un modelo de segmentación "por capas": * **Capa de entrada controlada**: el acceso a UI/API se centraliza a través de un punto de entrada gestionado (balanceador cuando aplica) protegido por controles de seguridad (WAF y mitigación DDoS). * **Capa de aplicación en red privada**: los componentes de la plataforma operan en subnets privadas, no expuestos directamente a Internet. * **Capa de datos gestionada**: almacenamiento de objetos (S3) y base de datos (DB gestionada) dimensionados según el perfil de infraestructura. * **Capa de operación** : backups periódicos y mecanismos de recuperación con objetivos RPO/RTO definidos (**sección 9** ). ## **4 Paquetes SaaS y entornos incluidos** ### 4.1 **Paquetes ofrecidos y mapeo a perfiles de infraestructura** Los paquetes SaaS se componen de una o dos instancias (entornos), cada una desplegada con un perfil de infraestructura: |------------------|-----------------------------------|-----------------------------------| | **Paquete Saas** | **Perfil de infraestructura PRO** | **Perfil de infraestructura PRE** | | Start | N/A | Base | | Productive (S) | Standard | PRE | | Productive (L) | Standard | PRE | | Scale (S) | Balanced | Base | | Scale (L) | Balanced | Base | | Grow | Balanced | Base | *Nota: Los límites funcionales del paquete (por ejemplo, objetos gobernados, plugins, integraciones de identidad) se definen en el Modelo de Licenciamiento. Este documento define prestaciones técnicas y operativas del servicio.* ## **5 Perfiles de infraestructura (PRE / Base / Standard / Balanced)** ### 5.1 **Prestaciones por perfil** Los perfiles de infraestructura definen el dimensionamiento técnico y capacidades de alta disponibilidad, así como parámetros de backup/retención. |-------------------------------|-----------------------|-----------------------|-----------------------|-----------------------|-------------------------| | **Perfil de infraestructura** | **POC** | **PRE** | **Base** | **Standard** | **Balanced** | | Tenant | Compartido | Privado | Privado | Privado | Privado | | Balanceador | Compartido | Privado | Privado | Privado | Privado | | Subdominio | anjanadata.org | anjanadata.net | anjanadata.net | anjanadata.net | anjanadata.net | | Singlenode | 4-8vCPU 32GB 64GB HDD | 4-8vCPU 32GB 64GB HDD | 4-8vCPU 32GB 64GB HDD | | | | Nodo Core | ❌ | ❌ | ❌ | 4vCPU 20GB 64GB HDD | (4vCPU 20GB 64GB HDD)x2 | | Nodo plugins | ❌ | ❌ | ❌ | 2vCPU 8GB 32GB HDD | 2vCPU 8GB 32GB HDD | | Nodo Indexer | ❌ | ❌ | ❌ | 2vCPU 4GB 32GB HDD | (2vCPU 4GB 32GB HDD)x3 | | Cloud S3 | ❌ | 64GB | 64GB | 128GB | 128GB | | Cloud DB | ❌ | 2vCPU 1GB 20-50GB HDD | 2vCPU 2GB 20-50GB HDD | 2vCPU 2GB 20-50GB HDD | 4vCPU 4GB 20-50GB HDD | | Managed MongoDB | ❌ | ❌ | ❌ | 1vCPU 2GB 16GB HDD | 1vCPU 2GB 16GB HDD | | Managed RabbitMQ | ❌ | ❌ | ❌ | 1vCPU 1GB 16GB HDD | 1vCPU 1GB 16GB HDD | | Managed Valkey | ❌ | ❌ | ❌ | 1vCPU 512MB | 1vCPU 512MB | | Backup | Diario | Diario | Diario | Diario | Diario | | Retención | 3 días | 3 días | 7 días | 7 días | 7 días | | RTO | 24h | 24h | 24h | 24h | 24h | | RPO | 24h | 24h | 24h | 24h | 24h | | Usuarios concurrentes | 15 | 15 | 100 | 500 | 500 | ### 5.2 **Principios de dimensionamiento** * **PRE**: entorno orientado a validación y preproducción. * **Base**: entorno no productivo robusto o entorno productivo de baja carga, según diseño del paquete. * **Standard**: entorno productivo con separación de responsabilidades (nodos) y dimensionamiento para cargas superiores. * **Balanced**: entorno productivo con capacidad y redundancia incrementadas (replicación/LB según tabla). *Nota: Los valores de "usuarios concurrentes" reflejan orientación de capacidad técnica del perfil.* ## 6 **Seguridad incluida por defecto (baseline)** Todos los despliegues SaaS incorporan un conjunto de controles de seguridad base orientados a proteger disponibilidad, reducir superficie de exposición y fortalecer el control de acceso. ### 6.1 **Protección ante ataques y control del tráfico** * **Mitigación DDoS (AWS Shield Standard)**: protección automática para ataques de capa de red y aplicación, orientada a preservar disponibilidad. * **Filtrado y protección de aplicaciones web (AWS WAF)**: reglas para mitigar ataques comunes (p.ej., inyección y scripting) y control de bots, aplicadas al tráfico HTTP/HTTPS. * **Gestión de dominios (Route 53)**: gestión del enrutamiento DNS del servicio. *Objetivo: asegurar que el tráfico entrante pase por una capa de inspección y mitigación antes de llegar a la aplicación.* ### **6.2 Aislamiento de red y mínima exposición** * **Subnets privadas:**los componentes de la plataforma se despliegan en red privada, sin exposición directa a Internet. * **Security Groups / control de tráfico:** control estricto del tráfico entrante/saliente, habilitando únicamente lo necesario para el servicio. * **Entrada centralizada:** el acceso externo se concentra en un punto de entrada controlado (balanceador cuando aplica), donde se aplican los controles anteriores. *Objetivo: reducir superficie de ataque y evitar exposición innecesaria de componentes internos.* ### 6.3 **Control de acceso e integraciones de identidad** * **Zeus (autenticación y autorización):** capa de autenticación/autorización compatible con múltiples proveedores de identidad (p.ej., LDAP, AD, proveedores cloud y otros). *Objetivo: proporcionar control de acceso robusto y flexible, alineado con integraciones corporativas del cliente (según paquete contratado en el Modelo de Licenciamiento).* ### 6.4 **Whitelisting a nivel de servidor web (cuando aplica)** * **Servidor web con whitelist:**posibilidad de restringir acceso por dominios/IP autorizados (configurable según necesidades del cliente y su paquete de conectividad). *Objetivo: reforzar el principio de "permitir solo lo necesario".* *El detalle técnico completo de estos controles (Shield, WAF, Security Groups, Zeus, whitelisting) se describe en el* *.* ## 7 **Conectividad y seguridad adicional (paquetes opcionales)** Además del baseline de seguridad (sección 6), Anjana ofrece 4 modelos opcionales de conectividad privada adicional, pensados para integrar la red del cliente con el SaaS o para acceder a plugins/fuentes desplegados en su infraestructura: * **No AWS / On-Premise (VPN Site-to-Site):** ideal para clientes on-premise, legacy o multi-cloud. * **Standard (AWS Transit Gateway)**: paquete de conectividad; no confundir con el perfil de infraestructura "Standard" de la sección 5. Ideal para arquitecturas AWS híbridas con integración centralizada. * **Premium A (AWS PrivateLink, Zero Trust a nivel L4):** ideal para despliegues con requisitos elevados de conectividad privada hacia plugins/fuentes del cliente, manteniendo el frontal UI/API bajo el baseline estándar (permanece expuesto a Internet mediante Shield/WAF). * **Premium B (AWS PrivateLink, UI/API + plugins):** ideal para organizaciones con requisitos estrictos de aislamiento y políticas de no exposición a Internet (Enterprise Ready). El detalle técnico completo de cada modelo (diagramas, requisitos de despliegue, tabla comparativa actualizada, incluyendo cifrado en tránsito, y responsabilidades por modelo) se recoge en el . ## 8 Regiones habituales de operación El servicio SaaS se ofrece de forma estándar en las siguientes regiones habituales de operación: * Europe (Frankfurt) - eu-central-1 * Europe (Spain) - eu-south-2 * US East (N. Virginia) - us-east-1 * US West (N. California) - us-west-1 * Europe (Ireland) - eu-west-1 (only WP) Cuando el cliente solicite una región distinta, podrá aplicarse un add-on de "región fuera de estándar" conforme al Modelo de Licenciamiento. En caso de que la región pase a considerarse habitual por adopción adicional, aplicará la política de cese de cómputo del coste definida en dicho modelo. ## 9 Backups, retención y recuperación (RPO/RTO) ### 9.1 **Backups y retención** Los backups del servicio se realizan con la frecuencia y retención definidas por el perfil de infraestructura (ver tabla 5.1-A). ### 9.2 **Objetivos de recuperación** * RPO (Recovery Point Objective): 24 horas. * RTO (Recovery Time Objective): 24 horas. Los objetivos anteriores aplican al servicio estándar. Requisitos superiores (RPO/RTO menor, retención extendida u obligaciones específicas) se tratan como condición particular y/o add-on, sujeto a evaluación técnica. ## 10 **Operación del servicio (alto nivel)** Anjana Data SL presta operación del servicio SaaS conforme al alcance definido en el Modelo de Licenciamiento (Servicio gestionado), incluyendo: * Operación y mantenimiento del servicio. * Actualizaciones planificadas. * Monitorización operativa. *Nota: Los detalles de soporte (canales, SLAs, horarios) se rigen por la Política de Soporte vigente (documento público).* ## 11 **Responsabilidades del cliente (SaaS)** El cliente es responsable de: * Gestionar el uso del servicio conforme a su licenciamiento (objetos gobernados, integraciones, plugins, etc.). * Mantener contacto administrativo para notificaciones operativas. * En caso de contratar conectividad/seguridad adicional: cumplir prerequisitos técnicos bajo su control (p.ej. configuración en su red/VPC o componentes equivalentes). * Proporcionar la información necesaria para configuración (dominios, [certificados](https://wiki.anjanadata.com/es/seguridad/26.1/mecanica-de-certificados) si aplica, sistemas de identidad) según el alcance contratado. * Para responsabilidades específicas de cada modelo de conectividad adicional contratado, ver la tabla de responsabilidades en el . --- version: "26.1" language: "es" --- # Modalidad SaaS Hybrid: Requisitos de infraestructura y recomendaciones En la modalidad **SaaS Hybrid** , Anjana Data aloja y opera el núcleo de la plataforma (Core, Indexer y servicios gestionados) en su entorno SaaS. El cliente únicamente despliega en su propia infraestructura la **máquina de plugins**, encargada de conectar con los sistemas de datos gobernados de su organización. Esta página recoge los requisitos y recomendaciones específicos de esa máquina de plugins. Para el resto de requisitos generales de sistemas operativos, bases de datos y arquitecturas completas, consulta [Modalidad IaaS/PaaS: Requisitos de infraestructura y recomendaciones](https://wiki.anjanadata.com/es/solucion-tecnica/26.1/despliegue.md). ## Máquina de plugins: requisitos y recomendaciones ### Dimensionamiento recomendado * 1 MV (Plugins) - 2 VCore \| 8 Gb RAM \| 32 Gb SSD **Nota:** este dimensionamiento coincide con el nodo de Plugins de los perfiles Standard y Balanced descritos en [Modalidad IaaS/PaaS: Requisitos de infraestructura y recomendaciones](https://wiki.anjanadata.com/es/solucion-tecnica/26.1/despliegue.md). ### Requisitos de despliegue * Sistema operativo: **Ubuntu** o **RedHat**. * Arquitectura requerida: **x86_64 (Intel/AMD 64 bits)**. * Usuario con acceso **SSH** y permisos **root** en la máquina de plugins. * La máquina debe disponer de **conectividad de salida a Internet** hacia `https://releases.anjanadata.com` (descarga de artefactos) y `https://veltesta.anjanadata.com` (activación y validación de licencias). ### Conectividad * Desde los nodos de plugins (**puertos 15001+** ) hacia los sistemas de datos gobernados y hasta el módulo **Tot** . Ver [documentación de Plugins TOT](https://wiki.portal.anjanadata.com/wiki/spaces/doc/pages/171933699/Tot+Plugins?atlOrigin=eyJpIjoiYjI5YjJiZTMzMmE5NGYxN2JiMDRlMDNlMmM4ZmZmNzIiLCJwIjoiYyJ9). ### Certificados Las conexiones de la máquina de plugins también se securizan mediante **SSL/TLS** . Consulta el detalle completo de requisitos, nomenclatura de ficheros y procedimiento de entrega en la sección Certificados de [Modalidad IaaS/PaaS: Requisitos de infraestructura y recomendaciones](https://wiki.anjanadata.com/es/solucion-tecnica/26.1/despliegue.md). --- version: "26.1" language: "es" --- # Volumetrías de referencia Anjana Data Platform (ADP) necesita cinco servicios que no forman parte de la plataforma y que usted debe contratar y operar si elige tener ADP en modalidad "On Premise/Self Hosted: **PostgreSQL** , **MongoDB** , **Valkey** , **RabbitMQ** y **almacenamiento de objetos (S3)**. Esta página le dice qué contratar. No necesita hacer cálculos: identifique su situación en el paso 1 y lea las tablas del paso 2. Las recomendaciones de esta página están calibradas al nivel de nivel de criticidad del servicio que brinda ADP en la organización y buscan que el servicio sea **estable, mantenible y respaldado por su proveedor**, no que sobreviva a la pérdida simultánea de varias zonas de disponibilidad. Si su organización aplica por política un estándar superior a todos sus sistemas, puede elevarlo, pero ADP no lo exige. ## Paso 1. Identifique su perfil Elija la fila que mejor describa su situación **actual o prevista para los próximos 12 meses**. | Perfil | Elija este perfil si... | |--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **XS** | Está en fase de implantación. El uso está limitado al equipo de proyecto y a la oficina de gobierno: **menos de 30 personas**. | | **S** | El catálogo ya está en producción para los equipos de gobierno de sus primeros dominios, y quizá algunos consumidores de negocio. **Hasta unas 500 personas** lo usan de forma habitual. | | **M** | El catálogo está abierto a varias áreas de negocio además de los equipos de gobierno. **Entre 500 y 5.000 personas** lo usan de forma habitual. | | **L** | El catálogo está abierto al conjunto de la organización. **Más de 5.000 personas** lo usan de forma habitual. | **Dos advertencias importantes al elegir:** **No use la plantilla de su organización como referencia.** Lo que cuenta son las personas que van a usar la plataforma de forma habitual, no las que teóricamente tendrían acceso. Una organización de 60.000 empleados que abre la plataforma de gobierno y Marketplace a toda la plantilla suele tener unos pocos miles de usuarios habituales, no 60.000. Dimensionar sobre la cifra teórica multiplica el coste sin ningún beneficio. **Si duda entre dos perfiles, elija el mayor.** La diferencia de coste entre perfiles contiguos es pequeña y le evita una ampliación temprana. ## Paso 2. Contrate según su perfil Anjana **recomienda contratar estos servicios en modalidad gestionada** con su proveedor de nube (no instalarlos y mantenerlos usted). Obtiene soporte del fabricante, parcheo de seguridad, copias de seguridad automáticas y sustitución automática de nodos averiados. Esta es, con diferencia, la recomendación de mayor impacto de esta página: para una plataforma de esta criticidad, el valor está en no tener que operar la base de datos, más que en la redundancia. La instalación propia está soportada por ADP, pero el mantenimiento queda íntegramente de su lado. ### MongoDB | Perfil | Topología | vCPU | RAM | Disco | |--------|---------------------------------------|------|-------|--------| | **XS** | 1 nodo | 2 | 4 GB | 20 GB | | **S** | 3 nodos, en 2 zonas de disponibilidad | 2 | 8 GB | 20 GB | | **M** | 3 nodos, en 2 zonas de disponibilidad | 2 | 8 GB | 50 GB | | **L** | 3 nodos, en 2 zonas de disponibilidad | 4 | 16 GB | 100 GB | **Sobre los 3 nodos.** No es una recomendación de alta disponibilidad, sino la unidad mínima con la que trabajan los servicios gestionados de MongoDB: un despliegue de 2 nodos pierde la capacidad de escritura ante la caída de cualquiera de ellos, por lo que no es una opción intermedia real. En entornos de desarrollo, preproducción y en el perfil XS, un solo nodo es perfectamente válido. **Sobre el disco.** Es muy superior al volumen de datos real de forma deliberada: debe alojar los registros de replicación, los diarios de transacciones, los logs y el espacio temporal de las operaciones de mantenimiento. No lo reduzca. **Sobre la memoria.** ADP almacena en MongoDB un volumen de datos pequeño, de unos cientos de megabytes incluso en despliegues extensos. La memoria de la tabla no responde al volumen de datos, sino a las conexiones concurrentes y a los mínimos habituales del mercado. No necesita ampliarla porque crezca su catálogo. ### PostgreSQL PostgreSQL es la base de datos transaccional del núcleo de ADP: autorización de usuarios, motor de workflows, catálogo de activos, búsqueda y auditoría, consola de administración y acuerdos de intercambio de datos. Junto con MongoDB, es el componente cuya indisponibilidad afecta directamente a la consulta del catálogo y a los flujos de gobierno. | Perfil | Topología | vCPU | RAM | Disco | |--------|------------------------------------|------|------|------------------------------| | **XS** | 1 nodo | 2 | 2 GB | 20 GB (autoescalado a 50 GB) | | **S** | 1 principal + 1 standby (Multi-AZ) | 2 | 2 GB | 20 GB (autoescalado a 50 GB) | | **M** | 1 principal + 1 standby (Multi-AZ) | 2 | 2 GB | 20 GB (autoescalado a 50 GB) | | **L** | 1 principal + 1 standby (Multi-AZ) | 4 | 4 GB | 20 GB (autoescalado a 50 GB) | **Sobre el standby.** A partir del perfil S, active la réplica síncrona (Multi-AZ): a diferencia de MongoDB, PostgreSQL solo necesita un segundo nodo para lograr conmutación automática sin perder capacidad de escritura. **Sobre el disco.** Igual que en Mongo, el arranque en 20 GB con autoescalado a 50 GB es intencionadamente holgado: el volumen de datos real de ADP en Postgres es pequeño incluso en despliegues extensos. **Sobre la memoria.** La memoria de la tabla responde a las conexiones concurrentes de los distintos servicios de ADP que comparten esta base de datos, no al volumen de datos --- igual que en MongoDB, no la reduzca. La base de datos relacional debería de ser de uso exclusivo para ADP ya que los microservicios hacen un uso extenso de esta misma. En caso de querer compartir o aumentar su rendimiento se debe de escalar la base de datos a una que pueda aceptar más conexiones. ### Valkey | Perfil | Topología | RAM por nodo | |--------|-------------------------------------------------------|--------------| | **XS** | 1 nodo | 1 GB | | **S** | 1 principal + 1 réplica, en 2 zonas de disponibilidad | 1 GB | | **M** | 1 principal + 1 réplica, en 2 zonas de disponibilidad | 2 GB | | **L** | 1 principal + 1 réplica, en 2 zonas de disponibilidad | 4 GB | Es el único de los tres servicios que crece con el número de usuarios. Antes de cerrar el tipo de instancia, **compruebe que puede ampliarse al doble de memoria sin cambiar de familia ni de región**: así podrá absorber el crecimiento de usuarios sin migrar el servicio. La réplica evita que una avería expulse a todos los usuarios de su sesión. Si prefiere un solo nodo por coste, es una opción admisible siempre que acepte ese efecto. ### RabbitMQ | Perfil | vCPU | RAM | Disco | |------------------------|------|-----------|-------| | **Todos los perfiles** | 2 | 1 -- 2 GB | 20 GB | En la versión actual de ADP, RabbitMQ solo interviene al dar de alta un nuevo idioma de traducción. No participa en la operación diaria de la plataforma, por lo que su tamaño no depende del perfil. **Un solo servidor es suficiente**, incluido producción: una avería solo pospone el alta de un idioma, que es una operación administrativa y planificable. Solo tiene sentido plantearse un clúster si su política corporativa exige alta disponibilidad homogénea en todos los componentes. Tenga en cuenta que los tipos de instancia más pequeños no suelen admitir clúster, por lo que esa opción implica subir de gama sin que la capacidad lo requiera. ### Almacenamiento de objetos (S3) Anjana Data Platform usa almacenamiento de objetos (S3 o equivalente) para activos de interfaz, documentos de acuerdos de intercambio de datos, ficheros importados por los conectores, contenido de texto enriquecido del catálogo, definiciones y logs de workflows, copias de seguridad y logs de plataforma. A diferencia de los demás servicios, el almacenamiento de objetos **no requiere dimensionamiento previo**: escala automáticamente con el uso y se factura por consumo. No hay tabla de perfiles para este servicio. **Recomendaciones:** * Active políticas de ciclo de vida (lifecycle) en los buckets de logs y copias de seguridad, con expiración o transición a almacenamiento de menor coste, según su política de retención. Sin esta configuración, esos buckets crecen sin límite. * Fuerce acceso solo por HTTPS/TLS. * Active cifrado en reposo. * Mantenga buckets separados por entorno --- preproducción y producción no deben compartir bucket. ## Paso 3. Aplique estas recomendaciones de configuración Son independientes del perfil y se aplican en todos los casos. **Disponibilidad** * Reparta los nodos en **dos zonas de disponibilidad**. Es suficiente para ADP; no necesita una tercera. * En producción, **MongoDB, Valkey y PostgreSQL (a partir del perfil S) no deberían desplegarse en un solo nodo**: participan en la operación diaria y, además de la disponibilidad, un despliegue redundante le permite aplicar mantenimientos sin interrumpir el servicio. * **Pruebe la conmutación automática** antes de dar por aceptado el despliegue. No basta con configurarla. * Las ventanas de mantenimiento fuera de horario laboral son perfectamente aceptables para ADP. No necesita contratar niveles de servicio que las eviten. **Crecimiento** * Active el **escalado automático de almacenamiento** en MongoDB. * En PostgreSQL, active el escalado automático de almacenamiento, igual que en MongoDB. * En Valkey, fije un límite de memoria explícito en torno al 75 % de la memoria del nodo y una política de expulsión. Consulte con Anjana la política concreta: la plataforma mantiene en Valkey información que no debe expulsarse. **Copias de seguridad** * MongoDB: **copia diaria automática con retención de 7 días** es suficiente. La recuperación a un punto en el tiempo es un extra que puede activar si su proveedor la incluye, pero ADP no la requiere: el volumen de cambios entre copias es reducido y recuperable. * PostgreSQL: copia diaria automática con retención de 7 días es suficiente, igual que en MongoDB. * Valkey y RabbitMQ: no requieren estrategia de copia específica. **Seguridad** * Todos los servicios en **red privada, sin acceso público**. * Cifrado en tránsito (TLS) y en reposo. * Credenciales gestionadas en un servicio de secretos, con rotación periódica. **Entornos** * Aprovisione **preproducción y producción por separado**. No comparta instancias de MongoDB, PostgreSQL ni de RabbitMQ entre entornos. * En preproducción y desarrollo puede usar un solo nodo en todos los servicios. **Antes de contratar, verifique** * Que la modalidad y el tipo de instancia elegidos **están disponibles en su región** (no todas las opciones lo están en todas las regiones). * Que la **versión que ofrece su proveedor** es compatible con su versión de ADP y no está próxima a su fin de soporte. --- version: "26.1" language: "en" --- # Release Notes |------------------------------------------------------------------|-------------|---------------------------------|---------------------------|--------------| | **Version** | **GA Date** | **Status** | **Within support window** | **EOS Date** | | [26.1](https://wiki.anjanadata.com/es/release-notes/26.1) | 29/06/2026 | Latest release | ✅ | - | | [25.2](https://wiki.anjanadata.com/es/release-notes/25.2) | 29/10/2025 | Version within support window | ✅ | 29/10/2026 | | [25.1](https://wiki.anjanadata.com/es/release-notes/25.1) | 28/05/2025 | Version in EOS (End of Support) | ❌ | 29/05/2026 | | [23.1](https://wiki.anjanadata.com/es/versiones-pasadas/current) | 24/04/2024 | Version in EOS (End of Support) | ❌ | 28/05/2025 | Definitions: * **"Next Release".** The next version to be released. * **"Latest Release".** The latest **YY.N** Version released by Anjana Data and, if any, its **latest active Patch**. * **"GA (General Availability)".** Date from which a Version is considered released for general use. * **EOS (End of Support):** End of support. For further detail, see the [Anjana Data Support Policy](https://wiki.anjanadata.com/es/portal-de-soporte/current/politica-de-soporte-de-anjana-data) 26.1 Patch 2 - 25/08/2026 ## 26.1 Patch 2 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.0.1** | **6.1.0** | |-------------------|-----------------------------|--------------------------------------------|---------------------------------------------------------------------|-------------------------------|------------| | ***marketplace*** | ***inventory-interceptor*** | ***tot*** ***anjana-ui*** ***portuno-ui*** | ***hermes*** ***horus*** ***portuno*** ***viator*** ***drittesta*** | ***kerno***🆕 ***minerva***🆕 | ***zeus*** | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | **5.2.1** | |-------------------------------------------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------| | **tot-plugin-databricks** **tot-plugin-** ***snowflake***🆕 | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3*** **tot-plugin-** ***azure-ad*** **tot-plugin-** ***azure-storage*** **tot-plugin-** ***gcp-iam*** **tot-plugin-jdbc-snowflake** | **tot-plugin-** ***aws-glue*** **tot-plugin-** ***aws-iam*** **tot-plugin-** ***gcp-bigquery*** **tot-plugin-** ***gcp-storage*** **tot-plugin-** ***jdbc*** **tot-plugin-** ***jdbc-oracle*** **tot-plugin-** ***jdbc-redshift*** **tot-plugin-** ***jdbc-sqlserver*** **tot-plugin-** ***ldap*** **tot-plugin-** ***powerbi*** **tot-plugin-** ***tableau*** | **tot-plugin-** ***jdbc-denodo*** | #### AI | **1.0.1** | |-----------------| | ***adp-mcp***🆕 | #### Installers | ***Ansible*** | ***K8S*** | ***Installer*** | |------------------|-----------|-----------------| | 26.a1.1788858836 | 26.k1 | 1.0.1 | ### **Updates** #### Minerva The connection client between the platform indexing module and the search engine has been modernized, migrating to the HTTP/2-based implementation supported by the current versions of Solr. The change aligns the platform with the engine version incorporated in 26.1, removes deprecated connection components and improves search stability during indexing schema update operations. #### Kerno An error has been fixed whereby, when approving the modification of a dataset, the fields referenced in attributes of type ENTITY_CONTAINER, ENTITY_SEARCH or ARRAY_ENTITY stopped appearing in the content. Modified fields now retain their identity after the flow is approved, applying the same behaviour that the parent DATASET already had, so that existing references in the aforementioned attribute types remain valid. The search index update of the affected objects is also completed when fields of the associated dataset are modified or deleted, preventing them from showing outdated information. The patch includes an automatic repair process for the attributes that may have been affected in existing environments. Related bug: **D13131** #### ADP-MCP An error in the MCP server login flow has been fixed whereby certain users could not complete authentication and received a generic authentication error message. Error traceability in the logs has also been improved. In addition, the authorization flow is reinforced with mandatory PKCE (S256), together with other security improvements. It is recommended to deploy this version of the MCP server. Related bug: **DS4920** #### Tot-Plugin-Snowflake A new integration plugin for **Snowflake** is released, based on the **Snowflake SQL API** and **OAuth2 authentication with Microsoft Entra ID** (External OAuth), which replaces the previous plugin based on a JDBC connector. In addition to metadata extraction and data sampling ---now with support for tables, views and materialized views, and retrieval of native Snowflake tags, including those inherited from ancestor assets---, the new plugin extends the functional scope with **access permission management**: creation and management of roles associated with Data Sharing Agreements and automatic granting and revocation of consumption privileges on the governed assets. Permission management requires the Entra ID plugin deployed and Azure SSO enabled. With the release of this plugin, the **Snowflake plugin via JDBC is deprecated**. It will remain available throughout the 26.1 lifecycle, but will not receive new features or updates, so it is recommended to plan the migration to the new plugin as soon as possible. More information in the plugin documentation: [Snowflake (Native API)](https://wiki.anjanadata.com/en/integraciones/26.1/snowflake-native-api.md) ### **Bugs** All the information relating to the problems and limitations that apply to this version or that have been fixed is available in the documentation under **Support portal \> Known problems and limitations** [Known Issues and Limitations](https://wiki.anjanadata.com/en/portal-de-soporte/current/known-issues-and-limitations.md) . 26.1 Patch 1 - 17/08/2026 ## 26.1 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.1.0** | |-------------------|-----------------------------|--------------------------------------------|-----------------------------------------------------------------------------------------------|------------| | ***marketplace*** | ***inventory-interceptor*** | ***tot*** ***anjana-ui*** ***portuno-ui*** | ***hermes*** ***horus*** ***portuno*** ***viator*** ***kerno*** ***minerva*** ***drittesta*** | ***zeus*** | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | **5.2.1** | |---------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| | **tot-plugin-databricks** | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3*** **tot-plugin-** ***azure-ad*** **tot-plugin-** ***azure-storage*** **tot-plugin-** ***gcp-iam*** **tot-plugin-jdbc-snowflake** | **tot-plugin-** ***aws-glue*** **tot-plugin-** ***aws-iam*** **tot-plugin-** ***gcp-bigquery*** **tot-plugin-** ***gcp-storage*** **tot-plugin-** ***jdbc*** **tot-plugin-** ***jdbc-oracle*** **tot-plugin-** ***jdbc-redshift*** **tot-plugin-** ***jdbc-sqlserver*** **tot-plugin-** ***ldap*** **tot-plugin-** ***powerbi*** **tot-plugin-** ***tableau*** | **tot-plugin-** ***jdbc-denodo***🆕 | #### AI | **1.0.0** | |---------------| | ***adp-mcp*** | #### Installers | ***Ansible*** | ***K8S*** | ***Installer*** | |---------------|-----------|-----------------| | 26.a1 | 26.k1 | 26.1 | ### **Updates** #### Denodo plugin Evolution of the plugin's functionality in the permissions granting flow to grant and revoke CONNECT permission on the Virtual Database (GRANT CONNECT, REVOKE CONNECT). More information in the plugin documentation [Denodo](https://wiki.anjanadata.com/en/integraciones/26.1/denodo.md) ### **Bugs** All the information relating to the problems and limitations that apply to this version or that have been fixed is available in the documentation under **Support portal \> Known problems and limitations**. 26.1 GA - 29/06/2026 ## 26.1 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.1.0** | |---------------------|-----------------------------|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------|--------------| | ***marketplace***🆕 | ***inventory-interceptor*** | ***tot***🆕 ***anjana-ui***🆕 ***portuno-ui***🆕 | ***hermes*** 🆕 ***horus*** 🆕 ***portuno*** 🆕 ***viator***🆕 ***kerno***🆕 ***minerva***🆕 ***drittesta***🆕 | ***zeus***🆕 | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | |-----------------------------|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **tot-plugin-databricks**🆕 | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3***🆕 **tot-plugin-** ***azure-ad***🆕 **tot-plugin-** ***azure-storage***🆕 **tot-plugin-** ***gcp-iam***🆕 **tot-plugin-jdbc-snowflake**🆕 | **tot-plugin-** ***aws-glue***🆕 **tot-plugin-** ***aws-iam***🆕 **tot-plugin-** ***gcp-bigquery***🆕 **tot-plugin-** ***gcp-storage***🆕 **tot-plugin-** ***jdbc***🆕 **tot-plugin-** ***jdbc-denodo***🆕 **tot-plugin-** ***jdbc-oracle*** 🆕 **tot-plugin-** ***jdbc-redshift***🆕 **tot-plugin-** ***jdbc-sqlserver*** 🆕 **tot-plugin-** ***ldap***🆕 **tot-plugin-** ***powerbi***🆕 **tot-plugin-** ***tableau***🆕 | #### AI | **1.0.0** | |-----------------| | ***adp-mcp***🆕 | #### Installers | ***Ansible*** | ***K8S*** | ***Installer*** | |---------------|-----------|-----------------| | 26.a1🆕 | 26.k1🆕 | 26.1🆕 | ### **Required manual actions** #### **Before the upgrade** * Update the deployment kit to its latest version, if not done yet. Review the specific documentation of the kit versions. * If any installation kit provided by Anjana Data is used, in order to have the software fully updated it is only necessary to update the artefact versions with the values mentioned in the previous section [++Affected artefacts++](https://docs.google.com/document/d/1h6PHJkv9NiT0FLoM_0-BgqUxAbqvzNQsRUWgdLEzR4Y/edit#heading=h.xwcis16s9c8e); the software takes care of the database changes. Only otherwise, the persistence versions will have to be updated to their latest production version, manually by the installer. #### **Before considering the upgrade complete** During the initial startup, Portuno migrates the configuration from the old Administration Portal to the new one (from PostgreSql to documentsDB). Once Portuno appears as UP in Horus, it is necessary to **restart the platform** from the installer in order to run the liquibase of each microservice that depends on the Portuno configuration. To verify that the above has been executed successfully: * Access the database and verify that the **databasechangelog** tables of the **anjana, hermes, minerva** , **portuno** and**zeus** schemas contain records corresponding to the 26.1 liquibase. To do so, filter the **filename** column by `filename like ('%/26.1/%')` * Access documentsDB and verify: * The **DATASABECHANGELOG** table is available with the records of `db/migrations/26.1/` ![image-20260727-093213.png](/__attachments/a_31d799192f7546c98b538764c31bbcf6e4d8a31b9bed726ceb3ab991086fe5dd/image-20260727-093213.png?cb=997877fa3042c52737ee6efb0d0eb512) * The **BATCH_JOB_EXECUTION** table is available and contains 2 records, one corresponding to the migrations of the i18n translation records and appConfigurations, and another one for the insertion of the default translations, both in status **COMPLETED** ![image-20260727-093435.png](/__attachments/a_8d029cee0ae602dddd37d829974fde150a5789ea382eb6975e6705cd341f7553/image-20260727-093435.png?cb=70765898a4fd4477f1c789fc50ada47b) ### **Optional manual actions** * If weightings were set in SolR, they will probably have to be regenerated given the volatile nature of the indexer * It is recommended to include the #REQUEST_REASON# variable in the body of the notifications associated with workflow alerts, so that the participants receive the texts associated with the request reason that is incorporated for all workflows in this version. * If notifications have been configured with an external provider (for example, via email), it is advisable to review the Notifications configuration in the Administration Panel in order to keep receiving them. By default, the migration leaves the EXTERNAL_SENDING field empty, so notifications will not be received. * From the new administration portal: * Reindex everything. * Review the Authentication mechanisms implemented and assess the migration of those that have been deprecated in this version before their expiry in 26.2. ### **Updates** Update in the deployment kits: #### **Ansible** ##### **Blocking changes** * **New deployment role for MongoDB 7.0** * **New deployment role for RabbitMQ 3.12** * **New deployment role for Valkey 7.2**and connection strings for new persistences: MONGO_URI, VALKEY_\*, RABBITMQ_\* * **New deployment role for the marketplace microservice** (port 8089), includes the creation of its schema in PostgreSQL during the update ###### **Other changes and optimizations** * Eureka and Spring Boot Admin URLs configured through environment variables (HORUS_REPLICAS, HORUS_ADMIN_URL, TOT_EUREKA_URL) in the systemd units, instead of Spring arguments * Variables in hosts.yaml for single-node and multi-node deployments * TLS certificate backup included in the Ansible backup * Correction of names in service templates * Correction of S3 properties * HTTP security headers added to the Apache VirtualHost, removal of the obsolete Swagger proxy and replacement of the MD5 trace ID with `Apache UNIQUE_ID` * Grafana exposed through the Apache proxy at `/grafana` (port 443) * JVM memory model aligned: `MaxRAMPercentage` + `systemd MemoryMax` instead of `Xmx` (fixed) * Solr: `SOLR_HEAP` replaced by `SOLR_JAVA_MEM`, with `GC_TUNE` set explicitly * systemd dependencies (`After=`/`Wants=`) between core services and plugins for an ordered startup * Compatibility with RHEL 9 and Ubuntu 24.04 (Python 3.12, pymongo 4+, Remi repository, PPA) for the new MongoDB, Valkey and RabbitMQ persistences * Idempotency improvements in the installation roles (Solr, artefact copy, SHA1 check of downloads) to allow safe re-runs of the playbook * New `delete-solrzk` and `delete-minio` tags for selective uninstallation * New warnings in `anjana.sh` indicating the mandatory steps to deploy MongoDB, RabbitMQ and Valkey before updating the microservices ##### **K8s Kit** ###### **Blocking changes** * **Complete restructuring of the kit:**from flat YAML manifests (122 files) to a Helm chart with anjana-core and anjana-plugins subcharts (11 reusable templates). Deployment via helm install/upgrade * **TLS automated with cert-manager:**internal mode (auto-generated self-signed certificates + truststore generation Job) and manual mode (pre-created secrets) * **IRSA support for Horus:**integration with AWS Secrets Manager as config server backend, with validation guard rails * **Multiple config server backends:**AWS Secrets Manager, Git or pure JDBC mode (Horus own credentials via Kubernetes Secret), selectable via values.yaml * **Standalone mode for plugins:**direct reading of cloud secrets (AWS SM, Azure KV, GCP SM) without the need for a config server * **Optional manifests for new persistences:**MongoDB, RabbitMQ, Valkey * **Migration from MinIO to SeaweedFS** as S3/CDN storage backend: new seaweedfs.yaml manifest replaces minio.yaml * **InitContainers to wait for dependencies:**ordered service startup with HTTPS health checks between them ###### **Other changes and optimizations** * Eureka and Spring Boot Admin URLs configured through environment variables (HORUS_REPLICAS, HORUS_ADMIN_URL, TOT_EUREKA_URL) instead of Spring arguments * Native OpenTelemetry integration: OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES injected into all services * AES backend scripts * extraCaBundles support in the truststore Job to inject additional CAs (e.g. corporate CA) * Resource profiles per environment (DEV/PRE/PRO) with automatic selection via global.environment.profile * HTTP security headers in the nginx ConfigMaps, login rate limiting on /gateway/public/, X-traceId forwarding to the backends and to portuno-ui, CORS restriction in viator via global.domain, and removal of the obsolete Swagger proxy * Loading page for anjana-ui with the health status of the services (HEALTH_LOCATIONS_CONF / HEALTH_MANIFEST_JSON) * Solr: default storage changed from emptyDir to hostPath * Auto-generated documentation with helm-docs, integrated into a Makefile target * Multiple chart validation and runtime behaviour corrections following E2E tests on EKS (database schemas, keystore/truststore in manual mode, resources, health checks) Update on the platform: #### **Anjana Data Platform MCP** Version 26.1 incorporates the Anjana Data Platform **MCP (Model Context Protocol)** , which exposes the platform capabilities through the MCP protocol for integration with AI assistants and agents. It is available for both **SaaS** and **IaaS/PaaS** deployments. The Anjana Data Platform MCP is released as a **new feature that may contain errors**. Before using it, please note that: * It is a **new and still barely tested** feature, which **may present failures** or unexpected behaviours. * It is offered **\<\\>** , with no guarantees of stability or completeness, and **its use in critical production processes is not recommended**. * **It is not covered by the** [**Anjana Data Support Policy**](https://wiki.anjanadata.com/es/portal-de-soporte/current/politica-de-soporte-de-anjana-data): the commitments regarding incident resolution, delivery of *fixes* and response times described in that policy do not apply to it. * We welcome **feedback** from those who use it: your comments will help us stabilize and evolve the feature in upcoming versions. * **Availability:** **SaaS** and **IaaS/PaaS** deployments. #### **Extension of the Power BI plugin capabilities** The Power BI Tot Plugin incorporates access management over the Power BI assets catalogued in **Anjana Data Platform** . The feature allows effective permissions in Power BI to be granted and revoked based on the lifecycle of a **DSA** , using **Azure Entra ID** groups as the only authorization unit. #### **New plugin for metadata extraction over Databricks** In its **Phase 1** , the integration enables the **discovery and extraction of technical metadata** (*read-only* mode) of the assets available in **Unity Catalog**, without performing any mutation on the source system. #### **Expand and set application permissions** From this version onwards, access to all **modules** and access to the **tabs** of the object view depend on **permissions**associated with the user's role. This makes the permission configuration more complex but provides greater access granularity, simplifying access to information by user groups. To this end, the following **viewing** permissions will be added: * Access to the Catalogue module: CATALOG_ACCESS * Access to the Jobs module: JOBS_ACCESS * Access to full security Audit: SEC_AUDIT_ACCESS ![warning](https://wiki.anjanadata.com/__attachments/a_8d662b3568361b7175a748faf07bb54607237e196b468db220046830fc2f0254/atlassian-warning?cb=14432459925d605e05cae2605cdfe666) *Permission created but without functional capability until release 26.2, planned for Q3 2026* * Access to full governance Audit: GOV_AUDIT_ACCESS * Access to the personal Workspace: WORKSPACE_ACCESS * Access to the Relationships tab of an entity: OBJ_RELATIONS_ACCESS * Access to the Stakeholders tab OBJ_STAKEHOLDERS_ACCESS * Access to the object Audit tab (OBJ_AUDIT_ACCESS) * Access to the Versions tab: OBJ_VERSIONS_ACCESS * Access to the Data sample tab OBJ_SAMPLE_DATA_ACCESS * Access to the Adherence information in the stakeholders tab ADHERENCE_VIEW A new permission is also included to edit the Access information received by adhered users: EDIT_ACCESS_INFO (action) ALL (subType) ##### Changes in existing permissions: * The ACCESS ALL permission to access the data portal is replaced by the PLATFORM_ACCESS (action) permission with subType ANJANA. * The ADMIN (action) ANJANA (subType) permission for the configuration/administration panel is replaced by ADMIN_ACCESS (action) ANJANA (subType) * The WIZARD (action) ALL (subType) permission is removed. The creation wizard will be accessed through the creation permissions (CREATION_MODIF) over any subType. * The ACCESS (action) ADHERENCE (subType) permission to grant access to data is updated to ADHERENCE_ACCESS (action) ALL (subType). This permission also grants access to the new Marketplace module. #### **Workflow evolutions** ##### **Add request reason for any workflow** All workflows will be completed with the request reason, just as previous versions did with adherence workflows. To this end, when the user chooses or confirms an action that triggers a workflow, Anjana Data Platform will show a window where the user can enter the reason in at least one of the application languages. The texts can be consulted from the workflow screens and in the notifications by using the #REQUEST_REASON# variable. It is suggested to include this variable in the body of the workflow notifications, thus ensuring that the users involved receive it. ##### **New workflow screens** From now on, the following screens will be available: 1. **My access requests** 🆕 : Provides access to adherence workflows requested by the user themselves ++Access restriction++: Only available for users who either have ADHERENCE permissions, or have been Requesters in an ADHERENCE workflow. 2. **My governance requests** 🆕 : Provides access to governance workflows requested by the user themselves, except for adherence workflows. ++Access restriction++: Only available for users who either have CREATION_MODIF, CHANGE_OU, CHANGE_OU or DEPRECATION permissions, or are users who have been Requesters in a CREATION, MODIFICATION, ACTIVATION, DEACTIVATION, RENAMING or TRANSFER workflow. 3. **My Tasks** 🆕 : Provides access to workflows that the user has to validate due to their role. ++Access restriction++: Only available for users who are Validators in a workflow. 4. **Workflows** : Provides access to the complete set of workflows. ++Access restriction++: Only available for users whose role has WORKFLOW_ACCESS permissions When a user receives a validation notification, they will always be able to access the workflow to approve or reject it from the notification, from the My Tasks screen or from the complete list of Workflows (only if they have the WORKFLOW_ACCESS permission). **More information on the workflow screens** The information displayed on the workflow screens has been enriched, so from now on it includes: * Object * Request type * Requester * Reason * Request date * Validation status * Last participant * Last response * Time without response * Total duration Some attributes may be omitted on certain workflow screens due to their redundancy. For example, on the "My governance requests" screen the "Requester" is not shown, since that field always corresponds to the user accessing it. #### **User interface evolutions** ##### **Home page** A home page is included as the entry point for users after logging in, and it will be accessible from the Anjana Data Platform and customer logos in the header. This home page includes: * A search engine that allows searches in the Catalogue or in the Marketplace * Activity summary with a date range selector (7 days, 30 days, 3 months, 6 months and 1 year) * My access requests * My governance requests * My tasks * Quick access to: * Creation wizard * Personal workspace * Date of the previous login. #### **Marketplace Portal** A new module called Marketplace is created, intended to be a portal for consumers to search for and request access to assets available for consumption through Data Sharing Agreements (DSA). The Marketplace first offers a **suggestions** space where the consumer can view recently added DSAs and the assets most requested by other users. It then offers a space for asset discovery through a search engine and filters, with an intuitive and agile experience supported by the following capabilities: * Save highlighted searches with the option to select one as a favourite. * Option to request immediate access or add to the cart for bulk requests * Bulk selections of objects to add to the cart * Bulk selections to add to the personal workspace * Preview the details of an object * Consult access information #### **Platform contract and terms of use** When logging in for the first time in this version, the user will be shown a terms of use contract for the platform which must be accepted in order to continue using it. #### Access Information on objects Users who are adhered to an object will be able to access its access information, where instructions can be included on how to access the physical asset that the object represents. Only those with EDIT_ACCESS_INFO can modify the access information. Update in the API: SUMMARY: 43 added · 43 removed · 22 DEPRECATED ### KERNO #### ✨ New Endpoints (5) PUT /api/admin/kerno/clear-all (AdminAPIController) POST /api/common/v1/massiveSubmit/{objectSubType} (CommonController) POST /api/entity/v1/rename/{objectSubType}/{idObject} (EntityController) POST /api/relationship/v1/rename/{objectSubType}/{idObject} (RelationshipController) POST /api/dataset/v1/structure/{idDataset} (DatasetController) #### ❌ Removed Endpoints (33) PUT /api/admin/kerno/name/{objectType} (AdminAPIController) POST /api/v2/attribute/custom/list (AttributeController) GET /api/v2/common/stakeholders/{objectType}/{objectSubType}/{idObject} (CommonV2Controller) POST /api/v2/common/massiveSubmit/{objectSubType} (CommonV2Controller) POST /api/v1/metadata/requests (MetadataController) POST /api/v1/metadata/requests/detail (MetadataController) GET /api/v1/dataset/versions/{idObject} (DatasetController) GET /api/v1/dsa/versions/{idObject} (DsaController) GET /api/v1/dsa/datasets/{idObject} (DsaController) POST /api/v1/dsa/datasets/{idObject} (DsaController) GET /api/v1/instance/versions/{idObject} (InstanceController) GET /api/v1/instance/project/{idObject} (InstanceController) GET /api/v1/instance/solutions/{idProcessInstance} (InstanceController) GET /api/v1/process/versions/{idObject} (ProcessController) GET /api/v1/process/instances/{idProcess} (ProcessController) GET /api/v1/solution/versions/{idObject} (SolutionController) GET /api/v1/solution/instances/owned/{idObject} (SolutionController) GET /api/v1/solution/instances/related/{idObject} (SolutionController) POST /api/v1/solution/instances/related/{idObject} (SolutionController) POST /api/v2/entity/create/{objectSubType} (EntityControllerV2) GET /api/v2/entity/relationships/{objectSubType}/{idEntity} (EntityControllerV2) GET /api/v2/entity/complete-dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/entity/dynamic-catalog/{objectSubTypeParam}/{idObject} (DynamicCatalogControllerV2) GET /api/v2/entity/dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/relationship/dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/relationship/dynamic-catalog/{objectSubType}/{idObject} (DynamicCatalogControllerV2) GET /api/v2/excel/{objectType}/{objectSubType} (ExcelController) GET /api/v2/objectsubtypes/{objectType} (ObjectSubtypeController) GET /api/v2/objecttypes/objectsubtypes (ObjectsAnjanaController) GET /api/v2/objecttypes/{objectType} (ObjectsAnjanaController) GET /api/v2/graphics/getAll (GraphicsController) GET /api/v2/graphics/listGraphics/{objectType}/{idObject} (GraphicsController) GET /api/v2/graphics/myLineage (GraphicsController) #### ⏲️ Deprecated Endpoints (4) POST /api/v5/common/massiveSubmit/{objectSubType} (CommonControllerV5) POST /api/v5/entity/rename/{objectSubType}/{idObject} (EntityControllerV5) POST /api/v5/relationship/rename/{objectSubType}/{idObject} (RelationshipControllerV5) POST /api/v4/dataset/structure/{idDataset} (DatasetControlerV4) ### MINERVA #### ✨ New Endpoints (8) PUT /api/admin/minerva/clear-all (AdminAPIController) POST /api/v4/audit/search/AUDIT_OBJECT (AuditController) GET /api/saved-searches/user/v1/{where} (SavedSearchController) GET /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) POST /api/saved-searches/user/v1/{where} (SavedSearchController) PUT /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) DELETE /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) POST /api/indexer/marketplace/v1/search (MarketplaceSearchController) #### ❌ Removed Endpoints (4) DELETE /api/admin/minerva/collection/kerno (AdminAPIController) DELETE /api/admin/minerva/collection/delete-field/{field}/kerno (AdminAPIController) PUT /api/admin/minerva/collection/update/kerno (AdminAPIController) POST /api/v4/audit/search (AuditController) #### ⏲️ Deprecated Endpoints (3) GET /api/v2/favorite/user (FavoriteSearchController) POST /api/v2/favorite/user/save (FavoriteSearchController) POST /api/v2/favorite/user/delete (FavoriteSearchController) ### HERMES #### ✨ New Endpoints (6) GET /api/workflow/v1/permissions (WorkflowController) POST /api/workflow/v1/search (WorkflowController) POST /api/workflow/v1/user/adherence/search (WorkflowController) POST /api/workflow/v1/user/search (WorkflowController) POST /api/workflow/v1/user/validation/search (WorkflowController) PUT /api/admin/hermes/clear-all (AdminAPIController #### ⏲️ Deprecated Endpoints (2) POST /api/v2/workflow (WorkflowControllerV2) GET /api/v1/workflow/execution/{id} (WorkflowOldController) ### ZEUS #### ✨ New Endpoints (7) PUT /api/admin/zeus/clear-all (AdminAPIController) GET /public/v6/auth/oidc/login (OidcRestController) GET /public/v6/auth/saml2/login (SamlRestController) POST /api/user-language/v1/update (UserLanguageController) GET /api/user-language/v1/obtain (UserLanguageController) POST /api/user/v1/autocomplete (UserAutoCompleteController) POST /api/user/v1/signed (UserSignedController) #### ❌ Removed Endpoints (5) GET /api/v2/auth/user (AuthorizationInfoControllerV2) GET /api/v2/organizationalunit/list/all (OrganizationalUnitControllerV2) GET /api/v2/organizationalunit/tree/{objectSubtype}/{permission} (OrganizationalUnitControllerV2) GET /public/v4/auth/licensed (AuthenticationPublicControllerV4) POST /public/v4/auth/logout (AuthenticationPublicControllerV4) #### ⏲️ Deprecated Endpoints (11) POST /api/admin/zeus/create/userLanguage (AdminAPIController) PATCH /api/admin/zeus/update/userLanguage (AdminAPIController) DELETE /api/admin/zeus/delete/userLanguage (AdminAPIController) POST /api/v2/auth/roles/byActionAndOrganizationalUnit (AuthorizationInfoControllerV2) POST /public/v4/auth/login/oidc/{provider} (AuthenticationPublicControllerV4) POST /public/v4/auth/login/oidc/password/{provider} (AuthenticationPublicControllerV4) POST /public/v4/auth/login/password/{provider} (AuthenticationPublicControllerV4) POST /api/v1/language/update (UserLanguageOldController) GET /api/v1/language/obtain (UserLanguageOldController) GET /api/v1/language (UserLanguageOldController) POST /api/v5/auth/users (AuthorizationInfoControllerV5) ### PORTUNO #### ✨ New Endpoints (17) POST /api/portuno/appconfiguration/v1/create (AppConfigurationController) POST /api/portuno/appconfiguration/v1/search (AppConfigurationController) GET /api/portuno/appconfiguration/v1/get/{id} (AppConfigurationController) GET /api/portuno/appconfiguration/v1/public (AppConfigurationController) GET /api/portuno/appconfiguration/v1/getAll (AppConfigurationController) POST /api/portuno/appconfiguration/v1/update/{id} (AppConfigurationController) POST /api/portuno/appconfiguration/v1/updateBulk (AppConfigurationController) POST /api/portuno/appconfiguration/v1/delete/{id} (AppConfigurationController) POST /api/portuno/translations/v1/search (TranslationController) GET /api/portuno/translations/v1/used-for (TranslationController) POST /api/portuno/translations/v1/exists (TranslationController) POST /api/portuno/translations/v1/apply-default-values (TranslationController) POST /api/portuno/i18n/v1/submit (I18nController) GET /public/portuno/languages/v1/available (LanguagePublicController) GET /public/portuno/languages/v1/active (LanguagePublicController) POST /api/portuno/languages/v1/search (LanguageController) GET /api/portuno/languages/v1/get/{i18nCode} (LanguageController) #### ❌ Removed Endpoints (2) PATCH /api/portuno/languages/{id} (LanguageController) DELETE /api/portuno/languages/{id} (LanguageController) #### ⏲️ Deprecated Endpoints (2) GET /api/v2/appconf (AppConfigurationLegacyController) PUT /api/portuno/insert/translations (AdminController) Update in the data: #### **Hermes** * The **external_sending** column is added to the **notification** table in order to configure which external providers (MAIL, TEAM, etc.) notifications are sent to. * Type change in the **request_reason** column of table **workflow_execution** * New native notification created for incorrect validations on ENRICHED type attributes. #### **Zeus** * Permissions granted to roles are renamed based on what is defined in **Expand and set application permissions and Changes in existing permissions** in **Update on the platform** * Foreign keys have been removed from the user_languaje table to adapt to the changes made to the languages. * The **previous_login** and **signed** columns have been added to the **users** table for the additional login information on the home screen and the platform terms of use contract. #### **Kerno** * Columns added to the **Entity** table: the **data_access** and **information_access**columns have been added for the new access information feature. * Change in **attribute_value**on the i18n column to adapt to the changes made to the languages. * Removal of the **MIN_LENGHT** and **MAX_LENGHT** validations on **ENRICHED_TEXT_AREA** and **ENRICHED_TEXT_AREA_INTERNATIONAL** #### **Minerva** * Extension of the **saved_search** table to accommodate different filters for both portals, adding **search_place** and changing **sorting_type** to be a text string. ### **Bugs** All the information relating to the problems and limitations that apply to this version or that have been fixed is available in the documentation under **Support portal \> Known problems and limitations**. --- version: "26.1" language: "es" --- # Release Notes |------------------------------------------------------------------|-----------------|---------------------------------|---------------------------|---------------| | **Versión** | **Fecha de GA** | **Estado** | **En ventana de soporte** | **Fecha EOS** | | [26.1](https://wiki.anjanadata.com/es/release-notes/26.1) | 29/06/2026 | Latest release | ✅ | - | | [25.2](https://wiki.anjanadata.com/es/release-notes/25.2) | 29/10/2025 | Versión en ventana de soporte | ✅ | 29/10/2026 | | [25.1](https://wiki.anjanadata.com/es/release-notes/25.1) | 28/05/2025 | Versión en EOS (End of Support) | ❌ | 29/05/2026 | | [23.1](https://wiki.anjanadata.com/es/versiones-pasadas/current) | 24/04/2024 | Versión en EOS (End of Support) | ❌ | 28/05/2025 | Definiciones: * **"Next Release" (Próxima versión).** La siguiente versión a publicar. * **"Latest Release" (Versión más reciente).** La última Versión **YY.N** publicada por Anjana Data y, si existe, su **último Parche vigente**. * **"GA (General Availability)".** Fecha a partir de la cual una Versión se considera liberada para uso general. * **EOS (End of Support):** Fin de soporte. Para más detalle consultar la [Política de Soporte de Anjana Data](https://wiki.anjanadata.com/es/portal-de-soporte/current/politica-de-soporte-de-anjana-data) 26.1 Patch 2 - 25/08/2026 ## 26.1 Patch 2 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.0.1** | **6.1.0** | |-------------------|-----------------------------|--------------------------------------------|---------------------------------------------------------------------|-------------------------------|------------| | ***marketplace*** | ***inventory-interceptor*** | ***tot*** ***anjana-ui*** ***portuno-ui*** | ***hermes*** ***horus*** ***portuno*** ***viator*** ***drittesta*** | ***kerno***🆕 ***minerva***🆕 | ***zeus*** | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | **5.2.1** | |-------------------------------------------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------| | **tot-plugin-databricks** **tot-plugin-** ***snowflake***🆕 | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3*** **tot-plugin-** ***azure-ad*** **tot-plugin-** ***azure-storage*** **tot-plugin-** ***gcp-iam*** **tot-plugin-jdbc-snowflake** | **tot-plugin-** ***aws-glue*** **tot-plugin-** ***aws-iam*** **tot-plugin-** ***gcp-bigquery*** **tot-plugin-** ***gcp-storage*** **tot-plugin-** ***jdbc*** **tot-plugin-** ***jdbc-oracle*** **tot-plugin-** ***jdbc-redshift*** **tot-plugin-** ***jdbc-sqlserver*** **tot-plugin-** ***ldap*** **tot-plugin-** ***powerbi*** **tot-plugin-** ***tableau*** | **tot-plugin-** ***jdbc-denodo*** | #### AI | **1.0.1** | |-----------------| | ***adp-mcp***🆕 | #### Instaladores | ***Ansible*** | ***K8S*** | ***Installer*** | |------------------|-----------|-----------------| | 26.a1.1788858836 | 26.k1 | 1.0.1 | ### **Actualizaciones** #### Minerva Se ha modernizado el cliente de conexión entre el módulo de indexación de la plataforma y el motor de búsqueda, migrando a la implementación basada en HTTP/2 soportada por las versiones actuales de Solr. El cambio alinea la plataforma con la versión del motor incorporada en 26.1, retira componentes de conexión deprecados y mejora la estabilidad del buscador durante las operaciones de actualización del esquema de indexación. #### Kerno Se corrige un error por el que, al aprobar la modificación de un dataset, los campos referenciados en atributos de tipo ENTITY_CONTAINER, ENTITY_SEARCH o ARRAY_ENTITY dejaban de aparecer en el contenido. Los campos modificados conservan ahora su identidad tras la aprobación del flujo, aplicando el mismo comportamiento que ya tenía el DATASET padre, de modo que las referencias existentes en los tipos de atributos mencionados siguen siendo válidas. Se completa además la actualización del índice de búsqueda de los objetos afectados cuando se modifican o eliminan campos del dataset asociado, evitando que muestren información desactualizada. El parche incluye un proceso de reparación automático para los atributos que hubieran quedado afectados en entornos existentes. Bug asociado: **D13131** #### ADP-MCP Se corrige un error del flujo de inicio de sesión del servidor MCP por el que determinados usuarios no podían completar la autenticación y recibían un mensaje de error genérico de autenticación. Se ha mejorado además la trazabilidad del error en los logs. Adicionalmente, se refuerza el flujo de autorización con PKCE (S256) obligatorio, junto con otras mejoras de seguridad. Se recomienda desplegar esta versión del servidor MCP. Bug asociado: **DS4920** #### Tot-Plugin-Snowflake Se publica el nuevo plugin de integración con **Snowflake** basado en la **Snowflake SQL API** y autenticación **OAuth2 con Microsoft Entra ID** (External OAuth), que sustituye al plugin anterior basado en conector JDBC. Además de la extracción de metadatos y el muestreo de datos ---ahora con soporte para tablas, vistas y vistas materializadas, y recuperación de tags nativos de Snowflake, incluidos los heredados de activos ancestros---, el nuevo plugin amplía el alcance funcional con la **gestión de permisos de acceso**: creación y gestión de roles asociados a Data Sharing Agreements y concesión y revocación automática de privilegios de consumo sobre los activos gobernados. La gestión de permisos requiere el plugin de Entra ID desplegado y el SSO de Azure activado. Con la publicación de este plugin, el **plugin de Snowflake vía JDBC queda deprecado**. Se mantendrá disponible durante el ciclo de vida de 26.1, pero no recibirá nuevas funcionalidades ni actualizaciones, por lo que se recomienda planificar la migración al nuevo plugin cuanto antes. Más información en la documentación del plugin: [Snowflake (API nativa)](https://wiki.anjanadata.com/es/integraciones/26.1/snowflake-api-nativa.md) #### Anjana-Installer Múltiples optimizaciones y correcciones entre las que se encuetran: * Ajuste de parada de microservicios durante operaciones de datos * Corregida validación de conectividad contra AWS Secrets Manager antes de adoptar su uso. * Extendidas opciones de seguridad disponibles en la configuración para personalizar el acceso a los paneles de administración. * Endurecidos los patrones de comunicación desde y hacia las persistencias * Añadido preflight que detecta el rango de kernels incompatibles con mongo en su versión selfhosted (6.19.0 - 7.0.14) * Mejorado preflight para la detección de conexión al repositorio de artefactos * Mejoradas comprobaciones del estado de salud de las persistencias * Corregido un error que impedía la auto-actualización del instalador de forma correcta * Mejorada detección y aplicación de cambios de configuración * El installer ahora permite la consulta de Logs y el estado de los componentes mediante su Dashboard durante operaciones ### **Bugs** Toda la información relativa a los problemas y limitaciones que aplican a esta versión o que han sido corregidas están disponibles en la documentación de **Portal de soporte \> Problemas y limitaciones conocidos** . 26.1 Parche 1 - 17/08/2026 ## 26.1 Parche 1 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.1.0** | |-------------------|-----------------------------|--------------------------------------------|-----------------------------------------------------------------------------------------------|------------| | ***marketplace*** | ***inventory-interceptor*** | ***tot*** ***anjana-ui*** ***portuno-ui*** | ***hermes*** ***horus*** ***portuno*** ***viator*** ***kerno*** ***minerva*** ***drittesta*** | ***zeus*** | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | **5.2.1** | |---------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------| | **tot-plugin-databricks** | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3*** **tot-plugin-** ***azure-ad*** **tot-plugin-** ***azure-storage*** **tot-plugin-** ***gcp-iam*** **tot-plugin-jdbc-snowflake** | **tot-plugin-** ***aws-glue*** **tot-plugin-** ***aws-iam*** **tot-plugin-** ***gcp-bigquery*** **tot-plugin-** ***gcp-storage*** **tot-plugin-** ***jdbc*** **tot-plugin-** ***jdbc-oracle*** **tot-plugin-** ***jdbc-redshift*** **tot-plugin-** ***jdbc-sqlserver*** **tot-plugin-** ***ldap*** **tot-plugin-** ***powerbi*** **tot-plugin-** ***tableau*** | **tot-plugin-** ***jdbc-denodo***🆕 | #### IA | **1.0.0** | |---------------| | ***adp-mcp*** | #### Instaladores | ***Ansible*** | ***K8S*** | ***Installer*** | |---------------|-----------|-----------------| | 26.a1 | 26.k1 | 26.1 | ### **Actualizaciones** #### Plugin de Denodo Evolución de la funcionalidad del plugin en el flujo de concesión de permisos para otorgar y revocar el permiso CONNECT sobre la Virtual Database (GRANT CONNECT, REVOKE CONNECT). Más información en la documentación del plugin [Denodo](https://wiki.anjanadata.com/es/integraciones/26.1/denodo.md) ### **Bugs** Toda la información relativa a los problemas y limitaciones que aplican a esta versión o que han sido corregidas están disponibles en la documentación de **Portal de soporte \> Problemas y limitaciones conocidos**. 26.1 GA - 29/06/2026 ## 26.1 ### Core | **1.0.0** | **5.0.0** | **5.2.0** | **6.0.0** | **6.1.0** | |---------------------|-----------------------------|--------------------------------------------------|----------------------------------------------------------------------------------------------------------------|--------------| | ***marketplace***🆕 | ***inventory-interceptor*** | ***tot***🆕 ***anjana-ui***🆕 ***portuno-ui***🆕 | ***hermes*** 🆕 ***horus*** 🆕 ***portuno*** 🆕 ***viator***🆕 ***kerno***🆕 ***minerva***🆕 ***drittesta***🆕 | ***zeus***🆕 | #### Tot Plugins | **1.0.0** | ***5.0.0*** | **5.1.0** | **5.2.0** | |-----------------------------|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **tot-plugin-databricks**🆕 | **tot-plugin-** ***aqtiva*** | **tot-plugin-** ***aws-s3***🆕 **tot-plugin-** ***azure-ad***🆕 **tot-plugin-** ***azure-storage***🆕 **tot-plugin-** ***gcp-iam***🆕 **tot-plugin-jdbc-snowflake**🆕 | **tot-plugin-** ***aws-glue***🆕 **tot-plugin-** ***aws-iam***🆕 **tot-plugin-** ***gcp-bigquery***🆕 **tot-plugin-** ***gcp-storage***🆕 **tot-plugin-** ***jdbc***🆕 **tot-plugin-** ***jdbc-denodo***🆕 **tot-plugin-** ***jdbc-oracle*** 🆕 **tot-plugin-** ***jdbc-redshift***🆕 **tot-plugin-** ***jdbc-sqlserver*** 🆕 **tot-plugin-** ***ldap***🆕 **tot-plugin-** ***powerbi***🆕 **tot-plugin-** ***tableau***🆕 | #### IA | **1.0.0** | |-----------------| | ***adp-mcp***🆕 | #### Instaladores | ***Ansible*** | ***K8S*** | ***Installer*** | |---------------|-----------|-----------------| | 26.a1🆕 | 26.k1🆕 | 26.1🆕 | ### **Actuaciones manuales requeridas** #### **Antes del upgrade** * Actualización del Kit de despliegue a su última versión, si no se ha hecho aún. Revisar la documentación propia de las versiones de los kits. * Si se usa algún kit de instalación proporcionado por Anjana Data, para tener el software completamente actualizado solamente es necesario actualizar las versiones de los artefactos con los valores mencionados en la tablas previas, el software se encarga de los cambios en la base de datos. Sólo en caso contrario, se tendrán que actualizar las versiones de las persistencias a su última versión productiva, de forma manual por parte del instalador. #### **Antes de dar por finalizado el upgrade** Durante el arranque inicial, Portuno migra la configuración del Portal de administración antiguo al nuevo (de PostgreSql a documentsDB). Una vez que Portuno aparece en Horus como UP, es necesario **reiniciar la plataforma** desde el instalador para ejecutar el liquibase de cada microservicio que depende de la configuración de Portuno. Para verificar que lo anterior se ha ejecutado satisfactoriamente: * Acceder a base de datos y verificar que en las tablas **databasechangelog** de los esquemas **anjana, hermes, minerva** , **portuno** y**zeus** hay registros correspondientes al liquibase de 26.1. Para ello, filtrar en la columna **filename** por `filename like ('%/26.1/%')` * Acceder a documentsDB y verificar: * Se dispone de la tabla **DATASABECHANGELOG** con los registros de `db/migrations/26.1/` ![image-20260727-093213.png](/__attachments/a_a5fcde015f2af4a4d9cbf82cd2342bdf5d872faaac4f9871ec5fcc0f5e169de5/image-20260727-093213.png?cb=997877fa3042c52737ee6efb0d0eb512) * Se dispone de la tabla **BATCH_JOB_EXECUTION** que contiene 2 registros, uno correspondiente a las migraciones de los registros de traducciones del i18n y appConfigurations y otra de las inserciones de las traducciones por defecto, ambas en estado **COMPLETED** ![image-20260727-093435.png](/__attachments/a_77ff0828b4f2d42694e83ccfadf3b8c990f3c4ae68622042bfc9665b57669730/image-20260727-093435.png?cb=70765898a4fd4477f1c789fc50ada47b) ### **Actuaciones manuales opcionales** * Si se tenían ponderaciones en SolR es probable que se tengan que regenerar dado el carácter volátil del indexador * Se recomienda introducir la variable #REQUEST_REASON# en el cuerpo de las notificaciones asociadas a alertas de los workflows, para que los intervinientes reciban los textos asociados al motivo de la solicitud que se incorpora para todos los workflows en esta versión. * Si se han configurado notificaciones con proveedor externo (por ejemplo, vía email) es conveniente revisar la configuración de las Notificaciones en el Panel de Administración para continuar recibiéndolas. Por defecto, la migración deja el campo EXTERNAL_SENDING vacío, por lo que las notificaciones no se recibirán. * Desde el nuevo portal de adminitración: * Reindexar todo. * Revisar los mecanismos de Autenticación implementados y evaluar la migración de aquellos que se han deprecado en esta versión antes de su expiración en 26.2. ### **Actualizaciones** Actualización en los kits de despliegue: #### **Ansible** ##### **Cambios bloqueantes** * **Nuevo rol de despliegue para MongoDB 7.0** * **Nuevo rol de despliegue para RabbitMQ 3.12** * **Nuevo rol de despliegue para Valkey 7.2**y cadenas de conexión para nuevas persistencias: MONGO_URI, VALKEY_\*, RABBITMQ_\* * **Nuevo rol de despliegue para el microservicio marketplace** (puerto 8089), incluye la creación de su schema en PostgreSQL durante la actualización ###### **Otros cambios y optimizaciones** * URLs de Eureka y Spring Boot Admin configuradas mediante variables de entorno (HORUS_REPLICAS, HORUS_ADMIN_URL, TOT_EUREKA_URL) en las units systemd, en lugar de argumentos Spring * Variables en hosts.yaml para despliegues single-node y multi-node * Backup de certificados TLS incluido en el backup de Ansible * Corrección de nombres en templates de servicios * Corrección de propiedades S3 * Cabeceras de seguridad HTTP añadidas al VirtualHost de Apache, eliminación del proxy Swagger obsoleto y sustitución del trace ID MD5 por `Apache UNIQUE_ID` * Exposición de Grafana a través de proxy Apache en `/grafana` (puerto 443) * Modelo de memoria de la JVM alineado: `MaxRAMPercentage` + `systemd MemoryMax` en lugar de `Xmx` fijo * Solr: `SOLR_HEAP` sustituido por `SOLR_JAVA_MEM`, con `GC_TUNE` explícito * Dependencias systemd (`After=`/`Wants=`) entre servicios core y plugins para un arranque ordenado * Compatibilidad con RHEL 9 y Ubuntu 24.04 (Python 3.12, pymongo 4+, repositorio Remi, PPA) para las nuevas persistencias MongoDB, Valkey y RabbitMQ * Mejoras de idempotencia en los roles de instalación (Solr, copia de artefactos, comprobación SHA1 de descargas) para permitir reejecuciones seguras del playbook * Nuevos tags `delete-solrzk` y `delete-minio` para desinstalación selectiva * Nuevos avisos en `anjana.sh` indicando los pasos obligatorios para desplegar MongoDB, RabbitMQ y Valkey antes de actualizar los microservicios ##### **Kit K8s** ###### **Cambios bloqueantes** * **Reestructuración completa del kit:**de manifiestos YAML planos (122 ficheros) a Helm chart con subcharts anjana-core y anjana-plugins (11 templates reutilizables). Despliegue vía helm install/upgrade * **TLS automatizado con cert-manager:**modo internal (certificados self-signed auto-generados + Job de generación de truststore) y modo manual (secretos pre-creados) * **Soporte IRSA para Horus:**integración con AWS Secrets Manager como backend de config server, con guard rails de validación * **Múltiples backends de config server:**AWS Secrets Manager, Git o modo JDBC puro (credenciales propias de Horus vía Kubernetes Secret), seleccionable vía values.yaml * **Modo standalone para plugins:**lectura directa de secretos cloud (AWS SM, Azure KV, GCP SM) sin necesidad de config server * **Manifiestos opcionales para nuevas persistencias:**MongoDB, RabbitMQ, Valkey * **Migración de MinIO a SeaweedFS** como backend de almacenamiento S3/CDN: nuevo manifiesto seaweedfs.yaml sustituye a minio.yaml * **InitContainers para espera de dependencias:**arranque ordenado de servicios con health checks HTTPS entre ellos ###### **Otros cambios y optimizaciones** * URLs de Eureka y Spring Boot Admin configuradas mediante variables de entorno (HORUS_REPLICAS, HORUS_ADMIN_URL, TOT_EUREKA_URL) en lugar de argumentos Spring * Integración OpenTelemetry nativa: OTEL_SERVICE_NAME y OTEL_RESOURCE_ATTRIBUTES inyectados en todos los servicios * Scripts de backend AES * Soporte extraCaBundles en el Job de truststore para inyectar CAs adicionales (ej. CA corporativa) * Resource profiles por entorno (DEV/PRE/PRO) con selección automática vía global.environment.profile * Cabeceras de seguridad HTTP en los ConfigMaps de nginx, rate limiting de login en /gateway/public/, forward de X-traceId a los backends y a portuno-ui, restricción CORS en viator vía global.domain, y eliminación del proxy Swagger obsoleto * Página de carga (loading page) para anjana-ui con estado de salud de los servicios (HEALTH_LOCATIONS_CONF / HEALTH_MANIFEST_JSON) * Solr: almacenamiento por defecto cambiado de emptyDir a hostPath * Documentación autogenerada con helm-docs e integrada en un target de Makefile * Múltiples correcciones de validación del chart y de comportamiento en runtime tras pruebas E2E en EKS (esquemas de base de datos, keystore/truststore en modo manual, recursos, health checks) Actualización en la plataforma: #### **MCP de Anjana Data Platform** En la versión 26.1 se incorpora el **MCP (Model Context Protocol)** de Anjana Data Platform, que expone las capacidades de la plataforma a través del protocolo MCP para su integración con asistentes y agentes de IA. Está disponible tanto para despliegues **SaaS** como **IaaS/PaaS**. El MCP de Anjana Data Platform se publica como **funcionalidad nueva susceptible de errores**. Antes de utilizarla, tenga en cuenta que: * Es una funcionalidad **nueva y aún poco probada** , que **puede presentar fallos** o comportamientos no esperados. * Se ofrece **\<\\> (as is)** , sin garantías de estabilidad ni de completitud, y **no se recomienda su uso en procesos críticos de producción**. * **No está cubierta por la** [**Política de Soporte de Anjana Data**](https://wiki.anjanadata.com/es/portal-de-soporte/current/politica-de-soporte-de-anjana-data): no le aplican los compromisos de resolución de incidencias, entrega de correcciones (*fixes*) ni tiempos de respuesta descritos en dicha política. * Agradecemos el **feedback** de quienes la utilicen: sus comentarios nos ayudarán a estabilizar y evolucionar la funcionalidad en próximas versiones. * **Disponibilidad:** despliegues **SaaS** e **IaaS/PaaS**. #### **Ampliación de las capacidades del plugin de Power BI** El Tot Plugin de Power BI incorpora la gestión de accesos sobre los activos de Power BI catalogados en **Anjana Data Platform** . La funcionalidad permite asignar y revocar permisos efectivos en Power BI a partir del ciclo de vida de un **DSA** , utilizando grupos de **Azure Entra ID** como única unidad de autorización. #### **Nuevo plugin para extracción de metadatos sobre Databricks** En su **Fase 1** , la integración habilita el **descubrimiento y la extracción de metadatos técnicos** (modo *read-only* ) de los activos disponibles en **Unity Catalog**, sin realizar ninguna mutación sobre el sistema origen. #### **Ampliar y establecer permisos de la aplicación** A partir de esta versión, el acceso a todos los **módulos** y el acceso a las **pestañas** de la vista de los objetos dependen de **permisos**asociados al rol del usuario. De esta forma, se complejiza la configuración de permisos pero se ofrece mayor granularidad de accesos, simplificando el acceso a información por grupos de usuarios. Para ello, se van a añadir los siguientes permisos de **visualización**: * Acceso al módulo de Catálogo: CATALOG_ACCESS * Acceso al módulo de Trabajos: JOBS_ACCESS * Acceso a Auditoría de seguridad completa: SEC_AUDIT_ACCESS ![warning](https://wiki.anjanadata.com/__attachments/a_8d662b3568361b7175a748faf07bb54607237e196b468db220046830fc2f0254/atlassian-warning?cb=14432459925d605e05cae2605cdfe666) *Permiso creado pero sin capacidad funcional hasta release 26.2 prevista para Q3 de 2026* * Acceso Auditoría de gobierno completa: GOV_AUDIT_ACCESS * Acceso al Espacio personal de trabajo (Workspace): WORKSPACE_ACCESS * Acceso a la pestaña de Relaciones de una entidad: OBJ_RELATIONS_ACCESS * Acceso a la pestaña de Intervinientes OBJ_STAKEHOLDERS_ACCESS * Acceso a pestaña de Auditoría de objeto (OBJ_AUDIT_ACCESS) * Acceso a la pestaña de Versiones: OBJ_VERSIONS_ACCESS * Acceso a la pestaña de Muestra de datos OBJ_SAMPLE_DATA_ACCESS * Acceso a la información de Adherencias en la pestaña de intervinientes ADHERENCE_VIEW También se incluye un nuevo permiso para editar la Información de acceso que reciben usuarios adheridos: EDIT_ACCESS_INFO (action) ALL (subType) ##### Cambios en permisos existentes: * El permiso ACCESS ALL para acceder al portal de datos se reemplaza por el permiso PLATFORM_ACCESS (action) con subTypeANJANA. * El permiso ADMIN (action) ANJANA (subType) para el panel de configuración/administración se sustituye por ADMIN_ACCESS (action) ANJANA (subType) * El permiso WIZARD (action) ALL (subType) se elimina. El asistente de creación se accederá mediante los permisos de creación (CREATION_MODIF) sobre cualquier subTipo. * El permiso ACCESS (action) ADHERENCE (subTipo) para conceder acceso a datos se actualiza a ADHERENCE_ACCESS (action) ALL (subType). Este permiso también otorga acceso al nuevo módulo de Marketplace. #### **Evoluciones en workflows** ##### **Añadir motivo de solicitud para cualquier workflow** Todos los workflows quedarán completados con el motivo de la solicitud igual que hacía en versiones previas con los workflows de adherencia. Para ello, cuando el usuario elija o confirme una acción que lance workflow, Anjana Data Platform le mostrará una ventana donde el usuario podrá introducir el motivo en, al menos, un idioma de la aplicación. Los textos podrán consultarse desde las pantallas de workflows y en las notificaciones al usar la variable #REQUEST_REASON#. Se sugiere incluir esta variable en el cuerpo de las notificaciones de los workflows, asegurando así que los usuarios involucrados la reciban. ##### **Nuevas pantallas de workflows** A partir de ahora se dispondrán de las siguientes pantallas: 1. **Mis solicitudes de acceso** 🆕 : Proporciona acceso a workflows de adherencia solicitados por el propio usuario ++Restricción de acceso++: Sólo disponible para usuarios que, o bien tienen permisos de ADHERENCE, o bien han sido Solicitantes en algún workflow de ADHERENCE. 2. **Mis solicitudes de gobierno** 🆕 : Proporciona acceso a workflows de gobierno solicitados por el propio usuario, a excepción de workflows de adherencia. ++Restricción de acceso++: Sólo disponible para usuarios que o tienen permisos de CREATION_MODIF, CHANGE_OU, CHANGE_OU o DEPRECATION o son usuarios que han sido Solicitantes en algún workflow de CREACION, MODIFICACION, ACTIVACION, DESACTIVAR, RENOMBRADO, TRANSFERENCIA. 3. **Mis Tareas** 🆕 : Proporciona acceso a workflows que tiene que validar el usuario debido a su rol. ++Restricción de acceso++: Sólo disponible para usuarios que son Validador en algún workflow. 4. **Flujos de trabajo** : Proporciona acceso a el conjunto completo de workflows. ++Restricción de acceso++: Solo disponible para usuarios que tienen rol con permisos de WORKFLOW_ACCESS Cuando un usuario reciba una notificación de validación, podrá acceder al workflow siempre a aprobar o rechazar desde la notificación, desde la pantalla de Mis Tareaso desde el listado completo de Workflows (sólo en caso de tener el permiso WORKFLOW_ACCESS). **Más información en las pantallas de workflows** Se ha enriquecido la información que se muestran en las pantallas de workflows, por lo que a partir de ahora se incluye: * Objeto * Tipo de solicitud * Solicitante * Motivo * Fecha de petición * Estado de la validación * Último participante * Última respuesta * Tiempo sin respuesta * Duración total Algunos atributos pueden omitirse en ciertas pantallas de flujos de trabajo debido a su redundancia. Por ejemplo, en la pantalla de "Mis solicitudes de gobierno" no se muestra el "Solicitante", ya que dicho campo siempre corresponde al usuario que accede. #### **Evoluciones en interfaz de usuario** ##### **Home page** Se incluye una página de inicio como punto de entrada para los usuarios tras hacer login y que será accesible desde los logos de Anjana Data Platform y del cliente en la cabecera. Esta página de inicio incluye: * Buscador que permite realizar búsquedas en el Catálogo o en el Marketplace * Resumen de actividad con selector por rango de fechas ( 7 días, 30 días, 3 meses, 6 meses y 1 año) * Mis solicitudes de acceso * Mis solicitudes de gobierno * Mis tareas * Accesos rápidos a: * Wizard de creación * Espacio personal de trabajo (workspace) * Fecha con el login anterior. #### **Portal Marketplace** Se crea un nuevo módulo denominado Marketplace que pretende ser un portal de búsqueda y solicitud de acceso a activos previstos al consumo mediante Data Sharing Aggreements (DSA) para los consumidores. El Marketplace ofrece en primer lugar un espacio de **sugerencias** donde el consumidor puede visualizar DSAs añadidos recientemente y los activos más solicitados por otros usuarios. A continuación ofrece un espacio para descubrimiento de activos mediante un buscador y filtros con una experiencia intuitiva y ágil que se apoya en las siguientes capacidades: * Guardar búsquedas destacadas con opción a seleccionar una como favorita. * Opción de añadir pedir acceso inmediato o añadir al carrito para compras masivas * Selecciones masivas de objetos para añadir al carrito * Selecciones masivas para añadir al espacio personal de trabajo (workspace) * Previsualizar los detalles de un objeto * Consultar información de acceso #### **Contrato y condiciones de uso de la plataforma** Al hacer login por primera vez en esta versión se mostrara al usuario un contrato de condiciones de uso sobre la plataforma que se debe aceptar para continuar usandola. #### Información de Acceso en objetos Aquellos usuarios que estén adheridos a un objeto podrán acceder a la información de acceso del mismo, donde se podrán incluir instrucciones para acceder al activo físico que el objeto representa. Solo aquellos con EDIT_ACCESS_INFO pueden modificar la información de acceso. Actualización en la API: RESUMEN: 43 añadidos · 1 MODIFICADO · 45 ELIMINADOS · 22 DEPRECADOS ### KERNO #### ✨ Nuevos endpoints (5) PUT /api/admin/kerno/clear-all (AdminAPIController) POST /api/common/v1/massiveSubmit/{objectSubType} (CommonController) POST /api/entity/v1/rename/{objectSubType}/{idObject} (EntityController) POST /api/relationship/v1/rename/{objectSubType}/{idObject} (RelationshipController) POST /api/dataset/v1/structure/{idDataset} (DatasetController) #### ❌ Endpoints eliminados (34) PUT /api/admin/kerno/name/{objectType} (AdminAPIController) POST /api/v2/attribute/custom/list (AttributeController) GET /api/v2/common/stakeholders/{objectType}/{objectSubType}/{idObject} (CommonV2Controller) POST /api/v2/common/massiveSubmit/{objectSubType} (CommonV2Controller) POST /api/v1/metadata/requests (MetadataController) POST /api/v1/metadata/requests/detail (MetadataController) GET /api/v1/dataset/versions/{idObject} (DatasetController) GET /api/v1/dsa/versions/{idObject} (DsaController) GET /api/v1/dsa/datasets/{idObject} (DsaController) POST /api/v1/dsa/datasets/{idObject} (DsaController) GET /api/v1/instance/versions/{idObject} (InstanceController) GET /api/v1/instance/project/{idObject} (InstanceController) GET /api/v1/instance/solutions/{idProcessInstance} (InstanceController) GET /api/v1/process/versions/{idObject} (ProcessController) GET /api/v1/process/instances/{idProcess} (ProcessController) GET /api/v1/solution/versions/{idObject} (SolutionController) GET /api/v1/solution/instances/owned/{idObject} (SolutionController) GET /api/v1/solution/instances/related/{idObject} (SolutionController) POST /api/v1/solution/instances/related/{idObject} (SolutionController) POST /api/v2/entity/create/{objectSubType} (EntityControllerV2) GET /api/v2/entity/relationships/{objectSubType}/{idEntity} (EntityControllerV2) GET /api/v2/entity/complete-dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/entity/dynamic-catalog/{objectSubTypeParam}/{idObject} (DynamicCatalogControllerV2) GET /api/v2/entity/dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/relationship/dynamic-catalog/{objectSubType} (DynamicCatalogControllerV2) GET /api/v2/relationship/dynamic-catalog/{objectSubType}/{idObject} (DynamicCatalogControllerV2) GET /api/v2/relationship/entities/{objectSubType}/{idRelationship} GET /api/v2/excel/{objectType}/{objectSubType} (ExcelController) GET /api/v2/objectsubtypes/{objectType} (ObjectSubtypeController) GET /api/v2/objecttypes/objectsubtypes (ObjectsAnjanaController) GET /api/v2/objecttypes/{objectType} (ObjectsAnjanaController) GET /api/v2/graphics/getAll (GraphicsController) GET /api/v2/graphics/listGraphics/{objectType}/{idObject} (GraphicsController) GET /api/v2/graphics/myLineage (GraphicsController) #### ⏲️ Endpoints deprecados (4) POST /api/v5/common/massiveSubmit/{objectSubType} -> POST /api/common/v1/massiveSubmit/{objectSubType}: solo re-versionado (renombrado interno de un V6), sin cambio funcional verificado POST /api/v5/entity/rename/{objectSubType}/{idObject} -> POST /api/entity/v1/rename/{objectSubType}/{idObject}: ninguno, DTOs idénticos POST /api/v5/relationship/rename/{objectSubType}/{idObject} -> POST /api/relationship/v1/rename/{objectSubType}/{idObject}: ninguno, DTOs idénticos POST /api/v4/dataset/structure/{idDataset} -> POST /api/dataset/v1/structure/{idDataset}: la respuesta pasa de array plano a paginada (results + totalResults) #### Unknown Attachment Endpoints modificados (1) POST /api/v2/entity/submit, change-state, change-organizational-unit; POST /api/v2/relationship/submit, change-state; POST /api/v1/dsa/adhere: nueva validación de longitud máxima (255 caracteres) en el campo requestReason ### MINERVA #### ✨ Nuevos endpoints (8) PUT /api/admin/minerva/clear-all (AdminAPIController) POST /api/v4/audit/search/AUDIT_OBJECT (AuditController) GET /api/saved-searches/user/v1/{where} (SavedSearchController) GET /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) POST /api/saved-searches/user/v1/{where} (SavedSearchController) PUT /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) DELETE /api/saved-searches/user/v1/{where}/{id} (SavedSearchController) POST /api/indexer/marketplace/v1/search (MarketplaceSearchController) #### ❌ Endpoints eliminados (4) DELETE /api/admin/minerva/collection/kerno (AdminAPIController) DELETE /api/admin/minerva/collection/delete-field/{field}/kerno (AdminAPIController) PUT /api/admin/minerva/collection/update/kerno (AdminAPIController) POST /api/v4/audit/search (AuditController) #### ⏲️ Endpoints deprecados (3) GET /api/v2/favorite/user (FavoriteSearchController) -> GET /api/saved-searches/user/v1/PORTAL: ninguno POST /api/v2/favorite/user/save (FavoriteSearchController) -> POST /api/saved-searches/user/v1/PORTAL: la respuesta pasa de devolver la lista completa a devolver solo el registro creado POST /api/v2/favorite/user/delete (FavoriteSearchController) -> DELETE /api/saved-searches/user/v1/PORTAL/{id}: el borrado pasa de identificarse por name a identificarse por id (UUID) ### HERMES #### ❌ Endpoints eliminados (1) POST /api/v2/notification #### ✨ Nuevos endpoints (6) GET /api/workflow/v1/permissions (WorkflowController) POST /api/workflow/v1/search (WorkflowController) POST /api/workflow/v1/user/adherence/search (WorkflowController) POST /api/workflow/v1/user/search (WorkflowController) POST /api/workflow/v1/user/validation/search (WorkflowController) PUT /api/admin/hermes/clear-all (AdminAPIController #### ⏲️ Endpoints deprecados (2) POST /api/v2/workflow (WorkflowControllerV2) -> POST /api/workflow/v1/search: confirmado por javadoc explícito en el código GET /api/v1/workflow/execution/{id} (WorkflowOldController) -> POST /api/workflow/v1/search (parcial): si el consumidor conoce el objeto (nombre/tipo/subtipo), el listado nuevo devuelve información equivalente o más rica (progreso por paso, tiempos acumulados). El gap real es solo para quien dispone únicamente del ID numérico de ejecución: no hay filtro por ID de ejecución ni por ID de objeto en la búsqueda nueva. Tampoco se confirmó si el nuevo campo object.state equivale exactamente al viejo isObjectPending/isProcessing GET /api/v1/workflow/execution/{id} --> sustituto parcial: POST /api/workflow/v1/search cubre el caso de uso cuando el consumidor conoce el objeto (nombre/tipo/subtipo), devolviendo información equivalente o más rica (progreso por paso, tiempos acumulados). El gap real y concreto es solo para quien dispone únicamente del ID numérico de ejecución sin más contexto: la búsqueda nueva no admite filtrar por ID de ejecución ni por ID de objeto. ### ZEUS #### ✨ Nuevos endpoints (7) PUT /api/admin/zeus/clear-all (AdminAPIController) GET /public/v6/auth/oidc/login (OidcRestController) GET /public/v6/auth/saml2/login (SamlRestController) POST /api/user-language/v1/update (UserLanguageController) GET /api/user-language/v1/obtain (UserLanguageController) POST /api/user/v1/autocomplete (UserAutoCompleteController) POST /api/user/v1/signed (UserSignedController) #### ❌ Endpoints eliminados (5) GET /api/v2/auth/user (AuthorizationInfoControllerV2) GET /api/v2/organizationalunit/list/all (OrganizationalUnitControllerV2) GET /api/v2/organizationalunit/tree/{objectSubtype}/{permission} (OrganizationalUnitControllerV2) GET /public/v4/auth/licensed (AuthenticationPublicControllerV4) POST /public/v4/auth/logout (AuthenticationPublicControllerV4) #### ⏲️ Endpoints deprecados (11) POST /api/admin/zeus/create/userLanguage (AdminAPIController) --> sin sustituto PATCH /api/admin/zeus/update/userLanguage (AdminAPIController) --> sin sustituto DELETE /api/admin/zeus/delete/userLanguage (AdminAPIController) --> sin sustituto POST /api/v2/auth/roles/byActionAndOrganizationalUnit (AuthorizationInfoControllerV2) -> POST /api/v4/auth/roles/byActionAndFullListOfOrganizationalUnit: ya existía antes de 26.1, no es de los "nuevos" documentados POST /public/v4/auth/login/oidc/{provider} (AuthenticationPublicControllerV4) -> GET /public/v6/auth/oidc/login: sin cambio funcional relevante POST /public/v4/auth/login/oidc/password/{provider} (AuthenticationPublicControllerV4) -> GET /public/v6/auth/oidc/login: se elimina el grant de password, no hay traspaso directo de payload POST /public/v4/auth/login/password/{provider} (AuthenticationPublicControllerV4) -> /login/ldap, /login/local o el oidc anterior, según provider: sin cambio funcional relevante POST /api/v1/language/update (UserLanguageOldController) -> POST /api/user-language/v1/update: sin cambio funcional relevante GET /api/v1/language/obtain (UserLanguageOldController) -> GET /api/user-language/v1/obtain: sin cambio funcional relevante GET /api/v1/language (UserLanguageOldController) -> GET /public/portuno/languages/v1/active: el sustituto es de Portuno, no de Zeus POST /api/v5/auth/users (AuthorizationInfoControllerV5) -> POST /api/user/v1/autocomplete: sin cambio funcional relevante #### Unknown Attachment Endpoints modificados (3) GET /public/v4/auth/providers: el campo type deja de admitir AZURE/AWS/GOOGLE/OKTA/AUTH0/OTHER y pasa a OIDC fijo, con un nuevo campo subtype POST /public/v4/auth/login/ldap, /login/local, GET /public/v6/auth/saml2/login (ver nota en Nuevos): LoginResponseDTO pierde el campo license, gana previousLogin y signed GET /api/v2/organizationalunit/list/{objectSubtype}, POST /api/admin/zeus/list/{objectSubtype}: el tipo de respuesta pasa de un DTO genérico a una clase dedicada (forma JSON equivalente, pero rompe clientes tipados) ### PORTUNO #### ✨ Nuevos endpoints (17) POST /api/portuno/appconfiguration/v1/create (AppConfigurationController) POST /api/portuno/appconfiguration/v1/search (AppConfigurationController) GET /api/portuno/appconfiguration/v1/get/{id} (AppConfigurationController) GET /api/portuno/appconfiguration/v1/public (AppConfigurationController) GET /api/portuno/appconfiguration/v1/getAll (AppConfigurationController) POST /api/portuno/appconfiguration/v1/update/{id} (AppConfigurationController) POST /api/portuno/appconfiguration/v1/updateBulk (AppConfigurationController) POST /api/portuno/appconfiguration/v1/delete/{id} (AppConfigurationController) POST /api/portuno/translations/v1/search (TranslationController) GET /api/portuno/translations/v1/used-for (TranslationController) POST /api/portuno/translations/v1/exists (TranslationController) POST /api/portuno/translations/v1/apply-default-values (TranslationController) POST /api/portuno/i18n/v1/submit (I18nController) GET /public/portuno/languages/v1/available (LanguagePublicController) GET /public/portuno/languages/v1/active (LanguagePublicController) POST /api/portuno/languages/v1/search (LanguageController) GET /api/portuno/languages/v1/get/{i18nCode} (LanguageController) #### ❌ Endpoints eliminados (6) PATCH /api/portuno/languages/{id} (LanguageController) DELETE /api/portuno/languages/{id} (LanguageController) GET /api/portuno/api/filter/languages GET /api/portuno/api/filter/translations GET /api/portuno/api/filter/appConfigurations GET /public/appconf PUT /public/v4/translations/upload GET /api/v1/migration/roles #### ⏲️ Endpoints deprecados (2) GET /api/v2/appconf (AppConfigurationLegacyController) -> GET /api/portuno/appconfiguration/v1/public: el legacy cifraba la respuesta con AES en un blob; el nuevo devuelve una lista plana sin cifrar PUT /api/portuno/insert/translations (AdminController) -> POST /api/portuno/translations/v1/apply-default-values: el legacy no devolvía cuerpo; el nuevo devuelve el número de documentos actualizados #### ⏲️Unknown Attachment Endpoints modificados (2) PUT /api/v1/cache/clear-all: la respuesta pasa de vacía a envuelta en ResponseBase GET /api/portuno: deja de devolver los campos languages, translations y appConfigurations (migración a Mongo) Actualización en los datos: #### **Hermes** * Se añade la columna **external_sending** en la tabla de **notification** para configurar a que proovedores externos (MAIL, TEAM, etc) se envían notificaciones. * Cambio de tipo en la columna **request_reason** en la tabla **workflow_execution** * Creada nueva notificación nativa para validación incorrectas sobre los atributos de tipo ENRICHED. #### **Zeus** * Se renombran permisos otorgados a roles en base a lo definido en **Ampliar y establecer permisos de la aplicación y Cambios en permisos existentes** en **Actualización en la plataforma** * Se han eliminado las claves extranjeras en la tabla user_languaje para adaptar a los cambios realizados sobre los idiomas. * Añadidas las columnas **previous_login** y **signed** sobre la tabla **users** para la información adicional de login en la pantalla de inicio y el contrato de condiciones de uso de la plataforma. #### **Kerno** * Añadidas columnas en la tabla **Entity** se han añadido las columnas **data_access** e **information_access**para la nueva funcionalidad de información de acceso. * Cambio en **attribute_value**sobre la columna i18n para adaptar a los cambios realizados sobre los idiomas. * Eliminación de las validaciones de **MIN_LENGHT** y **MAX_LENGHT** en atributos de tipo **ENRICHED_TEXT_AREA** y **ENRICHED_TEXT_AREA_INTERNATIONAL** #### **Minerva** * Ampliación de la tabla **saved_search** para acomodar diferente filtros para ambos portales. Añadiendo **search_place** y cambiando **sorting_type** a ser una cadena de texto. ### **Bugs** Toda la información relativa a los problemas y limitaciones que aplican a esta versión o que han sido corregidas están disponibles en la documentación de **Portal de soporte \> Problemas y limitaciones conocidos**. --- version: "Working version" language: "es" --- # Versiones pasadas En esta sección se pone a disposición la **documentación oficial de versiones anteriores** de Anjana Data Platform, con el objetivo de facilitar la consulta histórica y el soporte a instalaciones que aún se encuentren operando sobre dichas versiones. Aquí se incluyen los **documentos en formato PDF** correspondientes a versiones ya no vigentes, como **v23.1** y **v4.4**, que recogen la información funcional y técnica disponible en el momento de su publicación. Esta documentación se ofrece **exclusivamente a modo de referencia**. Para nuevas implantaciones, evolutivos o consultas sobre la versión en curso, se recomienda utilizar siempre la documentación publicada bajo la versión actual de la plataforma. --- version: "Working version" language: "es" --- # 23.1 Documentación Release Notes [PUB_Anjana Data 23.1 - RN - Release notes_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_6541b9a21be19dca34c2bb8ccdebc18451c9134638502c83c1d984ca607740a2/PUB_Anjana%2520Data%252023.1%2520-%2520RN%2520-%2520Release%2520notes_V1.0.pdf.md?cb=489bdc6d219a9515800ef2d14f60e5f9) [PUB_Anjana Data - RN 23.1 patch 8 (24_04_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_d8cef5930caa5fc751bad0f30cfe20f4f4ea1a8bcce9820e3acf39956f3eddd6/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25208%2520(24_04_2024)_V1.0.pdf.md?cb=cdbc7ba8cac77f2ee12b9348840485a1) [PUB_Anjana Data - RN 23.1 patch 7 (22_04_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_19662cfafd718570a65db6f441bd2babdf7f59adb4bf65b1a77affba376f591d/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25207%2520(22_04_2024)_V1.0.pdf.md?cb=9fc5a13fd1ddff324e0a69831ddfa11a) [PUB_Anjana Data - RN 23.1 patch 6 (12_04_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_1d8fab060fc8497bc799dd63d839cadd3fdbb9850feba5eb9fd5495a806a8196/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25206%2520(12_04_2024)_V1.0.pdf.md?cb=5a905e810c1c3d53831e926e7f5678f9) [PUB_Anjana Data - RN 23.1 patch 5 (19_03_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_283c0e5e7886ab75fdb1cc9e3eaa481570af5aeedfe3c9274f61c62a949cf07b/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25205%2520(19_03_2024)_V1.0.pdf.md?cb=599bb753229f44c4516df1e1d562727d) [PUB_Anjana Data - RN 23.1 patch 4 (12_03_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_818bf4093e0b070e7faa97aea746ba0847a6ea3507df1b232f7de6a077b1b037/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25204%2520(12_03_2024)_V1.0.pdf.md?cb=15016876b07b9147e4f47f1105ae998f) [PUB_Anjana Data - RN 23.1 patch 3 (16_02_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_3529c572aa9b61864f978bae79b1e0204f45f74f1add4c47e4ae4cecd43e8031/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25203%2520(16_02_2024)_V1.0.pdf.md?cb=853fbf9eb4d40d86c86d5209bdd7194f) [PUB_Anjana Data - RN 23.1 patch 2 (07_02_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_16ebedad3be112f8cd52001664a9dc512efe3ecfc24d72c7748202a542e23d5c/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25202%2520(07_02_2024)_V1.0.pdf.md?cb=d31368a2967e672651343e8de88f9005) [PUB_Anjana Data - RN 23.1 patch 1 (05_02_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_30279c5ce7c1da98a9ea34ce79733b303b55968de2ebe1b57955f2b1945970cc/PUB_Anjana%2520Data%2520-%2520RN%252023.1%2520patch%25201%2520(05_02_2024)_V1.0.pdf.md?cb=153c211f2424bf23369483a842d19952) [PUB_Anjana Data - PROD.RN 23.1 patch 19 (13_03_2025)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_997467d6f508e9bd7881c92cd0d7b0ad688197602a1499f30583ffb5c5b1ce1b/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252019%2520(13_03_2025)_V1.0.pdf.md?cb=ac78d4895314e2ed5fe326478aeacab8) [PUB_Anjana Data - PROD.RN 23.1 patch 18 (20_02_2025)_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_f21dd761d9adb00ab1f50ab57db41b96512873e61b671b386567323454bf3829/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252018%2520(20_02_2025)_V1.1.pdf.md?cb=a188af43fdda8d9dd0ffe76967eecc8f) [PUB_Anjana Data - PROD.RN 23.1 patch 17 (15_01_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_acffb6b74aa18d6e3b5e25fe169f23dd6ee1bf09b5b267b9aac2c435779be9f0/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252017%2520(15_01_2024)_V1.0.pdf.md?cb=6cdcf09823c60d273bccc81362b454c2) [PUB_Anjana Data - PROD.RN 23.1 patch 16 (17_10_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_6624529528e5e9350430f9064f46515460431f053a81902aab5068fdc6766772/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252016%2520(17_10_2024)_V1.0.pdf.md?cb=063573be97853f6860b5d20d16028a57) [PUB_Anjana Data - PROD.RN 23.1 patch 15 (03_10_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_5a7c3802176ac9d659b48881d7aad3492536ccef01009950423b2bbdeb0890b2/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252015%2520(03_10_2024)_V1.0.pdf.md?cb=af935dbe298056560fdcd84ea2c144e7) [PUB_Anjana Data - PROD.RN 23.1 patch 14 (09_09_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_d92d5f978ef9c32d2c12d652b54bf291f9b909c848b6b6c7a43ee88d0fd48e3f/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252014%2520(09_09_2024)_V1.0.pdf.md?cb=9d4b3dd8c28ed9a2093540aee24aaf6b) [PUB_Anjana Data - PROD.RN 23.1 patch 13 (26_08_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_a407cde75e07aff69506ace38078aabff726c2dc7341718ef1c5dbca30b7358a/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252013%2520(26_08_2024)_V1.0.pdf.md?cb=806ffc88e2bb6947bd53fe30f9471106) [PUB_Anjana Data - PROD.RN 23.1 patch 12 (19_07_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_ffa4897f539826e081f1ae6201375152e616083d57c7a4ec152d4728d247ae4b/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252012%2520(19_07_2024)_V1.0.pdf.md?cb=baf3419bf612af667f1d76e66d81b56f) [PUB_Anjana Data - PROD.RN 23.1 patch 11 (28_06_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9635595db98f5dfc7eb953aa9fb1d33c181d10a5b5de83cf5cdf1c74007259aa/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252011%2520(28_06_2024)_V1.0.pdf.md?cb=8addc04e389d00ab479ccf70226f87c3) [PUB_Anjana Data - PROD.RN 23.1 patch 10 (25_06_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_245135be94adf6f0ff0a95b2469fa248b60810930da5cb70789627cc217df5cf/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%252010%2520(25_06_2024)_V1.0.pdf.md?cb=91c0b0510424d75916ab34946d9b2109) [PUB_Anjana Data - PROD.RN 23.1 patch 9 (31_05_2024)_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_314a137208006a25e57ee6b9e73f0c810fc8745cecb0229bc0b5c2bcd447be12/PUB_Anjana%2520Data%2520-%2520PROD.RN%252023.1%2520patch%25209%2520(31_05_2024)_V1.0.pdf.md?cb=eddb50aae42d80036a402abe6025fc95) Funcionamiento [PUB_Anjana Data 23.1 - DOC - Tipos de ARI_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_05babf2a88ccecfb6b051a558b0745b690e851c039c7e285994f084e61d0b6be/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Tipos%2520de%2520ARI_V1.0.pdf.md?cb=ee8345843d113ee64918ae8a961347a7) [PUB_Anjana Data 23.1 - DOC - Interceptor de Inventario_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_12ad247e4d8d53b0f7d30669cddc5c1fdc8d22dab454588065903b1f517dd2c8/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Interceptor%2520de%2520Inventario_V1.0.pdf.md?cb=ce081003a066bcec95527f061ce32684) [PUB_Anjana Data 23.1 - DOC - Guia de usuario_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_cd7d3ee3fb1136c19b68e91767ec69ff8a116620bfb3cf7f7194ce8a0d882cdc/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Guia%2520de%2520usuario_V1.1.pdf.md?cb=138c1021e70d764cfafe3fc49d0fff71) Configuración [PUB_Anjana Data 23.1 - DOC - Guía de configuración de Workflows_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_ce8bc35bfbb7c11051542102ff7c9e99d02184310e03d8a7cdd8867f74b2b0b4/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Gu%25C3%25ADa%2520de%2520configuraci%25C3%25B3n%2520de%2520Workflows_V1.1.pdf.md?cb=a8d7aaaae3dd110c36f4bcc25bd5052c) [PUB_Anjana Data 23.1 - DOC - Activación de licencia_v1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b68f2a4fe67ca3018784987105783bc0a505e88d5880926f21110e4686b9d862/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Activaci%25C3%25B3n%2520de%2520licencia_v1.0.pdf.md?cb=6e160f9bba105280e6df58309edbe30f) [PUB_Anjana Data 23.1 - DOC - Guía de configuración funcional_V1.4.pdf](https://wiki.anjanadata.com/__attachments/a_6358665fa2137a842e67bf9daf428cdae1e634ca1d4c29a092247ad32b418400/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520%2520Gu%25C3%25ADa%2520de%2520configuraci%25C3%25B3n%2520funcional_V1.4.pdf.md) [PUB_Anjana Data 23.1 - CONF - Iconografia y CSS_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_0678d1fc5d0e8a98eb012f9a0ffbdfb740a57c272815ba48aae922fd8601b11c/PUB_Anjana%2520Data%252023.1%2520-%2520CONF%2520-%2520Iconografia%2520y%2520CSS_V1.1.pdf.md?cb=00c3d3517ec027022361eeeb698ec31c) [PUB_Anjana Data 23.1 - CONF - Configuración tripletas_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_6334f62cacde1ef309657686a61962a4b42b637e1969fedcabd2a7f3407e813a/PUB_Anjana%2520Data%252023.1%2520-%2520CONF%2520-%2520Configuraci%25C3%25B3n%2520tripletas_V1.0.pdf.md?cb=7eec18a5ab423dcfd24daed43e4c70ba) [PUB_Anjana Data 23.1 - DS - Guía de configuración técnica_V1.2.pdf](https://wiki.anjanadata.com/__attachments/a_03a687c725b0000591efe95b62d0119e5ce0a62559b2e99c04dafd1b4d07027f/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Gu%25C3%25ADa%2520de%2520configuraci%25C3%25B3n%2520t%25C3%25A9cnica_V1.2.pdf.md?cb=9cbdb3605d03e62b21dc183ae3043855) [PUB_Anjana Data 23.1 - DOC - Visualización por rol_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_95b1898eb66daa7af193228225cae65df9a1ac33db16d0999da6adb4e202315f/PUB_Anjana%2520Data%252023.1%2520-%2520DOC%2520-%2520Visualizaci%25C3%25B3n%2520por%2520rol_V1.0.pdf.md?cb=3c8bbf8b8cf51227467fe56b7b3aa9c4) Despliegue [PUB_Anjana Data 4.s5 - DS - K8s - Manual de despliegue con Statefulset k8s_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_8f936f4279b1d3e1de596173b32619419e6f99451debb01cd61330f10ac00fc7/PUB_Anjana%2520Data%25204.s5%2520-%2520DS%2520-%2520K8s%2520-%2520Manual%2520de%2520despliegue%2520con%2520Statefulset%2520k8s_V1.0.pdf.md?cb=aa8d0cd1e4eb134b7b0d1eae05b6f754) [PUB_Anjana Data 4.o5 - DS - K8s - Manual de despliegue con operador k8s_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_ab3391b8b762ae1df68f68d316b0c140f937d2c58c3a73b2553ac7f1dce27d88/PUB_Anjana%2520Data%25204.o5%2520-%2520DS%2520-%2520K8s%2520-%2520Manual%2520de%2520despliegue%2520con%2520operador%2520k8s_V1.0.pdf.md?cb=6b3ac6562aed8a45c2f3514b5b612306) [PUB_Anjana Data 4.a6 - DS - Ansible - Manual de despliegue con kit Ansible_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_0f871d780a250d8f0c0e0eec6bd28471d9f02f44f7ea85fa13be6ef600cbad77/PUB_Anjana%2520Data%25204.a6%2520-%2520DS%2520-%2520Ansible%2520-%2520Manual%2520de%2520despliegue%2520con%2520kit%2520Ansible_V1.0.pdf.md) Integraciones - Autorización/Autenticación [PUB_Anjana Data 23.1 - DS - Integración OKTA_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_271d1a222887cb2d460c1ad2137a203da5b24436b1cade74bcd7180726b4478a/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520OKTA_V1.0.pdf.md?cb=7d79c1cc65adb27d8e95902936b73d4e) [PUB_Anjana Data 23.1 - DS - Integración LDAP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_bde51c40d45a5fbae0e4382aa7b4dbcd0a6e5e7d88e0bb0a78803f24cbec9798/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520LDAP_V1.0.pdf.md?cb=21fd75e287daa302a4d9c6d64362dc77) [PUB_Anjana Data 23.1 - DS - Integración GCP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_686cf7914c4c5eafefd58f95476543b62bdbf60973061b4fd65ed7c437fd0246/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520GCP_V1.0.pdf.md?cb=82cdd5435c6dc50467eca5f54f57d4e4) [PUB_Anjana Data 23.1 - DS - Integración Azure_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_34eb181549146337213c070451670b1bdb95eb0e27151f26941d39546e0d8096/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520Azure_V1.0.pdf.md?cb=f228c0396884891be4f33d07595834d1) [PUB_Anjana Data 23.1 - DS - Integración AWS_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_07fd5595e5f99cffde4a64bed8994bef2c9a58cee72bd00add7327a7febce0f9/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520AWS_V1.0.pdf.md?cb=991c51193cbfdc4d18b0aa779b8a5a42) Integraciones - Tot Plugins [PUB_Anjana Data 23.1 - DS - Tot plugin Azure AD_V1.2.pdf](https://wiki.anjanadata.com/__attachments/a_0bf49d3271f63125d8a4a651e8b3e1ba80463c71ae168f97f71a3bcb16bd5943/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Azure%2520AD_V1.2.pdf.md?cb=79b3c72d992ffd5e18e2a2c1218442f0) [PUB_Anjana Data 23.1 - DS - Tot plugin AWS S3_v1.1.pdf](https://wiki.anjanadata.com/__attachments/a_8ac642cf867f8a1be2830a12f76ad6656a2024ff772c1dcd8e275ae6125abd98/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520AWS%2520S3_v1.1.pdf.md?cb=0af6ba340ac4fa1bbb3df365b66e4f76) [PUB_Anjana Data 4.5 - DS - Tot plugin AWS IAM_v1.0.pdf](https://wiki.anjanadata.com/__attachments/a_cbbd872d26cbecaaf8612e9709cfa463840bbda743692f864db6f4131d363936/PUB_Anjana%2520Data%25204.5%2520-%2520DS%2520-%2520Tot%2520plugin%2520AWS%2520IAM_v1.0.pdf.md?cb=0c5e2b5fd1631b6a474765ea0691dfdc) [PUB_Anjana Data 23.1- DS - Tot plugin GCP IAM_v1.0.pdf](https://wiki.anjanadata.com/__attachments/a_0c1c55c0f3fd0ae30f7c43ebe3a38dc1956550dbb3e274df29ef5d446932474b/PUB_Anjana%2520Data%252023.1-%2520DS%2520-%2520Tot%2520plugin%2520GCP%2520IAM_v1.0.pdf.md?cb=d0d448d41253108aa026b8be108df380) [PUB_Anjana Data 23.1 - DS - Tot plugin JDBC_V1.5.pdf](https://wiki.anjanadata.com/__attachments/a_039e3cef7f8d72a40049e86dedc600f3eb890dbe31883fefc749d5275d758896/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC_V1.5.pdf.md?cb=8916a250a3fc0061026111deac1df005) [PUB_Anjana Data 23.1 - DS - Tot plugin GCP BigQuery_v1.0.pdf](https://wiki.anjanadata.com/__attachments/a_0a9424b16bfbe6a8caf1a929d4ef5cf339fdc9f7472fb5b96a2d4629139b51df/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520GCP%2520BigQuery_v1.0.pdf.md?cb=4e5b96b5683ee9c35864c105d7ac6ffa) [PUB_Anjana Data 23.1 - DS - Tot plugin Azure AD_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9b8a379d55f5076b3caa7cb36ae22fb8c0f97c6f0814e1b17338872c371e4eff/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Azure%2520AD_V1.0.pdf.md?cb=cf8592ecde98ecf650c1a55e4c8fbf07) [PUB_Anjana Data 23.1 - PROD.INS - Tot plugin SQL Server_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_cca711dc6c9be330f0992a14bb092f4c3ea97eb5afffe7142e33a3763397ad93/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Tot%2520plugin%2520SQL%2520Server_V2.0.pdf.md?cb=fa1f3ef4b5e6c0d1231b4ec6a30fd18f) [PUB_Anjana Data 23.1 - PROD.INS - Tot plugin PowerBI_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_2817e3616db5df889a8ba7d9f2e96cbdb122f3bd0d7acd47afc8c4b27a3a259f/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Tot%2520plugin%2520PowerBI_V2.0.pdf.md?cb=b605d83bb16c49bdc5f4a3cccf15abcc) [PUB_Anjana Data 23.1 - PROD.INS - Tot plugin LDAP_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_03dc603f27d78d343cf1281a0d66b9f9d2ef923fbe18d4a0542297de629e6ac8/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Tot%2520plugin%2520LDAP_V2.0.pdf.md?cb=0ed89c3b425ec66c201dd2c802aff346) [PUB_Anjana Data 23.1 - PROD.INS - Tot plugin JDBC Oracle.pdf](https://wiki.anjanadata.com/__attachments/a_7633fd595efde0116b6816f0832d7afda69953c79e47b9dae946e0884472bebf/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Tot%2520plugin%2520JDBC%2520Oracle.pdf.md?cb=30036b82ea3ba046db75ca34f3ceb8b9) [PUB_Anjana Data 23.1 - PROD.INS - Tot plugin Aqtiva.pdf](https://wiki.anjanadata.com/__attachments/a_643296f8a6f3565ae75a17201bc95e5df12c8b012b5ce98d96051eb53841ad66/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Tot%2520plugin%2520Aqtiva.pdf.md?cb=bffd053783b476e38323f38278111c2c) [PUB_Anjana Data 23.1 - PROD.INS - Extracción de Metadata de Ficheros_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_56ce6c70f3a44e0e29cbc85aa45c58059d145667adb630aa99b9b438e1feec6d/PUB_Anjana%2520Data%252023.1%2520-%2520PROD.INS%2520-%2520Extracci%25C3%25B3n%2520de%2520Metadata%2520de%2520Ficheros_V1.0.pdf.md?cb=4f66d45aa6f349697fb9e979d8917927) [PUB_Anjana Data 23.1 - DS - Tot plugin Tableau_v1.0.pdf](https://wiki.anjanadata.com/__attachments/a_0d7f137d4a17f0a90a4dd9d5bb618cd88b4c741670d5673502dfc84ca6856a15/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Tableau_v1.0.pdf.md?cb=573205a2041eea8b0dcd8ae1d607f466) [PUB_Anjana Data 23.1 - DS - Tot plugin SQL Server_V1.3.pdf](https://wiki.anjanadata.com/__attachments/a_14ad81121950e761fad9a005bf8192644f65874e2add87795fb99a969de50177/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520SQL%2520Server_V1.3.pdf.md?cb=47e4af2c646b78752e2e4522d09b3f0d) [PUB_Anjana Data 23.1 - DS - Tot plugin Redshift_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_04e82c8a50783de0ae97a8fb2b10c99d7e7d793311cc4be3353ba42367294687/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Redshift_V1.0.pdf.md?cb=e346d8b9f456554e6a36504ad76433c8) [PUB_Anjana Data 23.1 - DS - Tot plugin Denodo_V1.2.pdf](https://wiki.anjanadata.com/__attachments/a_1ad26fe6ca96f017f9bb1c02442e98f67ce0f4f44451ddb23f0456bae3128f1d/PUB_Anjana%2520Data%252023.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Denodo_V1.2.pdf.md?cb=5ce4cbeb41e3ce0dc99a56817fcfafd6) --- version: "Working version" language: "es" --- # 4.4 Documentación Release Notes [PUB_Anjana Data 10_02_2023 - RN - Release Notes_V3.0.pdf](https://wiki.anjanadata.com/__attachments/a_8c80dcfe0807f02b5bd797d9d0f0873842b17663c137c654d989612e83f92d4f/PUB_Anjana%2520Data%252010_02_2023%2520-%2520RN%2520-%2520Release%2520Notes_V3.0.pdf.md?cb=8bcc4d4673a4e25c0db3be83abd04bc5) [PUB_Anjana Data 4.4.2 - RN - Release Notes Zeus.pdf](https://wiki.anjanadata.com/__attachments/a_1e05dd4012df77e63a0dec6e8b5834c316721e3bf483b51f12e9c5eb2034db34/PUB_Anjana%2520Data%25204.4.2%2520-%2520RN%2520-%2520Release%2520Notes%2520Zeus.pdf.md?cb=aa185e8f62ca570bbd8c9ba5fd055f50) [PUB_Anjana Data 4.4.1 - RN - Release Notes (Zeus, Portal)_V2.1.pdf](https://wiki.anjanadata.com/__attachments/a_09ceccb40df9e5516e78d39c2052e3ba0923998bd8429d0713133e125224e19e/PUB_Anjana%2520Data%25204.4.1%2520-%2520RN%2520-%2520Release%2520Notes%2520(Zeus,%2520Portal)_V2.1.pdf.md?cb=47614fbe36e365dd42b290b97fd63879) [PUB_Anjana Data 4.4 - RN - Release notes.pdf](https://wiki.anjanadata.com/__attachments/a_037b30cd3a7c87a7e3324ba16b149e0115144805041538ea4702102d33d00c9c/PUB_Anjana%2520Data%25204.4%2520-%2520RN%2520-%2520Release%2520notes.pdf.md?cb=e129836fc01140a6558975b4720d9cb2) [PUB_Anjana Data - RN - 28_04_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_83be495bb7a997d2ff56400080e2783cc08fbff1e9ebede3a8d7220e487acc3c/PUB_Anjana%2520Data%2520-%2520RN%2520-%252028_04_2023_V1.0.pdf.md?cb=5a20af660317d2f1de463a34b062b68c) [PUB_Anjana Data - RN - 25_04_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9597bfd090b7e1a0c48d0059ac507c8e7354c6c2078a7edaef635ded89f681f3/PUB_Anjana%2520Data%2520-%2520RN%2520-%252025_04_2023_V1.0.pdf.md?cb=41d951ac1aabd0c5157f1785f2f89825) [PUB_Anjana Data - RN - 22_04_2024.pdf](https://wiki.anjanadata.com/__attachments/a_1fd20502f8840dd220ed16e6482771231291e16992704535572ebcbd92dcc2b7/PUB_Anjana%2520Data%2520-%2520RN%2520-%252022_04_2024.pdf.md?cb=c222cf3c5c3928ac00a622ccf27f3e45) [PUB_Anjana Data - RN - 17_05_2023_V3.0.pdf](https://wiki.anjanadata.com/__attachments/a_b89706c52873ad3a74b976c53312cfe6f6642211340020d94faab30512ce5562/PUB_Anjana%2520Data%2520-%2520RN%2520-%252017_05_2023_V3.0.pdf.md?cb=4c39b9b6ed18c8c6938c599da17d07ac) [PUB_Anjana Data - RN - 16_03_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9eee20e1fbb553365111487f1f9bce6989bbedcfe15f7b3ee392a34e77e49d3c/PUB_Anjana%2520Data%2520-%2520RN%2520-%252016_03_2023_V1.0.pdf.md?cb=bdff6d842b9e91f5960d36df0dc6065b) [PUB_Anjana Data - RN - 14_06_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_bb36aa026dc4d9faa56575b7e33beed1d1ead9ba953665c83b3b507048c7ed61/PUB_Anjana%2520Data%2520-%2520RN%2520-%252014_06_2023_V1.0.pdf.md?cb=3db7b092c4a19dbe1df6786737dd2793) [PUB_Anjana Data - RN - 14_04_2023_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_8ab00489dd75443fa868d65274b35c744fa64d47d3afcce0367ebd1df22c1796/PUB_Anjana%2520Data%2520-%2520RN%2520-%252014_04_2023_V2.0.pdf.md?cb=6a3cf534459dff0bddb65304eddd0d15) [PUB_Anjana Data - RN - 07_11_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b2e572756dc1674770c9e54e71aac445db491ab6d0d3a46a5c8ad16a8dc97dcb/PUB_Anjana%2520Data%2520-%2520RN%2520-%252007_11_2023_V1.0.pdf.md?cb=bdd122cec4d59e02f4eb82b43dd2cdfc) [PUB_Anjana Data - RN - 06_07_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_349e9d22650081cbf8f6a25d7ff13c7aff17146f9c6b48f3f1afc68fe3e610d1/PUB_Anjana%2520Data%2520-%2520RN%2520-%252006_07_2023_V1.0.pdf.md?cb=0227c1aab7436fe0845dc712222cddd6) [PUB_Anjana Data - RN - 05_12_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_49ed4bde84211d7fbc523d9021b705fd74d86e1656f0131c735d1178b9807146/PUB_Anjana%2520Data%2520-%2520RN%2520-%252005_12_2023_V1.0.pdf.md?cb=c26bb9a8c7fcaac4cc1308afa4521f60) [PUB_Anjana Data - RN - 05_04_2023_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_fcba8b5dc11a94e73202a5c3e1347af5a281f872c12a7111b5620a76c99cad82/PUB_Anjana%2520Data%2520-%2520RN%2520-%252005_04_2023_V1.0.pdf.md?cb=d1999a73df7d7c3427b7f76dc8ac11a1) [PUB_Anjana Data - RN - 02_03_2023_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_549de2e09eb16713612c254520db1c00eee4e21b2ed4acaf73039f22062da0ae/PUB_Anjana%2520Data%2520-%2520RN%2520-%252002_03_2023_V1.1.pdf.md?cb=691f43adc1966787106c8dca6ffbb374) Funcionamiento [PUB_Anjana Data 4.4 - DOC - ARI types_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_1aecf43f110c7e6019931cec469b83f26cc410cfcd3a0fc2bcbe282770ffdcfc/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520ARI%2520types_V1.0.pdf.md?cb=6aa0ec808b0cc437cb3f4d0f74baed13) [PUB_Anjana Data 4.4 - DOC - Inventory interceptor_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_813bd93aa9be087cbe7884dd774f4d492004c3f8731735c33564ea951a18e376/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Inventory%2520interceptor_V1.0.pdf.md?cb=41d193bd5d13e56924bd87d9cf1b23df) [PUB_Anjana Data 4.4 - DOC - Guia de usuario_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_62c5a3e11d325c3aee3ad0bf28d16a280a589c514dfd815c1bf1649aacf5ed32/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Guia%2520de%2520usuario_V1.0.pdf.md) Configuración [PUB_Anjana Data 4.4 - DOC - Plan de pruebas configuración_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_2c70140b841dffd6e47dffaf650c5a4f6175dc9dc096d9d7554eb0d506774435/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520%2520Plan%2520de%2520pruebas%2520configuraci%25C3%25B3n_V1.0.pdf.md?cb=bce2427d255fa599665e40a9c0e66555) [PUB_Anjana Data 4.4 - DOC - Guía de configuración_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_0420ac428681642be16ffa9a89de7bd237581ebd721198573942fe12ad3ff0c3/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520%2520Gu%25C3%25ADa%2520de%2520configuraci%25C3%25B3n_V2.0.pdf.md?cb=35ebf036a065681beaa57c4570d86aba) [PUB_Anjana Data 4.4 - CONF - Iconografia y CSS_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b6248b980ee09c9f37e2623c329192a18f97c972c5b47fc920937ae8ea110a7e/PUB_Anjana%2520Data%25204.4%2520-%2520CONF%2520-%2520Iconografia%2520y%2520CSS_V1.0.pdf.md?cb=ff9909c0679ac1895cc595f0dd50c292) [PUB_Anjana Data 4.4 - CONF - Configuración tripletas_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_4c743f03bd4e1b0a9a8899e0a1c6abbef224d600b7263994fbab8ef4cb3fa7e7/PUB_Anjana%2520Data%25204.4%2520-%2520CONF%2520-%2520Configuraci%25C3%25B3n%2520tripletas_V1.0.pdf.md?cb=eec7415d4d2d313eb18f7b29510e1caf) [PUB_Anjana Data 4.4 - DOC - Guía rápida de Configuración_V1.2.pdf](https://wiki.anjanadata.com/__attachments/a_a4c30203544692e9249978d4e0efbcf09dbbd986526a161c7c1f6d2c36303531/PUB_Anjana%2520Data%25204.4%2520%2520-%2520DOC%2520-%2520Gu%25C3%25ADa%2520r%25C3%25A1pida%2520de%2520Configuraci%25C3%25B3n_V1.2.pdf.md?cb=0df0f5e1bb21bef4d59db413713e6229) [PUB_Anjana Data 4.4 - DS - Configuración técnica de Portal y microservicios_V3.0.pdf](https://wiki.anjanadata.com/__attachments/a_9fbe987a4dd36ad42e3cfa0180ccf4b8aba1e89aa2f309c23b81b8a28d0bacf1/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Configuraci%25C3%25B3n%2520t%25C3%25A9cnica%2520de%2520Portal%2520y%2520microservicios_V3.0.pdf.md?cb=e94e34b9a8946e49c5b659899a3e6a0d) [PUB_Anjana Data 4.4 - DOC - Guía de configuración de Workflows_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_4d75bab7cdbc9e79fd5c8cea252f0a24e0fc48666b356f39797550691421711e/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Gu%25C3%25ADa%2520de%2520configuraci%25C3%25B3n%2520de%2520Workflows_V1.0.pdf.md?cb=d561138a68b74052a94565c6443fbd66) [PUB_Anjana Data 4.4 - DOC - Activación de licencia_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_e80e9df0cb216a50e9895069ffca00edcd96a62a0d23cbba11c30afeeaccb73b/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Activaci%25C3%25B3n%2520de%2520licencia_V1.0.pdf.md?cb=96dc9172cbca9386bae2b9d9e28ef8f2) Despliegue [PUB_Anjana Data 4.s4 - DS - K8s - Manual de despliegue con Statefulset k8s_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_c4a30d9a334192c0dd0aabf03b498ba1fdd2a42d875b0b69a8cc09dc084144bb/PUB_Anjana%2520Data%25204.s4%2520-%2520DS%2520-%2520K8s%2520-%2520Manual%2520de%2520despliegue%2520con%2520Statefulset%2520k8s_V1.0.pdf.md?cb=2e54f4a12575242638b48f1e9e201f15) [PUB_Anjana Data 4.o4 - DS - K8s - Manual de despliegue con operador k8s_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_ada6feafa7146c7e774fadfe7e4e2deec2b6441c680721a0e200339d9caf8ce7/PUB_Anjana%2520Data%25204.o4%2520-%2520DS%2520-%2520K8s%2520-%2520Manual%2520de%2520despliegue%2520con%2520operador%2520k8s_V2.0.pdf.md?cb=deb3253fddbb17d7d3e92d4194530b99) [PUB_Anjana Data 4.a5 - DS - Ansible - Manual de despliegue con kit Ansible_V3.0.pdf](https://wiki.anjanadata.com/__attachments/a_267372a65114752895d6b6a178f07fc5a2597dbd77717d6294c058539ab0c793/PUB_Anjana%2520Data%25204.a5%2520-%2520DS%2520-%2520Ansible%2520-%2520Manual%2520de%2520despliegue%2520con%2520kit%2520Ansible_V3.0.pdf.md?cb=76ff7f71171a29ff124de9d945fbc50f) Integraciones - Autorizaciópn/Autenticación [PUB_Anjana Data 4.4 - DS - Integración OKTA_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b1751e9f4c2c588c6cca6cb9c2cbbfd5a1357a671bef95bc55f3a925e729fae4/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520OKTA_V1.0.pdf.md?cb=7b358fcf3d3e96f4053d5ee3e279e097) [PUB_Anjana Data 4.4 - DS - Integración LDAP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b16f4b34eb2057d5f07327906c0acb7b53b2d8aed43080ef8afbc213deb0aefc/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520LDAP_V1.0.pdf.md?cb=2c4bf373d6f0e7cf7f464076bc34810c) [PUB_Anjana Data 4.4 - DS - Integración Genérico_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_b459816aa03a788a2d45bb7a6c547432cbf7bc1136830f7759a0f40d36fe2c52/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520Gen%25C3%25A9rico_V1.0.pdf.md?cb=7195233dbee536af5e537f88dc87c0e0) [PUB_Anjana Data 4.4 - DS - Integración GCP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_722ba40b876d3650a60ec6240101b8d43994f10a4659105677575079c377b9f5/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520GCP_V1.0.pdf.md?cb=e20243cd916d45ad9d7e7b63f67d12f4) [PUB_Anjana Data 4.4 - DS - Integración Azure_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_34cf5787684a01ac40e66df528ed200a8168aff6097534571dce73747038e34b/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520Azure_V2.0.pdf.md?cb=33f8a720ec416a248d9e84550b47f32d) [PUB_Anjana Data 4.4 - DS - Integración AWS_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_eea52d24bcc34345edae87ce9a732e77b670bda95c21cd8d697c555594eed50b/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Integraci%25C3%25B3n%2520AWS_V1.0.pdf.md?cb=c5a91fbffd2154ac3a72dfff4a7c0b8a) Integraciones - Plugins [PUB_Anjana Data 4.4.2 - DS - Tot plugin Aqtiva_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_dba97ef334ef7f6314d6474bb868785c54103687c435346398e3decefb0fb970/PUB_Anjana%2520Data%25204.4.2%2520-%2520DS%2520-%2520Tot%2520plugin%2520Aqtiva_V2.0.pdf.md?cb=72844ca262ebf57063954ab5f00a6b97) [PUB_Anjana Data 4.4.1 - DS - Tot plugin Ranger_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_faded06c79fed79ec6f4cf8488b5b57c428c4b99b38eef69672c34682ec2eb63/PUB_Anjana%2520Data%25204.4.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Ranger_V1.0.pdf.md?cb=582753c4d7fa179f421894654fe48d59) [PUB_Anjana Data 4.4.1 - DS - Tot plugin JDBC Oracle_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_8f2840e4e0c4c4a62e57141549e5dc61c10f367408e426eb225d174d2bf79a6c/PUB_Anjana%2520Data%25204.4.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC%2520Oracle_V1.1.pdf.md?cb=de43f6bad5133a5260bc9be5e96d8191) [PUB_Anjana Data 4.4.1 - DS - Tot plugin Denodo_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9098e1ed3469bc82e418ee774217fc60a4082d93351aab000348cdb2d17a0985/PUB_Anjana%2520Data%25204.4.1%2520-%2520DS%2520-%2520Tot%2520plugin%2520Denodo_V1.0.pdf.md?cb=732d34534a908aa7c0108fe53449acb8) [PUB_Anjana Data 4.4.0 - DS - Tot plugin Tableau_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_17dc05b16b865cfc8a99cee460cfbb2576b6d972864e76d315dd60a4966feb1e/PUB_Anjana%2520Data%25204.4.0%2520-%2520DS%2520-%2520Tot%2520plugin%2520Tableau_V1.0.pdf.md?cb=24eeedc599117a2e9ef319246dabdf24) [PUB_Anjana Data 4.4 - DS - Tot plugin SQL Server_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_9ee7f753860bbeb0372919cde50ba9fa73a300cacabb81e82aa8cddefa1f8504/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520SQL%2520Server_V1.0.pdf.md?cb=27ddbd76b8a6354c9ae2f52f1127a879) [PUB_Anjana Data 4.4 - DS - Tot plugin Redshift_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_7597ce1e71e429c27b0fb61729b0d1ce24fe852ced1d07499627fb55a4c84fee/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Redshift_V1.0.pdf.md?cb=ae1b92f5c8e664c03a689f95a3bc4792) [PUB_Anjana Data 4.4 - DS - Tot plugin PowerBI_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_7c13a007c244155a072d322fc0750af264c552c29a127057fb58770036577379/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520PowerBI_V1.0.pdf.md?cb=5e06c5911e5aeb9cdc434577d83646f5) [PUB_Anjana Data 4.4 - DS - Tot plugin LDAP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_a24baad968f2ae280e49535bf9150c0de72fb6ea7501f68a5daab70c9d816ccd/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520LDAP_V1.0.pdf.md?cb=9f6f8c18689575d2d02e3933891c5e46) [PUB_Anjana Data 4.4 - DS - Tot plugin JDBC_V4.1.pdf](https://wiki.anjanadata.com/__attachments/a_3c00286ba74289902a6ebc3e6e0e0e13e904a56e23dc0ebd40deb1e40f86b29d/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC_V4.1.pdf.md?cb=ae309d9ff537da358ec253dff60a9239) [PUB_Anjana Data 4.4 - DS - Tot plugin JDBC Oracle_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_437a6648d5c5936dcf8f43c0e5ac7ff1ba82b00655de4ee05b2a37bf9281738a/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC%2520Oracle_V1.0.pdf.md?cb=9eb7bf690354d3c9c2041d64c1157887) [PUB_Anjana Data 4.4 - DS - Tot plugin GCP Storage_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_cd1fab0df19f87df7ce166cb7bcf4112b0de814c86fff0dcd3d21e101ea640bb/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520GCP%2520Storage_V1.0.pdf.md?cb=c874cefafcd515b9664c3e18905bd577) [PUB_Anjana Data 4.4 - DS - Tot plugin GCP IAM_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_8f001cf7774606ae88d4fa9b6a07b9e71e996516227f7b5f6d5e0561e1762507/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520GCP%2520IAM_V1.0.pdf.md?cb=2730783ef18f6ebd108d5b4d03ec5dc0) [PUB_Anjana Data 4.4 - DS - Tot plugin GCP BigQuery_V2.0.pdf](https://wiki.anjanadata.com/__attachments/a_38d9119e27df5496e25f4e6c1109ec4e1b79ef90cf6fa35558d0d9fdd8582bd7/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520GCP%2520BigQuery_V2.0.pdf.md?cb=6fe35ea2b4776987968b8fb501d6782a) [PUB_Anjana Data 4.4 - DS - Tot plugin Denodo_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_712d8c11f39f60c4bae271c7236e6d7549d073632be1e04e1383ae5f40691eea/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Denodo_V1.0.pdf.md?cb=761763c20a492afe71341ae81e7c8eea) [PUB_Anjana Data 4.4 - DS - Tot plugin Azure Storage_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_a76f7cd162f8074fd77794a6801b5350fc336b9ef811c894eee571cee4f8c690/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Azure%2520Storage_V1.0.pdf.md?cb=263815511e6048ae78c43f1a64cc3fb1) [PUB_Anjana Data 4.4 - DS - Tot plugin Azure AD_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_3f4f1c8f21e3dcfed7d58d81dcb469fba36a3f0cb44fcbeb25f49510319ab20d/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Azure%2520AD_V1.0.pdf.md?cb=fdca44b66b9bc65981ff3a73c6d2e1a0) [PUB_Anjana Data 4.4 - DS - Tot plugin AWS S3_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_d5161a0dde3862e7dd849207786c412c7b788c14276b839083112b5a46d5850d/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520AWS%2520S3_V1.0.pdf.md?cb=73cf102becab58ab5e0d19d7c9b50bc7) [PUB_Anjana Data 4.4 - DS - Tot plugin AWS IAM_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_4c60ccaa881e1ea87719706de40ed1d188e56a81e95278d406125e62fb143d7c/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520AWS%2520IAM_V1.0.pdf.md?cb=ff26554dbb50e1c23c3acb7336759a27) [PUB_Anjana Data 4.4 - DS - Tot plugin AWS Glue_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_14007dd524508f56cf073a9bbd5d60236cb8b62cc6b548c90df8e6c7bf7733b6/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520AWS%2520Glue_V1.0.pdf.md?cb=063533f79e7bf475bb9374a75e5c1ae4) [PUB_Anjana Data 4.4 - DS - Tot plugin Aqtiva_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_a1a20760302e946c1345b274cdd8bd1fccb7e3ecd073b1a6fca8b61f129cf107/PUB_Anjana%2520Data%25204.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Aqtiva_V1.0.pdf.md?cb=b866877ca3a85cb6d2d0aa5a2bd30d91) [PUB_Anjana Data 4.4 - DOC - Tot plugin PowerBI_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_f7bfa8fd6fe6a09b58b16185b9c68cc34e138d496422bc46d58d16172fca9e1c/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Tot%2520plugin%2520PowerBI_V1.0.pdf.md?cb=ad974bb3d14eba469a9f7f04e17b4275) [PUB_Anjana Data 4.4 - DOC - Tot plugin PowerBI - Reports integration_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_18510dc7b38bf14d8272a0082e3c1d6839273442e205d1cafc14c7f18b32324e/PUB_Anjana%2520Data%25204.4%2520-%2520DOC%2520-%2520Tot%2520plugin%2520PowerBI%2520-%2520Reports%2520integration_V1.0.pdf.md?cb=15b7f5f14771d8320e9feedea0423237) [PUB_Anjana Data 4.4.4 - DS - Tot plugin Denodo_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_acca262729c0801c6fc762e32d2271512ba03e4ca79f967c8534b04908a2758c/PUB_Anjana%2520Data%25204.4.4%2520-%2520DS%2520-%2520Tot%2520plugin%2520Denodo_V1.0.pdf.md?cb=4d46b01e549239c283f9df2f1f86166f) [PUB_Anjana Data 4.4.3 - DS - Tot plugin LDAP_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_d58551005024c9ed3b3a7abcae358bc2b2055da4353b70c0c02a38be95db8cf9/PUB_Anjana%2520Data%25204.4.3%2520-%2520DS%2520-%2520Tot%2520plugin%2520LDAP_V1.0.pdf.md?cb=bcfe4f89c8c7318ae8c8d34d3e5f5530) [PUB_Anjana Data 4.4.2 - DS - Tot plugin LDAP_V1.1.pdf](https://wiki.anjanadata.com/__attachments/a_57e2e073d8b3889fd74bb0992b20d399fe9f603dca16ab87df56d4de0c815d26/PUB_Anjana%2520Data%25204.4.2%2520-%2520DS%2520-%2520Tot%2520plugin%2520LDAP_V1.1.pdf.md?cb=c31c1436d302aa1621e6138cba086dab) [PUB_Anjana Data 4.4.2 - DS - Tot plugin JDBC_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_42fdba6f5ecb93ae16923a45c92c1815d9e954b027809c26ff790977b0dc701f/PUB_Anjana%2520Data%25204.4.2%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC_V1.0.pdf.md?cb=3c19782021f41f79da51661eaba3ab2d) [PUB_Anjana Data 4.4.2 - DS - Tot plugin JDBC Oracle_V1.0.pdf](https://wiki.anjanadata.com/__attachments/a_5fa1eb5d76c1c8ff3c98677c0a15bea9f5f2fc2e0b01667a492605000080acd5/PUB_Anjana%2520Data%25204.4.2%2520-%2520DS%2520-%2520Tot%2520plugin%2520JDBC%2520Oracle_V1.0.pdf.md?cb=0d23e2911e5bdffe4ddf69008e22b0fc) --- version: "26.1" language: "en" --- # Integrations ## 🌐 Integrations in Anjana Data Platform The **Integrations** section is designed to provide a complete view of how Anjana Data Platform can integrate with other tools, platforms, and services within an organization's Data \& AI Ecosystem. Here you will find technical documentation, step-by-step guides, and key references to facilitate the interoperability of our platform and its integration into any scenario and technology architecture. ### 🔌 Plugins In this subsection you can explore how to extend Anjana Data Platform's capabilities through its integrations with other technologies via native plugins already developed and maintained by Anjana Data. It includes specific documentation for integrations with technologies such as: * **AWS (Glue, S3, Redshift, ...)** * **Azure (SQL DB, DataLake Storage, PowerBI, Fabric, ...)** * **GCP (BigQuery, Cloud Storage, Looker, ...)** * **Oracle** * **Denodo** * **Cloudera** * **Databricks** * **Snowflake** * And other connectors, both general-purpose (JDBC, files, ...) and special-purpose These plugins allow organizations to easily connect Anjana Data Platform with their data platforms, enabling much more agile, comprehensive, and automated governance. **The plugin catalog only publishes plugins available in General Availability** that have been tested and certified in real production scenarios. It is recommended to check with the Presales team or the Customer Success Manager assigned to the client about the availability of other plugins that may be found: * Developed and in beta phase, available for testing in real production scenarios * In development phase with an expected release date for beta * On the Product Roadmap with the possibility of prioritization for development ### 🛠️ SDK To avoid vendor lock-in and so that any Anjana Data client and/or partner can develop their own integration plugins on any technology to cover their specific needs without needing to depend on Anjana Data as the software vendor, we provide an **SDK (Software Development Kit)**. This SDK provides a standardized framework that enables: * Integrating Anjana Data Platform with any external system or tool. * Leveraging Anjana Data Platform's APIs to enrich the functionality of already existing plugins. * Ensuring compatibility with the platform's control, audit, and security mechanisms. * Extending business logic without compromising the platform's native architecture. The SDK documentation includes examples, base templates, and best practices to ensure efficient and easily maintainable development. Finally, you can also request a quote from any of our certified integration partners () for the ad-hoc development of any plugin or integration. ### ⚙️ API Here you will find the specifications and functional descriptions of the APIs exposed by Anjana Data Platform, designed to facilitate process automation, integration with external systems, or implementation of custom developments. This section includes: * **Audit** Endpoints * **Basic API interactions** * **Kerno API** (core communication and interoperability) * Response formats, authentication, and usage examples All of this is aimed at developers and technical teams who want to leverage the power of Anjana Data Platform in their own workflows. ### 🔐 Authentication This section describes how to configure and integrate corporate authentication mechanisms with Anjana Data Platform to ensure secure and centralized access management. It includes guides for: * **SSO with OKTA / Auth0** * **AWS IAM** * **GCP IAM** * **Azure Entra ID (formerly Azure AD)** * **LDAP / WAD** Here the necessary steps to activate each integration, the required parameters, and security considerations are explained. --- version: "26.1" language: "en" --- # Advanced Operations ## Introduction The following summarizes a series of advanced operations that can be performed via the Administrative API. To perform these actions, a token is needed from a user who has been assigned a role that includes the API administration permission (API_ADMIN). For more details on any endpoint, see [Swagger](https://wiki.anjanadata.com/en/integraciones/26.1/swagger.md) ## Operations for creating or modifying objects ### Getting the body of objects The following endpoints allow the creation or modification of object metadata in Anjana. All the bodies needed for creating/editing objects can be obtained by calling the endpoint GET https://{{host}}/gateway/api/admin/kerno/body-create-update/{objectSubType}/{idObject} This call will return the body of the object corresponding to the idObject, which can be used for modifications to it. To get the body needed to create a new object, the idObject should not be sent. For more information about what should be included as a value depending on the metadata field type, see the User Guide for examples. Information about how ARIs are composed for fields that use ARIs (those related to files or entities) can be found in the ARIs document. ### Creating and editing native entities These endpoints allow creating and editing native entities (**DATASET, DSA, INSTANCE, SOLUTION, and PROCESS**) along with everything they involve (internal relationships, extra entities in the case of the dataset, etc.). Unlike the standard API, here each entity type has its own endpoint and the operation ends directly in the status included in the request. The request body is obtained as described in the previous section. In all cases, just as from the portal, the submitted data is validated and the operation is only completed if all validations are passed; otherwise, the errors will be reported. #### Creating native entities **Step 1. Prepare the request body.** Get the body as described in the previous section. Under no circumstances is it allowed to modify the PKs or primary keys. **Step 2. Call the endpoint corresponding to the entity type.** | Entity | Endpoint | What it creates | |--------------|---------------------------------------------------------------|-----------------------------------------------------------------------------------------------| | **Dataset** | `POST /gateway/api/admin/kerno/create-update/entity/dataset` | The DATASET and as many DATASET_FIELD entries as included, with their internal relationships. | | **DSA** | `POST /gateway/api/admin/kerno/create-update/entity/dsa` | The DSA and the internal relationships with its associated entities. | | **Solution** | `POST /gateway/api/admin/kerno/create-update/entity/solution` | The SOLUTION and the internal relationships with its associated instances. | | **Instance** | `POST /gateway/api/admin/kerno/create-update/entity/instance` | The INSTANCE and the internal relationships with its input and output datasets. | | **Process** | `POST /gateway/api/admin/kerno/create-update/entity/process` | The PROCESS entity. | **Tot invocation:** when the chosen status is **APPROVED** , Tot will be invoked. In the case of the dataset, it must also be **governed**. #### Editing native entities **Step 3. Prepare the request body and provide the** `idObject`**.** Get the body as described in the *API Basic Interactions* section and provide the `idObject` variable in the URL. **Step 4. Call the corresponding editing endpoint.** | Entity | Endpoint | |--------------|--------------------------------------------------------------------------| | **Dataset** | `POST /gateway/api/admin/kerno/create-update/entity/dataset/{idObject}` | | **DSA** | `POST /gateway/api/admin/kerno/create-update/entity/dsa/{idObject}` | | **Solution** | `POST /gateway/api/admin/kerno/create-update/entity/solution/{idObject}` | | **Instance** | `POST /gateway/api/admin/kerno/create-update/entity/instance/{idObject}` | | **Process** | `POST /gateway/api/admin/kerno/create-update/entity/process/{idObject}` | **Handling of sub-entity lists (dataset-fields, contained entities, instances, dataset input/output):** * Send the list as `null` → that relationship is not edited. * Send an **empty list** → interpreted as delete / leave without elements (in a dataset, this deletes all dataset-fields). ##### Editing behavior * **Versioning:** if the configuration indicates that changes version the object, a new version is generated with the changes and the entity that was sent for editing is deprecated. * **Non-editable fields:** they can be edited by sending the `disableNonEditValidations` parameter (disabled by default). * **Tot invocation:** for a governed dataset with APPROVED status and for a DSA with APPROVED status (sending the information about the edit performed). ### Generic creation and update of entities In addition to the type-specific endpoints, there is a **generic endpoint** that allows creating or editing any entity (native or non-native), ending directly in the status you want, **without needing a workflow** (for example, creating an entity already in APPROVED status, or editing from APPROVED to DRAFT). This endpoint applies controls similar to creation from the portal: it does not allow creating duplicate objects or including incorrect values in the fields. For **DATASET, SOLUTION, INSTANCE, or DSA** entities, it is recommended to use the [type-specific APIs](https://wiki.anjanadata.com/en/integraciones/26.1/api-interacciones-basicas.md#Creaci%25C3%25B3n-de-entidades-nativas), which provide more information about complete native entities. #### Creating an entity **Step 1. Prepare the request body.** The `idObject` must always be `null` since this is a creation. All the subtype's attributes are included within the `entityAttributes` property; the remaining properties depend on the subtype you want to create (see table below). **Step 2. Call the generic endpoint.** POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/{objectSubType} **Subtype-specific properties:** | Subtype | Property(ies) | Content | |----------------------------|----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Dataset** | `entityFormDatasetFields` | Information to create the dataset fields. If a dataset is created without fields, send it empty. | | **DSA** | `dsaDatasetDTO` | IDs of the datasets to be included in the DSA. | | **Instance** | `wizardDTO`, `datasetInput`, `datasetOutput` | In `wizardDTO`: the ARI of the process and the solution, and the name of the instance. In `datasetInput`/`datasetOutput` (optional): the IDs of the datasets to add. | | **Solution** | `instances` | Related instances to add to the solution (optional). | | **Process and non-native** | - | Simpler structure: it is enough to fill in the organizational unit, the status, and the attributes. | #### Updating an entity **Step 3. Prepare the request body and provide the** `idObject`**.** The **same endpoint** is used as in creation, but indicating the `idObject` both in the URL and in the body. **Step 4. Call the generic editing endpoint.** POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/{objectSubType}/{idObject} > **Restriction:** an entity in **PENDING** status that already has a workflow in progress cannot be edited; the workflow must be finished before editing it. ##### **Editing considerations:** * **Non-editable fields:** they can be edited by sending the `disableNonEditValidations` parameter (disabled by default). * **Complete native entities:** it may be necessary to create the internal relationships, or to use only the internal relationships if you only want to edit the internally related objects. See the [Editing native entities](https://wiki.anjanadata.com/en/integraciones/26.1/api-interacciones-basicas.md#Edici%25C3%25B3n-de-entidades-nativas) section. * **Attribute language:** the language must be included for international attributes. For boolean, user, list-of-values, etc. attributes, no language is included and the value must be indicated as defined in `attribute_definition_value`. ### Deleting an entity Allows deleting an entity. It consists of the following call: DELETE https://{{host}}/gateway/api/admin/kerno/delete/entity/{idObject}. This endpoint deletes all the entity's information and any related information that applies: * Deletion of relationships associated with the entity (with their attributes) * Deletion of workflow information associated with the entity (both in kerno and the workflow in activiti, which will be deleted, along with all its notifications) * Deletion of any existing combinations if the deleted object is a DATASET or DSA * Deletion of information saved in the cart related to the entity being deleted * Deletion of the entity itself (with its attributes) * Deletion of the entity's indexed information (including snapshots) * Deletion of the indexed information of the relationships with the entity (including snapshots) Processes or solutions that would leave orphaned instances cannot be deleted. Entities that have any type of associated relationship cannot be deleted; a notice will be sent to the owners of the objects at both ends of the relationship informing them that the relationships must be deleted first in order to delete their related objects. ### Creating and updating non-native relationships This endpoint allows creating or editing a non-native relationship, ending directly in the status you want, **without needing a workflow** (for example, creating it from scratch directly in APPROVED, or editing from APPROVED to DRAFT). It applies controls similar to creation from the portal: it does not allow creating duplicate objects or including incorrect values in the fields. #### Creating a relationship **Step 1. Prepare the request body.** The `idObject` must always be `null` since this is a creation. All the relationship's attributes are included within the `relationshipAttributes` property. The `source` and `destination` attributes are mandatory. **Step 2. Call the endpoint.** POST https://{{host}}/gateway/api/admin/kerno/create-update/relationships/{objectSubType} #### Updating a relationship **Step 3. Prepare the request body and provide the** `idObject`**.** The **same endpoint** is used as in creation, but indicating the `idObject` both in the URL and in the body. **Step 4. Call the editing endpoint.** POST https://{{host}}/gateway/api/admin/kerno/create-update/relationships/{objectSubType}/{idObject} > **Restriction:** an entity in **PENDING** status that already has a workflow in progress cannot be edited; the workflow must be finished before editing it. **Editing considerations:** * **Non-editable fields:** they can be edited by sending the `disableNonEditValidations` parameter in the body (disabled by default). * **Attribute language:** the language must be included for international attributes. For boolean, user, list-of-values, etc. attributes, no language is included and the value must be indicated as defined in `attribute_definition_value`. ### Deleting a relationship Allows deleting a relationship. It consists of the following call: DELETE https://{{host}}/gateway/api/admin/kerno/delete/relationship/{idObject} This endpoint deletes all the relationship's information and any related information that applies: * Deletion of workflow information associated with the relationship (both in kerno and the workflow in Activiti, which will be deleted, along with all its notifications) * Deletion of the relationship itself (with its attributes) * Deletion of the relationship's indexed information (including snapshots) ## Other operations ### Getting the metadata of an entity This endpoint allows obtaining the data of a defined metadata for an entity; that data is returned in the same way it is received in the portal, that is, with the structure of menus and sections (including the dummy menu and sections for custom fields). It consists of the call: GET https://{{host}}/gateway/api/admin/kerno/entity/{objectSubType}/{idObject} ### Changing the Organizational Unit of an entity Allows you to change an entity's organizational unit without going through the workflow validation that normally applies. It consists of the call POST https://{{host}}/gateway/api/admin/kerno/change-organizational-unit/{{idObject}} The validations applied are the same as from the portal; you cannot change the OU of an entity that does not exist, or of those that do not have their own OU, such as INSTANCE. ### Changing the status of an entity Allows changing an entity's status to any status, without applying the logic that status usually has (e.g.: changing it to expired would only change the entity, not its relationships, and would not involve Tot if necessary, etc.). It consists of the call: PUT https://{{host}}/gateway/api/admin/kerno/entity/change-state/{idObject}/{state} If the DATASET status is changed, its DATASET FIELD entries will be updated with the same status. **IMPORTANT:** Status changes to APPROVED using this endpoint do not involve Tot in any way, so moving a governed object from DRAFT status to APPROVED through this route would not involve any external system. ### Changing the status of a relationship Allows changing a relationship's status to any status allowed for relationships, without applying the logic involved in updating an entire relationship. Changing the status of a native relationship is not allowed. It consists of the call: PUT https://{{host}}/gateway/api/admin/kerno/relationship/change-state/{idObject}/{state} where **idObject** is the id of the relationship to modify and **state**is the status to change to. **IMPORTANT:** Status changes to APPROVED from this endpoint do not involve Tot in any way, so moving a governed object from DRAFT status to APPROVED through this route would not involve any external system. ### Changing the name of an entity or relationship Performs a name change on the entity or relationship specified in the request body. Before changing the name, the PK validations corresponding to the subtype of the entity or relationship being modified will be applied. Therefore, if a name is entered that already exists for another (or the same) entity, the user will receive an exception in the response to the request. The renaming will affect all persisted instances of the object's name and the object's ARI. * Database * entity or relationship * audit * notifications * workflows * Indexing Points to note: * The name cannot exceed 255 characters. * Renaming objects that have a workflow in progress is not allowed. * For changing the name of an approved DSA that contains governed entities, it is advisable to review the corresponding plugin's documentation. * Overwriting the name of objects in PENDING status is not allowed, nor for objects that have another version. ### Getting attributes that depend on other attributes Indicates, for the value of a given attribute, which attribute values depend on the one specified. It can be applied to all subtypes or to the relationship that applies to just one. It consists of the call: POST https://{{host}}/gateway/api/admin/kerno/relationship Description of the variables, all of which are mandatory: * **nameAttributeSource**Name of the source attribute * **nameAttributeDest** Name of the destination attribute * **valueAttributeSource**List of source values for which we want to know their related values * **objectSubType**Subtype of the template in which the attributes are defined ### Bulk editing of objects Allows editing the same attributes with the same values for a list of objects. It consists of the call: PUT https://{host}/gateway/api/admin/kerno/attribute/update/{objectType}/{objectSubType} Optionally, another parameter is included in the call: validateType. This parameter indicates whether you want to validate the type of the parameters (for example, that numbers are numbers, or that the value is valid in fields with limited values); by default it is set to true and should only be included if you want to disable those validations. As a result, you will receive an OK (200) if everything went well, or a PARTIAL CONTENT (206) if some object could not be edited, indicating the error that occurred (it will be a list with as many elements as objects that failed to be edited). ### Withdrawal from a DSA Allows executing the withdrawal from a DSA for the user indicated in the request. It consists of the call: POST https://{{host}}/gateway/api/admin/kerno/disadhere/{idObject} The only users who are not allowed to be withdrawn are the owners of the DSA's organizational unit. ### Indexing of all entities Allows completely updating the SolR collection of Anjana's objects (only the kerno one, not the snapshots), removing all existing objects and reindexing. It consists of the call: PUT https://{{host}}/gateway/api/admin/kerno/index/all-entities This endpoint launches the processing and indexing of all objects in the background. Depending on their size and the server configurations, the process may take a while. Internally, it is done in configurable blocks. If the process does not correctly index all the elements, review and adjust the block configuration so that it fits what the system can support. --- version: "26.1" language: "en" --- # API An API, or Application Programming Interface, is a set of rules and protocols that allows different applications to communicate with each other. It facilitates interaction between systems, allowing developers to access certain functionalities or data of an application without needing to know its internal implementation. Anjana Data has an extensive API available to developers, allowing them to integrate processes efficiently. In addition, we have documented audit log generation, which facilitates integration based on that content. This ensures that developers can implement and track their interactions with the API effectively. [(26.1-en) API Interacciones básicas](https://wiki.anjanadata.com/en/integraciones/26.1/api-interacciones-basicas.md) [Swagger](https://wiki.anjanadata.com/en/integraciones/26.1/swagger.md) --- version: "26.1" language: "en" --- # API Basic Interactions ## Introduction The creation of metadata in Anjana has a specific lifecycle across the usual channels (Web App, API). This lifecycle consists of generating an object with DRAFT status (or IMPORTED if it was created by importing data with automatic metadata from TOT), moving to PENDING while the validation workflow is in progress until its final approval or rejection. ## Swagger This document presents the different operations that can be performed to follow the cycle proposed by Anjana, exposed through an API. For more technical information, or information needed to make the call, check the endpoint at Each endpoint or group of endpoints specifies which module it belongs to, which is the module to check in Swagger to see the details. It also includes instructions and examples of the mechanism to use to introduce metadata into Anjana that will not follow that standard cycle, as well as how to obtain filtered listings of the existing metadata. ## Tools Since these are simple APIs, any tool capable of making a REST request is valid. In this document, in cases that include a screenshot or where a specific action is required in the REST calls, the Postman tool is used. ## Multi-language For requests dealing with multi-language text or translations (retrieving an object's metadata, Solr search, etc.), the language in which the information should be returned can be specified (the clearest case is obtaining an object's metadata with its values translated into a specific language). To do this, the header "x-language" must be included, with a value matching one of the i18n codes configured in the application, as shown in the following example: ![att_1_for_171901648.png](https://wiki.anjanadata.com/__attachments/a_e35e64b604df54a6ad8d7951e1abfdfc9d111fcfc10c7668d567e33ecb8ba72d/att_1_for_171901648.png?cb=65efedeba19fa62fe415ea0f9b3feb1d) Note that the header is entirely optional; if it is not received, results will be returned in the language of the user making the request, or, if that does not exist, in the application's default language. ## SSL Like the rest of its interface, Anjana secures its API with certificates signed by recognized public certificate authorities (Let's Encrypt, DigiCert, etc. See . Since these are certificates from a public CA, any HTTP client (curl, Postman, code) trusts them by default, with no need to specify any additional certificate. Only in environments with a self-signed certificate or one issued by a private CA (for example, some On-Premise/IaaS deployments) is it necessary to explicitly indicate the trusted CA: curl --cacert my-ca.crt https://{url_request} Only for testing and development can SSL verification be disabled in cURL with the -k option, since this results in a connection without security validation. ## Glossary Every URL will include variables that must be replaced when executing the call. Below is an explanation of what to put in each one. * host: the IP or alias where Anjana is deployed (e.g. google.com) * provider: the identity management provider to be used, with the name configured in Zeus's yml file (e.g. azure) * objectType: the type of the object involved in the request (e.g. ENTITY) * objectSubType: the subtype of the object involved in the request (e.g. DATASET) * idObject: the id of the object involved in the request (e.g. 21) * state: the state of the object involved in the request (e.g. APPROVED) * workflow: workflow type (e.g. CREATE). * target: the Solr collection to index into (e.g. KERNO). ## Minio/S3 ### Introduction For managing files as metadata (UPLOAD_FILE and ARRAY_UPLOAD_FILE), Anjana uses Minio or S3 to store the files. ### Installation and use Installing a MinIO client is required to interact directly with the internal S3 without going through the Anjana portal. To use the MinIO client, install it as follows: wget https://dl.min.io/client/mc/release/linux-amd64/mc then grant it execute permissions chmod +x mc and establish the connection with the server ./mc alias set minio https://{{host}}:9000 {{user}} {{password}} --api S3v4 to finally copy the file to the corresponding bucket ./mc cp xxxxx.pdf minio/dsa ## Login ### Obtaining a token Before performing any operation on the APIs, an access token is required. This token is obtained upon logging in. Depending on the identity manager being used, there are different endpoints to obtain the token. All these endpoints are found in the Zeus module. The payload to send in all cases will be the following: { "u": "usuario", "p": "contraseña" } Where both "u" and "p" must be encoded in base64. #### LDAP It consists of a call POST https://{{host}}/gateway/public/v4/auth/login/ldap This endpoint connects to the corresponding LDAP using the credentials sent, and returns the token needed for the rest of the calls, along with information about the user and their permissions (which vary depending on the license status). #### Database It consists of a call POST https://{{host}}/gateway/public/v4/auth/login/local This endpoint connects to the Zeus database using the credentials sent, and returns the token needed for the rest of the calls, along with information about the user and their permissions (which vary depending on the license status). #### Saml 2.0 It consists of a call GET https://{{host}}/gateway/public/v6/auth/saml2/login This endpoint is used so that, once connected via SAML using the corresponding credentials, it returns the Anjana token needed for the rest of the calls, along with information about the user and their permissions (which vary depending on the license status). #### Other providers It consists of a call GET https://{{host}}/gateway/public/v6/auth/oidc/login This endpoint is used so that, once connected via the provider specified in Zeus using the corresponding credentials, it returns the token needed for the rest of the calls, along with information about the user and their permissions (which vary depending on the license status). ### Sending the token The token obtained from one of the previously defined endpoints must be included in the header of every request. Example from POSTMAN: ![att_3_for_171901648.png](https://wiki.anjanadata.com/__attachments/a_811c8db2449df0cc007a6e1ae103cd8fe5972d998120d6e77fba1ef1ae4ba554/att_3_for_171901648.png?cb=5b0df101e8b0963cff451f1c90596317) Example from code: headers.add("Authorization", "Bearer " + token); ## API response codes according to license status |-------|-----------|-------------------------------------------------------------------------------------------------------| | Code | Status | Description | | 0000 | VALID | The license is valid and the user can access Anjana correctly. | | 99997 | EXPIRING | This is a warning state indicating that the license has been invalid for more than 3 and up to 7 days | | 99998 | EXPIRED | The license has been invalid for more than 7 days; the application cannot be accessed | | 99996 | TEMPORARY | Temporary license. The license is valid and the user can access Anjana correctly. | | 99995 | READ_ONLY | License indicating that the application can only be accessed in read-only mode | --- version: "26.1" language: "en" --- # Audit Operations ## Introduction Below are the basic operations that can be performed via API regarding Audit. All calls are located in Minerva. For more details on the endpoints, see [Swagger](https://wiki.anjanadata.com/en/integraciones/26.1/swagger.md) ## Indexing an audit Allows creating the audit specified in the data provided. It consists of the following call: **POST** https://{{host}}/gateway/api/admin/minerva/audit/save ## Get all existing audit This endpoint allows obtaining all existing audit in Anjana. **GET** https://{{host}}/gateway/api/admin/minerva/audit/getAll ## Get the audit of a user This endpoint will allow obtaining the existing audit for the specified user. **GET** https://{{host}}/gateway/api/admin/minerva/audit/getAll/{username} ## Get all audit for a given object This endpoint will allow obtaining all the audit for the specified object on the given subtype. The information returned will be that which exactly matches what was provided; that is, if the object id is not specified, the audit that has the specified subtype and an empty (null) object identifier will be returned. **GET** https://{{host}}/gateway/api/admin/minerva/audit/getAll/{objectSubType}/{objectId} --- version: "26.1" language: "en" --- # Authentication Authentication in an application verifies the user's identity before allowing access to resources and functionality. This process ensures security and protects sensitive information. The term **SSO (Single Sign-On)** allows users to access multiple applications with a single credential, improving the experience by reducing the need to remember multiple passwords and increasing security by centralizing access management. Anjana Data facilitates authentication by integrating with various platforms (Auth0, Okta, AWS, Azure, Google, Keycloak) via standard protocols (**OIDC** , **SAML** ), corporate directories (**LDAP/AD**), and the local database. *** ** * ** *** ## Prerequisite: the user must exist in Anjana For login to be successful, regardless of the mechanism used (OIDC, SAML, LDAP, or local database), **the user must already be registered in the Anjana database**. External authentication verifies the user's identity with the identity provider, but Anjana always checks that the user exists locally before granting access. If the user successfully authenticates with the IdP but is not registered in Anjana, access will be denied. There are two ways to register users in Anjana: * **Direct creation:** the administrator manually creates the user from the Anjana administration interface. * **Automatic provisioning:** connect Anjana to the corporate directory (Azure AD, Keycloak, LDAP, Okta, etc.) using the [User provisioning](https://wiki.anjanadata.com/en/integraciones/26.1/user-provisioning.md) feature and run the **synchronization**, which automatically imports and keeps records up to date. This is the recommended method in environments with a centralized corporate directory. User synchronization is independent of the authentication mechanism: users can be provisioned from Azure AD even if authentication is performed via SAML with Okta, for example. *** ** * ** *** ## General configuration Before explaining each provider, the `app.base-url` property must be configured, setting the API host as its value, as follows: YAML app: base-url: https://dev.anjanadata.org/ The configuration for each supported mechanism is detailed below. [SSO OIDC (OpenID Connect)](https://wiki.anjanadata.com/en/integraciones/26.1/sso-oidc-openid-connect.md) [SSO SAML 2.0](https://wiki.anjanadata.com/en/integraciones/26.1/sso-saml-2-0.md) [Login LDAP/WAD](https://wiki.anjanadata.com/en/integraciones/26.1/login-ldap-wad.md) [Internal (Provider: Database)](https://wiki.anjanadata.com/en/integraciones/26.1/internal-provider-database.md) --- version: "26.1" language: "en" --- # Auth0 This module allows synchronizing users from **Auth0 Identity Cloud**. The process is carried out through a **Machine-to-Machine (M2M)** application authorized to query the management API. It is efficient for large user bases thanks to asynchronous export jobs. *** ** * ** *** ## Part 1: Configuration in the Auth0 Dashboard To access the management API, we need to create a specific "machine" application for Anjana. ### Step 1: Create the M2M application 1. Log in to your Auth0 admin dashboard. 2. Go to **Applications** \> **Applications**. 3. Click **Create Application**. 4. Assign a name (e.g. `Anjana Provisioning Service`). 5. Select the type **Machine to Machine Applications**. 6. Click **Create**. ### Step 2: Authorize the Management API After creating the app, Auth0 will ask which API you want to authorize. 1. In the "Select an API" dropdown, choose **Auth0 Management API**. 2. In the permissions list (Scopes), find and select: * `read:users` (Allows reading users and creating export jobs). 3. Click **Authorize**. ### Step 3: Get credentials 1. Once authorized, go to the **Settings** tab of the created application. 2. Copy the following values: * **Domain:** (e.g. `dev-xyz.us.auth0.com`). * **Client ID**. * **Client Secret**. *** ** * ** *** ## Part 2: Configuration in `application.yml` of the Zeus microservice Edit Anjana's configuration file and include the data in the `security.provisioning.providers.auth0` section. YAML security: provisioning: providers: auth0: # Unique key for this data source (e.g: auth0-main-tenant) auth0-main-tenant: # Your tenant's domain (without https://) domain: "dev-xyz.us.auth0.com" # Client ID of the M2M App (Step 3) client-id: "A1b2C3d4..." # Client Secret of the M2M App (Step 3) client-secret: "secret_value_..." *** ** * ** *** ## Property summary |-------------------|----------------------------|-------------------------------------------| | **YAML Property** | **Description** | **Source in Auth0** | | `domain` | Tenant domain. | Applications \> Settings \> Domain | | `client-id` | Identifier of the M2M App. | Applications \> Settings \> Client ID | | `client-secret` | Secret of the M2M App. | Applications \> Settings \> Client Secret | *** ** * ** *** ## Custom field mapping (`field-mapping`) Anjana includes a default mapping that covers common cases. You can override any field by indicating the Auth0 profile key from which the value should be read. The keys are lists in order of priority: the **first non-empty value** is used. User metadata (`user_metadata` and `app_metadata`) is exposed with the prefix `user_metadata.` and `app_metadata.` respectively. For example, if you have `user_metadata.department`, you can reference it directly in `field-mapping`. ### Default mapping | **Anjana Field** | **Default keys (priority order)** | |------------------|----------------------------------------------| | `userName` | `username`, `email` | | `email` | `email` | | `firstName` | `given_name`, `name` | | `lastName` | `family_name` | | `phone` | `user_metadata.phone_number`, `phone_number` | | `title` | `user_metadata.title` | ### Available fields | **Key** | **Description** | |-------------------|--------------------------------------------------------------------------------------------------------------------| | `userId` | Unique identifier of the user in Auth0 (e.g. `auth0|abc123`). | | `username` | Username (only available if the User Pool has usernames enabled). | | `email` | Email address. | | `given_name` | First name. | | `family_name` | Last name. | | `name` | Full name. | | `nickname` | Nickname. | | `picture` | URL of the user's avatar. | | `phone_number` | Phone number. | | `user_metadata.*` | Any `user_metadata` key with the prefix `user_metadata.` (e.g. `user_metadata.title`, `user_metadata.department`). | | `app_metadata.*` | Any `app_metadata` key with the prefix `app_metadata.` (e.g. `app_metadata.role`). | ### Configuration example YAML security: provisioning: providers: auth0: auth0-main-tenant: domain: "dev-xyz.us.auth0.com" client-id: "..." client-secret: "..." field-mapping: # Use given_name; if empty, use full name first-name: ["given_name", "name"] # Read position from user_metadata.position, with fallback to user_metadata.title title: ["user_metadata.position", "user_metadata.title"] # Direct phone or from metadata phone: ["phone_number", "user_metadata.phone_number"] --- version: "26.1" language: "en" --- # AWS Cognito This module allows Anjana Data to synchronize the users of an Amazon Cognito **User Pool**. The process uses the standard AWS API (`ListUsers`) to periodically download the full user directory. All user attributes (standard and custom) are available for field mapping. *** ** * ** *** ## Part 1: Configuration in AWS (IAM User) Anjana needs programmatic credentials (Access Key / Secret Key) with specific read permissions to access the User Pool. ### Step 1: Create IAM User 1. Go to the **IAM** (Identity and Access Management) console in AWS. 2. Select **Users** \> **Create user**. 3. Assign a name (e.g. `anjana-cognito-sync`). 4. Complete the creation without granting console access. 5. Go to the **Security credentials** tab \> **Access keys** \> **Create access key**. 6. Select "Local code" or "Third-party application". 7. **Important:** Copy and save the **Access Key** and the **Secret Key**. ### Step 2: Create Permissions Policy It is recommended to restrict access solely to the User Pool you want to synchronize. 1. On the IAM user, add an **Inline Policy** or create a managed policy. 2. Use the following JSON, replacing the `Resource` with the ARN of your User Pool (or use `*` to grant access to all pools in the account): YAML { "Version": "2012-10-17", "Statement": [ { "Sid": "CognitoReadAccess", "Effect": "Allow", "Action": [ "cognito-idp:ListUsers", "cognito-idp:AdminGetUser" ], "Resource": "arn:aws:cognito-idp:eu-west-1:123456789012:userpool/eu-west-1_AbCdEfG" } ] } *** ** * ** *** ## Part 2: Get User Pool Data 1. Go to the **Amazon Cognito** console. 2. Access the **User Pool** you want to connect. 3. In the header of the "Overview" page, copy the **User Pool ID**. * *Example:* `eu-west-1_XyZ123` 4. Note the **Region** where it is deployed (e.g. `eu-west-1`). *** ** * ** *** ## Part 3: Configuration in `application.yml` Edit Anjana's configuration file and include the data in the `security.provisioning.providers.aws-cognito` section. YAML security: provisioning: providers: aws-cognito: # Unique key to identify this data source (e.g.: pool-clientes-externos) pool-clientes: # AWS Region of the User Pool region: "eu-west-1" # User Pool ID (obtained in Part 2) user-pool-id: "eu-west-1_XyZ123456" # IAM User credentials (created in Part 1) access-key: "AKIAXXXXXXXXXXXXXXXX" secret-key: "SECRET_KEY_XXXXXXXXXXXXXXXXXXXXXXXX" *** ** * ** *** ## Properties Summary Use this table to quickly locate the values needed in the AWS console. | **YAML Property** | **Description** | **Source in AWS** | |-------------------|--------------------------------------------------|------------------------------------------------------------------| | `access-key` | Access key ID of the technical user. | IAM \> Users \> Security credentials | | `secret-key` | Access key secret. | IAM \> Users \> Security credentials (Only visible when created) | | `region` | Code of the region where the service is located. | AWS Console (Top right corner) | | `user-pool-id` | Unique identifier of the directory. | Amazon Cognito \> User Pools \> Overview | *** ** * ** *** ## Custom field mapping (`field-mapping`) Anjana includes a default mapping that covers the usual cases. You can override any field by indicating the Cognito attribute key from which the value should be read. The keys are listed in order of priority: the **first non-empty value** is used. ### Default mapping | **Anjana Field** | **Default keys (priority order)** | |------------------|-----------------------------------| | `userName` | `preferred_username`, `email` | | `email` | `email` | | `firstName` | `given_name`, `name` | | `lastName` | `family_name` | | `phone` | `phone_number` | | `title` | `custom:title` | ### Available fields Anjana exposes **all Cognito user attributes** (both standard and custom), so any key can be used in `field-mapping`. | **Key** | **Description** | |----------------------|------------------------------------------------------------------------------| | `sub` | Unique, immutable identifier of the user. | | `email` | Email address. | | `email_verified` | `true` if the email is verified. | | `phone_number` | Phone number (E.164 format, e.g. `+34612345678`). | | `name` | Full name. | | `given_name` | First name. | | `family_name` | Last name. | | `middle_name` | Middle name. | | `nickname` | Nickname. | | `preferred_username` | Preferred username (login). | | `profile` | Profile URL. | | `gender` | Gender. | | `birthdate` | Date of birth. | | `zoneinfo` | Time zone (e.g. `Europe/Madrid`). | | `locale` | Locale setting (e.g. `es_ES`). | | `custom:*` | Any custom attribute of the pool (e.g. `custom:title`, `custom:department`). | ### Configuration example YAML security: provisioning: providers: aws-cognito: pool-clientes: region: "eu-west-1" user-pool-id: "eu-west-1_XyZ123456" access-key: "..." secret-key: "..." field-mapping: # Read job title from the custom attribute 'custom:position' title: ["custom:position", "custom:title"] # Read department from the attribute 'custom:department' # (there is no Anjana field for department, but it can be used as a fallback in title) phone: ["phone_number"] --- version: "26.1" language: "en" --- # AWS Glue ## **Integration Model** ### **Metadata Extraction** The methods provided by the Glue API are used to access the definition of databases and tables. It extracts the following attributes, which must be named the same in the attribute_definition table, name field, so that they appear in the template. |-----------------------|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------| | **Attribute name** | **Attribute type** | **Description** | | physicalName, name | INPUT_TEXT | Table name | | dataBase | INPUT_TEXT | Database name | | description | INPUT_TEXT | Table description | | path | INPUT_TEXT | Path to the object, using the pathSeparator property as separator | | infrastructure | SELECT | Anjana attribute used to extract the table | | technology | SELECT | Anjana attribute used to extract the table | | zone | SELECT | Anjana attribute used to extract the table | | data_format | INPUT_TEXT | Data format of the table | | compressed | INPUT_CHECKBOX | Whether the table data is compressed | | partitionKeys | ARRAY_ALPHANUMERICAL | The partition key(s) of the table, if it has been partitioned. It will arrive as a single String using "_-" as separator between values | | tableCreatedTime | INPUT_DATE | Table creation date | | datasourceLocation | INPUT_TEXT | Source of the table's data | | datasourceInputFormat | INPUT_TEXT | Format of the source data of the table | | serializationLibrary | INPUT_TEXT | Library used in the creation and update of the table | | tableType | INPUT_TEXT | Table type | | tableVersion | INPUT_TEXT | Table version | | catalogId | INPUT_TEXT | ID of the catalog where the table is located | All extra parameters present in the table's metadata will be included. It will also send the following attributes related to the fields of the requested resource: |--------------------|--------------------|----------------------------------------------------| | **Attribute name** | **Attribute type** | **Description** | | physicalName, name | INPUT_TEXT | Column name of the table | | description | INPUT_TEXT | Description of the column of the table | | fieldDataType | INPUT_TEXT | Data type of the column of the table | | pk | INPUT_CHECKBOX | Whether the column is the primary key of the table | | position | INPUT_NUMBER | Position of the column in the table | All extra parameters present in the column's metadata will be included. The plugin is able to extract metadata from the following types of elements: Tables from the different databases hosted in the service; always in the same format as it appears in Glue, never in the format of the location of the generated files (S3). #### Tables with characters in the name This technology allows characters such as "/" in the name; if they are being used, the path-separator must be configured with a character other than "/". See [File extraction](https://wiki.anjanadata.com/es/integraciones/25.2/extraccion-de-metadata-de-ficheros) for more details. ## **Required Credentials** ### **Metadata Extraction** A user with read permissions on the Glue service is required. Among the read permissions\*, the following are necessary: * glue:SearchTables * glue:GetConnection * glue:GetTable * glue:GetTables * glue:GetDatabases * glue:GetPartitions Note: These are the minimum permissions for Amazon Glue to work correctly. Each technology that Glue goes through to obtain the data may require its own permissions in Glue. If metadata extraction is desired, a connection with Amazon Glue is required. To establish this connection, an accessKey and a secretKey from the AWS IAM account are required. In addition, the region in which it is located is required. In order to obtain the accesskey and secretkey needed for the installation, a user must be created in AWS IAM and, in the security credentials tab, access keys must be created, which will be entered in the configuration yaml. ![att_1_for_171901169.png](https://wiki.anjanadata.com/__attachments/a_59477a0a6326a87d9128a537558dace034c6053f112762596eb4f4fa13f3193d/att_1_for_171901169.png?cb=e275e3c60223e85cf9a057800b3a2b9c) An AWS policy must be created and assigned to the group where the user is located. It must be as follows: JSON { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "glue:SearchTables", "glue:GetTable", "glue:GetConnection", "glue:GetTables", "glue:GetPartitions", "glue:GetPartition", "glue:GetDatabases" ], "Resource": "*" } ] } --- version: "26.1" language: "en" --- # AWS IAM ## Introduction This plugin is used in coordination with the storage technology plugins connected to AWS IAM to provision the groups that represent the DSAs, and it additionally manages the memberships that represent users' acceptance of the DSAs. ### Services available in the plugin * Create and associate permissions to groups: Create groups with users, associate permissions to the bucket access group and to parts of it. * Add user to groups: Add users to existing groups. * Remove users from groups: Remove users from groups. * Remove access: Modify the group's policies to remove access to a particular resource. * Delete groups: Delete previously created groups, deleting the policy created for it. ## Integration model ### Active governance of access permissions In general terms, the **DSAs (Data Sharing Agreements)** managed in Anjana Data are represented as **groups in AWS IAM** , and the users signing each agreement are managed as **members** of those groups. In this way, group membership materializes effective access to the data resources governed by the DSA. Anjana Data Platform **automatically creates, updates, and deletes these groups** , including or excluding users according to the **adherence** and **withdrawal** processes defined in the platform. This ensures that the permissions assigned in AWS always remain aligned with the governance and validation status of the agreements. The groups created by Anjana Data Platform follow this naming convention: `__v` Where: * ``: prefix defined by the organization to identify the groups managed by Anjana Data Platform. It is configured in the plugin's YAML. * ``: functional name of the agreement as it appears in Anjana. * `v`: DSA version number, which allows distinguishing between active and historical versions. The provisioning of these groups and the management of their members is carried out through the **AWS SDK interface**, which Anjana Data Platform uses to automate the lifecycle of the groups and ensure their consistency with the governance model. ## Required credentials ### Active permission governance For active governance, a service credential with the following IAM permissions is needed: * AddUserToGroup: Add users to groups. * AttachGroupPolicy: Associate access policies with groups. * CreateGroup: Create groups. * CreatePolicy: Create access policies. * CreatePolicyVersion: Creates a new version of a policy. * DeleteGroup: Delete groups. * DeletePolicy: Deletes a policy. * DeletePolicyVersion: Deletes a version of a policy. * DeleteGroupPolicy: Deletes the policies of a group. * DetachGroupPolicy: Detach the managed policies from a group. * [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup: Retrieve groups * GetPolicy: Retrieve policies. * GetPolicyVersion: Retrieves a version of a policy. * GetUser: List and retrieve users. * ListAttachedGroupPolicies: Lists and retrieves the managed policies of a group. * ListGroupPolicies: Lists and retrieves the policies of a group. * ListPolicyVersions: Lists the versions of a policy. * RemoveUserFromGroup: Remove users from groups. In addition, it will need the following S3 permissions: * ListAllMyBuckets: Retrieve the list of available buckets * GetObject: Retrieve file information (assign on specific buckets) * ListBucket: List objects within a bucket (assign on specific buckets) * GetBucketLocation: List the region of a bucket (assign on specific buckets) The available services use the following permissions: * Create and associate permissions to groups: AddUserToGroup, AttachGroupPolicy, CreateGroup, CreatePolicy, [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup and GetUser. * Add user to groups: AddUserToGroup, [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup and GetUser. * Remove users from groups: [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup, GetUser and RemoveUserFromGroup. * Remove access: CreatePolicyVersion, DeletePolicyVersion, [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup, GetPolicyVersion and ListPolicyVersions. * Delete groups: DeleteGroup, DeleteGroupPolicy, DeletePolicy, DetachGroupPolicy, [GetG](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)roup, ListAttachedGroupPolicies, ListGroupPolicies and RemoveUserFromGroup. ## Restrictions The prefix for the groups (and the DSA name itself) cannot contain spaces, and the only allowed characters are alphanumeric characters and _=,.@- ; if the prefix has a value and is not valid, the plugin will not start and will generate a log with the error. Given the maximum length of policies, it is not recommended to govern more than 100 datasets within the same DSA. Due to AWS limitations, a user cannot be adherent to and/or be an owner of (the sum of both) more than X DSAs. The specific number of DSAs depends on the AWS quota: [++IAM Quotas++](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) --- version: "26.1" language: "en" --- # AWS IAM Identity Center ## Provisioning with AWS IAM Identity Center This module allows Anjana Data to synchronize users from **AWS IAM Identity Center** (formerly AWS SSO). There are **two synchronization modes** depending on whether `application-arn` is configured or not: * **Application-filtered mode** (with `application-arn`): Anjana queries the SAML application's assignments via `ListApplicationAssignments` and resolves only the assigned users and groups. Recommended when only a subset of the organization should have access. * **Full Identity Store mode** (without `application-arn`): Anjana calls `ListUsers` directly on the Identity Store and synchronizes *all* users in the directory. *** ** * ** *** ### Part 1: Configuration in AWS (IAM User) To securely access the AWS API, we will create a technical user (IAM User) with restricted read permissions. #### Step 1: Create IAM User 1. Go to the **IAM** (Identity and Access Management) console, *not* Identity Center. 2. Go to **Users** \> **Create user**. 3. Assign a name (e.g. `anjana-provisioning-user`). 4. Do not check the box for access to the management console (we only need programmatic access). 5. Complete the creation. 6. Once created, go to the **Security credentials** tab \> **Access keys** \> **Create access key**. 7. Select "Local code" or "Third-party application". 8. **Important:** Copy and save the **Access Key** and the **Secret Key**. #### Step 2: Assign Permissions (Policy) The required permissions vary depending on the mode you are going to use: **Application-filtered mode** (with `application-arn`): JSON { "Version": "2012-10-17", "Statement": [ { "Sid": "AnjanaProvisioningRead", "Effect": "Allow", "Action": [ "sso:ListApplicationAssignments", "identitystore:DescribeUser", "identitystore:DescribeGroup", "identitystore:ListGroupMemberships", "identitystore:GetGroupId", "identitystore:GetUserId" ], "Resource": "*" } ] } **Full Identity Store mode** (without `application-arn`): JSON { "Version": "2012-10-17", "Statement": [ { "Sid": "AnjanaProvisioningRead", "Effect": "Allow", "Action": [ "identitystore:ListUsers" ], "Resource": "*" } ] } 3. Assign a name to the policy (e.g. `AnjanaProvisioningPolicy`) and save the changes. *** ** * ** *** ### Part 2: Obtaining IDs in IAM Identity Center We need to locate the Identity Store ID and, if you are going to use filtered mode, also the application's ARN. 1. Go to the **IAM Identity Center** console. 2. **Identity Store ID:** * In the side menu, go to **Settings**. * Look for the "Identity store" section. * Copy the **Identity Store ID** (e.g. `d-9067xxxxxx`). 3. **Application ARN** (only for application-filtered mode): * Go to **Applications**. * Select the SAML application you created for Anjana Data. * In the details header, copy the **application ARN** (e.g. `arn:aws:sso::123456789012:application/ssoins-xxxx/apl-yyyy`). *** ** * ** *** ### Part 3: Configuration in `application.yml` #### Application-filtered mode (with `application-arn`) Only the users and groups assigned to the specified application are synchronized. YAML security: provisioning: providers: aws-iam-ic: aws-prod: region: "eu-west-1" access-key: "AKIAXXXXXXXXXXXXXXXX" secret-key: "SUPER_SECRET_KEY_XXXXXXXXXXXXXXXX" identity-store-id: "d-9067xxxxxx" # Application ARN (Part 2) application-arn: "arn:aws:sso::123456789012:application/ssoins-xxxx/apl-yyyy" #### Full Identity Store mode (without `application-arn`) **All** users in the Identity Store are synchronized. YAML security: provisioning: providers: aws-iam-ic: aws-prod: region: "eu-west-1" access-key: "AKIAXXXXXXXXXXXXXXXX" secret-key: "SUPER_SECRET_KEY_XXXXXXXXXXXXXXXX" identity-store-id: "d-9067xxxxxx" # application-arn not configured -> synchronization of the entire Identity Store #### Property Summary | **Property** | **Description** | **Source** | **Required** | |---------------------|---------------------------------------------------------------------------------------------------------------------|-------------------------------------|---------------| | `access-key` | Access key ID of the technical user | IAM (Users) | Yes | | `secret-key` | Secret of the technical user's access key | IAM (Users) | Yes | | `region` | AWS region code (e.g. `eu-west-1`) | AWS Console (top right corner) | Yes | | `identity-store-id` | User directory identifier | IAM Identity Center \> Settings | Yes | | `application-arn` | App ARN. If present, it only synchronizes its assigned users. If absent, it synchronizes the entire Identity Store. | IAM Identity Center \> Applications | No (optional) | *** ** * ** *** ### Custom field mapping (`field-mapping`) Anjana includes a default mapping that covers common cases. You can override any field by indicating the provider key from which the value should be read. The keys are listed in priority order: the **first non-empty value** is used. #### Default mapping | **Anjana field** | **Default keys (priority order)** | |------------------|-----------------------------------| | `userName` | `userName` | | `email` | `email` | | `firstName` | `givenName`, `displayName` | | `lastName` | `familyName` | | `phone` | `phoneNumber` | | `title` | `title` | #### Available fields | **Key** | **Description** | |---------------------|------------------------------------------------------| | `userId` | Unique identifier of the user in the Identity Store. | | `userName` | Unique username (login). | | `displayName` | Display name. | | `nickName` | Nickname or informal name. | | `title` | Job title or position. | | `userType` | User type. | | `preferredLanguage` | Preferred language. | | `locale` | Locale. | | `timezone` | Time zone. | | `givenName` | First name (from the *name.givenName* field). | | `familyName` | Last name (from the *name.familyName* field). | | `middleName` | Middle name. | | `formattedName` | Formatted full name. | | `email` | User's first email address. | | `phoneNumber` | User's first phone number. | | `streetAddress` | Street (first postal address). | | `locality` | City or locality. | | `region` | Region or province. | | `postalCode` | Postal code. | | `country` | Country. | #### Configuration example YAML security: provisioning: providers: aws-iam-ic: aws-prod: region: "eu-west-1" access-key: "..." secret-key: "..." identity-store-id: "d-9067xxxxxx" field-mapping: # Use displayName as the name if givenName is empty first-name: ["givenName", "displayName"] # Read title and, if empty, use userType title: ["title", "userType"] --- version: "26.1" language: "en" --- # AWS S3 ## Introduction This plugin is used to extract, sample data, and grant and revoke access (together with the AWS IAM plugin) on assets in AWS S3. ## Integration model ### Metadata extraction To list the available structures, the list of accessible *buckets* and all objects are retrieved in order to return a content map. The behavior is slightly different if a *bucket* is configured in the YML configuration file, since in that case the listing is limited to the content of that *bucket*. The value returned in the structure listing is an object with the structure name (which is a concatenation of the infrastructure, technology, and zone) and a list of the objects found within it. In this case, the structure corresponds to the *bucket*and the object to the object in Amazon S3. The same tools are used to extract metadata from an object: the object's content is read to extract its metadata and the result is returned. After running the metadata extraction, an object is obtained with a name (*elementName* ), a list of key-value attributes (such as infrastructure, technology, and zone), and also a list of fields (*fields*) associated with it, also with their own list of key-value attributes. For a successful metadata extraction, the attributes must be named the same in the *attribute_definition* table for the *name*field, so that they appear on screen: * **physicalName** with thename with the same value as the object * **path**with the concatenation of the object's values in Amazon S3 * **infrastructure**with the selected value * **technology**with the selected value * **zone**with the selected value The attributes to be created in Anjana must have the following types: |--------------------|--------------------| | **Attribute name** | **Attribute type** | | physicalName | INPUT_TEXT | | path | INPUT_TEXT | | infrastructure | SELECT | | technology | SELECT | | zone | SELECT | | name | INPUT_TEXT | It will also send attributes related to the fields of the requested resource, always depending on the resource's content and type. For more information [File System - File Metadata](https://wiki.anjanadata.com/en/integraciones/26.1/extraccion-de-metadata-de-ficheros.md). ### Data sampling For data sampling, the object to be sampled is located (up to the configured maximum number of results), the content of its files is read using Apache libraries according to their type, and the results are returned. The value returned in the data sampling is an object that contains headers (*headers* )and values (*values*). The headers (*headers* )include the names of the object attributes that must be returned after the data sampling. The values (*values* )include the list of values for each header for each object to be returned. This will allow the plugin to return, in addition to attributes such as the file name or file content, the rest of the data and metadata. ### Active governance of structures In the S3 protocol, paths are emulated, so it is not possible to pre-provision these elements. ### Active governance of access Access management for this technology is performed directly in AWS IAM, so this type of action is delegated to the plugin for that technology, making the presence of this plugin essential in order to have this functionality. ### Object editing Object editing for this technology is performed directly in AWS IAM, so this type of action is delegated to the plugin for that technology, making the presence of this plugin essential in order to have this functionality. ## Required credentials ### Metadata extraction If metadata extraction actions are to be performed, a connection to Amazon S3 is required. To establish that connection, an *accessKey* and a *secretKey*are needed for the account provided to Anjana to manage data governance. Optionally, a proxy is required if the user does not want a direct connection to Amazon S3. From the Amazon S3 data, the region where it is located is needed and, optionally, if only a single *bucket* is to be governed, the desired *bucket* (if no *bucket,* is included, all *buckets*for which the account has permissions are governed). For its part, Amazon S3 defines a set of actions^1^ that can be specified in a policy and that will help the user with access to the technology obtain the desired information. For this plugin, the following actions are of interest: * **s3:ListAllMyBuckets** to list all the *buckets* of the authenticated user. * **s3:ListBucket** to list the content of a *bucket*. * **s3:GetBucketLocation** to return the region where the *bucket* resides. * **s3:GetObject** to return objects from Amazon S3. To be able to read the object, read permissions on it are also required. ![att_4_for_171933864.png](https://wiki.anjanadata.com/__attachments/a_29583ac356d5ecdfddc40c229b46634490b2ed3d61b35c84b26afab8133d97da/att_4_for_171933864.png?cb=678b6603d1d60cee4b93b1b077842aae) If the Amazon S3 bucket uses encryption with KMS-managed keys (SSE-KMS), it is necessary to grant additional permissions so that the data key associated with the object can be decrypted and the object decrypted. * **kms:Decrypt** → to be able to decrypt data keys and read content. * **kms:DescribeKey** → to validate the key. ### Data sampling To trigger actions related to data sampling, the same configuration and credentials mentioned above for data extraction are required. ### Active governance of structures In the S3 protocol, paths are emulated, so it is not possible to pre-provision these elements. ### Active governance of access Access management for this technology is performed directly in AWS IAM, so this type of action is delegated to the plugin for that technology, making the presence of the latter essential in order to have this functionality. ### Object editing Object editing for this technology is performed directly in AWS IAM, so this type of action is delegated to the plugin for that technology, making the presence of the latter essential in order to have this functionality. ## Limitation on file names There are certain restrictions in AWS regarding file names for everything to work correctly. The safe characters to use are the following: ![att_1_for_171933864.png](https://wiki.anjanadata.com/__attachments/a_4041e0390b9e9f64bd0e6dc29e5f95329c2a35f206e5e2af71532bbcf81c4884/att_1_for_171933864.png?cb=469fa5cd54a106998a42609e4b6ad398) There are also characters that may need special handling, although it is recommended not to use them to avoid problems: ![att_2_for_171933864.png](https://wiki.anjanadata.com/__attachments/a_893e4f40bbb8e11ead77b7c23d9792f13dcdbb1afaa2adc914471d9d1f19e093/att_2_for_171933864.png?cb=558c7293ebdbf694f139b6309ff10938) And finally there are characters to avoid that are not supported by AWS [++https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html++](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html) ![att_3_for_171933864.png](https://wiki.anjanadata.com/__attachments/a_c32ec303bf08feb62125da659b03ba7b9b1b9232e61f042b2c279da0971692c7/att_3_for_171933864.png?cb=e1120e09f5edf9fe2eb86a1852378d4b) For more information, see the AWS documentation. ^1^ Actions allowed in Amazon S3: [++https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operations_Amazon_Simple_Storage_Service.html++](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operations_Amazon_Simple_Storage_Service.html) --- version: "26.1" language: "en" --- # Azure Entra ID ## Introduction This plugin is used in coordination with the storage technology plugins connected to Entra ID to provision the groups that represent DSAs, and it also manages the memberships that represent users' acceptance of the DSAs. ## Integration model ### Active governance of access permissions In general, **DSAs (Data Sharing Agreements)** managed in Anjana Data Platform are represented in **Entra ID** as **groups** . The users who sign each DSA are managed as **members** of the corresponding group, so that group membership reflects effective access to the data governed by the agreement. Groups created by Anjana Data Platform follow this **naming convention**: `__v` Where: * ``: prefix defined by the organization to identify the groups managed by Anjana Data. It is configured in the plugin's YAML. * ``: functional name of the agreement as it appears in the Anjana Data Platform Portal. * `v`: version number of the DSA, which allows distinguishing between active and historical versions. This convention ensures traceability, operational clarity, and controlled coexistence of different versions of the same agreement within Entra ID. In cases where the DSA has the `physicalName` attribute populated with the name of an existing group in Entra ID: * When the DSA is created, the plugin will not create the group in Entra ID; instead, it will reuse the existing group for assigning roles, privileges, and user adherences. * When the DSA is deleted or expires, the plugin will not delete the group and will only remove the users it added as part of the DSA's user adherences (the rest of the users will remain unaffected). ### Editing objects The plugins connected to Entra ID allow managing the activation or deactivation of non-native entities; to do this, this plugin needs to retrieve the necessary group information. ## Required credentials It is necessary to register an application in Entra ID and generate the required client ID and secret so that the plugin can authenticate and acquire the necessary permissions for each functionality. ### Active governance of access permissions The actions performed by this plugin are as follows: * Create groups: Groups will be created to represent DSAs that move to approved status. To do this, the registered application must have the "Group.Create" permission in order to create the groups. * Read users: Reading the fields is required to perform the membership. To do this, the application requires the "User.Read" permission. * Add/Remove users in groups: Users will be added to and removed from the groups created by the plugin (the plugin neither creates nor deletes Active Directory users) based on adherences and withdrawals from the DSA. To do this, the application requires the "User.Read" permission to locate the users and "GroupMember.ReadWrite.All" to modify the group's members with the located users. * Delete groups: The plugin will delete groups that represent DSAs that automatically move to expired status in Anjana. To do this, the application requires the "Group.ReadWrite.All" permission in order to delete groups. ![att_1_for_171999508.png](https://wiki.anjanadata.com/__attachments/a_80d0647d04e24a19dc5d3925a13af9dfee7bfb7d215f04b22cf73a0b5d94d270/att_1_for_171999508.png?cb=425eec05bb0683a8d5d270dad4d11f22) ![att_3_for_171999508.png](https://wiki.anjanadata.com/__attachments/a_779aa27764503ea7d1744e92cff5128234b8290bec9082919a137ca8ef262e72/att_3_for_171999508.png?cb=ae379301d95780dd583ddd531d7ea3c6) ### Editing objects The actions performed by this plugin are as follows: Read groups: A request will be made to read the data of the groups that represent DSAs. To do this, the registered application must have the "Group.Read.All" permission in order to read the groups. ## ⚠️ Azure limitations The maximum number of users in a group is 100. This means that a DSA governing objects in Azure cannot have more than 100 people adhered (including owners); beyond the 100th, active governance can no longer be applied. The DSA name (including the configurable prefix) must not contain the following characters '@', '(', ')', '\\', '\[', '\]', ';', ':', '\<', '\>', nor whitespace, nor exceed 64 characters (including the suffix with the DSA version added by the plugin). This limitation only applies if the DSA does not have the physical name field filled in and the group is expected to be created automatically. --- version: "26.1" language: "en" --- # Azure Storage ## Introduction This plugin is used to extract, sample data, and grant and revoke access (together with the Entra ID plugin) on assets in Azure Storage storage accounts. ## Integration Model ### Metadata extraction Using the libraries provided by Azure, it authenticates against the storage account that contains the container to be governed. Once the connection has been established, the container in question is traversed in order to generate a tree representing all of its content. To extract the metadata of a given object, the same connection and the same tools provided by the Azure library are used to read the metadata, which will subsequently be sent to Anjana to create the object. The following attributes are the ones the plugin will extract as metadata. If you want the object in Anjana to have these attributes, you must create the corresponding field in the attribute_definition table with the same name as in the document, and it must be present in the object's template. The set of attributes on the extracted object is optional, except for schema, physicalName, path, infrastructure, technology, and zone, in the case where the extracted object is going to be governed by Anjana. * **schema**with the value of the Azure container. * **physicalName**and name with the same value, the name of the file within Azure. * **path**with the path and the name of the resource if it is a file. * **infrastructure**with the selected value * **technology**with the selected value * **zone**with the selected value * **creationTime** with the file's creation date * **lastModified** with the date of the file's last modification * **eTag** with the file's eTag * **fileSize** with the file size in bytes * **contentType**with the file type * **contentMd5**with the md5 hash of the file content * **contentEncoding**with the file encoding * **contentDisposition** with the file disposition * **contentLanguage**with the file language * **cacheControl** with the file's cache control value * **leaseStatus**with the file's lock status, which can be * LOCKED: The file is locked by an operation from some service. * UNLOCKED: The file has no lock. * **leaseState**with the lock state of the file, which can be * AVAILABLE: There is no active lock. * BREAKING: Transitioning to BROKEN. * BROKEN: It is not being used by another service, but it will be released when the lock expires. Renewing the lock is not allowed. * EXPIRED: The previous lock has expired and can be locked again by another service or renewed (in case it was not broken before). * LEASED: Locked by another service. * **leaseDuration** with the type of lock the file has, which can be * FIXED: The current lock has a maximum time * INDEFINITE: The current lock has no maximum time; it must be removed manually via a release or break request. * **copyId**with the identifier of the last copy operation on the file (if a copy has never been performed or the file has been modified, this property has no value) * **copyStatus**with the status of the last copy operation on the file (if a copy has never been performed or the file has been modified, this property has no value), which can be * PENDING: There is an operation in progress * SUCCESS: The last operation completed successfully * ABORTED: The last operation was aborted * FAILED: The last operation failed. * **copySource** with the source path of the last copy operation on the file (if a copy has never been performed or the file has been modified, this property has no value) * **copyProgress**with the number of bytes copied and total source bytes of the last copy operation on the file (if a copy has never been performed or the file has been modified, this property has no value) * **copyCompletionTime**with the date of the last time a copy operation was performed on the file (if a copy has never been performed or the file has been modified, this property has no value) * **copyStatusDescription**with the description of the last copy operation on the file if it was aborted or failed (if a copy has never been performed or the file has been modified, this property has no value) * **isServerEncrypted**indicating whether the file is encrypted * **isIncrementalCopy**indicating whether the file is an incremental copy * **accessTier** with the type of access tier of the file, which can be * ARCHIVE: The file cannot be read or modified. * COOL: The file is expected not to be read or modified frequently. * HOT: The file is expected to be read or modified frequently. * P4, P6, P10, P15, P20, P30, P40, P50, P60, P70, or P80: These options refer to cases where the medium on which the files are stored is not flexible and has fixed values both in storage capacity and in speed and number of accesses. In some cases they have temporary expansions in case their access is exceeded. * **archiveStatus** with the file's rehydration status (only applies if the file is at the ARCHIVE access tier and it is being made accessible again), which can be * REHYDRATE_PENDING_TO_HOT: It is in the process of moving from ARCHIVE to HOT * REHYDRATE_PENDING_TO_COOL: It is in the process of moving from ARCHIVE to COOL * **encryptionKeySha256**with the key used to encrypt the file * **accessTierChangeTime**with the date when the access tier was last modified * **isDirectory**indicating whether the file is a directory (this can only be true for partitioned files such as avro or parquet) In addition to these values present in every Azure Storage file, extra properties can be added; all included properties will be collected and extracted. It will also send attributes related to the fields of the requested resource, always depending on the content and type of the resource. For more information [File System - File Metadata](https://wiki.anjanadata.com/en/integraciones/26.1/extraccion-de-metadata-de-ficheros.md). ### Data sampling Using the libraries provided by Azure, it authenticates against the storage account that contains the container to be governed. Once the connection has been established, the object to be sampled is located, its content is read (up to the configured maximum number of results) using Apache libraries depending on the file type, and the results are returned. ### Active governance Using the libraries provided by Azure, it authenticates against the storage account that contains the container to be governed. The object on which permissions are to be manipulated is located, and using ACL manipulation tools, the necessary permissions are added to the group on the objects (Read, Execute at all levels from the root to the file representing the object, and in the case of a partitioned file, on all files present at that time) when they are included in a DSA. Additionally, the group's ACL is removed when the group expires or the object itself expires. The plugin only grants access to files or directories within the blobs of the storage account it governs. Access to the storage account for users must be set up manually. It is recommended to give users the reader role on the storage account (this will allow them to see the blob names but not access their content). ### Object editing Using the libraries provided by Azure, it authenticates against the storage account that contains the container to be governed, in this case to manage the activation or deactivation of non-native entities. When a non-native entity is activated, the necessary permissions will be given to the group on the objects (Read, Execute at all levels from the root to the file representing the object, and in the case of a partitioned file, on all files present at that time), and when the object is deactivated, the group's ACLs will be removed when the group expires or the object itself expires. The plugin only grants access to files or directories within the blobs of the storage account it governs. Access to the storage account for users must be set up manually. It is recommended to give users the reader role on the storage account (this will allow them to see the blob names but not access their content). ## Required credentials It is necessary to register an application in Entra ID and generate the required clientID and secret so that the plugin can authenticate and acquire the necessary permissions for each functionality. The plugin has the capacity to handle only one storage account; therefore, it is necessary to create an instance for each of the storage accounts to be managed. ![att_1_for_171868322.png](https://wiki.anjanadata.com/__attachments/a_6427564925db986cecb601edc3e4472da5836a26d3491927fd40cf4e706fae2e/att_1_for_171868322.png?cb=425eec05bb0683a8d5d270dad4d11f22) ### Metadata extraction and data sampling Read permissions are required on the different storage types, as well as on the general configuration of the storage account itself. * Reader: Allows reading all resources, but not making any changes. * Storage Blob Data Reader: Read access on an Azure Storage Blob Container. * Storage File Data SMB Share Reader: Read access on Azure File Share using SMB. * Storage Table Data Reader: Read access for Azure Storage tables and entities. ![att_4_for_171868322.png](https://wiki.anjanadata.com/__attachments/a_55cdcd8c56b768db3b6c7504778e315ed92b0d9469ce5818b49108475a17d311/att_4_for_171868322.png?cb=8c3432e81cfa1fc4c57b75cb3a40405b) ### Active governance of access and structures * User Access Administrator: Ability to manage user access to Azure resources. * Storage Blob Data Owner: Full access to Azure Storage Blob Containers, the data they contain, and access to them. Required to be able to modify ACLs on governed files. ### Object editing * User Access Administrator: Ability to manage user access to Azure resources. * Storage Blob Data Owner: Full access to Azure Storage Blob Containers, the data they contain, and access to them. Required to be able to modify ACLs on governed files. ![att_3_for_171868322.png](https://wiki.anjanadata.com/__attachments/a_cfd9775c0b30dd04c775bbe8cef4c1acc7c3dee74cfa048a41629699c598cfe4/att_3_for_171868322.png?cb=b360f49abb57cc24248ae7c329f5abf8) ## Limitations The maximum number of effective ACLs on a file or directory is 28. In practical terms, this means that a blob can be governed by up to 28 DSAs at most, if no other system applies ACLs to that blob. When granting permissions to partitioned files, if the files in those partitions change or more are added, they will not contain the permissions that other parts of the same file have. Given the strict limitations of the technology, it is recommended to deprecate and expire the DSA as soon as possible once all of its governed objects have expired, in order to clean up unused ACLs. --- version: "26.1" language: "en" --- # Basic Operations with Objects ## Introduction The following highlights the basic operations that can be performed via the public API on the platform's objects. For more details on the endpoints, see [Swagger](https://wiki.anjanadata.com/en/integraciones/26.1/swagger.md) ## Creating an entity Creating or registering an entity is done in two phases: first the entity skeleton is created, and then the metadata is completed through editing. This is because, due to the complexity of native entities, creation only allows setting the primary fields and keys. If only the basic information is needed, then the first step will be sufficient. ### Creating the entity **Step 1. Create the entity skeleton.** Generates the entity with the fundamental values (name, OU, and PKs) and includes the necessary internal relationships (for example, in the case of an instance, with a process and a solution). POST https://{{host}}/gateway/api/v4/entity/create/{objectSubType} > At this stage, only the primary fields and keys can be set. The rest of the metadata is completed during the editing phase. ### Editing the entity **Step 2. Query the dynamic form structure.** Serves as a reference for building the input data for the modification. Returns the form structure along with its validations. GET https://{{host}}/gateway/api/v4/catalog/entity/{objectSubType} **Step 3 (optional). Query the full list of validations.** Also includes the *only-on-edition* validations. GET https://{{host}}/gateway/api/v4/catalog/complete/entity/{objectSubType} **Step 4 (optional). Query the structure of a specific entity.** Returns the fields and validations of a specific object. GET https://{{host}}/gateway/api/v4/catalog/entity/{objectSubType}/{idObject} **Step 5. Send the list of attributes to modify the entity.** Editing requires sending a list of attributes with the metadata modification. POST https://{{host}}/gateway/api/v2/entity/save/{objectSubType}/{idObject} ### Editing behavior * **If the object is in DRAFT status:** the previous values are modified directly. * **If the object is in APPROVED, DEPRECATED, or EXPIRED status:** a new DRAFT is created with a new ID, cloning everything necessary (for example, the *datasetfield* entries in a DATASET or the dataset relationships in a DSA) and leaving the original object intact. Just as from the portal, the submitted data is validated and the entity is only edited if all validations are passed. ### Validation Once editing is complete, the following endpoint is required to submit the entity for validation. POST https://{{host}}/gateway/api/v2/entity/submit/{objectSubType}/{idObject} ## Creating a relationship As with entities, working with relationships relies on the dynamic form as a reference for building the input data. Unlike the entity, the relationship is created directly by sending the list of attributes (there is no prior skeleton phase). ### Creating a relationship **Step 1. Query the dynamic form structure.** Allows you to find out which attributes the template of the relationship to be created has. Returns the form structure with the relationship's fields and their validations. GET https://{{host}}/gateway/api/v4/catalog/relationship/{objectSubType} **Step 2. Send the list of attributes to create the relationship.** Creation requires sending a list of attributes. Since this is a creation, the **name** must be included as an attribute of the object. POST https://{{host}}/gateway/api/v2/relationship/create/{objectSubType} > The created relationship will always be in **DRAFT** status. Just as from the portal, the data is validated and the relationship is only created if all validations are passed. ### Editing a relationship **Step 3. Query the dynamic form structure of the specific relationship.** Serves as a reference for building the modification data. Returns the relationship's fields and their validations. GET https://{{host}}/gateway/api/v4/catalog/relationship/{objectSubType}/{idObject} **Step 4. Send the list of attributes to modify the relationship.** Editing requires sending a list of attributes with the metadata modification. POST https://{{host}}/gateway/api/v2/relationship/save/{objectSubType}/{idObject} ### Editing behavior * **If the relationship is in DRAFT status:** the previous values are modified directly. * **If the relationship is in APPROVED, DEPRECATED, or EXPIRED status:** a new DRAFT is created with a new ID, leaving the original object intact. > Just as from the portal, the submitted data is validated and the relationship is only edited if all validations are passed. ### Validation Once editing is complete, the following endpoint is required to submit the relationship for validation. POST https://{{host}}/gateway/api/v2/relationship/submit/{objectSubType}/{idObject} ## Other operations ### Getting all relationships of an entity Allows you to obtain all the relationships that an entity has, including internal relationships. It consists of the following call: GET https://{{host}}/gateway/api/v2/relationship/all/{objectSubtype}/{id} ### Getting the defined values for an attribute Allows you to obtain all possible values of an attribute with predefined values of type SELECT. It consists of the call: POST https://{{host}}/gateway/api/v2/attribute/values --- version: "26.1" language: "en" --- # Databricks This page documents the integration of **Anjana Data Platform** with **Databricks** via the `tot-plugin-databricks` plugin. In its **Phase 1** , the integration enables the **discovery and extraction of technical metadata** (*read-only* mode) of the assets available in **Unity Catalog**, without performing any mutation on the source system. ## **Integration model** The `tot-plugin-databricks` connector integrates with **Unity Catalog** to discover assets and extract their structured technical metadata, adapting it to the operational metamodel of Anjana Data Platform. It acts as a **metadata extractor** -type plugin within the **Tot** architecture: it runs under its orchestration, implements the platform's standard contracts, and returns the information in the required format. The solution is decoupled from the cloud provider (Azure, AWS, and GCP), so that the same code operates against any of them without changes. The plugin implements the operations defined in the standard interface `ExtractMetadataControllerInterface` (`tot-plugin-lib`), corresponding to Tot's two extraction mechanisms: discovery (`metadataList`) and detail extraction (`metadataExtract`). ### **Supported assets** Phase 1 covers the following Unity Catalog asset types: |----------------------|---------------------------------------|------------------------------------------------------------------------------------------------------------------| | **Databricks asset** | **Proposed object SubType in Anjana** | **Nature** | | Catalog | DBK_CATALOG | Unity Catalog catalog. First-level logical container. | | Schema | DBK_SCHEMA | Schema within a catalog. Logical container. | | Dataset | DATASET | Tabular object (table, view, materialized view, streaming table). The specific type is reported in `dataFormat`. | | Volume | DBK_VOLUME | Unstructured data asset. Non-tabular and without columns. | ![image-20260715-132917.png](https://wiki.anjanadata.com/__attachments/a_f8d5eb19b7014ebf83d152bb60e6f9417b8ca3bd86ced8041455fd25a6418888/image-20260715-132917.png?cb=8fac2c790adff3fbdbf3d5526d3235d5) Hierarchy and depth level of the extraction The correspondence between each Unity Catalog asset type and the object `subType` used to represent it in Anjana **is not hard-coded** : it is declared in the connector YAML's `technology.mapping` block. The default values, which it is recom mended not to modify unless necessary, are: |----------------------------------------------|--------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Key in** `mapping`**(Unity Catalog type)** | **Proposed SubType in Anjana** | **Notes** | | `catalog` | DBK_CATALOG | N/A | | `schema` | DBK_SCHEMA | N/A | | `table` | DATASET | It is proposed to reuse this entity so that the structure of tables, views, and materialized views is represented in Anjana with the `subType` DATASET_FIELD | | `volume` | DBK_VOLUME | N/A | The resulting `subType` determines both the depth of the traversal in `metadataList` and the set of attributes extracted in `metadataExtract` --- for example, only **DATASET** generates `DATASET_FIELDS`. These names must match the `subType` values configured in the Anjana metamodel so that assets are associated with the correct template. ### **Asset discovery (metadataList)** The `metadataList` operation discovers and lists the assets available in Unity Catalog, allowing the user to explore the hierarchy and select the assets to import into Anjana Data Platform. The traversal follows Unity Catalog's native hierarchy, and its depth depends on the requested `subType`: * **DBK_CATALOG**, flat list of catalogs (root level). * **DBK_SCHEMA**, two-level tree: catalog \> schema. * **DATASET**, three-level tree: catalog \> schema \> tabular object (table, view, materialized view, streaming table). * **DBK_VOLUME**, three-level tree: catalog \> schema \> volume. The listing relies on Unity Catalog's REST APIs (`GET /api/2.1/unity-catalog/{catalogs|schemas|tables|volumes}`) and applies **pagination** via `max_results` and `page_token`, iterating until `next_page_token` is exhausted, with a per-operation safety page cap configurable in `maxPages` (default 1000) to avoid infinite pagination. To limit the cost of massive discovery, the parameters `omit_columns=true` and `omit_properties=true` can be used on `/tables`. The result is returned **deterministically sorted** by ascending `name` at each level and **deduplicated** by technical identifier. ### **Metadata extraction (metadataExtract)** The `metadataExtract` operation retrieves the detailed technical metadata of a specific asset, previously selected via `metadataList`, and transforms it to Anjana's model. The hierarchical path of the asset to extract is parsed using the separator configured in the YAML's `pathSeparator` and is internally converted to Databricks' fully qualified name (FQN). For each asset within scope, the plugin retrieves --- whenever available via the API --- the following metadata: * **physicalName**, the asset's fully qualified technical identifier (FQN). * **name**, the asset's name. * **path** , full hierarchical path (uses `pathSeparator`). * **description**, description when it exists. * **owner**, the asset's owner. * **createdAt**, creation date (epoch ms), when exposed by the API. * **tags**, asset-level tags. For tabular assets (**DATASET** ), the plugin also retrieves the column structure as `DATASET_FIELDS`, including name, native data type, position, nullability, description, and column tags. Column numbering is transformed from base 0 (Databricks) to base 1 (Anjana) during mapping. The operation is **atomic**: it returns the asset's complete result or an error, with no partial results. ![image-20260715-133124.png](https://wiki.anjanadata.com/__attachments/a_9506c2c911a99d3b4de83d99ac7a83f7cba657f651a589168346f8ddd2c82f60/image-20260715-133124.png?cb=481865ef2392747124cc84a74fbfe905) ### **Mapping to Anjana attributes** The extracted attributes are mapped to `entityAttributes` entries in Anjana. The attributes to be created in Anjana's functional configuration must have the following types (the names must match those in the `attribute Definition` table, `name` field, for them to appear in the template). #### DATASET (Table, View, Materialized View, Streaming Table.. in Databricks) |--------------------------------------------------|-------------------------------------------------------|-------------------------------------------|------------------------------------|-------------------------------------| | **ANJANA** (`name` in `attribute Definition`) | **Attribute name** (`type` in `attribute Definition`) | **DATABRICKS** | **APPLIES TO DATABRICKS ENTITIES** | **NOTES** | | physicalName (native) | INPUT_TEXT | full_name | ALL | FQN | | name (native) | INPUT_TEXT | name | ALL | Logical name | | path (native) | INPUT_TEXT | catalog/schema | ALL | hierarchical + asset, pathSeparator | | datasetId | INPUT_TEXT | table_id | ALL | Identifier | | infrastructure (native) | SELECT | resource.infrastructure | ALL | DTO | | technology (native) | SELECT | "Databricks" | ALL | Fixed | | zone (native) | SELECT | resource.zone | ALL | DTO | | schema (not native but common to other plugins) | INPUT_TEXT | schema_name | ALL | Container | | catalog (not native but common to other plugins) | INPUT_TEXT | catalog_name | ALL | Container | | data_format (native) | INPUT_TEXT | table_type | ALL | table, view, mv, st... | | dataSourceFormat | INPUT_TEXT | data_source_format | TABLE | Tables only | | storageLocation | INPUT_TEXT | storage_location | TABLE, MV, ST | Not in views | | description (native) | ENRICHED_TEXT_AREA_INTERNATIONAL | comment | ALL | Optional | | owner | INPUT_TEXT | owner | ALL | | | createdAt | | created_at | ALL | | | tags | ARRAY_ALPHANUMERICAL | /entity-tag-assignments/{type}/{FQN}/tags | ALL | Additional API call. key-value | #### DATASET_FIELD (Column structure of Databricks tabular entities) For the fields of tabular assets (`DATASET_FIELDS`), the following are additionally mapped: |-----------------------------------------------|-------------------------------------------------------|-------------------------------------------|------------------------------------|----------------------------------------------------------------------------------------------------------------------| | **ANJANA** (`name` in `attribute Definition`) | **Attribute name** (`type` in `attribute Definition`) | **DATABRICKS** | **APPLIES TO DATABRICKS ENTITIES** | **NOTES** | | Name | INPUT_TEXT | name | TABLE, MV, ST | Column name | | fieldDataType | INPUT_TEXT | type_name | TABLE, MV, ST | Databricks native type | | position | INPUT_NUMBER | position from 0 to n-1 | TABLE, MV, ST | Ordinal position (base 1) Column numbering is transformed from base 0 (Databricks) to base 1 (Anjana) during mapping | | nullable | INPUT_CHECKBOX | nullable | TABLE, MV, ST | true/false | | description | ENRICHED_TEXT_AREA_INTERNATIONAL | comment | TABLE, MV, ST | Description, when it exists | | tags | ARRAY_ALPHANUMERICAL | /entity-tag-assignments/{type}/{FQN}/tags | TABLE, MV, ST | Additional API call. For each tag: tag_key = name, tag_value = value | The **tags** attribute of datasets and dataset fields must have the name 'tags' in the `attribute Definition` table and be of type **ARRAY_ALPHANUMERICAL** . Tags are transformed by concatenating each `tag_key=tag_value` pair with the character defined in `attributeSeparator`. #### DBK_CATALOG (Catalog in Databricks) |-----------------------------------------------|-------------------------------------------------------|-------------------------------------------|------------------------------------|----------------------------------------------------------------------| | **ANJANA** (`name` in `attribute Definition`) | **Attribute name** (`type` in `attribute Definition`) | **DATABRICKS** | **APPLIES TO DATABRICKS ENTITIES** | **NOTES** | | physicalName (native) | INPUT_TEXT | full_name | Catalog | Unique catalog identifier | | name (native) | INPUT_TEXT | name | Catalog | Same as PHYSICAL_NAME | | path (native) | INPUT_TEXT | catalog_name | Catalog | Root | | infrastructure (native) | SELECT | resource.infrastructure | Catalog | Sourced from the DTO | | catalogId | INPUT_TEXT | id | Catalog | Identifier | | technology (native) | SELECT | "Databricks" | Catalog | Fixed value | | zone (native) | SELECT | resource.zone | Catalog | Sourced from the DTO | | description (native) | ENRICHED_TEXT_AREA_INTERNATIONAL | comment | Catalog | Optional | | owner | INPUT_TEXT | owner | Catalog | Owner | | createdAt | INPUT_TEXT | created_at | Catalog | Epoch ms | | catalogType | INPUT_TEXT | catalog_type | Catalog | MANAGED_CATALOG, DELTASHARING, etc. | | tags | ARRAY_ALPHANUMERICAL | /entity-tag-assignments/{type}/{FQN}/tags | Catalog | Additional API call. For each tag: tag_key = name, tag_value = value | #### DBK_SCHEMA (Schema in Databricks) |--------------------------------------------------|-------------------------------------------------------|-------------------------------------------|------------------------------------|----------------------------------------------------------------------| | **ANJANA** (`name` in `attribute Definition`) | **Attribute name** (`type` in `attribute Definition`) | **DATABRICKS** | **APPLIES TO DATABRICKS ENTITIES** | **NOTES** | | physicalName (native) | INPUT_TEXT | full_name | Schema | FQN | | name (native) | INPUT_TEXT | name | Schema | Schema name | | path (native) | INPUT_TEXT | catalog_name | Schema | Represents all hierarchical levels+asset uses pathSeparator | | infrastructure (native) | SELECT | resource.infrastructure | Schema | Sourced from the DTO | | schemaId | INPUT_TEXT | id | Schema | Identifier | | technology (native) | SELECT | "Databricks" | Schema | Fixed value | | zone (native) | SELECT | resource.zone | Schema | Sourced from the DTO | | description (native) | ENRICHED_TEXT_AREA_INTERNATIONAL | comment | Schema | Optional | | owner | INPUT_TEXT | owner | Schema | Owner | | createdAt | INPUT_TEXT | created_at | Schema | Epoch ms | | catalog (not native but common to other plugins) | INPUT_TEXT | catalog_type | Schema | Hierarchical relationship | | storageLocation | INPUT_TEXT | /entity-tag-assignments/{type}/{FQN}/tags | Schema | Optional | | tags | ARRAY_ALPHANUMERICAL | | Schema | Additional API call. For each tag: tag_key = name, tag_value = value | ### **Assets with special characters in the name** Unity Catalog allows characters such as `/` in asset names. If used, `pathSeparator` must be configured with a character other than `/` to guarantee correct construction of the `path` attribute. Any character except `:` can be used. The Databricks plugin's `pathSeparator` must match that of the rest of the plugins, as well as the extraction path separator of Kerno and Tot. ![image-20260716-104246.png](https://wiki.anjanadata.com/__attachments/a_d5dd9fb8b212883500b84cd6e12d9dc8dff60d2721435472133389bbee7420be/image-20260716-104246.png?cb=2949f937d0c7b4727ad31f49e57c92bb) Kerno and Tot path separator configuration in the Administration Portal ## **Required credentials and privileges** ### **Metadata discovery and extraction** The integration requires a **Service Principal** with **read-only** permissions on the assets to be governed. It is the client's responsibility to: * **Service Principal** , with the **read** privileges on Unity Catalog required for discovery and metadata extraction in Phase 1 (see the detail in *Required privileges in Unity Catalog*). * **Governance workspace** (*playground* ) and assets **accessible** to the technical entity used by the plugin (see *Provisioning the governance workspace*). * **Correct credential configuration** in the connector's YAML. The effective visibility of assets depends on the Service Principal's hierarchical permissions in Unity Catalog and on the configuration of the workspace from which it operates. ### **Required privileges in Unity Catalog** Having a **Service Principal** is not enough: for the Unity Catalog APIs to respond, the identity must have **explicitly granted** the privileges that allow traversing the hierarchy and reading each asset's metadata. Unity Catalog's privilege model is **hierarchical**, so reaching a table or a volume requires first being able to traverse its catalog and its schema. The minimum privileges required by the API are: |-----------------------------|-------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------| | **Unity Catalog privilege** | **Granted on** | **Necessary for** | | `USE CATALOG` | The catalogs to be discovered | Access the catalog and discover its schemas. Required for all subtypes. | | `USE SCHEMA` | The schemas to be discovered | Access the schema and discover its tables and volumes. Required for DBK_DATASET and DBK_VOLUME. | | `BROWSE` | For the objects whose metadata is to be extracted (tables, views, volumes...) | Recommended | | `SELECT` | The table or view (DBK_DATASET) | Read the metadata and column structure of tabular objects. | | `READ VOLUME` | The volume (DBK_VOLUME) | Read the metadata of unstructured data volumes. | In summary, the credential always needs `USE CATALOG` and `USE SCHEMA` to navigate the hierarchy, and additionally `SELECT` on tables or `READ VOLUME` on the volumes to be governed, depending on the asset type. Since these are hierarchical privileges, they can be granted at the catalog or schema level so that they cascade over the contained objects. ![image-20260715-135611.png](https://wiki.anjanadata.com/__attachments/a_ebfba5dce0bf77612f10e10ef67c8e8803374a3c650d2db85e9504c29ad54418/image-20260715-135611.png?cb=ba6d8e7431bf48ddc89fd2306b2a00da) The absence of these privileges does not produce an authentication failure, but an **authorization** one: in `metadataList` it results in a `403` that omits the affected scope (WARN), and in `metadataExtract` a `NOT_FOUND` ("does not exist or is not accessible"). A correctly authenticated Service Principal without privileges will therefore see an empty catalog. ### **Provisioning the governance workspace (playground)** The plugin always operates **from a Databricks workspace** , so its provisioning is a prerequisite as critical as the credentials themselves. It is the **client's responsibility** to have a **governance workspace** --- commonly called a *playground* --- that acts as the plugin's single point of access to Unity Catalog. For discovery and extraction to work, that workspace must meet two conditions: * **Service Principal enablement**, the technical identity used by the plugin must be registered and enabled in the governance workspace. * **Asset accessibility** , the catalogs and assets to be governed must be **bound and accessible** from that workspace. In Unity Catalog, a catalog not bound to the workspace is not visible even if the Service Principal has privileges on it. The effective visibility of an asset is, therefore, the **intersection** of two independent conditions: that the Service Principal has the Unity Catalog privileges described in the previous section, and that the asset is accessible from the governance workspace. If either is missing, the asset will not appear in discovery. ![image-20260715-135459.png](https://wiki.anjanadata.com/__attachments/a_a2b746c76045ca1efd0484489186063611850d8802f592ae2b93856dc5623b1e/image-20260715-135459.png?cb=ab4f6988b0ed6bf58936517c91481c71) Incomplete workspace provisioning is the most common cause of **empty discovery despite having valid credentials**. Before reporting an incident, it is advisable to verify that the governance workspace has the catalogs bound and the Service Principal enabled. ## **Authentication and authorization** The plugin authenticates against Databricks using **OAuth 2.0 Client Credentials with Service Principal** . The difference between cloud providers is limited to how the *Bearer Token* is obtained; the functional logic remains decoupled and the strategy is resolved through configuration via the YAML's `authType` parameter. Personal tokens (PAT) and user credentials are not supported. |--------------------|--------------------------------------|-----------------| | **authType** | **Required parameters** | **Cloud** | | `databricks-oauth` | host, clientId, clientSecret | Azure, AWS, GCP | | `azure-sp` | host, tenant, clientId, clientSecret | Azure only | The connection and authentication parameters are defined in `technology.credential` within each connection of the connector's YAML: |----------------|---------------------------------------------------------------------------------|-----------------| | **Parameter** | **Description** | **Applies to** | | `host` | URL of the Databricks workspace against which the connection operates. | Both strategies | | `authType` | Token acquisition strategy. Supported values: `databricks-oauth` or `azure-sp`. | Both strategies | | `clientId` | Service Principal identifier. | Both strategies | | `clientSecret` | OAuth secret associated with the Service Principal. | Both strategies | | `tenant` | Azure Entra ID tenant identifier. | Only `azure-sp` | Any `authType` value other than the two supported ones causes the `PLUGIN_INCOMPLETE` error. ### **Databricks OAuth M2M (primary strategy)** Databricks exposes a native OIDC provider in each workspace, from which the plugin requests the token directly (`POST {host}/oidc/v1/token`). It is the recommended strategy because it works the same way on Azure, AWS, and GCP, only requires `host`, `clientId`, and `clientSecret`, and does not depend on external providers. It is selected with `authType: "databricks-oauth"`. #### Step 1: Create the Service Principal in Databricks • Access Databricks Account Console → User Management → Service Principals. • Create a new Service Principal ![image-20260716-105612.png](https://wiki.anjanadata.com/__attachments/a_aa33b3d5277d1494fb8b86d6c7ed25788a50dee152310c4b37a74fbbe216e37e/image-20260716-105612.png?cb=82582843f6f3021adc7c0015bd8c7943) More detail in the official Azure Databricks documentation: #### Step 2: Generate OAuth credentials * Generate an OAuth Secret for the Service Principal. * Note down the following values to add to the YAML: * **clientId**(application Id) * **clientSecret**(create an authentication secret in the Secrets section) ![image-20260716-105939.png](https://wiki.anjanadata.com/__attachments/a_371d11f4383f527821d5df574b4aeb6ceeb86e33b3c61aef87c624f33f370041/image-20260716-105939.png?cb=907abbe42f5305a68c02f70cbf48ded0) ![image-20260716-105958.png](https://wiki.anjanadata.com/__attachments/a_4d712ea2d10a25fa318b46c35bd6044167942480cf9c24e6518369c6c8d654bb/image-20260716-105958.png?cb=c644e366915dc11c97066ac06112df52) #### Step 3: Grant minimum privileges on Unity Catalog assets Grant the privileges indicated in [Required privileges in Unity Catalog](https://wiki.anjanadata.com/en/integraciones/26.1/databricks.md#Privilegios-requeridos-en-Unity-Catalog). The plugin only queries metadata via the Unity Catalog REST APIs. It does not access the content of tables or volumes, nor does it perform write operations or permission modifications. The plugin uses Unity Catalog's listing APIs (Catalogs, Schemas, Tables, and Volumes). If authorization errors occur on tables or volumes during discovery, it will be necessary to grant the minimum privileges indicated by Databricks for those resources (USE CATALOG, USE SCHEMA, and SELECT for tables or READ VOLUME for volumes). These requirements are defined by Unity Catalog's own official API documentation and may vary depending on the permission strategy used by the client. #### Step 4: Configure the plugin's YAML Add to the YAML: * Authorization type `authType: "databricks-oauth"` * Host * Client ID / Application Id (obtained in Databricks Account in Step 2) * Client Secret (obtained in Databricks Account in Step 2) ### **Azure Entra ID (alternative strategy)** Authentication via Azure Entra ID Service Principal (`POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token`), recommended in exclusively Azure environments that want to reuse an existing identity. It is selected with `authType: "azure-sp"` and additionally requires the `tenant`. The connection and authentication parameters are defined in `technology.credential` within each connection of the connector's YAML: #### **Step 1: Create an App Registration in Microsoft Entra ID** • Microsoft Entra ID → App registrations. • Register a new application. #### **Step 2: Create a Client Secret** * Generate a Client Secret. * Note down the following values to add to the YAML: * tenantId * clientId * clientSecret #### **Step 3: Register the Service Principal in Databricks** Register the Entra ID application as a Service Principal in Databricks (Account Console or via SCIM/API, depending on the environment's administration) and follow the rest of the steps required by the configuration to register the Service Principal within Databricks ![image-20260716-111921.png](https://wiki.anjanadata.com/__attachments/a_4f24e9aebd4052b7b80dfcaf076aeffb2cd2fb286ac30276271120da82a716fa/image-20260716-111921.png?cb=4f1741c9b0aa69537328b44f6f5ef90d) More information at: #### **Step 4: Assign the Service Principal to the Workspace** Add the Service Principal to the corresponding Workspace #### **Step 5: Grant minimum permissions** Grant the privileges indicated in [Required privileges in Unity Catalog](https://wiki.anjanadata.com/en/integraciones/26.1/databricks.md#Privilegios-requeridos-en-Unity-Catalog). The plugin only queries metadata via the Unity Catalog REST APIs. It does not access the content of tables or volumes, nor does it perform write operations or permission modifications. The plugin uses Unity Catalog's listing APIs (Catalogs, Schemas, Tables, and Volumes). If authorization errors occur on tables or volumes during discovery, it will be necessary to grant the minimum privileges indicated by Databricks for those resources (USE CATALOG, USE SCHEMA, and SELECT for tables or READ VOLUME for volumes). These requirements are defined by Unity Catalog's own official API documentation and may vary depending on the permission strategy used by the client. #### Step 6: Configure the plugin's YAML Add to the YAML: * Authorization type `authType: "azure-sp"` * Host * Tenant (obtained in Azure in Step 2) * Client ID / Application Id (obtained in Azure in Step 2) * Client Secret (obtained in Azure in Step 2) ## **Error handling and retries** The plugin distinguishes between **functional errors** (input validation, unsupported `subType`, incorrect `element` format), which are not retried, and **transient technical errors** (network, HTTP 5xx, throttling), which are retried according to a configurable policy. In `metadataList`, partial errors per scope (catalog/schema) are tolerated to maximize discovery coverage; in `metadataExtract`, partial results are not allowed. The retry policy is defined per connection via `databricksCountRetry` (maximum number of retries) and `databricksWaitRetry` (base wait, in seconds, between retries). On `429` errors with a `Retry-After` header, the plugin honors that value; in its absence, it applies exponential back-off starting from `databricksWaitRetry`. If the error affects a root level of discovery (for example, the inability to list catalogs), it is considered a global error and the operation is aborted. ## **Configuration** ### **Connectivity** The plugin's connectivity is established against the Unity Catalog REST APIs (`/api/2.1/unity-catalog/...`) over the `host` of the Databricks workspace. Domains vary depending on the cloud: * **Azure** : `https://adb-xxxx.azuredatabricks.net` * **AWS** : `https://xxxx.cloud.databricks.com` * **GCP** : `https://xxxx.gcp.databricks.com` ### **Multi-connection** The plugin supports multiple connections to different Databricks workspaces or environments. Each connection is uniquely identified by the **infrastructure / technology / zone** triple (ARI model), where `zone` acts as a logical discriminator. It is recommended to configure a **workspace dedicated to governance** (*playground*) as a central access point under a single ARI. The separator that Anjana uses to retrieve the values of a list-type attribute (for example, tags) is controlled via `attributeSeparator`. It is not normally necessary to modify it. ### **Performance and limits** The plugin regulates the load it places on the Unity Catalog APIs through two YAML blocks, with reasonable default values that normally do not require adjustment: * **rate-limit** , limits the rate of calls with `requests-per-second` (requests per second) and `timeout-seconds` (maximum wait time per request). * **concurrency** , controls the parallelism of discovery and tag retrieval via `listing-threads` and `listing-batch-size` (listing) and `tags-threads` and `tags-batch-size` (tags). Additionally, `maxPages` limits the maximum number of pages per operation (default 1000), as a safeguard against unbounded pagination. Common guidelines for all plugins are available in the [Technical configuration](https://wiki.anjanadata.com/es/configuracion/25.2/configuracion-tecnica) and [Tot plugin deployment](https://wiki.anjanadata.com/es/configuracion/25.2/tot-despliegue-de-plugins) sections. In addition, a [**sample YAML**](https://wiki.anjanadata.com/en/integraciones/26.1/example-yaml-databricks-plugin.md) is available to facilitate plugin setup (child page). This file includes the description of each property and its default values, so it can be copied and adapted to the client's installation. ## Appendix More information about the APIs: --- version: "26.1" language: "en" --- # Denodo ## **Integration Model** ### **Metadata extraction** To extract the metadata of an object, the methods provided by the com.denodo.vdp.jdbc.Driver driver are used, through which the schema and table definitions are accessed. The plugin extracts the following attributes, which must be named the same in the attribute_definition table, name field, so that they appear in the template: * **catalog**with the catalog value in the database * **schema**with the schema value in the database * **physicalName** and **name**with the same value, the table name * **path**with the concatenation of the catalog, schema and table values * **infrastructure**with the selected value * **technology**with the selected value * **zone**with the selected value * **tags**are the view-level tags that the tables have. It also sends the following attributes related to the fields of the requested resource: * **name** and **physicalName**with the field value * **defaultValue**with the default value defined for the field * **fieldDataType**with the data type defined for the field * **length**with the field size * **incrementalField**indicating whether it is an incremental field * **position**the position occupied by the field * **precision**with the field's precision value * **nullable**indicating whether the field is nullable * **pk**indicating whether the field is a pk * **description**with the value for the field * **tags**are the column-level tags that the tables have. The attributes to be created in Anjana must have the following types: |--------------------|----------------------------------| | **Attribute name** | **Attribute type** | | Catalog | INPUT_TEXT | | Schema | INPUT_TEXT | | PhysicalName | INPUT_TEXT | | Path | INPUT_TEXT | | Infrastructure | SELECT | | Technology | SELECT | | Zone | SELECT | | Tags | ARRAY_ALPHANUMERICAL | | Name | INPUT_TEXT | | DefaulValue | INPUT_TEXT | | FieldDataType | INPUT_TEXT | | Length | INPUT_NUMBER | | IncrementalField | INPUT_CHECKBOX | | Position | INPUT_NUMBER | | Precision | INPUT_NUMBER | | Nullable | INPUT_CHECKBOX | | Pk | INPUT_CHECKBOX | | Description | ENRICHED_TEXT_AREA_INTERNATIONAL | The plugin is able to extract metadata from the following types of Denodo elements: * Database table views * Interfaces * Derived #### Tables with characters in the name This technology allows characters such as "/" in the name; if they are being used, the path-separator must be configured with a character other than "/". See [File extraction](https://wiki.anjanadata.com/es/integraciones/25.2/extraccion-de-metadata-de-ficheros) for more details. ### **Data sampling** Using the Java com.denodo.vdp.jdbc.Driver driver, a simple SELECT query is executed to access a limited number of table elements in order to retrieve a sample of the stored data. Additionally, the values of sensitive fields are replaced with asterisks. If any View type is incorrectly defined in Denodo, sampling will not be possible. Likewise, if the implementations associated with Interface-type Views are modified after they have been created, sampling will also fail. ### **Access permissions management** Through queries, Denodo roles can be created/deleted when a DSA is approved or expires, and the necessary permissions on the table view (Read, Connect) are managed when datasets are added to or expire from a DSA. The Ldap or Entra ID plugin must be deployed to allow creating the groups. #### Permissions management flow 1. **DSA creation**: The ROLE is created (CREATE ROLE) and read-only permissions are granted (GRANT READ on the views, GRANT CONNECT on the vdb) 2. **DSA deletion or expiration**: The role is deleted (DROP ROL) and read-only permissions are removed (REVOKE READ on the views, REVOKE CONNECT on the vdb) 3. When an object is removed from the DSA(`dsaContent`), expires or is disabled: Permissions on the views are revoked (REVOKE READ) ### Object editing When a non-native entity is activated or deactivated, through queries, permissions on the corresponding tables are granted to or removed from the Denodo roles. ## **Required credentials** ### **Metadata extraction** User with the necessary privileges to perform SELECT on the views of the tables to be governed (Connect, Metadata and Execute). ### **Data sampling** User with the necessary privileges to perform SELECT on the views of the tables to be governed (Connect, Metadata and Execute). ### **Permissions management** To perform active governance operations, the following roles are required for the connection user specified in the yml: * **create_role** -\> Required to create roles. * **assignprivileges** -\> Required to perform the grant/revoke. * **drop_role**-\> Required to delete roles. ### Object editing When a non-native entity is activated or deactivated in Anjana, the plugin will grant or remove the permissions on the corresponding tables. To perform these actions, the connection user specified in the yml must have the permission: * **assignprivileges** -\> Required to perform the grant/revoke. ## Authentication and authorization ### With Ldap For the Denodo plugin to work, authentication and authorization with Ldap must be enabled in Denodo. To do this, follow these steps: [++https://community.denodo.com/docs/html/browse/8.0/en/vdp/administration/server_configuration/server_authentication/ldap_authentication/ldap_authentication++](https://community.denodo.com/docs/html/browse/8.0/en/vdp/administration/server_configuration/server_authentication/ldap_authentication/ldap_authentication) For both authentication and authorization to work, users must not exist in Denodo, only in Ldap; this way, it connects to Ldap to authenticate and authorize. ### With Entra ID For the Denodo plugin to work, authentication and authorization with EntraID must be enabled in Denodo. To do this, follow these steps: [++https://community.denodo.com/kb/en/tag/Azure%20AD++](https://community.denodo.com/kb/en/tag/Azure%20AD) For both authentication and authorization to work, users must not exist in Denodo, only in EntraID; this way, it connects to EntraID to authenticate and authorize. ## **Tag update** The plugin can automatically update the tags modified in Anjana in Denodo, for all datasets that are governed and are approved or deprecated. This synchronization is performed through a batch process, configured by means of a crontab command that defines how often the action should run. To perform tag update operations, the following roles are required for the connection user specified in the yml: * **manage_tags** -\> Required to create the tags. * **assign_tags**-\> Required to assign tags to the columns. In the following example, the process runs Monday through Friday every hour from 7:00 to 22:00: YAML totplugin: batch: tags: cron: 0 0 7-22 * * MON-FRI In addition, the triplet ARI will need to be configured to specify which Anjana objects will be acted upon. YAML totplugin: connection: - ... aris: ari: "anja:totplugin:updateTags:/jdbc/denodo/denodo/" It is also possible to configure the separator that Anjana uses to retrieve the values of a list-type attribute. This value normally does not need to be changed, but if it does, the following configuration can be modified: YAML totplugin: anjana: attributeSeparator: "_-" The tags attribute of the datasets and dataset fields must have the name 'tags' in the attribute_definition table and be of type ARRAY_ALPHANUMERICAL. ## **Configuration** ### **Connectivity** The plugin's connectivity is done through: * JDBC protocol. The connection URL to the VDP must be provided as explained in the example configuration file * Port. The standard VDP port is usually 9999, although this may vary depending on the context in which the plugin is installed ### Case-sensitive queries The Denodo plugin runs the queries including the names of tags, roles, schemas and datasources in double quotes so that they are case sensitive, but it is also necessary to configure the following property in the Denodo portal: ![att_1_for_171868349.png](https://wiki.anjanadata.com/__attachments/a_a6ceba6cbad2912be5d9fde17e58250c055d9ba45480f390716ab54e19a1c5c1/att_1_for_171868349.png?cb=ffcf2554a5f382ca8e0a0ff2c7940361) ## **Check the tags available in Denodo** There are two options: * In the tags section of Denodo ![att_2_for_171868349.png](https://wiki.anjanadata.com/__attachments/a_d08116b829097991ff4e0af67cb273081b1344405afb915a4b7e25053f015a0a/att_2_for_171868349.png?cb=247c9b7a070b45f7dd29d260801fefcb) * Running this query SQL SELECT column_name, tag_name from GET_VIEW_TAGS() WHERE INPUT_DATABASE_NAME = 'dev' and INPUT_VIEW_NAME= 'anjana_adherence_cart'; They appear as follows: ![att_4_for_171868349.png](https://wiki.anjanadata.com/__attachments/a_4dd772c9151f52b12a67d7d72d21859926f573a1e837d95af59e8b6128ce69f9/att_4_for_171868349.png?cb=fee627fe1d44bc68f2bd40f39199e1c5) --- version: "26.1" language: "en" --- # Example YAML - AWS Glue Plugin YAML #################################################################################################### # Example YAML for Tot Plugin AWS Glue 6.0.0 # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening to port: 15019 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ connection: # name of this instance connection - name: instance-1 # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/AWS/awsGlue/devQA/" ################################ ## Glue technology properties ## accessKey: the access key ## secretKey: the secret key ## catalogId: the catalog id ## region: the AWS region selected ## pathSeparator: character to be used by Anjana for the path ## ################################ technology: accessKey: secretKey: bucket: region: path-separator: "/" sample-rows: 5 obfuscation-string: "*****" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-AWS-S3] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - AWS IAM Plugin YAML #################################################################################################### # Example YAML for Tot Plugin AWS IAM 6.0.0 # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15008 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ connection: # name of this instance connection - name: awsS3 # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/AWS/awsS3/devQA/" - ari: "anja:totplugin:sample:/AWS/awsS3/devQA/" - ari: "anja:totplugin:im:/AWS/awsS3/devQA/" imAri: "anja:totplugin:im:/AWS/awsIam/devQA/" ################################ ## S3 technology properties ## proxy: url to Amazon S3 ## accessKey: the access key ## secretKey: the secret key ## idAccount: the id of the account to connect with ## bucket: the AWS bucket to connect with ## region: the AWS region selected ## groupPrefix: the prefix to concat to the names of the groups ## bucketPolicy: the name of the bucket policy ## policyPrefix: the prefix to concat to the policies ## ################################ technology: proxy: "proxy.corp.local" # hostname only (optional) proxyPort: 8080 # optional proxyScheme: http # optional, defaults to "http" accessKey: secretKey: idAccount: bucket: region: groupPrefix: Dsa_ bucketPolicy: "anjana_ListAllMyBuckets" policyPrefix: "DsaPolicy_" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-AWS-S3] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - AWS S3 Plugin YAML #################################################################################################### # Example YAML for Tot Plugin AWS S3 6.0.0 # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15007 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ connection: # name of this instance connection - name: awsS3 # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/AWS/awsS3/devQA/" - ari: "anja:totplugin:sample:/AWS/awsS3/devQA/" - ari: "anja:totplugin:im:/AWS/awsS3/devQA/" imAri: "anja:totplugin:im:/AWS/awsIam/devQA/" ################################ ## S3 technology properties ## accessKey: the access key ## secretKey: the secret key ## bucket: the AWS bucket to connect with ## region: the AWS region selected ## path-separator: character to be used by Anjana for the path ## sampleRows: number of sample rows ## obfuscation-string: string to replace information when it is obfuscated ## attributeSeparator: Character to be used between multi-value attributes ## ################################ technology: accessKey: secretKey: bucket: region: path-separator: "/" sample-rows: 5 obfuscation-string: "*****" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-AWS-S3] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - Azure EntraID Plugin YAML #################################################################################################### # Example YAML for Tot Plugin Azure AD # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # Port where service will be listening port: 15009 ############################## ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ connection: # Name of the instance, multiples instance can be configured - name: {instance-name} # To define the different ARIs of instance functionalities aris: - ari: "anja:totplugin:im:/Azure Analytics/azureAD/devQA/" # Azure properties technology: clientId: {clientId} tenantId: {tenantId} secret: {secret} scopes: {scopes} groupPrefix: {groupPrefix} azureCountRetry: {azureCountRetry} azureWaitRetry: {azureWaitRetry} ################################ ## Azure AD properties ## clientId: the client id ## tenantId: the tenant id ## secret: the secret key ## scopes: the scope permissions to connect the API. They must be defined in Azure AD. ## groupPrefix: Prefix group to concat the group name ## azureCountRetry: how many retries for the azure API ## azureWaitRetry: wait in seconds between retries for the azure API ################################ ######################### ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-AZURE-AD] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # Url where Tot is listening defaultZone: https://tot1server.anjanadata.local/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - Azure Storage Plugin YAML ################################################################################################### # Example YAML for Tot Plugin Azure Storage # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # ################################################################################################### ######################### ### Server properties ### ######################### server: # Port where service will be listening port: 15012 ########################## ### Logs properties ### ########################## logging: # Pattern to convert logs in the convenient format for the client pattern: console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [AZURE-STORAGE] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level is the base for all logs root: INFO # Every package of code can be marked with a different log level, every package of code printed # on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################## ### General Spring properties ### ################################## spring: application: # Application name to be as identifier name: tot-plugin-azure-storage loadbalancer: ribbon: # Disable the default Ribbon-backed load balancing strategy enabled: false ################################## ### Plugin properties ### ################################## totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - http://totserver/totserver/ # How often will send a hearbeat to tot in seconds keep-alive-seconds: 60 # Character to be used between multi-value attributes attributeSeparator: "_-" connection: # Name of the instance - name: "instance_name" # List of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/Azure Analytics/azureStorage/pro/" - ari: "anja:totplugin:sample:/Azure Analytics/azureStorage/pro/" - ari: "anja:totplugin:edit:/Azure Analytics/azureStorage/pro/" - ari: "anja:totplugin:edit:/Azure Analytics/azureStorage/devQA/" - ari: "anja:totplugin:im:/Azure Analytics/azureStorage/pro/" imAri: "anja:totplugin:im:/Azure Analytics/azureAD/pro/" technology: # The name of the storage account to connect storageAccount: "account" # Client id to connect to azure storage clientId: "client_id" # Tenant id to connect to azure storage tenantId: "tenant_id" # Secret id to connect to azure storage secret: "secret" # Number of sample rows returned sampleRows: 15 # Character to be used to process the path into its parts pathSeparator: "/" # Character to be used to process the path into its parts obfuscation-string: "*****" --- version: "26.1" language: "en" --- # Example YAML - Databricks Plugin YAML #################################################################################################### # Example YAML for Tot Plugin Databricks 1.0 (Phase 1: metadata discovery and extraction) # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # Port where service will be listening port: 15021 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ # Character used to build/interpret the logical path (path attribute). Default: "/" # Use a different character if asset names may contain "/". Any character except ":" is allowed. pathSeparator: "/" # Separator used by Anjana to read the values of a list-type attribute (e.g. tags). attributeSeparator: "_-" # Rate limiting applied by the plugin against the Unity Catalog REST API rate-limit: requests-per-second: 10 timeout-seconds: 30 # Concurrency settings for listing and tag retrieval concurrency: listing-threads: 4 listing-batch-size: 8 tags-threads: 5 tags-batch-size: 10 ################################ ## Databricks connection properties ## name: Name of the connection instance ## aris: list of aris that define the functionalities of the instance (Phase 1: extract) ## technology.credential: specific connection/authentication properties of the instance ## ## host: Databricks workspace URL ## ## ## Azure: https://adb-xxxx.azuredatabricks.net ## ## ## AWS: https://xxxx.cloud.databricks.com ## ## ## GCP: https://xxxx.gcp.databricks.com ## ## authType: token strategy. Only "databricks-oauth" or "azure-sp" are allowed ## ## tenant: Azure Entra ID tenant id (only required when authType is "azure-sp") ## ## clientId: Service Principal id ## ## clientSecret: OAuth secret ## ## databricksCountRetry: max number of retries for transient errors ## ## databricksWaitRetry: base wait time (seconds) between retries ## ## maxPages: max pages per operation to avoid infinite pagination (default 1000) ## technology.mapping: subType assigned to each Unity Catalog asset type ################################ connection: # --- Connection 1: native Databricks OAuth M2M (recommended, works on Azure/AWS/GCP) --- - name: DBK-OAuth aris: - ari: "anja:totplugin:extract:/Databricks/databricks/dev-1/" technology: credential: host: "https://adb-xxxx.azuredatabricks.net" authType: "databricks-oauth" clientId: "your-client-id" clientSecret: "your-client-secret" databricksCountRetry: 5 databricksWaitRetry: 5 maxPages: 1000 mapping: catalog: DBK_CATALOG schema: DBK_SCHEMA table: DATASET volume: DBK_VOLUME # --- Connection 2: Azure Entra ID Service Principal (Azure-only alternative) --- - name: DBK-AzureSP aris: - ari: "anja:totplugin:extract:/Databricks/databricks/dev-2/" technology: credential: host: "https://adb-yyyy.azuredatabricks.net" authType: "azure-sp" tenant: "your-tenant-id" clientId: "your-client-id" clientSecret: "your-client-secret" databricksCountRetry: 5 databricksWaitRetry: 5 maxPages: 1000 mapping: catalog: DBK_CATALOG schema: DBK_SCHEMA table: DATASET volume: DBK_VOLUME ######################### ### Logs properties ### ######################### logging: pattern: # Pattern to convert logs into the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-DATABRICKS] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Log level per package. ERROR > WARN > INFO > DEBUG > TRACE level: root: info com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # Url where Tot is listening defaultZone: https://tot1server.anjanadata.local/totserver/ --- version: "26.1" language: "en" --- # Example YAML - Denodo Plugin YAML #################################################################################################### # Example YAML for Tot Plugin JDBC Denodo 5.1.0 # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # Port where service will be listening port: 15018 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ ################################ ## Denodo connection properties ## name: Name of the connection instance ## aris: list of aris to define the different instance functionalities ## technology: bellow this are the specific connection properties of the instance ## ## driver: denodo driver ## ## url: denodo connection url ## ## user: user ## ## password: password ## ## sampleRows: page size of sample rows ## ## path-separator: character to be used on path ## ## obfuscation-string: string to replace information when it is obfuscated ## ## imType: string to indicate which IM denodo is using, only options are LDAP and ENTRA ID ################################ connection: - name: denodo-entra aris: - ari: "anja:totplugin:updateTags:/jdbc/denodo/devQA-1/" - ari: "anja:totplugin:sample:/jdbc/denodo/devQA-1/" - ari: "anja:totplugin:extract:/jdbc/denodo/devQA-1/" - ari: "anja:totplugin:edit:/jdbc/denodo/devQA-1/" - ari: "anja:totplugin:im:/jdbc/denodo/devQA-1/" imAri: "anja:totplugin:im:/Azure Analytics/azureAD/devQA-1/" technology: url: jdbc:vdb://host:9999/EID user: password: imType: "ENTRA ID" - name: denodo-ldap aris: - ari: "anja:totplugin:updateTags:/jdbc/denodo/devQA-2/" - ari: "anja:totplugin:sample:/jdbc/denodo/devQA-2/" - ari: "anja:totplugin:extract:/jdbc/denodo/devQA-2/" - ari: "anja:totplugin:edit:/jdbc/denodo/devQA-2/" - ari: "anja:totplugin:im:/jdbc/denodo/devQA-2/" imAri: "anja:totplugin:im:/ldap/ldap/ldap/" technology: url: jdbc:vdb://host:9999/LDAP user: password: imType: "LDAP" batch: tags: # Cron configuration to execute tags batch. E.g. Every hour, between 07:00 AM and 10:59 PM, Monday through Friday cron: 0 0 7-22 * * MON-FRI ######################### ### Logs properties ### ######################### logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC-DENODO] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # Url where Tot is listening defaultZone: https://tot1server.anjanadata.local/totserver/ --- version: "26.1" language: "en" --- # Example YAML - GC BigQuery Plugin YAML #################################################################################################### # Example YAML for Tot Plugin GCP BigQuery # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15002 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - http://totserver/totserver/ connection: # Name of the instance, multiples instance can be configured - name: {instance-name} # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/Google/gcpBigQuery/devQA/" - ari: "anja:totplugin:sample:/Google/gcpBigQuery/devQA/" - ari: "anja:totplugin:edit:/Google/gcpBigQuery/devQA/" - ari: "anja:totplugin:im:/Google/gcpBigQuery/devQA/" imAri: "anja:totplugin:im:/Google/gcpIam/devQA/" # value used in anjana to separate the values in a multi value attribute value attributeSeparator: {anjana_attribute_separator} ############################################################################################################### ## BigQuery connection properties ## credentialsContent: the json to download from GCP with the credentials to connect with the GCP Server ## path-separator: character to be used by Anjana for the path ## sampleRows: number of sample rows ## sampleQueryPattern: the query to extract the sample with ## obfuscation-string: string to replace information when it is obfuscated ############################################################################################################### technology: credentialsContent: | { "type": "service_account", "project_id": {project_id}, "private_key_id": {private_key_id}, "private_key": "-----BEGIN PRIVATE KEY----------END PRIVATE KEY-----\n", "client_email": {client_email}, "client_id": {client_id}, "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": {client_x509_cert_url} } sample-rows: 15 path-separator: "/" obfuscation-string: "*****" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-GCP-BIGQUERY] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - GCP IAM Plugin YAML #################################################################################################### # Example YAML for Tot Plugin GCP IAM # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15010 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - http://totserver/totserver/ connection: # Name of the instance, multiples instance can be configured - name: {instance-name} # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:im:/Google/gcpIam/devQA/" # value used in anjana to separate the values in a multi value attribute value attributeSeparator: {anjana_attribute_separator} ############################################################################################################### ## GCP IAM connection properties ## project: the project name in GCP ## credentialsContent: the json to download from GCP with the credentials to connect with the GCP Server ## path-separator: character to be used by Anjana for the path ## sampleRows: number of sample rows ## groupPrefix: the prefix for the group name ############################################################################################################### technology: project: {project_name} credentialsContent: | { "type": "service_account", "project_id": {project_id}, "private_key_id": {private_key_id}, "private_key": "-----BEGIN PRIVATE KEY----------END PRIVATE KEY-----\n", "client_email": {client_email}, "client_id": {client_id}, "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": {client_x509_cert_url} } sample-rows: 15 path-separator: "/" groupPrefix: Dsa_ ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-GCP-IAM] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - GCP Storage Plugin YAML #################################################################################################### # Example YAML for Tot Plugin GCP Storage # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15003 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - http://totserver/totserver/ ############################################################################################################### ## Storage connection properties ## credentialsContent: the json to download from GCP with the credentials to connect with the GCP Server ## path-separator: character to be used by Anjana for the path ## sampleRows: number of sample rows ## bucket: the bucket to connect with ## obfuscation-string: the string to ## ## attributeSeparator: the separator of the attributes ############################################################################################################### connection: # Name of the connection - name: # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/Google/gcpStorage/devQA/" - ari: "anja:totplugin:sample:/Google/gcpStorage/devQA/" - ari: "anja:totplugin:edit:/Google/gcpStorage/devQA/" - ari: "anja:totplugin:im:/Google/gcpStorage/devQA/" imAri: "anja:totplugin:im:/Google/gcpIam/devQA/" technology: credentialsContent: | { "type": "service_account", "project_id": {project_id}, "private_key_id": {private_key_id}, "private_key": "-----BEGIN PRIVATE KEY----------END PRIVATE KEY-----\n", "client_email": {client_email}, "client_id": {client_id}, "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": {client_x509_cert_url} } sample-rows: 15 path-separator: "/" bucket: obfuscation-string: "*****" # The separator of the attributes, common for all connections attributeSeparator: "_-" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-GCP-STORAGE] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - Generic JDBC Plugin YAML #################################################################################################### # Example YAML for Tot Plugin JDBC # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15001 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ connection: - name: local # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:sample:/jdbc/postgresql/devQA/" - ari: "anja:totplugin:extract:/jdbc/postgresql/devQA/" - ari: "anja:totplugin:im:/jdbc/postgresql/devQA/" imAri: "anja:totplugin:im:/ldap/ldap/ldap/" ## Vendor connection properties technology: vendor: driver: url: user: password: ################################ ## JDBC connection properties ## Depends on the selected vendor ## Oracle ## vendor: ORACLE ## url: jdbc:oracle:thin:@:: || jdbc:oracle:thin:@:/ ## SQL Server ## vendor: MSSQLSERVER ## url: jdbc:sqlserver://: ## Postgresql ## vendor: POSTGRESQL ## url: jdbc:postgresql://:/database= ## Snowflake ## vendor: SNOWFLAKE ## url: jdbc:snowflake://.snowflakecomputing.com/?db=&warehouse=&JDBC_QUERY_RESULT_FORMAT=JSON ## Hive standalone ## vendor: HIVE ## url: jdbc:hive2://:/;principal=;ssl=true ## Hive on Cloudera ## vendor: HIVE ## url: jdbc:hive2://:/;principal=;ssl=true ## DB2 ## vendor: DB2 ## url: jdbc:db2://:/ ## MySQL ## vendor: MYSQL ## url: jdbc:mysql://:/ ## MariaDB ## vendor: MARIADB ## url: jdbc:mariadb://:/ ## H2 ## vendor: H2 ## url: jdbc:h2:[type:][] ## Teradata ## vendor: TERADATA ## url: jdbc:teradata://:/ ################################ ## Other Properties, under technology # number of sample rows sampleRows: 15 # character to be used by Anjana for the path path-separator: "/" # character to be used on queries query-separator: "." # lists all tables of all schemas in all databases it sees using-catalogs: false # lists all the tables of all the schemas it has access to using-schemas: true # string to replace information when it is obfuscated obfuscation-string: "*****" # List of schemas to be ignored in the structure recovery for extraction of metadata ignoredSchemas: - DBC - dbcmngr - SYSBAR # ignoredSchemas: DBC, dbcmngr, SYSBAR another way of configuring the list ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - Omma Data Plugin (Aqtiva) YAML #################################################################################################### # Example YAML for Tot Plugin OmmaData / Omma Data # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Logs properties ### ######################### logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-OMMADATA] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base for all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ######################### ### Server properties ### ######################### server: # the port where the service will be listening to port: 15020 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ # list of aris to define the different plugin functionalities aris: - ari: "anja:totplugin:extract:/jdbc/ommadata/devQA" ########################################### ### Own properties of the OmmaData plugin ### ########################################### ommadata: # If we want to avoid the validation of certificates in requests to OmmaData (always true in production or remove this property) enable-certs-validation: false # OmmaData API url url: http(s)://:/ auth: # OmmaData authentication properties url: http(s)://:/public/auth/login client-id: secret: # Synchronisation execution schedule with OmmaData. Cron format: scheduling: 0 */1 7-22 * * MON-FRI # Delta to be added to the last execution date. The result date will be used to request the data in OmmaData synchronization: delta: 5 unit: SECONDS # ChronoUnit format: MILLIS, SECONDS, MINUTES, HOURS, DAYS ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # the url where Hecate is listening. Plugins use Anjana's Hecate server so they need to use Tot as proxy defaultZone: https://tot1server.anjanadata.local/totserver/ --- version: "26.1" language: "en" --- # Example YAML - Oracle Plugin YAML #################################################################################################### # Example YAML for Tot Plugin Jdbc Oracle # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: port: 15013 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local:15000/tot/ ################################ ## Oracle connection properties ## url: where oracle service is running ## user: user to log in ## password: password ## path-separator: character to be used on path ## query-separator: character to be used on query ## sampleRows: number of rows in sample ## obfuscation-string: string to replace information when it is obfuscated ################################ connection: - name: dev # name of the instance connection # To define the different ARIs of plugin functionalities aris: - ari: "anja:totplugin:extract:/jdbc/oracle/devQA/" - ari: "anja:totplugin:sample:/jdbc/oracle/devQA/" - ari: "anja:totplugin:create:/jdbc/oracle/devQA/" - ari: "anja:totplugin:edit:/jdbc/oracle/devQA/" - ari: "anja:totplugin:im:/jdbc/oracle/devQA/" imAri: "anja:totplugin:im:/ldap/ldap/ldap/" technology: url: user: password: path-separator: "/" query-separator: "." sampleRows: 15 obfuscation-string: "*****" ############################# ### Query pattern ### ############################# ## createRole: create role query ## existRole: check if exist role ## grantSelect: grant select permission to role on table ## deleteRole: delete role query ## revokeSelect: revoke select permission to role on table ## identifiedGlobally: link role in oracle with ad group sql: query-pattern: createRole: "CREATE ROLE {0}" existRole: "SELECT * FROM dba_roles WHERE ROLE = {0}" grantSelect: "GRANT READ ON {0} TO {1}" deleteRole: "DROP ROLE {0}" revokeSelect: "REVOKE READ ON {0} FROM {1}" identifiedGlobally: " IDENTIFIED GLOBALLY AS {1}" # Example of the hierarchy established for group names in the external identity manager globalGroupName: cn={0},ou=groups,dc=anjanadata,dc=org # The same variable globalGroupName is used for IAM oracle cloud # globalGroupName: IAM_GROUP_NAME={0} # Group prefix of dsa, only use if not config imAri groupPrefix: Dsa_ ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC-ORACLE] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # Url where Tot is listening defaultZone: http://totserver:15000/tot/eureka --- version: "26.1" language: "en" --- # Example YAML - Redshift Plugin YAML #################################################################################################### # Example YAML for Tot Plugin Redshift # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15017 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ #################################### ### Redshift instance properties ## name: Name of the connection instance ## aris: list of aris to define the different instance functionalities ## technology: bellow this are the specific connection properties of the instance ## sampleRows: number of sample rows ## path-separator: character to be used by Anjana for the path ## query-separator: character to be used on queries ## using-catalogs: lists all tables of all schemas in all databases you see ## using-schemas: lists all the tables of all the schemas you have access to ## obfuscation-string: string to replace information when it is obfuscated ## sample: the query to obtain the sample data ## #################################### connection: - name: example-instance aris: - ari: "anja:totplugin:sample:/jdbc/redshift/devQA/" - ari: "anja:totplugin:extract:/jdbc/redshift/devQA/" - ari: "anja:totplugin:im:/jdbc/redshift/devQA/" imAri: "anja:totplugin:im:/ldap/ldap/ldap/" technology: driver: com.amazon.redshift.jdbc42.Driver url: jdbc:redshift://rdbservice:5432/anjana user: password: sampleRows: 15 path-separator: "/" query-separator: "." using-catalogs: false using-schemas: true obfuscation-string: "*****" #################################### ### SQL properties ## sql: Common SQL properties for all instances ## query-pattern: list of properties for the queries that can be configured ## sample: Pattern for the sample query #################################### sql: query-pattern: sample: "SELECT * FROM {0} LIMIT {1}" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC-REDSHIFT] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # the url where Tot is listening defaultZone: http://totserver/totserver/eureka --- version: "26.1" language: "en" --- # Example YAML - Snowflake Plugin YAML #################################################################################################### # Example YAML for Tot Plugin Jdbc Snowflake 5.0.0 # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: port: 15025 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local:15000/tot/ ################################ ## Snowflake connection properties ## url: where oracle service is running ## user: user to log in ## password: password ## path-separator: character to be used on path ## query-separator: character to be used on query ## sampleRows: number of rows in sample ## obfuscation-string: string to replace information when it is obfuscated ################################ connection: - name: dev # name of the instance connection technology: url: user: password: path-separator: "/" query-separator: "." sampleRows: 15 obfuscation-string: "*****" # To define the different ARIs of plugin functionalities aris: - ari: "anja:totplugin:extract:/jdbc/snowflake/devQA/" - ari: "anja:totplugin:sample:/jdbc/snowflake/devQA/" - ari: "anja:totplugin:create:/jdbc/snowflake/devQA/" - ari: "anja:totplugin:edit:/jdbc/snowflake/devQA/" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC-ORACLE] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################ ## Hecate(Eureka) properties ### ################################ eureka: client: serviceUrl: # Url where Tot is listening defaultZone: http://totserver:15000/tot/eureka --- version: "26.1" language: "en" --- # Example YAML - Snowflake Plugin (Native API) YAML #################################################################################################### # Example YAML for Tot Plugin Snowflake (native API) # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # the port where the service will be listening port: 15030 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # the tot server list of URLs, tot can have more than one instance running. urls: - {TOT_SERVER_URL} connection: - name: SF-1 # list of aris to define the different plugin functionalities # the infrastructure/technology/zone triplet must match the one selected in Anjana when importing aris: - ari: "anja:totplugin:extract:/{INFRASTRUCTURE}/snowflake/{ZONE}/" - ari: "anja:totplugin:sample:/{INFRASTRUCTURE}/snowflake/{ZONE}/" - ari: "anja:totplugin:edit:/{INFRASTRUCTURE}/snowflake/{ZONE}/" - ari: "anja:totplugin:im:/{INFRASTRUCTURE}/snowflake/{ZONE}/" # the ari of the Entra ID plugin that manages groups and users for the governance imAri: "anja:totplugin:im:/{ENTRA_ID_PATH}/" ## Connection properties ## host: the Snowflake account host, in the form {account}.snowflakecomputing.com ## warehouse: the warehouse used to run the statements sent through the Snowflake SQL API ## role: the role used to run the statements. It must be written in UPPERCASE: ## the Snowflake SQL API does not normalise it and the request fails otherwise ## timezone: time zone used by the Snowflake SQL API to format DATE/TIME/TIMESTAMP values. ## Examples: Europe/Madrid, UTC, America/Los_Angeles ## path-separator: character used to separate the parts of the path (database, schema, object) ## attribute-separator: separator used to build compound attribute names ## sample-rows: maximum number of rows returned by the sample operation ## obfuscation-string: value shown instead of the real one for sensitive fields (pi = true) ## imType: identity manager used for the governance technology: host: {ACCOUNT}.snowflakecomputing.com warehouse: {WAREHOUSE} role: {ROLE} timezone: {TIMEZONE} path-separator: / attribute-separator: "_-" sample-rows: 25 obfuscation-string: "*****" imType: "ENTRA ID" ## OAuth2 properties, used to authenticate against Snowflake through Entra ID ## token-url: Entra ID endpoint where the access token is requested ## client-id: application registered in Entra ID for the Snowflake OAuth integration ## client-secret: secret of that application ## grant-type: OAuth2 flow. client_credentials is the one used for server to server processes ## scope: scope requested to obtain a token valid for Snowflake. ## It must end with /.default, otherwise Entra ID rejects the request oauth: token-url: https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token client-id: {SNOWFLAKE_OAUTH_CLIENT_ID} client-secret: {SNOWFLAKE_OAUTH_CLIENT_SECRET} grant-type: client_credentials scope: api://{SNOWFLAKE_APP_ID}/.default ## Retry policy applied to the calls to the Snowflake SQL API ## max-attempts: number of retries when a retry policy is applied ## backoff-ms: milliseconds to wait between retries ## http-statuses: HTTP codes considered transient, the only ones that are retried ## status-check-max-attempts: number of attempts to check the status of an asynchronous statement retry: max-attempts: 1 backoff-ms: 1000 http-statuses: 408,429,500,502,503,504 status-check-max-attempts: 60 ## SCIM properties, used to provision the Entra ID groups into Snowflake as roles ## enabled: enables or disables the use of SCIM in the plugin. ## When disabled, the plugin creates the role directly in Snowflake ## tenant-id, client-id, client-secret: Entra ID application that allows calling Microsoft Graph. ## It needs the Synchronization.ReadWrite.All and Group.Read.All application permissions ## scope: scope requested to obtain a token valid for Microsoft Graph ## graph-base-url: base URL of the Microsoft Graph API ## snowflake-app-name: exact display name of the Snowflake Enterprise Application in Entra ID ## service-principal-id: Object ID of that Enterprise Application, not the one of the Graph app ## job-id: provisioning job of the Enterprise Application ## user-rule-id: synchronisation rule used to provision users on demand ## group-rule-id: synchronisation rule used to provision groups on demand ## role-sync-max-attempts: attempts to check in Snowflake that the role has been provisioned ## role-sync-backoff-ms: milliseconds to wait between those attempts scim: enabled: false tenant-id: {TENANT_ID} client-id: {GRAPH_CLIENT_ID} client-secret: {GRAPH_CLIENT_SECRET} scope: https://graph.microsoft.com/.default graph-base-url: https://graph.microsoft.com/v1.0 snowflake-app-name: {ENTERPRISE_APP_NAME} service-principal-id: {ENTERPRISE_APP_SERVICE_PRINCIPAL_ID} job-id: {PROVISIONING_JOB_ID} user-rule-id: {USER_PROVISION_ON_DEMAND_RULE_ID} group-rule-id: {GROUP_PROVISION_ON_DEMAND_RULE_ID} role-sync-max-attempts: 60 role-sync-backoff-ms: 5000 ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [SNOWFLAKE] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # the url where Tot is listening defaultZone: {TOT_SERVER_URL}/eureka --- version: "26.1" language: "en" --- # Example YAML - SQL Server Plugin YAML #################################################################################################### # Example YAML for Tot Plugin JDBC SQLServer # # # # This file has all the technical properties that can be edited for the client. # # These properties have a default value in the application, # # so there is no necessity to configure them. # # Only configure these properties if they are going to be different to the value of this file, # # this will make your files more clean and readable. # #################################################################################################### ######################### ### Server properties ### ######################### server: # Port where service will be listening port: 15005 ############################# ### Tot Plugin properties ### ############################# totplugin: server: # Tot server URL. It is a list because Tot can have more than one instance running. urls: - https://tot1server.anjanadata.local/totserver/ ################################ ## url: connection url ## imType: EID / AD / NONE ## ## EID: for EntraID (former AzureAD) ## ## AD: for Windows AD ## ## NONE: leave empty the property for pure SQLServer (default value) ## imDomain: the domain of the IM to work with, it has no default value and it is only required if imType is not empty ## user: the user ## password: the password ## serverName: the server name ## databaseName: the database name ## principalId: the principal id ## principalSecret: the principal secret ## path-separator: separator on path attribute of the objects ## sampleRows: number of rows retrieved on sample data functionality ################################ connection: - name: sqlserver-local technology: imType: imDomain: url: user: password: serverName: databaseName: principalId: principalSecret: path-separator: sampleRows: 15 # Role suffix to add on the role creation rolePrefix: "_role" # Properties to retry and wait if AzureAD is connected to SQLServer azureCountRetry: 5 azureWaitRetry: 15 # To define the different ARIs of plugin functionalities aris: - ari: "anja:totplugin:extract:/jdbc/sqlserver/devQA/" - ari: "anja:totplugin:sample:/jdbc/sqlserver/devQA/" - ari: "anja:totplugin:create:/jdbc/sqlserver/devQA/" - ari: "anja:totplugin:edit:/jdbc/sqlserver/devQA/" - ari: "anja:totplugin:im:/jdbc/sqlserver/devQA/" imAri: "anja:totplugin:im:/Azure Analytics/azureAD/devQA/" # Prefix group to concat the group name groupPrefix: Dsa_ # SQL queries for every action sql: query-pattern: createRole: "CREATE ROLE {0}" existRole: "SELECT DATABASE_PRINCIPAL_ID({0})" grantSelect: "GRANT SELECT ON {0} TO {1}" deleteRole: "DROP ROLE {0}" revokeSelect: "REVOKE SELECT ON {0} FROM {1}" # If we want to connect to an external AD different from AzureAD the createFromExternalProvider must be: CREATE USER [DOMAIN\{0}] FROM EXTERNAL PROVIDER WITH DEFAULT_SCHEMA = [{1}] createFromExternalProvider: "CREATE USER [{0}] FROM EXTERNAL PROVIDER WITH DEFAULT_SCHEMA = [{1}]" deleteUser: "DROP USER IF EXISTS [{0}]" addMemberRole: "ALTER ROLE [{0}] ADD MEMBER {1}" dropMemberRole: "ALTER ROLE [{0}] DROP MEMBER {1}" ######################## ## Logs properties ### ######################## logging: pattern: # Pattern to convert logs in the convenient format for the client console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [TOT-PLUGIN-JDBC-SQLSERVER] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}" # Mark the level of log to show for every package. ERROR > WARN > INFO > DEBUG > TRACE level: # The main log level this is the base fot all logs root: info # Every package of code can be marked with a different log level, every package of code printed on log is selectable to have a record here and mark a log level com.anjana: DEBUG ################################# ### Hecate(Eureka) properties ### ################################# eureka: client: serviceUrl: # Url where Tot is listening defaultZone: http://totserver/totserver/eureka [Next Page](https://wiki.anjanadata.com/llms-full.txt/1)