Fix Alma ILS driver to get status only for numeric record IDs

[stweil]

No description provided.

[EreMaijala]

Alma's REST API defines the mms_id as a string. Even if the identifiers currently contain only numbers, it'd be dangerous to assume that's always going to be the case.

[stweil]

Nevertheless the Alma REST API throws an error like "Input parameters mmsId MADOC71291 is not numeric" if it gets a non-numeric mmsId.

It looks like all records which were imported as MARC21 are handled by the Alma ILS driver. Without this patch, I cannot import records from our EPrints OAI-PMH with format marc21, but have to use the format oai_dc which gives less information (https://madoc.bib.uni-mannheim.de/cgi/oai2?verb=ListMetadataFormats). When I import marc21, the search results show errors, and an individual search results claims that the ILS is not operational because the Alma ILS driver throws an exception.

What would you suggest to handle this? Ideally MARC21 records which were not imported from Alma should not trigger an Alma status query later. Refusing such queries in the Alma driver is only the 2nd best solution, but I think it is a valid solution: if Ex Libris had plans to introduce non-numeric mmsIds, the error message would simply say that an ID like MADOC71291 is unknown.

[stweil]

See also the official documentation which describes the mms_id.

[EreMaijala]

@stweil As far as I can see, the documentation you linked to just describes the current structure. And while Alma may internally limit the format of the IDs, the API does not. See e.g.

• https://developers.exlibrisgroup.com/alma/apis/docs/bibs/R0VUIC9hbG1hd3MvdjEvYmlicy97bW1zX2lkfQ==/#urlParameters
• https://developers.exlibrisgroup.com/alma/apis/docs/xsd/rest_bib.xsd/?tags=GET#bib

Let's use the related Slack thread to discuss further options.

[demiankatz]

This PR hasn't moved in a few months. @stweil, did you find a different solution to your problem? Should we close this and/or replace it with a different approach, or do you still want to move forward as-is?

[stweil]

Thanks for the reminder. I still use this solution in our test installations. But maybe a better solution is possible.

As far as I see, the problem exists because VuFind handles any MARC21 imports as ILS imports – maybe not only for Alma, but for any ILS. Therefore I get this problem when I import EPrints records as MARC21 reocrds, but not if I use a different kind of import.

Using the MultiBackend driver does not look like the correct solution for me, because there is only a single ILS (EPrints is not an ILS).

Maybe the MARC21 import can be enhanced with an option which tells VuFind whether the records come from the ILS or not? I still have to find out whether such a solution is possible.

For non-ILS records – especially for electronic media like EPrints – there is typically no need for a status query. So would it be possible and reasonable to avoid such queries for certain media types, no matter which ILS is used? This would also solve the problem. For Alma, it would also have a desired side effect because the (limited) number of API calls would be reduced.

[demiankatz]

@stweil, I may have suggested this before, but one relatively simple approach would be to create a SolrMarcWithoutILS driver that subclasses SolrMarc, and configure it in the plugin manager to omit the IlsAwareDelegatorFactory. Then you could use the recordtype field to control which driver gets used for the non-Alma records. This would effectively disable ILS functionality for a subset of records based on indexing. As discussed on Slack, the disadvantage to any of these solutions is that they don't prevent ID collisions, but as long as your circumstances guarantee that all IDs are always unique, it should be workable.