Notification Services Overview

How It Works

When a user performs an action associated with a subscribed event, the ScholarOne Manuscripts application generates a notification message and transmits it to the preconfigured endpoint(s).

• Multiple Endpoint Support: For a single subscribed event, ScholarOne Notification Services can generate and dispatch messages to one or more endpoints, depending on configuration settings.

Standards

ScholarOne Notification Services adhere to the following technical standards:

• Protocol: HTTP/HTTPS
• Method: GET (HTTP)
• Formats/Encoding: UTF-8 with RFC-3986 percent encoding for query string parameter name/value pairs.

Service Prerequisites

To use ScholarOne Notification Services, ensure the following:

Endpoint Requirements

• The receiving endpoint must be available to accept notifications.
• The receiver must respond with an appropriate HTTP status code (success/failure).
  • Note: ScholarOne requires an HTTP 200 response to confirm successful receipt and avoid retries.
• The receiver can be implemented using any framework.

Configuration Steps

1. Request ScholarOne to enable and configure Notification Services for the relevant journal(s).
   1. Provide the endpoint URL where notifications should be sent.
2. Configure the firewall to allow HTTP requests from ScholarOne.
   1. ScholarOne will supply the necessary IP address(es) if required.

Message Delivery

The delivery system is equipped with fault tolerance and hold features to provide assurance attempted messages are successfully received at the destination endpoint.

Message Lifecycle

• Creation: Messages are generated and sent to the configured endpoint upon a subscribed user action.
• Delivery Guarantee: Messages are typically delivered once under normal conditions.

Fault Tolerance & Retries

If delivery fails due to any of the following, the system will retry:

• Endpoint timeout (slow response)
• Connection failure (ScholarOne is unable to connect to the endpoint)
  • Network issues
  • Endpoint downtime

Retry Interval: Subsequent attempts occur <10 minutes> after failure.

Expiration Policy

• Unsuccessful delivery attempts expire after 7 days from creation.
• If an endpoint is expected to be unavailable for an extended period, consider using the On-Hold feature (see below).

On-Hold Feature

The On-hold feature provides the ability to place the delivery of messages to a specific endpoint on-hold (i.e. don’t send messages to this endpoint).

• Temporarily suspends message delivery to a specified endpoint.
• Messages continue to be queued but are not sent until the hold is lifted.
• Upon resumption:
  • The expiration period resets to 7 days from the hold end date.
  • Messages older than 45 days (from creation) are not retried, regardless of endpoint status.

Management: The On-hold feature can be managed within the ScholarOne Manuscripts Application. See Monitoring and Support Tools page for more information.

Message Cancellation

Pending messages can be canceled via the Notification Services Report in ScholarOne Manuscripts Application (see Monitoring and Support Tools).

Web Services Overview

Notification Services can be used independently or in conjunction with the Web Services APIs . These services support integration scenarios where external systems must remain synchronized as manuscripts progress through the peer review process.

Support

For assistance with ScholarOne Notification Services:

• Visit the ScholarOne Support Site for FAQs, documentation, and case submission.
• Questions about network connections and/or the use of your Web browser should be directed to your Network Administrator.