Page History
...
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
...
| Create a new Community: |
|
Create a new Collection inside the community created above. It is important for this community to have no Entity Type set. Take a look into the item-submission.xml file for the "traditional" steps sequence configuration. Here we've set the coarnotify-step! The traditional step sequence is used as the default, and the default is used for Collection with no entity type associated. If the coar-notify step is needed for every collection possible, the entry-step must be added onto every <submission-process> described into item-submission.xml |
|
Create a new Item, select the collection created above. As expected we see the COAR Notify section: here it is the ldn request configuration: comboes for Review, Endorsement and Ingest are filled with the corresponding configured LDN Services. For this example we see only one value for the Endorsement combo (see the Inbound Pattern configured onto the Notify Service named NotifyService Score0.123 - first screenshot of this paragraph) A new LDN Message of type Offer: Endorsement Action is stored and enqueued! As soon as the Extractor manages it, it is enrouted to the Processor configured at ldn-coar-notify.xml (as one of the <outcomingProcessors>). The processor is the bean named outcomingAnnounceEndorsementAction, which lists the SendLDNMessageAction. So, it is only at this point, when the action SendLDNMessageAction is executed - that the notification is sent out to the external Notify Service. To whom the notification is sent out? To the url configured as the LDN Inbox property of the Notify Service (see above: https://notify-inbox.info/inbox/). |
|
as soon as our Offer is correctly received on the Notify Service side, the Notify Service has to provide us - asynchronously as a separate Acknowledge LDN message - the Acceptance or Rejection of the Endorsement we offered. When Acceptance is received: The Acknowledge LDN Message - when received - is managed by the Processor configured into the bean named acceptAckAction. When Rejection is received: The Acknowledge LDN Message - when received - is managed by the Processor configured into the bean named rejectAckAction. | Until an Acknowledge or an Announce is received for this item, on the item page you can see the upper yellow window as: |
at time of writing COAR service for test purposes is responding an HTTP 500 as we sent the Offer. This error did not exist back in December 2023 when we firstly developed the LDN implementation. |
Testing Announce Review against current repository
Let's trigger an Request Review (see COAR official pattern documentation here).
...
For this test to succeed you must update the json below based on your system configuration. See the "IMPORTANT" lines.
| { "@context@context":[ "https://www.w3.org/ns/activitystreams", "https://purl.org/coar/notify" ], "actor":{ "id":"https://orcid.org/0000-0002-1825-0097", "name":"Josiah Carberry", "type":"Person" }, "id":"urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a50dff", //// IMPORTANT!! this MUST be a unique value because it's going to be stored as uuid into the ldn_message table. "object":{ "id":"http://localhost:4000/handle/123456789/1122", ////IMPORTANT!! this MUST be the URL of an Item in your DSpace repository. It can be either a handle-based URL or a UUID-based URL. "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" ] } }, "origin":{ "id":"url.ServiceURL?score=0.8https://research-organisation.org/repository", "inbox":"httphttps://ldn.ServiceURL?score=0.8research-organisation.org/inbox", /// IMPORTANT!! this field MUST match the "LDN Inbox URL" for one of the LDN/Notify Services you've added to your repository. (See previous screenshot) "type":"Service" }, "target":{ "id":"https://review-service.com/system", "inbox":"https://notify-inbox.info/inbox", "type":"Service" }, "type":[ "Offer", "coar-notify:ReviewAction" ] } |
...
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.
Please remember the enqueued ldn messages must be evaluated by the Extractor for a QA Event (with source=coar-notify) to be producedcreated.
As soon as it is processed by the extractor, a blue popup is shown on Item and myDSpace pages:
|
|
by clicking on that the Check button navigation brings we are redirected to the Quality Assurance Page for the source coar-notify:
|
If we navigate to the previous Quality Assurance page we can see the counter for QA Event of coar-notify source increased by 1!
...
Let's accept it with a click on the Green Check.
Go back to the item page to see the new Review metadata!
|
|
WORK IN PROGRESS Test calls: Request Review
Let's evaluate the request' json body (some field is commented) according to the COAR official documentation of this pattern:
{
"@context":[
"https://www.w3.org/ns/activitystreams",
"https://purl.org/coar/notify"
],
"actor":{
"id":"https://orcid.org/0000-0002-1825-0097",
"name":"Josiah Carberry",
"type":"Person"
},
"id":"urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a50dff", //// IMPORTANT!! this must be a unique value because it's going to be stored as uuid into the ldn_message table.
"object":{
"id":"http://localhost:4000/handle/123456789/1122", ////IMPORTANT!! this is the handle link to the item from the referred local repository
"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"
]
}
},
"origin":{
"id":"url.ServiceURL?score=0.8",
"inbox":"http://ldn.ServiceURL?score=0.8", ///IMPORTANT through this field we reach the configured Notify Service entity by matching this field to the one named LDN Inbox URL/
"type":"Service"
},
"target":{
"id":"https://review-service.com/system",
"inbox":"https://notify-inbox.info/inbox",
"type":"Service"
},
"type":[
"Offer",
"coar-notify:ReviewAction"
]
}
See below the successful response:
This means the LDN Message has been enqueued. Please remember the enqueued ldn messages must be evaluated by the Extractor.
Postman Project
Postman Collection for testing COAR-Notify Feature
Here’s the Postman collection for all test scenariosHere’s the Postman collection for all test purposes:
| View file | ||||
|---|---|---|---|---|
|
...
Overview
Content Tools