Functional Configuration

Introduction

This document is the Anjana Data Functional Configuration Guide, whose purpose is to serve as a reference for adapting the platform to the requirements of each organization. Throughout this guide, the steps and considerations necessary to configure the various components that make up the data governance model in Anjana Data are described in detail.

Specifically, the following configuration aspects are covered:

• Governance operating model: definition of roles, permissions, data domains, workflows, workflow launch rules, and notifications that ensure the coordinated operation of data governance.

• Metamodel: configuration of the entity-relationship model that enables governance of the different types of data assets and information managed by the organization.

• Metadata templates: creation and adjustment of menus, sections, and attributes of different typologies, including validations and versioning rules to ensure quality and impact control.

• Lineage: configuration of the lineage layers, specifying which entities and relationships of the metamodel belong to each layer and which relationships should be represented as aggregation relationships.

• Filters: configuration of filters on the Object Browser screen and on the Audit screen of the Data Portal, in order to optimize navigation and information querying.

This guide is aimed at profiles responsible for the functional administration of the platform. The functional administrator does not necessarily define the configuration model, but is responsible for configuring it and keeping it up to date within the Configuration Panel.

Basic concepts for Anjana Data configuration

Before starting the functional configuration of the platform, it is important that the profiles responsible for administration understand a series of fundamental concepts. These terms are the foundation for correctly interpreting the sections of this guide.

For a detailed description of each of them, it is recommended to consult the Anjana Data Glossary of Terms.

Main concepts

• Data domain / functional domain / business domain / organizational unit: structures that allow organizing and segmenting data assets within the organization, and that serve as the basis for applying the authorization mechanisms that determine which users exercise governance roles over those assets.

• Governance roles: functions and responsibilities assigned to the different profiles in the data governance model.

• Permissions: specific authorizations that determine what actions a user can perform on the various objects of the platform.

• Workflows: configurable work flows that support the validation processes of governance actions, from creation to authorization of access to data assets.

• Notifications: automatic alerts that inform users about changes, requests, or pending actions on the platform.

• Users: people with access to the platform. Each user can have one or more governance roles assigned, and their permissions are additive, meaning they have the sum of all permissions associated with their roles.

• Metamodel: conceptual structure that defines which entities and relationships are governed in the platform.

• Entity: element of the metamodel that represents a data or information asset (e.g. dataset, report, AI model, data processing...).

• Relationship: link between two entities that reflects dependencies, hierarchies, or associations.

• Object type: In Anjana Data, the object type refers to the basic classification of governed elements within the metamodel. Since the metamodel is composed of entities and relationships, the object type allows distinguishing whether it is an entity (e.g. dataset, report, AI model) or a relationship (e.g. related business term, report metrics...).

• Object subtype: Specifies the specific category of an object within the metamodel: for example, a dataset or a term in the case of entities, or a dependency or aggregation in the case of relationships.

• Lineage: capability to trace the journey and transformation of data throughout its lifecycle.

• Lineage layer: level within the lineage that groups entities and relationships according to their function (e.g. technical layer, consumption layer, semantic layer...).

• Aggregation relationship: metamodel relationship that shows grouping dependencies between entities in a specific lineage layer.

• Audit: module that records and allows querying all actions performed on the platform or on external platforms.

• Data Portal: business interface oriented toward querying, requesting access to data, and collaborating on data assets.

• Filters: configurable criteria that facilitate the search and selection of objects on screens such as the Object Browser or the Audit.

• Translation keys: Allow configuring the application in multiple languages, so that each user views roles, domains, templates, attributes, and notifications in the language they have selected.

Configuration mechanisms

There are two ways to configure Anjana Data:

1. From the Configuration Panel (recommended option) (Administrator view)

The Configuration Panel allows entering all the necessary parameters to perform functional configuration and a large part of the technical configuration.

• It is the recommended option because it implements validation rules and automatically applies a large part of the configuration logic, reducing the risk of error.

• To operate in the Configuration Panel, the user must have the appropriate roles and permissions on the application's data model:

  • ADMIN_ANJANA: permission to access the Configuration Panel and the tables that contain the functional configuration parameters.

  • CREDENTIAL_ADMIN_ANJANA: permission to access the authentication and authorization tables (this permission does not grant access to the Configuration Panel).

  • API_ADMIN_ALL: permission to access special actions (e.g. clear caches, load lineage, update sequences).

Note: The Configuration Portal is sometimes referred to internally as Portuno, as this is the name of the microservice associated with the platform's configuration capabilities.

2. Via direct access to the database (Developer view)

This mechanism means that all configuration parameters are set through SQL queries executed against the internal data model of Anjana Data. To perform the configuration, the user must have access to the database through a database manager (for example: Dbeaver).

This configuration option is discouraged because:

• All the weight of the configuration logic falls on the developer who executes SQL queries directly on the platform's internal tables.

• It increases the risk of inconsistencies, as it lacks the validations provided by the Configuration Panel.

• It requires running a sequence update script on the database tables after each configuration operation. (This same procedure can be performed from the Configuration Panel under Actions > Reset DQ sequences).

Configuration via the Configuration Panel (recommended option) (Administrator view)

Within the configuration panel, the administrator has access to the following resources and actions:

• Schemas: access to the content of Anjana Data's functional configuration tables

• BPM: access to the workflow editor (more information in the Workflows Configuration Guide)

• Actions: The dropdown enables the execution of the following actions:

  • Validate fields ( Actions > Validate fields ): action that allows checking whether the attributes that form part of the PK of objects have the required and non-editable attribute validations configured, and that the values configured for taxonomy-type attributes generate correct trees (without cycles, for example). Before running this validation, it is necessary to clear the cache.

  • Upload translations files( Actions > Upload translation files ): action that updates the application's translation files for multi-language configuration. The files are located in Minio or S3, with all the content of the translations table (Translations). Users will not have the changes available in the Data Portal until the next time caches are cleared ( Actions > Clear cache ) and the screen is reloaded.

  • Insert default translations( Actions > Insert default translations ): action that inserts the missing default translations of Anjana Data. Action exclusive to Spanish (es-ES) and English (en-US) languages. This action does not overwrite existing translations that may have been modified by the administrator.

  • Clear Cache ( Actions > Clear cache ): action that allows clearing the application's caches, recommended after any configuration change, authentication, identity providers for authentication, translations, or iconography and CSS.

  • Load lineage ( Actions > Load lineage ): action that regenerates the total lineage of entities and relationships so that it can be visualized later in the Anjana Portal. This action is recommended when lineage access errors occur as a result of errors or manual operations.

  • Force indexing ( Actions > Force indexing ): action that forces a complete indexing of all entities and relationships. This action is recommended when a desynchronization or inconsistency is detected between the data contained in the database (DB) and Solr, or when the weighting in the searches of the object browser of the Data portal is modified.

  • Reset DB sequences ( Actions > Reset DB sequences ): action that updates the database sequences, adjusting to the highest existing value for each table associated with the sequences. This action is recommended when the content of the Anjana Data data model is modified.

  • Clear data ( Actions > Clear cache ): Action that deletes the data stored in Anjana Data's persistence layers, including objects and their associated attributes.. ⚠️ Recommended use: clear test data generated during functional configuration, before beginning the real governance of use cases.

  • Clear data & config( Actions > Clear data & config ):Action that deletes all information and configuration from the platform in Anjana Data's database persistence layers. It is equivalent to running Clear data, but also deletes the configuration (templates, organizational units, domains, etc.)⚠️ Recommended use: only to restore an environment to factory state

Structure of the Configuration Panel

From the Schema option, you access the complete catalog of Anjana Data tables, where all the configuration parameters of the platform are stored.

Accessing the functional parameterization tables

The user can click directly on each table to view or modify its content. For each table, filters are available along with the ability to sort columns.

Applying filters to the functional parameterization tables

Filters allow searching for records according to different criteria:

• Values equal to, starting with, ending with, or containing the entered text.

• Selection from a list of possible options.

• Filtering by empty (null) or non-empty values.

To undo a filter, simply enter the character - in one of the filter fields (operator or value) and apply it again.

Applying record sorting to the functional parameterization tables

To sort, simply click on the column name until the desired sort order is obtained (ascending or descending). It is possible to sort by multiple columns at once by holding the Ctrl key while clicking on the additional column names.