Skip to end of banner
Go to start of banner

Approach to update SRS MARC Records and corresponding inventory Instances

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Current »

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Requirements

Required to enable quickMarc updates.

Whenever an SRS MARC Bib record is updated, then the corresponding changes need to be made in the Instance fields that are controlled by the tenant's default map.

The default MARC Bib-Inventory Instance map may vary from tenant to tenant. Updates should be made based on the Instance fields mapped/controlled by the specific tenant's default map.

The FOLIO-supplied default MARC-Instance map: https://github.com/folio-org/mod-source-record-manager/blob/master/mod-source-record-manager-server/src/main/resources/rules/rules.json

Approach & Design

SRS is short for mod-source-record-storage

SRM or CM (Change Manager) can be used interchangeably and refer to mod-source-record-manager

SRM exposes the following endpoints for quickMarc to retrieve the MARC record by instanceId and to save the updated MARC record:

MethodPathPermissionsRequestResponseDescriptionNotes
GET

change-manager/parsedRecords?instanceId={instanceId}

change-manager.parsedrecords.getNA

200 OK

(ParsedRecordDto)

(A) GET MARC record{instanceId} - corresponding Instance id
PUT/change-manager/parsedRecords/{id}change-manager.parsed-records.put

Updated 

ParsedRecordDto

204 UPDATED (B) Update MARC record{id} - record id

SRS/SRM do not perform any validation of the updated MARC record, MARC Leader value should be recalculated on the quickMarc side

The actual update of the SRS MARC Record and the corresponding inventory Instance happens using pub-sub approach.

1) Upon receiving the request for update of the MARC record, a new QM_RECORD_UPDATED event is formed and published to mod-pubsub. Event payload contains the following data

  • PARSED_RECORD_DTO - received ParsedRecordDto containing updated MARC record
  • MAPPING_RULES - MARC-to-Instance default mapping rules
  • MAPPING_PARAMS - mapping parameters for populating reference data
  • SNAPSHOT_ID (optional) - new Snapshot id to which the updated MARC record will be linked

2) SRS is subscribed to QM_RECORD_UPDATED eventType. When SRS receives the event the following operations are performed:  

  1. a new Snapshot is created 
  2. a new Record is created with incremented generation value and state ACTUAL
  3. state of the original Record is set to OLD

Steps 2 and 3 are executed in transaction.

3) After the Record is successfully “updated” (records in SRS are not overwritten, new Record is being saved with higher generation, and all the others are marked as OLD), a new QM_SRS_MARC_BIB_RECORD_UPDATED event is published to mod-pubsub with payload:

  • MAPPING_RULES (received from SRM) - MARC-to-Instance default mapping rules
  • MAPPING_PARAMS (received from SRM)- mapping parameters for populating reference data
  • MARC - updated SRS MARC Record

4) mod-inventory is subscribed to QM_SRS_MARC_BIB_RECORD_UPDATED event. When event is received, a new Instance entity is mapped from MARC record using Mapper from data-import-processing-core library. The original Instance is retrieved from mod-inventory-storage, compared to the newly mapped one and updated accordingly.

  • No labels