Page History
...
|
| 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 used when DSpace sends out LDN Messages |
Level of Trust: floaing 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 qa event automation. See the project file dspace/config/spring/api/qaevents.xml on the bean qaAutomaticProcessingMap/qaScoreEvaluation |
Service IP Range: two IP numbers expected as minimum and maximum. This range can be 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 out of this range - the LDN Message is set as untrusted. |
LDN Inbox URL: every incoming LDN Message must have an identifiable Notify Service. We match this field to the origin.inbox attribute of the LDN Message. Despite the ip range - 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. |
Inbound Pattern: stored into the database table notifyservice_inbound_pattern - we can add at lease 1 of them for each Notify Service. Every inbound pattern is the triple of [ pattern, item filter, automatic flag ] :
|
LDN Inbox queueing
LDN incoming messages are stored into the ldn_message database table. The incoming LDN messages is stored into a logical queue. 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.
...
Please consider that this means that the corresponding QAEvent is not automatically created ! The corresponding QAEvent is created by the processor instance of the LDN message, invoked by the extractor.
LDN message processing
All the possible incoming LDN messages patterns are documented in the official link: COAR Notify Protocol: Notification Patterns Every LDN message json ends with the array named Type. Inside the DSpace spring configuration settings we store a list of LDN message types to be routed to certain processors. See dspace/config/spring/api/ldn-coar-notify.xml the bean ldnRouter and its incomingProcessors map property. When the extractor finds an LDN message with a Type mismatching any of the processors, the LDN message queue status moves to unmapped.
Unmapped LDN messages are not processed.
At time of writing the processing of an LDN message corresponds to the creation of a QAEvent.
LDN Messages Queue is maintained by two different tasks:
Message Extractor
Timeout Checker
The Extractor pick an LDN message from the queue, assigns a processor and launches it. If the processor ends successfully the LDN message is out out of the queue, updating its queue_status to processed. Also, queue_last_start_time and queue_timeout are updated: queue_last_start_time is updated with the current timestamp, queue_timeout is updated with a value current timestamp + the configuration value of the key ldn.processor.queue.msg.timeout. Also, increases queue_attempts by 1. The extractor does not consider the LDN messages with attempts already done >= the value of the configuration key ldn.processor.max.attempts
The Timeout looks for timed-out LDN messages with queue_status as processing. If attempts < ldn.processor.max.attempts the message is enqueued again, moving its status to queued; otherwise its status is set to failed.as soon as the LDN Message is received. LDN Message => Extractor => Routing => Processor => Action that creates the QA - see class org.dspace.app.ldn.action.LDNCorrectionAction
Offer, Acknowledgement and Announce
...
Overview
Content Tools