Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
Introduction
To complement the developments for the COAR Notify protocol COAR Notify Documentation, the Notify Administrative Dashboard has been implemented to monitor the general usage of the COAR Notify protocol across the repository.
The dashboard is accessible to repository administrators only via the menu voice COAR Notify > Dashboard.
The dashboard is organised in three tabs:
Metrics
Logs/Inbound
Logs/Outbound
Dashboard tabs
Metrics
The “Metrics” tab displays data about usage of the COAR Notify protocol, showing the number of received (accepted/processed/failure/untrusted) and generated (delivered/queued/queued for retry/failure) LDNs, and the total number of items involved.
Any LDN Message is considered in this view as long as the Notification is stored.
Meaning of each box
Each box describes a different status the notifications are
Accepted
This box displays the number of LDN received as an acceptance to a previous request sent from the repository.
This means We have received an acceptance notification from the external service (Notice this is not the same as receiving the Review/Endorsement or any other object)
so the external service has accepted our previous notification an has replied with a confirmation to the LDN.
When an Acceptance LDN is received as reply to a previously sent notification this counter is increased.
Processed LDN
This box displays the number of LDN received and processed correctly (acceptance notifications are included as well since acceptance might be defined as a subset of processed notification)
Notifications in this status have been correctly processed and a corresponding action was triggered
Failure
This box displays the number of LDN received but not correctly processed.
This status includes QUEUE_STATUS_FAILED and QUEUE_STATUS_UNMAPPED_ACTION. So any failing notification is reported to be reviewed by the user
Untrusted
This box displays the number of LDN received but not even processed.
Any notification in this status has not even been evaluated since the Service was not recognized or the IP range was not respected
Delivered
This box displays the number of LDN Sent without any error.
Any notification successfully delivered will increase this counter
Queued
This box displays the number of LDN waiting to be sent (LDN is still queued)
Since LDN are not immediately sent to the external service this status is displaying how many items are still queued
Queued for retry
This box displays the number of LDN waiting for reprocessing
This means the failing (outgoing) notification has been re-queued to be reprocessed
Failure
This box displays the number of Failing LDN
Generally in this case the external service didn't receive the notification (an error code is expected when delivering the LDN)
Involved Items
These boxes are duplicated for each row for Incoming and Outgoing LDN.
They display the total number of items in the repository involved in the workflow process for COAR NOTIFY.
In few words these boxes display the number of items a LDN was receive/generated for
Boxes configuration
REST (Discovery configuration)
Each box is related to a different discovery configuration as mentioned above
- ldnMessageEntityBaseConfig is the "base" configuration for all the different LDN discovery config.
This configuration mainly defines the search filter and facets used by any discovery config. - NOTIFY.incoming.accepted is the configuration for the "Accepted" box
- NOTIFY.incoming.processed is the configuration for the "Processed LDN" box
- NOTIFY.incoming.failure is the configuration for the "Failure (for incoming)" box
- NOTIFY.incoming.untrusted is the configuration for the "Untrusted" box
- NOTIFY.incoming.involvedItems is the configuration for the "Involved items (for incoming)" box
- NOTIFY.outgoing.delivered is the configuration for the "Delivered" box
- NOTIFY.outgoing.queued is the configuration for the "Queued" box
- NOTIFY.outgoing.queued_for_retry is the configuration for the "Queued for retry" box
- NOTIFY.outgoing.failure is the configuration for the "Failure (for outgoing)" box
- NOTIFY.outgoing.involvedItems is the configuration for the "Involved items )for outgoing)" box
Angular
On the angular application we can decide which box has to be displayed, the text color, the background color and the title for each one
The angular configuration involved is found in default-app-config.ts
Here's an example of the angular configuration
notifyMetrics: AdminNotifyMetricsRow[] = [ { ........
......
|
---|
The above layout configuration allows to configure the whole Dashboard/Metrics Tab
Using AdminNotifyMetricsRow we are allowed to define a custom number of rows (The default is two)
Each Row has title and boxes elements
- title is the title being displayed on the row
- boxes is the list of boxes in the current row
Each Box object has the following mandatory fields: color, title, config and description and one optional parameter textColor
- color is the background color for the box (as HEX color code)
- title is the text displayed on the box (as key for the label)
- config is the discovery configuration to use
- description is the tool-tip text displayed (as key for the label)
- textColor is the font color used for the title of the box (as HEX color code)
User Interface
Each colored box is clickable and behind each box there's a different discovery configuration:
Statuses Boxes will redirect the user to the corresponding log’s tab (either inbound or outbound), showing the LDN messages filtered by the corresponding selected criteria
Involved item boxes will redirect the user to the Administrative Search page, where only the involved items, either by incoming or outgoing LDN messages, will be shown in the results list.
Items can than be further filtered also for any COAR Notify metadata (notify.relation.endorsedBy, datacite.relation.isReviewedBy, and datacite.relation.isReferencedBy) using the facets.
Logs Inbound Tab
In the “Logs/Inbound” tab it’s possible to search and check the individual status of each LDN message received by the repository.
Logs are listed in a table displaying the following columns:
Timestamp
Repository item
LDN Service
Type
Status
Action
Logs can be scrolled and/or filtered by:
Related item
LDN Service
Queue status
Activity stream type
COAR Notify type
Last processing time
In the logs' table, the value in the “Repository Item” column links to the involved item in the repository.
By clicking on the 'detail' button corresponding to each log, a modal will open displaying the technical information of the received LDN message
and it is also be possible to inspect the JSON notification which might be relevant for some purposes.
In case of messages with a queue status equal to “untrusted” and “unmapped action”, a second button ”Reprocess” will be displayed.
By clicking this button, a request to reprocess the LDN message is triggered.
This allows administrators to reprocess, for instance, messages received from LDN services that have not yet been registered (once the proper mapping has been added on the related spring config file),
or notification which hadn't been correctly processed the first time.
In case of deleted items, LDN services, etc., “n/a” will be shown in the logs' table in the corresponding "Repository Item" coloumn.
Logs with “Unmapped Action” status don’t display a timestamp, as they have not been processed.
Why a LDN notification should be reprocessed?
- The external service might have changed the IP and it doesn't match any longer with the rage provided on the LDN Service
- The LDN Notification had an unsupported type an this led to an unmapped action status.
In this case we should configure a new mapping for the missing type before reprocessing the notification
Logs Outbound Tab
In the “Logs/Outbound” tab it’s possible to search and check the individual status of each LDN message received by the repository.
Logs are listed in a table displaying the following columns:
Timestamp
Repository item
LDN Service
Type
Status
Action
Logs can be scrolled and/or filtered by:
Related item
LDN Service
Queue status
Activity stream type
COAR Notify type
Last processing time
In the logs' table, the value in the “Repository Item” column links to the involved item in the repository.
By clicking on the 'detail' button corresponding to each log, a modal will open displaying the technical information of the received LDN message
and it is also be possible to inspect the JSON notification which might be relevant for some purposes.
In case of messages with a queue status equal to “failed”, a second button ”Reprocess” will be displayed. By clicking this button, a request to reprocess the message is triggered.
This allows administrators to reprocess messages received from LDN services that have not yet been registered in the repository, or whose data (i.e. service URL and IP range) have not been correctly entered in the LDN service registry.
Why a LDN notification should be reprocessed?
- The Service was temporarily down at the moment the LDN notification was sent
- The Service changed the Inbox Url and the notification was not deliverable
In case of deleted items, LDN services, etc., “n/a” will be shown in the logs' table.
Logs with “Untrusted” status don’t display a timestamp, as they have not been processed.