In Anjana Data it is possible to generate entities that represent concepts specific to the Business Glossary (term, report, indicator, policy…) or assets related to the Data Catalog (schemas, databases…) that fit the organization's needs and scope.
These entities have their own metadata and, therefore, their structure must be configured.
This page includes, on one hand, the attributes that make up the entity's primary key (PK) — and which form its ARI, the identifier used to uniquely represent each object in Anjana — and, on the other hand, the tabs that display the object's information in its detail view.
Primary key (PK) and ARI
Each object in Anjana Data Platform is uniquely identified by its ARI (Anjana Resource Identifier), which is built from the attributes that make up its primary key (PK). In the case of the non-native entity, the attribute that forms the PK — with its internal naming in parentheses — is:
-
name (
name)
The ARI also includes the entity's subtype and the object's organizational unit (organizationalUnit). For example, for a term with ID 61:
ANJA:OBJECT:ENTITY:TERM:61:Client:Europe/SPA/Finance
where the structure is:
ANJA:OBJECT:ENTITY:<entity subtype name>:<entityId>:<name>:<organizational unit>
NOTES:
-
The name attribute (
name) must not contain the ':' character, since it is the separator for the ARI components and would interfere with the application's internal logic. -
To ensure that the fields making up the ARI are not editable, it is the administrator's responsibility to configure these attributes in the templates with "non-editable" validations. Any manual intervention to modify these values will break the object's referential integrity.
-
The organizationalUnit value that appears in the ARI does not necessarily match the one the user sees in the template. If multi-language support has been configured, the translation key is the one that forms part of the ARI, while the user sees in the template the translated value of that key for the language selected in their profile.
Detail tabs
The detail view of a non-native entity is organized into several tabs, each containing a type of information about the object. When accessing the detail view, the screen shown by default is Attributes.
The availability of the "Relationships", "Lineage", "Stakeholders" and "Audit" tabs depends on the permissions assigned to the user's role. When access to a tab is disabled, it is displayed in gray and the user cannot navigate to it. If a user believes they should have access but do not, they should contact the Anjana Data Platform administrator.
Attributes
When a user accesses an entity's detail view, the screen shown is Attributes, where the user can access the different functional, technical, operational, etc. attributes defined in the template, within the corresponding menus and sections, as well as the specific attributes that are not part of the template but have been included in that particular entity.
Relationships
On the relationships screen, the user can view the existing relationships between the entity and other entities in the Anjana repository.
Relationships can be:
-
Direct: Relationships in which the entity is the source or target
-
Composition: Native relationships created by being part of another object. This is possible if the entity is contained in a DSA
Relationships can also be filtered by the name and subtype of the related entity, the relationship type (source or target), and the name and subtype of the relationship.
Lineage
On this screen, the user can view the lineage of the non-native entity, and can expand the entity to see, for example, the organizational unit it belongs to, the objects it is related to, etc.
The objects shown in this graph depend on the chosen lineage layer and their relationship to the entity (whether it is a source or target, and the type of relationship). It is possible to filter which entity types, relationships and statuses to display.
More detail on the graph is included in the Lineage section.
Stakeholders
On the Stakeholders screen, the user can view all the interested parties of the entity.
Users are typed as:
-
Adherents: user who has adherence to a DSA that contains the entity
-
Primary: user who created or owns the entity
-
Secondary: user assigned in some attribute of the template (in case the object has an attribute of the Named User type)
Stakeholders can also be filtered by stakeholder type, role or name.
Audit
On the Audit screen, the user can access Anjana's internal audit trail, where the entity's evolution can be seen throughout its entire life in the tool: its creation, its workflow validations, the modifications it has undergone…
It is possible to filter based on whether it is a search action or not, and what, who and when an action was performed on that process.
The origin allows distinguishing between the different sources that generate audit records: "anjana" in the case of internal audit, and the system name in the case of external audit.
Access information
The Access information tab is available only to users who have physical access to the entity, obtained through an adherence to a Data Sharing Agreement (DSA) that contains it. In this tab, these users will find the information that has been filled in through the Edit access information action:
-
Access data, the URL (for example, the link to a Power BI report) or the connection string (for example, a JDBC string to access an Oracle database) needed to access the information.
-
Access information, the informational text — in the user's language, among those configured — that describes, for example, the steps to follow to access the entity's information.
If the user is not adhered to a DSA that contains the entity, this tab will not be available.
