Record Contribution: Process contribution or update Jobs of Items to an INN-Reach central Server

Purpose/Overview:

Add functionality to the job queue for processing contribution of Bibs (MODINREACH-51) to enable contribution of appropriate items via defined D2IR API endpoints.

Requirements/Scope:

• Add functionality to the queue that processes job definitions and contributes or updates specified Instance records as INN-Reach Bibs to a central server based on existing settings configuration for record contribution (MODINREACH-42, MODINREACH-49) to enable the processing and contribution (according to record contribution configuration settings) of associated item records. Items should be indicated for processing via associated instance record or directly.
  • If job definition is "update-only" skip the next requirement and just attempt to update the holdCount, itemCircStatus, or dueDateTime for the item(s) using the update APIs
    • There are no APIs for checking the contribution status of an item record, so the system will need to handle errors returned by the central server and log them appropriately.
• Indicated records are evaluated for exclusion from contribution, suppression from central discovery, or contribution as system-owned (MODINREACH-42)
  • If more than one relevant statistical code is defined on the item record, this is an error and the record should be skipped and the error logged.
  • Relevant statistical codes defined on parent holdings records should also be considered when evaluating records for contribution, but codes defined on the item record take precedence
    • e.g. If the statistical code assigned the holdings record indicated contribute but suppress, but the item statistical code indicates to not contribute the record, the item statistical code is controlling
  • If multiple items are associated with an Instance that is being contributed as a Bib to the central server, then we should attempt to use the batch item contribution APIs (INN-Reach D2IR API Reference v2.3.pdf, pg. 27)
  • Contributed item records should have the following fields data attributes mapped form the FOLIO Item record (all fields required except as indicated). See D2IR documentation, pg. 28 for details:
    • itemId: FOLIO Item HRID
    • agencyCode: based on Library to Agency code mapping in Central Server Configuration settings
    • centralItemType: based on FOLIO material type to Central Item Type mapping settings (MODINREACH-44)
    • locationKey: based on FOLIO location to INN-Reach location mapping. Location must be contributed to the central server BEFORE the item can be.
    • itemCircStatus: one of "Available/Not Available/On Loan/Non-lendable"
      • Available = Requestable according to the request whitelist
      • Not Available = Not requestable according to the request whitelist
      • On Loan = Checked out
      • Non-lendable = N/A (future feature: setting to enable admins to specify criteria for considering an item non-lendable, eg. loan/material types or locations)
    • holdCount: number of local requests on the item (not required on contribution)
    • dueDateTime: current due date, if checked out, as UNIX epoch timestamp (not required on contribution)
    • callNumber: Item effective call number, max 128 characters (not required)
    • volumeDesignation: (not required)
    • copyNumber: (required if non-zero)
    • marc856URI: If there is an online access URL on the item record that is different from the URL of the associated MARC bib record, include it here
    • marc856PublicNote: Maximum 64 characters, include if sending previous field
    • itemNote: Maximum 256 Characters, not mapped yet
    • suppress: ASCII "y" or "n" based on statistical code or item suppress from discovery flag
  • Errors are logged with sufficient detail to indicate which FOLIO record was being processed when the error occurred and at what stage in the process, but errors do not terminate the job
• Process is repeated until all indicated records have been processed for each job
• Queue is evaluated until all jobs have been processed
• Jobs should be able to be paused
  • The pause is logged, including the user who paused the job
• Jobs should be able to be resumed
  • Resumed jobs are added to the end of the queue
  • Resumption is logged, including the user who resumed the job
• Jobs should be able to be cancelled
  • Job cancellations are logged, including reference to the user who cancelled the job
• The status of a job should be reportable via API call
• Job log should be retrievable via API in JSON format
• Job log should include an array of FOLIO inventory IDs that experienced errors during processing or contribution

Acceptance Criteria:

• AC: Properly structured job definition payloads can be posted to the queue
• AC: Jobs defined as "update only" only update the itemCount and titleHoldCount for Bibs already contributed
• AC: Jobs can process an arbitrary number of records without causing the entire module host to become unresponsive
• AC: A detailed log of FOLIO instance records processed, held back from contribution or that experienced an error during processing or contribution should be generated for each job
• AC: Log is retrievable by anyone with permission to manage jobs
• AC: Queued jobs are processed in the order generated
• AC: Resumed jobs are moved to the end of the queue when resumed
• AC: All valid FOLIO instances with associated MARC records in SRS that are not excluded from contribution by module settings are properly transformed and successfully contributed to the central server
• AC: Errors returned by the central server when attempting to contribute or update an item are logged in the job log
• AC: All FOLIO item ids that are not successfully processed or contributed as items due to errors are included in an array in the generated JSON log file