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: false - suppressed record is ignored (skipped) by OAI-PMH and not going to Discovery Layer; true - all records are available for retrieval via OAI-PMH, suppression flag value is included into each record.	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: HTTP status 200 - OAI-PMH level error is associated with HTTP status 200 HTTP error status - OAI-PMH level error may be associated with HTTP error status (4xx or 5xx)	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.

Browser not supported