Title-level request scenarios
A title-level request is placed. An item is available. A page request is created for that item. The item is located and the request is fulfilled.
A title-level request is placed. An item is available. A page request is created for that item. The item cannot be located. The request status remains Open until the item is located, or, in perpetuity.
A title-level request is placed. There is no item available to be paged. A hold request is placed. The staff looks for an un-inventoried item. An item is located and the request is fulfilled.
A title-level request is placed. There is no item available to be paged. A hold request is placed. The staff looks for an un-inventoried item. An item cannot be found. The request status remains Open until the item is located, or, in perpetuity.
Solution Design
Component diagram
Module mod-search in the Central tenant has the merged information about all instances (as well holdings and items), and in which tenants those instances are available
In the diagram, the “Some other FOLIO module” module called mod-tlr is located in the Congressional Tenant, but in general, it can be located in any tenant in the consortium
The case when ECS TLR starts from the Data Tenant
The case when ECS TLR starts from the Central Tenant
Sequencing
Work Breakdown Structure (draft, in man-days)
Task | Details | Estimates, workdays |
---|---|---|
Accept ECS TLR, store it, search for Data tenants available, search for an item available for fulfillment (Сrawl phase) | ||
Create a new backend Spring-based module mod-tlr | Create a new repo, and add it to building/deployment pipelines Note: this is the 1st Spring-based module for the team | 5 |
Create a database schema for storing ECS TLR requests |
| 5 |
Add API endpoints for TLR mgmt and CRUD support |
| 5-10 (it depends on if this can be implemented in a Spring-based module) |
Implement a timer for triggering internal actions | 3-5 | |
Implement a call from mod-tlr to mod-search to retrieve a list of tenants by instanceId |
| 3-5 |
Implement logic for analyzing data from the mod-search and choosing which tenant to place the Single tenant TLR request to |
| 3-5 |
Implement a call from the Central tenant’s mod-tlr to the Data tenant’s mod-circulation |
| 3-5 to make an API call + 3-5 to address questions with service points and circulation rules |
Add Kafka integration |
| 5-10 ( need to implement event publishing in mod-circulation and consumers/listeners in mod-tlr) |
Transaction initialization in mod-dcb |
| 3-5 |
Update mod-dcb |
| 3 |
Update mod-circulation |
| ? |
mod-tlr - Orchestration phase |
| 3-5 |
ui-requests | Since we need to be able to place an ECS TLR request directly through UI, ui-requests need to be able to support this
|
Other considerations and assumptions
Do we need a separate UI for ECS TLR? - No. A TLR request created in the Central Tenant will be available in the Requests App in exactly the same way as other requests. The TLR request created in the Data Tenant will also be visible. In this case, both will be maintained in a consistent state using mod-dcb. At the same time, the ECS TLR entity, which will be stored and processed in mod-tlr, is a service entity that helps organize the work of the platform, and end users do not need to work with it.
Can Central Tenant have its own collections/inventory?
Can a Data Tenant cancel a TLR request? Do we want to avoid this?
Currently, when creating a TLR in mod-circulation through a discovery endpoint, settings are applied that regulate the creation of a Hold type TLR. This can be done through a policy, or some special flag, or you can add logic in the program code. We need to remember to pay attention to this later
mod-dcb and mod-circulation-item - assumption: no additional work will be required in this regard
Multi-tenant TLR issues
Scenario: any TLR
Single-tenant env behavior: Circulation rules and item statuses are checked in order to determine which TLR types (Hold, Page, Recall) are available
Multi-tenant env issues:
Each tenant needs to be checked separately, because each tenant may have different
items (and their statuses, which can affect available request types)
circulation rules
TLR settings (enabled/disabled)
location structure (important for TLR Page)
already existing open requests and loans (important for not allowing duplicates + affects TLR Recall)
Scenario: TLR Hold
Single-tenant env behavior: The first item that gets checked in fulfills the request
Multi-tenant env issue: mod-circulation in TenantA knows nothing about an item checked in in TenantB, the request in TenantA won't be fulfilled
Scenario: TLR Page
Single-tenant env behavior: The request is fulfilled by the item that is the closest to the Pickup Service Point (https://wiki.folio.org/display/DD/TLR+-+picking+an+item+for+Page+request )
Multi-tenant env issues:
In case when TenantA has 0 Available items, TLR Page placed in TenantA will fail even though TenanB might have Available items
mod-circulation in TenantA knows nothing about available items and location structure in TenantB => TLR Page placed in TenantA may be fulfilled with an item that is not the closest to the Pickup SP
Scenario: TLR Recall
Single-tenant env behavior: The loan with the closest due date will be recalled
Multi-tenant env issue:
In case when TenantA has 0 loans, TLR Recall placed in TenantA will fail even though TenantB might have open loans
mod-circulation in TenantA knows nothing about loans in TenantB => TLR Recall placed in TenantA may be fulfilled with an item that is not on the closest-due-date loan