Closed lwrubel closed 1 year ago
We can use the/holdings-storage/holdings
endpoint to POST holdings records.
Docs: https://s3.amazonaws.com/foliodocs/api/mod-inventory-storage/p/holdings-storage.html
To send a record with a permanent location ("1b14e21c-8d47-45c7-bc49-456a0086422b" is the UUID for SUL-SDR and it can't be null) and holdings type of electronic, here's an example:
{"holdingsTypeId": "996f93e2-5b5e-4cf2-9168-33ced1f95eed",
"instanceId":"99a6d818-d523-42f3-9844-81cf3187dbad",
"permanentLocationId": "1b14e21c-8d47-45c7-bc49-456a0086422b" }
Returns a 201 with a holdings record in the response. For example, when POSTing the above holdings_record:
{'id': '581f6289-001f-49d1-bab7-035f4d878cbd',
'_version': 1,
'hrid': 'ho00000000065',
'holdingsTypeId': '996f93e2-5b5e-4cf2-9168-33ced1f95eed',
'formerIds': [],
'instanceId': '99a6d818-d523-42f3-9844-81cf3187dbad',
'permanentLocationId': '1b14e21c-8d47-45c7-bc49-456a0086422b',
'effectiveLocationId': '1b14e21c-8d47-45c7-bc49-456a0086422b',
'electronicAccess': [],
'administrativeNotes': [],
'notes': [],
'holdingsStatements': [],
'holdingsStatementsForIndexes': [],
'holdingsStatementsForSupplements': [],
'statisticalCodeIds': [],
'holdingsItems': [],
'bareHoldingsItems': [],
'metadata': {'createdDate': '2023-03-07T20:33:56.382+00:00',
'createdByUserId': '297649ab-3f9e-5ece-91a3-25cf700062ae',
'updatedDate': '2023-03-07T20:33:56.382+00:00',
'updatedByUserId': '297649ab-3f9e-5ece-91a3-25cf700062ae'}}
Returns a 422 with an errors
key (or see other possible responses in the docs). For example:
{'errors': [{'message': 'Cannot set holdings_record.permanentlocationid = 1b14e21c-8d47-45c7-bc49-456a0086422c because it does not exist in location.id.',
'type': '1',
'code': '-1',
'parameters': [{'key': 'holdings_record.permanentlocationid',
'value': '1b14e21c-8d47-45c7-bc49-456a0086422c'}]}]}
@shelleydoljack does this sound right to you? BTW, I'm not sure what the best way to verify these UUIDs for permanent location and holdings type--I grabbed them from an existing record, and when I created a record the right names were visible.
You can get the different holdings types with GET /holdings-types. I guess "Electronic" is the one you will always want for this, so 👍 . With the location ID, again, you can do GET /locations. We have at least 400 locations, but you probably only want the locations where the primary service point is "Online" (${OKAPI_URL}/locations?query=primaryServicePoint==7c5abc9f-f3d7-4856-b8d7-6712462ca007
). Although, maybe it'd be better to do a query for stuff with "SDR" or "ELECTRONIC" in the name or code, such as ${OKAPI_URL}/locations?query=cql.allRecords=1 and name any "ELECTRONIC SDR"
. @ahafele I noticed that the coordinate library ELECTRONIC locations do not have "Online" as the primary service point. Should it be? But maybe the cql query to the locations endpoint is more exact for the location ID's that are needed to update 856's.
@shelleydoljack yes I think they should. I'll make a ticket to update these. I think in this context we are only concerned with SDR locations. I don't think you need to even include Electronic.
It looks like we also need to make the LAW-SDR, etc. locations, right @ahafele ?
Correct - we haven't done that work yet - https://github.com/sul-dlss/FOLIO-Project-Stanford/issues/252
For SUL-SDR, this looks like the location we'll want to use, based on a query for 'name any "SDR"'
:
{'locations': [{'id': '1b14e21c-8d47-45c7-bc49-456a0086422b',
'name': 'SUL SDR',
'code': 'SUL-SDR',
'discoveryDisplayName': 'SUL SDR',
'isActive': True,
'institutionId': '8d433cdd-4e8f-4dc1-aa24-8a4ddb7dc929',
'campusId': 'c365047a-51f2-45ce-8601-e421ca3615c5',
'libraryId': 'c1a86906-ced0-46cb-8f5b-8cef542bdd00',
'primaryServicePoint': '7c5abc9f-f3d7-4856-b8d7-6712462ca007',
'servicePointIds': ['7c5abc9f-f3d7-4856-b8d7-6712462ca007'],
'servicePoints': [],
'metadata': {'createdDate': '2023-02-08T23:38:05.776+00:00',
'createdByUserId': '7dc1ae38-1e06-4de9-ac86-568b9a2318ec',
'updatedDate': '2023-02-08T23:38:05.776+00:00',
'updatedByUserId': '7dc1ae38-1e06-4de9-ac86-568b9a2318ec'}}],
'totalRecords': 1}
The id in this location record is the same ID used in the code above (1b14e21c-8d47-45c7-bc49-456a0086422b
).
So, it sounds like the work is in progress to create the other locations, and once we also know the logic for determining which location goes with which item, then we can use them when updating the MARC and adding holdings records.
Closed with creation of implementation ticket #39.
This is in support of adding 856 fields to records being released/published.