Introduction to mod-oai-pmh configurations
- Illia Daliek
- Anastasiia Zakharova
- Dmytro Popov
The OAI-PMH module has a set of default configurations that are declared within config.properties file.
They are the next as presented in the table below.
| Config name | Default value | Supported? | Description |
repository.name | FOLIO_OAI_Repository | yes | Describes the repository name and used for constructing value for OAI-PMH/Identify/repositoryName element. Actually used only for getting repository info via GET /oai/repository_info request. |
repository.baseURL | http://folio.org/oai | yes | The URL of the repository (basically the URL of the edge-oai-pmh). Takes place in record identifier composing: http://folio.org/oai → oai:folio.org:{tenantId}/{recordId}. As well the value is used in OAI-PMH/Identify/baseURL element. |
repository.adminEmails | oai-pmh@folio.org | yes | Email list of repository administrators, if more than one declared then these emails should be separated by comma. |
repository.timeGranularity | YYYY-MM-DDThh:mm:ssZ | yes | Defines the granularity level of date fields in response, would be it composed only from the date only or with the time as well. Values supported: YYYY-MM-DD; YYYY-MM-DDThh:mm:ssZ. |
repository.deletedRecords | no | no | Defines in which manner the deleted records are treated by repository, will be it persisted, transient or not supported as well. Since records deletion haven't been implemented yet, the property doesn't affect module flows. |
repository.maxRecordsPerResponse | 100 | yes | Sets the number of records returned in the List responses. |
jaxb.marshaller.enableValidation | false | yes | Allows to enable(true value)/disable(false val.) validation of response content against xsd schema if present. |
jaxb.marshaller.formattedOutput | false | yes | Allows to enable(true value)/disable(false val.) formatting the linefeeds and indentations of XML data. |
| repository.storage | SRS | yes | Defines which storage should be used to get records from. This configuration is not tenant specific, but system wide therefore cannot be defined in mod-configuration module. There are 2 allowed values: SRS (mod-source-record-storage) and INVENTORY (mod-inventory-storage). The default value for this is SRS, for enabling mod-inventory-storage as record storage the -Drepository.storage=INVENTORY VM option should be specified. |
What default values mean and which values actually are used.
The values are default by the reason that each time when the request comes to any of OAI-PMH endpoints there are another request takes place to mod-configuration to retrieve config values from it before processing the initial one. If mod-configuration didn't return within response the config value, then the value is taken from system properties that declared in config.properties file as mentioned earlier. Declared jaxb config's and repository. storage configuration are taken only from system properties, therefore they aren't requested from the mod - configuration.
Configurations to be implemented
| Config name | Allowed values | Description | T-shit size estimation |
|---|---|---|---|
| Resumption token expiration | Depends from implementation details. For instance If int value will be used then - from 0 up to 2 147 483 647. In case of 0 value property will be considered as disabled. | The period of resumptionToken validity, after which it expires. It can be set to empty value, so expirationDate of the resumption token is undefined. Or validity period in hours may be specified. | S Such token just requires to be verified on its validity and if it does, then just continue the request processing. In opposite case return appropriate response with corresponding feed. But investigation how to track the token expiration are required, will be it stored within a database or in other ways. As well, this token is generated based on OAI-PMH request and response from particular record storage (so it includes offset, limit, total records, date stamps and etc.) and creation date in theory may be put to token generation part as well and therefore can be used for checking token expiration, but deeper investigation here is needed (token generation algorithm). |
| Mapping profile (instance/holding/item) | - | Chosen data export mapping profile, where Inventory-MARC conversion rules are specified. Used only for Inventory records. If no profile is defined for the record type, mapping rules are used (instance and holding records) or records aren’t transferred at all (item records). | Mapping profiles to be implemented by Concorde team MDEXP-85 - Getting issue details... STATUS |
| Suppressed records transferring | true/false | Defines in which way suppressed records are going to be processed:
| M It requires to just filter results that is grabbed from particular record storage but filtering process can be complex as long as different record parts may by supressed(instance, holding, item and etc). |
| Errors processing | true/false | Defines in which way OAI-PMH level errors are going to be processed:
| S At each endpoint after code processing of request there is a place where exceptions are handled and corresposnding http status is put to response. So, it will not be a challenge to impelement such configuration since this can be done in one place. |
| Cache warming periodicity | true/false | The periodicity of pre-generated OAI output can be configured. If cache warming isn’t scheduled, it doesn’t happen. | M/L Suppressed records transferring (SRT) config may occur impact on implementation complexity since different data sets will be responded in depens from SRT value. |
| repository.storage | true/false | There are 2 allowed values: SRS (mod-source-record-storage) and INVENTORY (mod-inventory-storage). | S For now value for such config isn't set up at all. The code composed in the way if the repository.storage hasn't any value, then SRS is used. Thus is why the SRS is "default" value here. So, the code should be refactored in a way that appropriate storage will be used dependently from the value that should be stored within mod-configuration. Since such code change may be done in one place the implementation will be easy. |
| Enable OAI service | true/false | Defines whether an OAI-PMH module is accessible in the repository. If unchecked, then all other OAI-PMH settings are disabled | S/M Here it requires just to verify this property before the main request logic processing and if it enabled, then some variant of response with appropriate information should be sent to harvester to inform him that service doesn't work now. The only complexity here is to establish what kind of behaviour would be better(response format). From code side i'd prefer to estimate it like 3-5 story points. |
Tips and tricks
1) The system default values can be overwritten by VM options.
Example: -Drepository.name=Example_OAI-PMH_Repository
2) It is possible to specify another configuration file throght -DconfigPath=<path_to_configs>. Important to note that file should be accessible by ClassLoader.