MARC 999 field: Put SRS UUID
RCA Group
None
Description
Environment
None
Potential Workaround
None
blocks
defines
relates to
Checklist
hideTestRail: Results
Activity
Show:

Ann-Marie Breaux May 3, 2019 at 2:27 PM
Terrific - thank you !

Igor Gorchakov May 3, 2019 at 11:44 AM
Hi , I attached parsed record in

Ann-Marie Breaux May 3, 2019 at 6:45 AM
Hi Could you attach a record/JSON file showing the parsed MARC record with the new 999 field? That would be really helpful. Thank you!

Ann-Marie Breaux April 22, 2019 at 6:12 AM
looks good - thank you! And I also linked MODSOURCE-96, which will add the MARCcat UUID into the 999 field. That one is blocked until we can start work on integration between SRS and MARCcat

Igor Gorchakov April 21, 2019 at 6:20 PMEdited
Hi , you are right. It's better to construct '999' in 2 Jira-tickets because of source-record-manager's algorithm nature. This story is only about putting SRS UUID into '999'. The new story for putting Inventory instance UUID is on its way : https://folio-org.atlassian.net/browse/MODSOURMAN-100
Done
Details
Details
Assignee

Reporter

Priority
Story Points
5
Sprint
None
Development Team
Folijet
Fix versions
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created April 19, 2019 at 12:46 PM
Updated February 2, 2021 at 10:45 PM
Resolved May 7, 2019 at 11:01 AM
TestRail: Cases
TestRail: Runs
We need to generate UUID for every parsed record in source-record-manager and reuse UUID to construct 999 field (actually UUID is generated in mod-source-record-storage for each received parsed record).
The UUID for parsed records should be generated in source-record-manager before parsed records are being posted into source-record-storage. Once a raw records are transfigured into parsed records, we can reuse UUID to created and fill 999 field for each.
Development notes:
Actual algorithm of how source-record-manager processes raw records (ChunkProcessingService):
1 saves raw records into source-record-storage;
2 updates job fields (status, runBy, progress, started date);
3 transforms raw records into parsed records using marc4j, saves parsed records into source-record-storage;
4 creates new Inventory instance for each parsed record;
5 sets out 'State' field to received chunk;
6 checks if processing completed;
Expected algorithm of how mod-source-record-manager should process raw records (ChunkProcessingService):
1 saves raw records into source-record-storage;
2 updates job fields (status, runBy, progress, started date);
3 transforms raw records into parsed records using marc4j, generates and puts UUID for each parsed record, does not save parsed records into SRS;
4 creates new Inventory instance for each parsed record;
5 puts UUID from step 3 into '999' field to each parsed record, saves parsed records then into source-record-storage(should be new method in ChangeEngineService);
6 sets out 'State' field to received chunk;
7 checks if processing completed;
Finally '999' should look like this:
Tag: 999
Indicator 1: f (lower-case letter f)
Indicator 2: f
Subfield s: SRS UUID
999 ff$s<SRS UUID>