Page History
...
Configuration properties involved:
ldn.enabled = true|false | true => message is received and managed the server responds with an HTTP 202 code |
ldn.notify.inbox = <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 validation against the IP of received ldn message against the registered range |
...
- If the pattern is flagged as automatic the item filter is evaluated automatically
- if the item filter is respected the LDN Notification is stored and queued for sending
- if the item filter is not respected the LDN Notification is not even generated an nothing will be sent to the external service
- If the pattern is not flagged as automatic the item filter is evaluated when choosing the service from the dropdown for Notify in the submission
- if the pattern is not respected an error message will be displayed saying the selected LDN service cannot be used for the current item
- if the pattern is respected no error message is displayed
Item Filter is a non-mandatory field. It activates a filter to be applied to the item during the submission.
If the item matches the item filter condition the submission will be successful: otherwise the submission will fail with a talkative message.
Visible item filters are configured into a static list mapped into item-filters.xml file - on a bean named ldnItemFilters. We established for the following item filter to be shown:
Has one Bitstream = the item must have exactly one bundle named "ORIGINAL";
Item is public = anonymous user can see/read the item;
Title starts with pattern = the dc.title metadata of the item must start with 'Pattern';
Type equals dataset = the dc.type metadata of the item must be 'Dataset';
Type equals dataset = the dc.type metadata of the item must be 'Journal Article';
item-filter.xml has all item filters declarations: only the ones declared inside the ldnItemFilters map are shown.
The LDN Consumer
The LDN Consumer is the consume responsible for generating the outgoing LDN Notification.
...
This consumer is responsible for the handling of both automatic a non-automatic patterns
event.consumer.ldnmessage.class = org.dspace.app.ldn.LDNMessageConsumer event.consumer.ldnmessage.filters = Item+Install |
---|
Understanding the structure of the LDN Notification
...
The context section is the same for any LDN Notification
|
---|
actor
This section describes the actor which performs the request
This is a descriptive section and doesn't include important information
|
---|
context
This is one of the most important section.
In this section we have a description of the Item being involved in the LDN Notification
...
other fields are descriptive fields for the item
|
---|
id
The identifier of the LDN notification (Each notification has a different id)
"id": "urn:uuid:94ecae35-dcfd-4182-8550-22c7164fe23f" |
---|
inReplyTo
This field is used to reply to other LDN notification so that the system knows if the current notification is a response
"inReplyTo": "urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a509dd" |
---|
object
This is a descriptive section of the received Review, Endorsement etc..
- id → is the URL of the review/endorsement etc.
|
---|
origin
This is an important section since it is used (for incoming notifications) to determine the service among the registered ones.
If the service is not recognized as registered the notification is untrusted
The field being used for this check is inbox
|
---|
target
This section is used to describe the target system involved in the notification workflow
|
---|
type
This type section is important since it's determining how to process/evaluate any received notification
|
---|
...
Testing
Request Endorsement (LDN Message on item submission)
...
See below the successful response:
This means the LDN Message has been received.
At this point there's not feedback if the notification has been stored & enqueued or just stored as untrusted.
...