Just as Anjana makes it possible to create as many entities as needed, it is also possible to configure as many relationships as apply.
The relationship must contain a source and a target in order to recognize the two entities involved in it, but the rest of the metadata is fully configurable.
This page covers, on the one hand, the attributes that make up the relationship's primary key (PK) —and that form its ARI, the identifier used to uniquely represent each object in Anjana— and, on the other hand, the tabs that show 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 relationship, these attributes —with their internal naming in parentheses when applicable— are:
-
name
-
source (source entity of the relationship)
-
target (target entity of the relationship)
The ARI also includes the relationship's subtype and, unlike other objects, the organizational unit (organizationalUnit) of the relationship's source entity and its target entity. For example, for a relationship with ID 53:
ANJA:OBJECT:RELATION:ASSOCIATED_TERMS:53:Concepto de Cliente:Europe/SPA/Finance:Europe/SPA/Finance
where the structure is:
ANJA:OBJECT:RELATION:<relationship subtype name>:<idRelacion>:<relationship name>:<organizational unit of the source entity>:<organizational unit of the target entity>
NOTES:
-
The name attribute 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 those attributes in the templates with the "not editable" validations. Any manual intervention to modify these values will break the object's referential integrity.
-
The source and target fields are only editable through the administrative API. If the object needs to have a different PK, the object must be cloned with different values in its PK; the original will continue to exist.
-
The organizationalUnit values (for the source and target entities) that appear in the ARI do not necessarily match what 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 relationship 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 "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 and do not, they should contact the Anjana Data Platform administrator.
Attributes
When a user accesses the detail view of a relationship, the screen shown is the Attributes screen, 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 relationship.
Lineage
On this screen, the user can view the lineage of the non-native relationship; unlike lineage for entities, for relationships it starts with the source and the target, and those entities are the ones that get expanded.
The objects shown in this graph depend on the chosen lineage layer and their relationship to the relationship (whether they are the source, the target, and the type of relationship). It is possible to filter which entity types, relationships and statuses should be shown.
More detail about the graph is included in the Lineage section.
Stakeholders
Within the Stakeholders screen, the user can view all the interested parties of the relationship.
Users appear typed as:
-
Primary: user who created the relationship
-
Secondary: user assigned in some template attribute (in case the object has an attribute of type Named User)
Stakeholders can also be filtered by stakeholder type, role, or name.
Audit
Within the Audit screen, the user can access Anjana's internal audit trail, where the evolution of the relationship can be seen throughout its entire life in the tool: its creation, the validations of its workflows, the modifications it has undergone…
It is possible to filter based on whether it is a search action or not, what, who, and when an action was performed on that process.
The origin makes it possible to distinguish between the different sources that generate audit records: "anjana" for internal audit, and the system name for external audit.
