Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Configuration properties involved:



ldn.enabled = true|false


true => message is received and managed the server responds with an HTTP 202 code
false => message is refused and the server responds with an HTTP 404 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.

Image Added

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 

  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ]

actor

This section describes the actor which performs the request
This is a descriptive section and doesn't include important information

  "actor": {
    "id": "https://review-service.com",
    "name": "Review Service",
    "type": "Service"
  }

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

  "context": {
    "id": "https://research-organisation.org/repository/preprint/201203/421/",
    "ietf:cite-as": "https://doi.org/10.5555/12345680",
    "type": "sorg:AboutPage",
    "url": {
      "id": "https://research-organisation.org/repository/preprint/201203/421/content.pdf",
      "mediaType": "application/pdf",
      "type": [
        "Article",
        "sorg:ScholarlyArticle"
      ]
    }
  }

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.
  "object": {
    "id": "https://review-service.com/review/geo/202103/0021",
    "ietf:cite-as": "https://doi.org/10.3214/987654",
    "type": [
      "Document",
      "sorg:Review"
    ]
  }

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

  

  "origin": {
    "id": "https://review-service.com/system",
    "inbox": "https://review-service.com/inbox/",
    "type": "Service"
  }

target

This section is used to describe the target system involved in the notification workflow 

  "target": {
    "id": "https://generic-service.com/system",
    "inbox": "https://generic-service.com/system/inbox/",
    "type": "Service"
  }

type

This type section is important since it's determining how to process/evaluate any received notification

  "type": [
    "Announce",
    "coar-notify:ReviewAction"
  ]




...

Testing

Request Endorsement (LDN Message on item submission)

...

See below the successful response:

Image Modified

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.

...