API Basic Interactions

API: Basic Interactions

Version control

Introduction

Concepts

The creation of metadata in Anjana follows a specific lifecycle through 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), transitioning to PENDING while the validation workflow is in process until final approval, or rejection.

Swagger

This document presents various operations that can be performed to follow the lifecycle proposed by Anjana, which are presented in an API. For more technical information or details needed to make the call, consult the endpoint in Swagger (Access URL: <http|https>://<host>/swagger/swagger-ui.html )

Each endpoint or group of endpoints specifies which module they belong to, which is the module to visit in Swagger to see the details.

Additionally, instructions and examples are included for the mechanism to use in order to introduce metadata into Anjana that will not follow the standard lifecycle, as well as how to obtain filtered lists of existing metadata.

Tools

As these are simple APIs, any tool capable of making a REST request is valid.

In this document, in cases that include screenshots or where specific actions are described for REST calls, the Postman tool is used.

Multi-language

For requests that handle multilingual text or translations (retrieving object metadata, SolR search, etc.) it is possible to specify the language in which the information should be returned (the clearest case is obtaining an object's metadata with its values and translations in a particular language).

To do this, it is necessary to include the “x-language” header, entering a value that matches one of the i18n codes configured in the application. As shown in the following example:

Note that the header is entirely optional, and if not provided, results will be returned in the language of the user making the request or, if not available, in the default language of the application.

SSL

Anjana has its API secured, like all its interface, under certificates signed by recognized entities. An example is provided with the Linux cUrl command:

curl --cacert my-ca.crt https://{url_request}



Only for testing and development purposes can SSL verification be disabled in cUrl using the -k option.

Glossary

All URLs will include variables that must be updated when executing the call. Below is an explanation of what should be specified for each.

• host: the IP or alias where Anjana is deployed (e.g.: google.com)

• provider: the identity management provider to use, with the name configured in the zeus yml (e.g.: azure)

• objectType: the type of object involved in the request (e.g.: ENTITY)

• objectSubType: the subtype of 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 file management as metadata (UPLOAD_FILE and ARRAY_UPLOAD_FILE), Anjana uses Minio or S3 to store files.

Installation and usage

Installation of a MinIO client is required to interact directly with the internal S3 without going through the Anjana portal.

To use the MinIO client, it must be installed as follows:

then grant execution permissions

and establish the connection to the server

and finally copy the file to the appropriate bucket

Login

Token retrieval

Before performing any operation on the APIs, an access token must be obtained. This token is retrieved upon login.

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:

Both “u” and “p” must be encoded in base64.

LDAP

It consists of a call POST a https://{{host}}/gateway/public/v4/auth/login/ldap

This endpoint connects to the corresponding LDAP using the provided credentials and returns the token needed for the remaining calls, along with user information and their permissions (which vary depending on the license status).

Database

It consists of a call POST a https://{{host}}/gateway/public/v4/auth/login/local

This endpoint connects to the Zeus database using the provided credentials and returns the token needed for the remaining calls, along with user information and their permissions (which vary depending on the license status).

Other providers

It consists of a call POST a https://{{host}}/gateway/public/v4/auth/login/oidc/password/{provider}

This endpoint connects to the specified provider in Zeus using the provided credentials and returns the token needed for the remaining calls, along with user information and their permissions (which vary depending on the license status)

Additionally, this login is currently only possible with AWS and also with Azure for users without multi-factor authentication.

Google does not allow this login option.

Sending the token

The token obtained from any of the previously defined endpoints must be included in every request in the header.

Example from POSTMAN:

Example from code:

Administrative API

Introduction

To insert, update or delete metadata in Anjana via the administrative route, a token from a user with a role containing the API administration permission (API_ADMIN) is required.

Metadata Insertion/Update

These endpoints allow the creation or modification of object metadata in Anjana.

All are found in the Kerno module.

All the bodies needed for object creation/editing can be obtained by calling the endpoint

GET https://{{host}}/gateway/api/admin/kerno/body-create-update/{objectSubType}/{idObject}

This call returns the body of the object corresponding to idObject, which can be used for modifications. To obtain the body needed to create a new object, idObject should not be sent.

For more information about what values to include according to the field type of the metadata, consult the User Guide for examples.

Information about the composition of ARIs for fields that use ARIs (those related to files or entities) can be found in the ARIs document.

Creation of an entity

This endpoint allows creating an entity and completing its creation in the desired state, i.e., an entity with APPROVED status can be created directly without a workflow.

Entity creation consists of the following call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/{objectSubType}

It applies controls similar to creation from the portal; duplicate objects cannot be created and incorrect values cannot be included in fields.

In this way, both native and non-native entities can be created.

If you want to create an entity of type DATASET, SOLUTION, INSTANCE or DSA, it is recommended to use the specific APIs for these types.

If you want to use it for the creation of a complete native entity (DATASET, DATASET FIELD, DSA, PROCESS, INSTANCE, SOLUTION), in the section Creation of native entities the information is expanded.

The body to fill in is similar for all subtypes. Below is an example of the body needed to create a DSA:

Within the ‘entityAttributes’ property, all subtype attributes are found. The idObject for creation must always be null, and the other properties depend on the subtype to be created:

• Dataset → Has the ‘entityFormDatasetFields’ property containing information to create the dataset fields (if creating a dataset without fields, it does not need to be filled in; it should be sent empty).

• Dsa → Has the ‘dsaDatasetDTO’ property, where the IDs of the datasets to include in the DSA must be specified.

• Instance → Has the ‘wizardDTO’ property where the ARI of the process and solution and the name to be given to the instance must be specified, along with ‘datasetInput’ and ‘datasetOutput’ where the IDs of the datasets to add can be included; these two properties are optional.

• Process and non-native entities → Their structure is the simplest; filling in the organizational unit, state and attributes is sufficient.

• Solution → Has the ‘instances’ attribute where the related instances to add to the solution can be included; it is optional.

Creation of a non-native relationship

This endpoint allows you to create a relationship and complete its creation in the desired state, i.e., something can be created from scratch to APPROVED directly without a workflow.

Relationship creation consists of the following call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/relationships/{objectSubType}

It applies controls similar to creation from the portal; duplicate objects cannot be created and incorrect values cannot be included in fields.

Below is an example of the creation of a relationship of subtype CONTROL_DQ

Within the ‘relationshipAttributes’ property, all relationship attributes are found, and idObject must always be null for the creation of a new relationship.

For relationships, the ‘source’ and ‘destination’ attributes are mandatory

Update of an entity

This endpoint allows you to edit an entity and complete its editing in the desired state, i.e., it can be edited from APPROVED to DRAFT.

It consists of the following call:

POST https://{{host}}}/gateway/api/admin/kerno/create-update/entity/{objectSubType}/{idObject}.

The endpoint for updating an entity is the same as for creation, but this time idObject must be filled in the URL and in the body that is sent.

It applies controls similar to creation from the portal; duplicate objects cannot be created and incorrect values cannot be included in fields. The only case not allowed is editing a PENDING entity that already has a workflow in progress; the workflow must be completed before it can be edited.

Non-editable fields can be edited by sending the input parameter: disableNonEditValidations. It is disabled by default.

If you want to update an entity of type DATASET, PROCESS, SOLUTION, INSTANCE or DSA, in the section Editing of native entities the information is expanded.

If used for the update of a complete native entity (DATASET, DATASET FIELD, DSA, PROCESS, INSTANCE, SOLUTION), it may be necessary to create the internal relationships or use exclusively the internal relationships if the only objects to be edited are the internally related ones.

NOTE: The language of the attributes to be edited must be included if they are international. If the attribute is boolean, user, list of values… it is not included and the value defined in attribute_definition_value must be specified.

Update of a relationship

This endpoint allows you to edit a relationship and complete its editing in the desired state, i.e., it can be edited from APPROVED to DRAFT.

Relationship editing consists of the following call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/relationships/{objectSubType}/{idObject}

The endpoint for updating a relationship is the same as for creation, but this time idObject must be filled in the URL and in the body that is sent.

It applies controls similar to creation from the portal; duplicate objects cannot be created and incorrect values cannot be included in fields. The only case not allowed is editing a PENDING entity that already has a workflow in progress; the workflow must be completed before it can be edited.

Non-editable fields can be edited by sending the input parameter in the body: disableNonEditValidations. It is disabled by default.

NOTE: The language of the attributes to be edited must be included if they are international. If the attribute is boolean, user, list of values… it is not included and the value defined in attribute_definition_value must be specified.

Entity deletion

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 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 possible existing combinations if the deletion is a DATASET or DSA

• Deletion of cart information related to the entity to be deleted

• Deletion of the entity itself (with its attributes)

• Deletion of the indexed information of the entity (including snapshots)

• Deletion of the indexed information of 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 the ends of the relationship to inform them that the relationships must first be deleted before their related objects can be deleted.

Deletion of 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 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 indexed information of the relationship (including snapshots)

Get metadata of an entity

This endpoint allows obtaining the data of a defined metadata of an entity. The data will be returned in the same way as received in the portal, i.e., with the menu and section structure (including fictitious menus and sections for custom fields).

It consists of the call:

GET https://{{host}}/gateway/api/admin/kerno/entity/{objectSubType}/{idObject}

Change Organizational Unit of an entity

Allows changing the organizational unit of an entity without going through the workflow validation that is normally applied.

It consists of the call

POST https://{{host}}/gateway/api/admin/kerno/change-organizational-unit/{{idObject}}

The request body that must be sent in the call is:

The validations applied are the same as from the portal; the OU of a non-existent entity or of those that do not have an OU by themselves, such as INSTANCE, cannot be changed.

Change the state of an entity

Allows changing the state of an entity to any state, without applying the logic that such state usually has (e.g.: changing it to expired would only change the entity, not its relationships, 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 state of a DATASET is changed, its DATASET FIELDs will be updated with the same state.

IMPORTANTE: State changes to APPROVED using this endpoint do not involve Tot in any way, so moving any governed object from DRAFT to APPROVED via this route would not involve any external system.

Change the state of a relationship

Allows changing the state of a relationship to any permitted state, without applying the logic of a full relationship update. State changes of a native relationship will not be permitted.

It consists of the call:

PUT https://{{host}}/gateway/api/admin/kerno/relationship/change-state/{idObject}/{state}

donde idObject is the id of the relationship to modify and state the state to which you want to change it.

IMPORTANTE: State changes to APPROVED from this endpoint do not involve Tot in any way, so moving any governed object from DRAFT to APPROVED via this route would not involve any external system.

Rename 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 that already exists for another (or the same) entity is entered, the user will receive an exception in the request response.

The renaming will affect all persistence of the object name and the object ARI.

• Database

  • entity or relationship

  • audit

  • notifications

  • workflows

• Indexing

Call structure:

PUT https://{{host}}/gateway/api/admin/kerno/rename/{objectType}/{idObject}

Request body:

Parameters:

• objectType: type of object. Allowed values: ENTITY or RELATIONSHIP.

• idObject: internal identifier of the object.

• name: nombre que se le quiere aplicar a la entity or relationship.

Observations to keep in mind:

• The name cannot exceed 255 characters.

• Renaming objects that have a workflow in progress is not allowed.

• For modifying the name of an approved DSA containing governed entities, it is advisable to review the documentation of the corresponding plugin.

• Overwriting the name of objects in PENDING state or objects that have another version is not allowed.

Get attributes that depend on other attributes

Indicates, for the value of a given attribute, which attribute values depend on the indicated one. It can be applied to all subtypes or the relationship that applies to a single one.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/relationship

Request body:

Description of the variables, all 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

Creation of native entities

This section presents the endpoints prepared to create native entities (DATASET, DSA, INSTANCE, SOLUTION and PROCESS) with everything they entail (internal relationships, additional entities in the case of dataset, etc.).

Dataset and dataset-fields

Allows creating a dataset and its associated dataset-fields, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/dataset

The request body to send is obtained as indicated in the section Metadata Insertion/Update

This will create the DATASET entity and as many DATASET_FIELDs as are included in the request, with the internal relationships between the dataset and its dataset fields.

As with the portal, the submitted data will be validated, and the dataset will only be created if all validations pass; otherwise, the errors will be reported.

Under no circumstances will modification of PKs or primary keys be permitted.

If the dataset is governed and its state is APPROVED, tot will be invoked.

Dsa

Allows creating a DSA and associating the desired entities, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/dsa

The request body to send is obtained as indicated in the section Metadata Insertion/Update.

This will create the DSA entity and the internal relationships between the DSA and its associated entities.

As with the portal, the submitted data will be validated, and the DSA will only be created if all validations pass; otherwise, the errors will be reported.

When the chosen state is APPROVED, Tot will be invoked.

Solution

Allows creating a solution and associating the desired related instances, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/solution

The request body to send is obtained as indicated in the section Metadata Insertion/Update.

This will create the SOLUTION entity and the internal relationships between the solution and its associated instances.

As with the portal, the submitted data will be validated, and the solution will only be created if all validations pass; otherwise, the errors will be reported.

Instancia

Allows creating an instance with its associated input/output datasets, completing in the state included in the request.

It consists of the call

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/instance

The request body to send is obtained as indicated in the section Metadata Insertion/Update.

This will create the INSTANCE entity and the internal relationships between the instance and its input and output datasets.

As with the portal, the submitted data will be validated, and the instance will only be created if all validations pass; otherwise, the errors will be reported.

Proceso

Allows creating a process, completing in the state included in the request.

It consists of the call:

POST https://{host}/gateway/api/admin/kerno/create-update/entity/process

The request body to send is obtained as indicated in the section Metadata Insertion/Update.

This will create the PROCESS entity.

As with the portal, the submitted data will be validated, and the process will only be created if all validations pass; otherwise, the errors will be reported.

Editing of native entities

This section presents the endpoints prepared to edit native entities (DATASET, DSA, INSTANCE, SOLUTION) with everything they entail (internal relationships, additional entities in the case of dataset, etc.).

In all these edits, if there is configuration indicating that the changes create a new version of the object, a new version of the entity will be generated with the corresponding changes and the one that was edited will be deprecated.

Additionally, non-editable fields can be edited by sending the input parameter: disableNonEditValidations. It is disabled by default.

Dataset and dataset-fields

Allows editing a dataset and its associated dataset-fields, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/dataset/{idObject}

The request body to send is obtained as indicated in the section Metadata Insertion/Update. The variable must be specified idObject in the URL.

If the dataset fields are not to be edited, send the list as null. An empty list is interpreted as deleting all dataset fields.

As with the portal, the submitted data will be validated, and the dataset will only be created if all validations pass; otherwise, the errors will be reported.

If the edit state is APPROVED and the dataset is governed, tot will be invoked.

Dsa

Allows editing a DSA and changing the contained entities, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/dsa/{idObject}

The request body to send is obtained as indicated in the section Metadata Insertion/Update. The variable must be specified idObject in the URL.

If the contained entities are not to be edited, send the list as null. An empty list is interpreted as having no contained entities.

As with the portal, the submitted data will be validated, and the DSA will only be created if all validations pass; otherwise, the errors will be reported.

When the chosen state is APPROVED, Tot will be invoked with the information of the edit performed.

Solution

Allows editing a solution and its related instances, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/solution/{idObject}

The request body to send is obtained as indicated in the section Metadata Insertion/Update. The variable must be specified idObject in the URL.

If the related instances are not to be edited, send the list as null. An empty list is interpreted as having no related instances.

As with the portal, the submitted data will be validated, and the solution will only be created if all validations pass; otherwise, the errors will be reported.

Instancia

Allows modifying an instance with its associated input/output datasets, completing in the state included in the request.

It consists of the call:

POST https://{{host}}/gateway/api/admin/kerno/create-update/entity/instance/{idObject}

The request body to send is obtained as indicated in the section Metadata Insertion/Update. The variable must be specified idObject in the URL.

If the related input datasets are not to be edited, send the list as null. An empty list is interpreted as having no input datasets. The same applies to output datasets.

As with the portal, the submitted data will be validated, and the instance will only be created if all validations pass; otherwise, the errors will be reported.

Proceso

Allows editing a process, completing in the state included in the request.

It consists of the call:

POST https://{host}/gateway/api/admin/kerno/create-update/entity/process/{idObject}

The request body to send is obtained as indicated in the section Metadata Insertion/Update. The variable must be specified idObject in the URL.

As with the portal, the submitted data will be validated, and the process will only be created if all validations pass; otherwise, the errors will be reported.

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}

As an option, another parameter is included in the call: validateType. This parameter indicates whether to validate the type of parameters (that numbers are numbers or that the value is valid in fields with limited values, for example); it defaults to true and should only be included if those validations need to be disabled.

As a result, an OK (200) will be received if everything went well, or a PARTIAL CONTENT (206) if any object could not be edited, indicating the error that occurred (it will be a list with as many elements as objects that failed to edit).

De-adherence of a DSA

Allows executing the de-adherence of 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 that cannot be de-adhered are the owners of the organizational unit of the DSA.

Indexing of all entities

Allows completely updating the SolR collection of Anjana objects (only the kerno collection, not the snapshots), deleting 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 be delayed.

Internally, it is performed in configurable blocks. If the process does not correctly index all elements, review and adjust the block configuration to adapt it to what the system supports.

Notifications

All are found in the Hermes module.

Get all sent notifications

Allows obtaining all sent notifications according to the specified search criteria, as long as the user making the request is a recipient of them (either by name or by their role and organizational unit)

It consists of the call:

POST https://{{host}}/gateway/api/admin/hermes/notification

The request body is the following:

Filtering by at least one variable is mandatory; otherwise a 400 bad request error will be received.

En ese endpoint es recomendable incluir la cabecera de “x-language”, ya que las notifications siempre contienen valores traducidos.

Send a notification

Allows sending a notification to a user or any role with the desired parameters.

The call is made:

POST https://{{host}}/gateway/api/admin/hermes/send

The request body is the following:

Below, each variable is explained:

• senderUser User sending the notification

• moduleType Notification module. Possible values: ALL, DC and BG

• notificationReceiverType Receiver type. Possible values: USER and ROLE

• notificationType Notification type. Possible values: NOTICE, ALERT and ADMIN_ALERT.

• read Indicates whether the notification has been read

• severity Importance of the notification. Possible values: LOW, MEDIUM and HIGH

• typeObject Object type. Possible values: ENTITY and RELATIONSHIP

• subtypeObject Object subtype. E.g.: DATASET, DSA, INSTANCE… or client-specific subtypes defined in the ObjectSubType table

• idObject Internal ID of the object

• redirectionType type of redirect of the notification

• objectName Name of the object

• objectVersion Version del objeto

• organizationalUnit Organizational Unit

• idNotification Identifier of the notification defined in the Notification table.

• execution Identifier of the workflow in case it is a notification associated with an execution.

• task Name of the task related to the notification

• creationDate Notification creation date

• endDate Notification end date

• receiverUser User that receives the notification when the notificationReceiverType is USER

• receiverRole User that receives the notification when the notificationReceiverType is ROLE

• messageKey Translation key of the notification message

• messageParams Map of notification variables that will be replaced by their corresponding value in the messageKey translation.

Workflows

All are found in the Hermes module except for the launch of the final workflow step.

Get all workflows

Allows obtaining a summary of all workflows according to the specified search criteria. If you do not want to filter by any of these criteria, it must be indicated with null.

Permite obtener todos los workflows lanzados en el sistema. It consists of the call:

POST https://{{host}}/gateway/api/admin/hermes/executions

Get a specific workflow

Allows obtaining information about a particular workflow, including information about the different steps that make up the workflow, who validated each one, its state, etc.

It consists of the call:

GET https://{{host}}/gateway/api/admin/hermes/execution/{id}

Deletion of a specific workflow

This endpoint allows deleting a particular workflow and all the information related to it both in the workflow engine and in Anjana.

DELETE https://{{host}}/gateway /api/admin/hermes/delete/workflow/{id}

Launch the final step of a workflow

This service allows launching the final step of any workflow in the same way as when a workflow ends in Activiti, mainly intended for cases where some desynchronization occurs and the last processes in the objects are not completed.

It is the following call:

PUT https://{{host}}/gateway/api/admin/kerno/workflow/finish/{workflowExecutionId}

Organizational Units

All are found in the Zeus module.

List of Organizational Units with creation/modification permission

Allows obtaining the list of Organizational Units for which the queried user has creation or modification permission for a given object subtype.

It consists of the call:

POST https://{{host}}/gateway/api/admin/zeus/list/{{objectSubtype}}

It collects information from all configured providers, so there may be a delay in obtaining a response due to delays that may exist with the providers.

Get the roles and organizational units of a user

Allows obtaining the roles and organizational units of the queried user.

It consists of the call:

POST https://{{host}}/gateway/api/admin/zeus/organizational-unit/role

It collects information from all configured providers, so there may be a delay in obtaining a response due to delays that may exist with the providers.

Creation of Organizational Units

Allows creating a new organizational unit.

POST https://{{host}}/gateway/api/admin/zeus/create/organizational-unit

Deletion of Organizational Units

Allows deleting an organizational unit using the identifier assigned to it in the database.

DELETE https://{{host}}/gateway/api/admin/zeus/delete/organizational-unit/{id}

Update of Organizational Units

Allows changing a property of the organizational unit indicated in the provided data, based on its identifier in the database

PATCH https://{{host}}/gateway/api/admin/zeus/update/organizational-unit

Indexer

All are found in the Minerva module.

Index an object

Allows indexing a particular object (ENTITY or RELATIONSHIP) in the KERNO collection and will automatically always generate a SNAPSHOT.

It consists of the call:

POST https://{{host}}/gateway/api/admin/minerva/index

Get all documents

Allows obtaining all indexed documents in the Kerno collection of Anjana.

It consists of the call:

GET https://{{host}}/gateway/api/admin/minerva/kerno/getAll

It is highly recommended to include the “x-language” header in this endpoint, as objects always contain translated values and multilingual values. If not included, they will come in the default language of the application.

If, on the contrary, a language is specified that does not exist in the system, the international fields will not appear in the returned data.

To correctly obtain all documents, the call must be made using a curl command specifying a file where the response will be saved. Example:

curl -X GET ^ https://dev44.anjanadata.org/gateway/api/admin/minerva/kerno/getAll \

-H "accept: */*" \

-H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJwcnVlYmEucHJ1ZWJhIiwiYXVkIjoid2ViIiwicm9sZXMiOiJST0xFX0FTU09DSUFURURfQlVTSU5FU1NfUFJPQ0VTU0VTX0NIQU5HRV9TVE…." \

-o C:\Users\user\Escritorio\file.json

Get all snapshots of an object

Allows obtaining all snapshots of an object.

It consists of the call:

GET https://{{host}}/gateway/api/admin/minerva/snapshots/getAll/{objectSubType}/{idObject}

It is highly recommended to include the “x-language” header in this endpoint, as objects always contain translated values and multilingual values. If not included, they will come in the default language of the application.

If, on the contrary, a language is specified that does not exist in the system, the international fields will not appear in the returned data.

Indexing de una audit

Permite crear la audit que se le indique en los datos provistos.

It consists of the call:

POST https://{{host}}/gateway/api/admin/minerva/audit/save

Obtener toda la audit existente

Este endpoint permite obtener toda la audit existente en Anjana.

GET https://{{host}}/gateway/api/admin/minerva/audit/getAll

Obtener la audit de un usuario

This endpoint allows obtaining the existing audit records for the specified user.

GET https://{{host}}/gateway/api/admin/minerva/audit/getAll/{username}

Obtener toda la audit de un objeto dado

This endpoint allows obtaining all audit records for the indicated object for the provided subtype. The information returned will be that which matches exactly what is provided, i.e., if no object ID is specified, the audit records that have the indicated subtype and an empty (null) object identifier will be returned.

GET https://{{host}}/gateway/api/admin/minerva/audit/getAll/{objectSubType}/{objectId}

Creation of filter configuration

This endpoint allows creating the different filters to be used in Anjana according to the provided data

POST https://{{host}}/gateway/api/admin/minerva/create/filterConf

Update of filter configuration

This endpoint allows updating the indicated filter with the provided information.

PATCH https://{{host}}/gateway/api/admin/minerva/update/filterConf

Collection update

This endpoint performs a collection update. This means it will first delete it, then create the fields (both the basic collection fields and those found in the attribute_definition table of anjana).

This endpoint can be used for any Anjana collection.

The endpoint is:

PUT https://{{host}}/gateway/api/admin/minerva/collection/update

Deletion of a collection field

To delete a field, it is necessary to delete all the data in the collection, so first all the data is deleted and then the field is deleted; therefore, if you want to have the collection with the data loaded again, you must call the indexAll endpoint.

The endpoint is:

DELETE https://{{host}}/gateway/api/admin/minerva/collection/delete-field/STATE/KERNO

Public API

Metadata Insertion/Update

Entity Creation

Due to the complexity of native entities, entity creation does not allow editing anything except the primary and key fields of entities; to complete all the metadata it is necessary to subsequently use the entity editing endpoint.

The call is:

POST https://{{host}}/gateway/api/v4/entity/create/{objectSubType}

This endpoint generates the skeleton of an entity filling in only the fundamental values (name, ou, pks) including the required internal relationships (e.g.: in the case of an instance, with a process and a solution).

Relationship Creation

To create the input data for metadata insertion, it is necessary to know which attributes the relationship template to be created has. For this, use the response from the dynamic form service as a reference. This endpoint is a call that can be found at:

GET https://{{host}}/gateway/api/v4/catalog/relationship/{objectSubType}

These endpoints return the dynamic form structure with the fields the relationship has and their validations.

To create the object, a list of attributes must be sent; since it is a creation, the name must be included as an object attribute.

The attribute list is sent with the call:

POST https://{{host}}/gateway/api/v2/relationship/create/{objectSubType}

The created relationship will always be in DRAFT state.

As with the portal, the submitted data will be validated, and the relationship will only be created if all validations pass.

Entity editing

To create the input data for metadata modification, the response from the dynamic form service can be used as a reference. This endpoint is a call that can be found at:

GET https://{{host}}/gateway/api/v4/catalog/entity/{objectSubType}

This endpoint returns the dynamic form structure with its validations.

To consult the complete list of validations, including those for only-on-edition, consult the following endpoint:

GET

https://{{host}}/gateway/api/v4/catalog/complete/entity/{objectSubType}

To consult the structure of a specific entity with its fields and validations, consult:

GET

https://{{host}}/gateway/api/v4/catalog/entity/{objectSubType}/{idObject}

To modify the entity, a list of attributes must be sent.

The attribute list is sent with the following call:

POST https://{{host}}/gateway/api/v2/entity/save/{objectSubType}/{idObject}

This edit will modify the previous values when editing a DRAFT, but when editing an APPROVED, DEPRECATED or EXPIRED, it will create a new DRAFT with a new ID (cloning everything necessary, for example datasetfield in the case of DATASET or the dataset relationships in the case of a DSA) leaving the original object untouched.

As with the portal, the submitted data will be validated and, only if all validations pass, the entity will be edited.

Relationship editing

To create the input data for metadata modification, the response from the dynamic form service can be used as a reference. This endpoint is a call that can be found at:

GET https://{{host}}/gateway/api/v4/catalog/relationship/{objectSubType}/{idObject}

These endpoints return the dynamic form structure with the fields the relationship has and their validations.

To modify the relationship, a list of attributes must be sent.

The attribute list is sent with the call:

POST https://{{host}}/gateway/api/v2/relationship/save/{objectSubType}/{idObject}

This edit will modify the previous values when editing a DRAFT, but when editing an APPROVED, DEPRECATED or EXPIRED, it will create a new DRAFT with a new ID leaving the original object untouched.

As with the portal, the submitted data will be validated, and the relationship will only be edited if all validations pass.

Get all relationships of an entity

Allows obtaining all relationships an entity has, including internal relationships.

It consists of the following call:

GET https://{{host}}/gateway/api/v2/relationship/all/{objectSubtype}/{id}

Get the defined values for an attribute

Allows obtaining all possible values of an attribute with predefined SELECT values.

It consists of the call:

POST https://{{host}}/gateway/api/v2/attribute/values

The request body is the following:

Filtered search

Allows performing searches in SolR with different filters.

It consists of a call POST https://{{host}}/gateway/api/v1/indexer/{target}/search including in the body the search parameters.

It is highly recommended to include the “x-language” header in this endpoint, as objects always contain translated values and multilingual values. If not included, they will come in the default language of the application.

Workflow validation

Allows validating one or more workflows at a time using their identifiers

It consists of the call PUT https://{{host}}/gateway/api/v1/task/validate

Bulk submission

Allows sending multiple objects of the same subtype for validation.

It consists of the call POST https://{{host}}/api/v2/common/massiveSubmit/{{objectSubtype}} including in the body the object IDs and the role with which the workflows will be launched.

The response will include those IDs that successfully completed the operation and those that did not, along with the reason why.

It is highly recommended to include the “x-language” header in this endpoint, as objects always contain translated values and multilingual values. If not included, they will come in the default language of the application.

As a help to avoid many errors, another endpoint is included that, given a list of IDs, returns those that meet the conditions to be submitted; that endpoint is a POST https://{{host}}/api/v2/common/checkSubmit con la lista de ids de los objetos y su subtipo.

API response codes based on license status