Page History
...
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. |
Test calls: Announce Relationship
Let's trigger an Announce Relationship (see COAR official pattern documentation here).
Firstly configure a Notify Service such as:
By clicking the + New green button fill the form as:
Pick the following POST call from the Postman project (see below to download it and import it to your installed PostMan instance): let's emulate the Notify Service external system sending us an LDN Message!
Let's evaluate the request' json body (some field is commented) according to the COAR official documentation of this pattern:
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. |
Test calls: Announce Review
Let's trigger an Request Review (see COAR official pattern documentation here).
Create a new Item into the COAR Notify Collection (collection created for the previous test).
Configure a new Notify Service such as:
By clicking the + New green button fill the form as:
For this specific example we can set just the first Inbound Pattern as Request Review and leave the item filter blank. This test is not about item submission.
Pick the following POST call from the Postman project (see below to download it and import it to your installed PostMan instance): let's emulate the Notify Service external system sending us an LDN Message!
{ "@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 for a QA Event (with source=coar-notify) to be produced. As soon as it is, a blue popup is shown on Item and myDSpace pages:
by clicking on that Check button navigation brings to the Quality Assurance Page for the source coar-notify:
If we navigate to the Quality Assurance page we can see the counter for QA Event of coar-notify source increased by 1!
Here it is the page of the specific QA Event in example:
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{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://purl.org/coar/notify"
],
"actor": {
"id": "https://research-organisation.org",
"name": "Research Organisation",
"type": "Organization"
},
"context": {
"id": "http://localhost:4000/handle/123456789/1119", //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://another-research-organisation.org/repository/datasets/item/201203421/data_archive.ziporcid.org/0000-0002-1825-0097",
"name":"Josiah Carberry",
"mediaTypetype":"application/zipPerson",
},
"type": [
"Article",
"sorg:Dataset"
]
}
},
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":"urnhttp:uuid:2f4ec582-109e-4952-a94a-b7d7615a8c69", // IMPORTANT!! this must be a unique value because it's going to be stored as uuid into the ldn_message table.
"object": {
"as:object": "newValue",
"as:relationship": "somethingElse", // as "http://purl.org/vocab/frbr/core#supplement" or something else
"as:subject//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/item/201203/421//preprint/201203/421/content.pdf",
"mediaType":"application/pdf",
"idtype":"http://localhost:4000/handle:123456789/1119",
"type": "Relationship"
},
[
"Article",
"sorg:ScholarlyArticle"
]
}
},
"origin":{
"id":"https://research-organisation.org/repositoryurl.ServiceURL?score=0.8",
"inbox":"2f4ec582-109e-4952-a94a-b7d7615a8c69http://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":{ // MUST be valid but it is not rilevant
"id":"https://anotherreview-research-organisationservice.orgcom/repositorysystem",
"inbox":"https://anothernotify-research-organisationinbox.orginfo/inbox/",
"type":"Service"
},
"type":[
"AnnounceOffer",
"coar-notify:RelationshipActionReviewAction"
]
}
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.
...