ScholarOne’s submission integration infrastructure incorporates multiple system monitoring mechanisms to ensure stable operation and rapid issue resolution. Key monitoring components include:

Queue Depth Monitor: This feature alerts ScholarOne when the manuscript queue in the S3 bucket awaiting processing exceeds a predefined threshold.
Heartbeat Monitor: A continuous test submission process that verifies manuscripts are being processed as expected.
Structured Logging: The system generates detailed structured logs, enabling efficient issue identification and troubleshooting.

Monitoring, Reconciliation, and Status Tracking for Integrators

When designing system architecture and business processes for submission integration, it is essential for the sending system to implement mechanisms for:

Monitoring submission progress.
Reconciling manuscripts sent against those successfully ingested by the receiving system.
Tracking the status of each manuscript within the workflow post-ingestion.

The following sections outline available tools for integrators to monitor, reconcile, and track ingested manuscripts, including system-to-system notifications, API methods, and client dashboards.

Notification Services

ScholarOne Notification Services provide near real-time updates to customer-specified endpoints when subscribed events occur within the ScholarOne Manuscripts application. Notifications are transmitted using HTTP or HTTPS protocols and facilitate external application integration with ScholarOne Manuscripts. Each notification includes a minimal payload containing essential metadata, such as the triggering event and related manuscript or user information.

Integrators can utilize the provided metadata to retrieve complete details via ScholarOne’s API. A comprehensive integration guide for ScholarOne Notification Services is available [here].

Success and Failure Notifications

While most workflow events in ScholarOne can be subscribed to as notifications, the most critical notifications for submission integration are:

Submission Success Notifications: Indicate successful ingestion of a manuscript.
Submission Failure Notifications: Triggered when a manuscript ingestion attempt fails.

As submission packages are processed by ScholarOne, these notifications provide near real-time status updates, eliminating the need for manual status checks. In case of ingestion failure, the notification includes an error code, which corresponds to a predefined list of failure reasons. This enables integrators to diagnose and resolve failures efficiently.

systemEventName=SUB_INTEGRATION_FAILURE&externalSubmissionId=ERR-1634-08&zipFileName=ERR-1634-08.zip&errorCode=3&notificationServiceVersion=V2&siteName=supportdemo&journalName=Journal%20of%20Support&subscriptionId=34245&subscriptionName=Failure&subscriptionType=SYSTEM_EVENT&eventDate=2019-04-09T10:37:28Z&messageUUID=e9b7ba0d-ad8b-478e-9e8e-54e2495c2bc5

Ingestion Status API

To support automated reconciliation between external systems and ScholarOne, an API method is available for integrators to retrieve the status of all ingestion attempts associated with a specific client key.

The getExternalDocumentIdsFull API method operates on ScholarOne’s enterprise-level web service platform, which is documented [here]. Similar to the integration dashboard in ScholarOne, ingestion status data is available on a six-month rolling basis. This API method retrieves all ingestion data for a user-specified time period, supporting periods of up to one week.

A complete guide to implementing ScholarOne web services is available [here].

Integration Center

The ScholarOne platform includes an Integration Center that provides access to Ingestion Status reporting. This feature enables integrators to retrieve and export data related to manuscript ingestions through a user interface.

Accessing the Integration Center

Note that access permissions to the Integration Center are granted by ScholarOne staff. To obtain the necessary role permissions, contact ScholarOne support.

Click the "Support" link located in the header of your ScholarOne portal site.
From a drop-down menu select Integration Center (INT)

The Integration Center is also accessible from individual journal sites. However, reports generated at the journal site level will only include ingestion attempts specific to that journal, and will not contain portal-level data.

The Integration Center link directs users to the Integration Tools Dashboard, which contains a link to the Ingestion Status Report (Figure 13).

Ingestion Status Report

The Ingestion Status Report allows users to search and report on ingestion attempts made to a single site or a portal of sites within the past six months. The report can be customized using filters located at the top of the page. These filters enable users to view all ingestion attempts or a subset based on criteria such as success/failure, external ID, and ingestion date (Figure 14).

For each ingestion attempt, the report provides the following fields (Figure 15):

Integration Name: The name assigned to the integration by ScholarOne when the client key is created. This name is used to differentiate ingestion attempts made by different integrations for publishers receiving external manuscripts from multiple integrators (e.g., more than one pre-print server).
Process Date: The date and time the package ingestion process was completed.
Site: The intended destination of the externally submitted manuscript.
External ID: The manuscript identifier provided by the external system and included in the package.
Document ID: The ScholarOne document identifier generated for the submission.
- Note: The Document ID is distinct from the Manuscript ID. Draft submissions are assigned a Document ID, which is retained by the document after submission.
Manuscript ID: The submission ID used in the ScholarOne user interface.
- Only manuscripts that have been submitted by the author will have a Manuscript ID.
Status: The status of the ingestion attempt, which can be "Success" or "Failure".
Error Code: A numeric code indicating the reason for a failed ingestion attempt. Successful ingestions will have a value of 0.
Error Reason: A text description of the reason for a failed ingestion attempt.

Notification Subscriptions

The "Notification Services Subscriptions" link in the Integration Center allows users to add or remove trigger events from notification subscriptions for existing endpoints. To add or edit an endpoint, contact ScholarOne support.

To configure notifications:

In the "Select" section at the top of the page, select the desired journal, consumer, and area (Figure 16).
- "Journal" refers to the ScholarOne site that will trigger the notification. For example, if "salesdemoplus" is selected, configured Accept events will trigger notifications when they occur on "salesdemoplus".
- "Consumer" is the configured name for one or more URLs where notifications will be delivered.
- "Area" is a defined set of event types. Options include:
  - System Events: A standard set of events in ScholarOne that are consistent across all journals, such as submission integration-related events, unsubmit, and submission confirmations.
  - Decisions: Decision events based on the journal's workflow and configuration.
  - Task Status Changes: Workflow events that trigger a notification when a workflow task changes to a specific status. To configure a Task Status Change notification, both the task and the status that will trigger the notification must be selected.
  - Checklist Question Change: Events triggered by response to a checklist question.
To configure an event, select the event(s) from the pick list and click "Add". The selected events will appear in the "Configured" table below the Select area.
Events are added in an inactive state. To activate a configured notification, check the box in the "Active" column, and click "Save". All configured notifications can be activated or deactivated simultaneously using the checkbox in the header label.

In some cases, integrators use the configurable "Subscription Nam" element in the payload to provide additional information about the event. To configure the subscription name:

Double-click the cell in the "Name" column associated with the notification to be edited.
Enter the Subscription Name in the editable text area.

Cells with unsaved changes are indicated by a red tag in the upper left-hand corner. Inactive notifications can be removed from the configuration by clicking the "Delete" icon on the far right-hand side.

Total count of active and configured notifications: Represents a number of active and configured notifications in the Notification Services Subscriptions area located in the Integration Center.

Notification Services Report

The "Notification Services Report," located in the "Notification Tools and Reports" section, enables users to search for individual notifications triggered within ScholarOne.

Filtering options for the Notification Services Report are shown in Figure 17 and include:

Consumer Journal: The ScholarOne site on which the consumer is configured.
- If the report is run from a portal site, all underlying sites will be available in this filter.
- If the report is run from a leaf site, only the site from which the report is run will be available.
Consumer: A consumer is a collection of one or more endpoints that subscribe to the same notification events. For example, endpoints for different environments (production, implementation, beta) for the same integration are typically grouped under a consumer.
Endpoint: The configured name of the specific URL to which the notification is sent.
Subscription: The subscribed event that triggers the notification, listed by Site name (site short name) and subscript name, if configured.
Message Status: Filters the report based on notification status. Possible values include: "Succeeded", "Pending", "Failed", "Cancelled", "Expired", and "Timeout".
Subscription Area: Filters notifications by Decision, Task Status Changes, or System Events.
Subscription Journal: The ScholarOne site on which the subscribed event will trigger the notification.
- For example, selecting "Client Test" will filter the report results to only notifications generated from events on the "Client Test" site.
- If the report is run from a portal site, all underlying sites are available in this filter.
- If the report is run from a leaf site, then the site from which the report is run will be the only available option.
Message ID: The unique identifier assigned to each notification message within ScholarOne. This field allows users to locate and track a specific notification message within the system.
Person ID: Filters report results to a specific individual based on the ScholarOne-generated Person ID. This identifier is used to track notifications associated with a particular user.
Document ID: Filters report results to a specific document based on the ScholarOne-generated Document ID. This identifier is used to locate notifications related to a specific document within the system.
Message UUID: The unique ID contained in the payload of each notification sent by ScholarOne. This field can be used to locate a specific notification if the UUID is known.
Submission ID: Filters report results to a specific submission based on the ScholarOne-generated Submission ID.
Create Date: Filters report results by a specific date range for when the notification was generated.

When reporting on notifications from a portal-level site, note that submission integrations often require numerous notifications to maintain data synchronization between ScholarOne and the external system. To optimize the user experience, use the filtering options to narrow the results returned in notification reports. This tool is designed to retrieve a subset of notifications, not all notifications sent between ScholarOne and an external system in a single report.

Results for the Notification Services Report are displayed in a paginated table, which allows users to sort by any of the column headers (Figure 18).

Data fields included in the report are:

Message UUID: The unique identifier provided by ScholarOne for each notification.
Create Date: The date and time when the notification was generated.
Status: The delivery status of the notification. Possible values include: "Succeeded", "Pending", "Failed", "Cancelled", "Expired", and "Timeout".
Subscription Area: The type of triggering event. Possible values are: "Decision", "Task Status Changes", or "System Events".
Next Process Date: For pending or failed messages, the date and time of the next delivery attempt.
Expiration Date: The date on which the notification will expire if delivery is unsuccessful.
Consumer Name: The configured name of the consumer associated with the notification's endpoint.
Endpoint Name: The configured name of the notification's delivery endpoint.
Subscription Name: The configured name of the triggering event. This field will be blank if no name is configured.
Document ID: For manuscript-related notifications, the associated system generated document ID.
Submission ID: For manuscript-related notifications, the associated manuscript ID.
Person ID: For account-related notifications, the unique person ID of the associated account holder.
Person Name: For account-related notifications, the name of the associated account holder.

The "Actions" column on the left side of the report contains two icons for each notification. The first icon (a magnifying glass) opens a window with detailed information about the notification, its payload, and delivery history. The second icon (an "X") allows users to cancel a notification that has not yet been successfully delivered.