Page History
...
ldn.enabled = true|false | true => message is received and managed the server responds with an HTTP 202 code false => message is refuced refused and the server respond responds with an HTTP 404 code |
ldn.notify.inbox = DSpace\url\address\ = <ldn inbox endpoint> | where the ldn inbox rest service is mapped on the current DSpace instance. IE: ${dspace.server.url}/ldn/inbox |
coar-notify.ip-range.enabled = true|false | enables the filter on validation against the IP of the sender (external) for received ldn message (into the DSpace ldn inbox)against the registered range |
Relation with the Quality Assurance Correction Service
...
Third party system can retrieve the location of the repository LDN InBox via the LDN autodiscovery mechanism, nevertheless to be able to interact with DSpace they need to be approved by a Repository Administrators and listed in the LDN Services Directory (see next paragraph); otherwise their messages will be flagged as untrusted and not processed at all.
LDN Services Directory (Registering Services)
Anchor | ||||
---|---|---|---|---|
|
You need to register the external services to trust allow the handling of the incoming LDN messages / send LDN messages to:.
These services are also used to send LDN notification during the submission process of an item (Please take a look at LDN Inbound pattern)
Administrators can do that manage services using the menu LDN Services. New/Edit Notify Service with this form
The following page is used to submit a new LDN Service:
Name: a label for the Notify Service used on the UI |
Description: the description of the Notify Service - add details here |
Service URL: the url of the remote Notify Service. This is mostly used when DSpace sends out LDN Messagesas a descriptive URL when sending notification to an external system. The service URL must not be confused with the inbox url. As said this url is descriptive so we expect the main application URL to be added here |
Level of Trust: floating point number Level of Trust: floating point number value accepted between 0 and 1. This value is passed into every QA Event created by every LDN Message associated with this Notify Service: it goes to evaluate the "score" attribute of the QA Event. Score attribute is used for rejection/acceptance used to assign to the service a TRUST value that describes how much reliable the external service is. This value is not used if the automatic processing of QA Events is disabled Check the configuration file qa event automation. See the project file dspace/config/spring/api/qaevents.xml on the bean qaAutomaticProcessingMap/qaScoreEvaluation to enable the automatic approval When the automatic approval is configured the trust value of the LDN Service is check against configured score thresholds. Thresholds for automatic Approval/Rejection/Ignoring can be set. Also within a specified range QA Events will need a manual approval |
Service IP Range: two IP addresses Service IP Range: two IP numbers expected as minimum and maximum. This range can be is used to add a filter to entrust the identified Notify Service of every incoming LDN Messages. If IP Range is enabled, the sender Notify Service is identified but the current LDN Message is coming from an IP validate the received LDN Messages. When the LDN notification doesn't match the configured IP Range the notification is stored as UNTRUSTEDout of this range - the LDN Message is set as untrusted. |
LDN Inbox URL: every incoming LDN Message must have an identifiable Notify Service. This is the URL of that external system's LDN Inbox. We match this field to the "origin.inbox" attribute of the incoming LDN Message. This field is mandatory. Every incoming LDN Message with a non-identifiable Notify Service associated is set as untrusted and won't be enrouted to the Ldn Router. this is the url used to send the LDN Notifications. This url is also used when a notification is received to retrieve the registered LDN service it belongs to This URL must is unique among the registered LDN Services |
Inbound Pattern: the section for Inbound pattern is the section which describes what operations/actions are supported by the external service The pattern itself can be selected from the dropdown as there's a list of pattern. To better understand pattern usage please Inbound Pattern: stored into the database table notifyservice_inbound_pattern - we can add at least 1 of them for each Notify Service. Every inbound pattern is the triple of [ pattern, item filter, automatic flag ] : pattern: see https://notify.coar-repositories.org/patterns/ for all possible combinations, currently are hardcoded on the angular frontend project;
The item filter is used to describe which item can be processed for the current LDN Service/Inbound pattern. The automatic flag when set to true the ldn message exchange is performed automatically right after the item submission has finished. message targeting the Notify service and the item in submission. The automatic flag involves only the submission phase of an item. LDN notification is generated for any submitted item. |
LDN Inbox queueing
LDN incoming messages are stored into the ldn_message database table. As far as the property ldn.enabled is true and the incoming json is valid, the LDN Message is stored on the table. Together with the storage of the record, the queue status of the message is initialized. The queue_status column of the table contains the status of the LDN message inside the queue. All the possible queue_status values are described into the java class org.dspace.app.ldn.LDNMessageEntity as integer constants.
...