Page History
...
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.
...
Let's configure a new Notify Service such as:
and save.
(NOTE: If you plan to test with Docker, the "Service IP Range" should likely include 172.23.0.1 – this is the IP that your Host machine will likely appear as when running the backend in Docker.)
| 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. |
...
Overview
Content Tools