Technical approach for update MARC Bib fields controlled by related Authority records
- 1 Overview
- 2 Solutions
- 2.1 Option 1
- 2.1.1 Brief overview
- 2.1.2 Pros / Cons
- 2.2 Sequence Diagrams
- 2.2.1 High Level Flow
- 2.2.2 Low Level Design
- 2.2.3 Messages Body
- 2.2.3.1 inventory.authority
- 2.2.3.2 links.authority.instance
- 2.2.3.3 srs.authority.bib
- 2.2.3.4 inventory.authority.bib.stats
- 2.2.4 Implied Changes per module
- 2.2.5 Current specifics
- 2.2.6 Concerns
- 2.3 Reporting
- 2.1 Option 1
- 3 Phase 2. Calculation of the anticipated time for updating of bibs
- 4 Defined Flows
- 5 Delivery Plan
- 6 LOE
- 7 Phase 3. Performance optimization approach
- 8 TBD
- 9 Rationale
Overview
Concise problem sounds as next: "Find a solution to update MARC Bib fields controlled by related Authority records, w/o significant impact on performance".
High performance is considered as an Architectural Significant Requirement for this technical approach.
Solution touches the next modules: mod-source-record-storage, mod-inventory-storage, mod-entities-links
Jira links
https://folio-org.atlassian.net/browse/ARCH-23
Current Data Flow Diagram
Solutions
Option 1
Brief overview
Start update links on import of authorities completion (on mod-inventory-storage level).
Pros / Cons
Modules | Pros | Cons |
|---|---|---|
source-record-storage |
| Extra logic and computation efforts to consume and handle messages from entities links module one by one (by authority) to update corresponding bib records and notify inventory storage about instance updates |
entities-links |
| Needs to determine and filter those authority records where specific fields are not updated (1XX or 010 $a) to exclude from further process flow [NEG. IMPACT: excessive computations on mod-entities-links side] |
inventory-storage | proceed with one generic message on update authorities for both mod-search and mod-entities-links |
|
entities (not links) consistency between modules: SRS and inventory |
| |
Others / All | import process could be divided on two phases - entities update (Phase 1) and links update (Phase 2). Thus links update could be considered as a separate process and there will be no impact on Phase 1 (actual import of entities) |
|
Sequence Diagrams
High Level Flow
Low Level Design
Messages Body
inventory.authority
{"old": {...}, // the entity state before update or delete"new": {...}, // the entity state update or create"type": "UPDATE|DELETE|CREATE|DELETE_ALL", // type of the event"tenant": "diku", // tenant id"ts": "1664881538352" // timestamp of the event}
links.authority.instance
{
"jobId": "...", // TBD field to track context within which update of linked bib records performed"authorityId": "...", // updated authority id"instanceIds": [], // string list of linked instance ids to updated authority
"tenant": "diku", // tenant id
"updatedAuthorityFields": [
"<Tag>": { // e.g. "100" "subfields": [ { "a": "Mozart, Wolfgang Amadeus," }, { "d": "1756-1791." } ... ] }, ... ]}
srs.authority.bib
{"old": {...}, // the entity state before update or delete"new": {...}, // the entity state update or create"type": "UPDATE", // type of the event"tenant": "diku", // tenant id