This This document will illustrate how search will operate in a consortium using a central index for all members of a consortium.
...
Name | Description | Index Name |
|---|---|---|
shared | boolean value signaling where the corresponding FOLIO object is shared. Three values should be possible True, False & empty string. | Instance |
tenantId | identifier of the tenant that owns the document. Even though documents will be in the consortial tenant index, those document still need to indicate their originating tenant. | Instance(should also be added to holding & item sub-objects of the instance), Contributor, Instance Subject, Authorities |
FOLIO Tenant Module Configuration
...
When mod-search determines a recent update to a FOLIO objects and in the tenant is in a consortium, it will determine the central tenant identifier for the consortium. If the tenant is in a consortium, it will populate the central index(index belonging to the consortial tenant) and corresponding FOLIO object. The central index will be populated instead of the standard index that a regular tenant would own.
insert the object payload into a table in the central tenant. In addition, a Kafka message is sent to a topic which is consumed by a Consortium Indexing Handler to get the inserted payload, together with other records that would constitute a single index document. The index document is inserted into index owned by the central tenant.
Payload retrieved from mod-inventory will be stored in two tables in the central tenant, consortium_instances and consortium_authorities. Both tables will have the following columns
| Column Name | Column Description | Column Datatype |
|---|---|---|
| tenantId | tenant Identifier | varchar |
| instanceid | instance identifier | UUID |
| json | payload | JSON(NOT JSONB) |
| created_date | created date | date |
| updated_date | updated date | date |
| Info |
|---|
The primary key for the table should be tenantId & instanceId. There should also be an index on instanceId. |
Consortium Indexing Handler
The consortium indexing handler will rebuild an instance when the instance or its holdings and items are created/updated.
General steps for the indexing handler as follows:
Consume a message from CONSORTIUM_SEARCH_UPDATES Kafka topic
This would indicate whether an instance or authority is updated.
For an updated instance, objects are retrieved from consortium_instances table by instanceId.
This can return more than one object; a Shared Instance in the central tenant and its Shadow Instances.
A whole new payload is created with the Shared Instance as the starting point. Holdings & items objects are copied from Shadow Instances into the holdings & items properties of the Shared Instance.
The new payload is processed like any instance payload retrieved in a non-consortia deployment of FOLIO.
Processed payload is indexed into the search engine.
The instance document schema currently fields such as holdingsIdentifiers, holdings, itemsIdentifiers, items. A Shared Instance lives in the consortial tenant while Shadow Instances live in member tenants. Both Shared Instance and it Shadow Instances will have the same UUID. FOLIO users are allowed to have holdings and items on the Shadow Instances only. When an Holding or Item is updated on a Shadow Instance, mod-search will post the update to the index document representing the Shared Instance in the central index belonging to the consortial tenant.
...
Name | Values | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Shared |
| ||||||||||||
Held By |
|
Active Affiliation
A new query parameter “The active _ affiliation “ will be added to signal the active affiliation for a search request. Its valid values will be identifiers of tenants in the consortiumof a search request will be tenant context with which a search request is made. A “Local Record” can be different depending on the active affiliation for the search. For example, If there are three records in mod-search: Consortial Tenant Record, Tenant A Record & Tenant B Record.
An active affiliation of “Tenant A” means that Consortial Tenant Record is a shared record and Tenant A Record is a local record while Tenant B Record is not returned by mod-search.
An active affiliation of “Tenant B” means that Consortial Tenant Record is a shared record and Tenant B is a local record while Tenant A Record is not returned by mod-search.
An active affiliation of “Consortial Tenant” means that Consortial Tenant Record is a shared and local record while Tenant A Record & Tenant B Record are not returned by mod-search.
...
.
...