The OAI-PMH module has a set of default configurations that are declared within config.properties file.
...
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.
...
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
| ||||||||
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 (srs or inventory) 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. |
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.