This page describes the DSA (Data Sharing Agreement) object of Anjana Data Platform. It covers, on one hand, the attributes that make up its primary key (PK) —which form its ARI, the identifier that uniquely represents 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 DSA, the attribute that makes up the PK —with its internal naming in parentheses— is:
-
name
The ARI also includes the object's organizational unit (organizationalUnit). For example, for a DSA with ID 83:
ANJA:OBJECT:ENTITY:DSA:83:Facturación:Europe/SPA/Finance
where the structure is:
ANJA:OBJECT:ENTITY:DSA:<idDSA>:<name>:<organizational unit>
NOTES:
-
The name attribute must not contain the ':' character, since it is the separator of 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 "not editable" validations. Any manual intervention to modify these values will break the object's referential integrity.
-
The value of organizationalUnit that appears in the ARI does not necessarily match the one the user sees in the template. If multi-language 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 DSA is organized into several tabs, each containing a type of information about the object. When accessing the detail view, the screen displayed by default is Attributes.
The availability of the "Relationships", "Lineage", "Stakeholders", "Audit" and "Versions" 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 DSA, the screen displayed is Attributes, where the user can access the various 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 DSA.
The DSA template must contain an attribute in which to include the terms of the DSA contract. This contract will determine the use that users adhering to the DSA will make of the datasets' data. This attribute can be defined in any menu and section of the DSA template and can be of either File type or URL type. Internally in Anjana this attribute is 'termCondFile'.
Another attribute that the DSA must contain is the list of entities that DSA will encompass. This attribute can be defined in any menu and section of the DSA template and must be of type ENTITY_CONTAINER. The name of this attribute is 'dsa_content'.
NOTES:
-
Since the DSA corresponds to a group in the identity manager, there are restrictions on their names:
-
GCP IAM does not allow groups whose names contain = < > &
-
Azure does not allow "/ \\\\\\\\ [ ] : | < > + = ; ? * , and must not end with a .
-
AWS IAM only allows names made up of letters, numbers and the following characters: + = , . @ _ and -
-
For the LDAP protocol, it is recommended that names contain letters, digits and -. It is also advisable to review the protocol implementation used, due to specific limitations
-
Relationships
On the relationships screen, the user can view the existing relationships between the DSA and other entities in the Anjana repository.
Relationships can be:
-
Direct: Relationships in which the DSA is the source or target
Relationships can also be filtered by the name and subtype of the related entity, the type of relationship (source or target), and the name and subtype of the relationship.
Lineage
On this screen, the user can view the DSA's lineage, and can expand the DSA to see, for example, the organizational unit it belongs to, the users who have access to its data through adherences, the data structures it grants access to…
The objects shown in this graph depend on the chosen lineage layer and its relationship with the DSA (whether it is a source, a target, and the type of relationship). It is possible to filter which entity types, relationships and statuses are to be displayed.
More detail about the graph is included in the Lineage section of this Guide.
Stakeholders
Within the Stakeholders screen, the user can view the users who are interested parties in the DSA, including all users adhering to the DSA.
Users appear typed as:
-
Adherents: user who has adherence to the DSA
-
Primary: user who created or owns the DSA
-
Secondary: user assigned in some attribute of the template (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 view Anjana's internal audit trail, where the evolution of the DSA can be seen throughout its entire life in the tool: creation, workflow validations, modifications made, adherence requests…
It is possible to filter according to whether it is a search action or not, and what, who and when an action was performed on that DSA.
The origin allows distinguishing between the different sources that generate audit records: "anjana" in the case of internal audit, and the name of the system in the case of external audit.
Versions
List of DSA versions from which the details of all of them can be accessed.
In this window, the user can:
-
Navigate to each of the DSA versions
-
Download the snapshot of each DSA version
-
If there is a version pending approval, navigate to its validation workflow