Skip to end of banner
Go to start of banner

UXPROD-4559 ECS with cross-tenant circulation enabled

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

UXPROD-4559 - Getting issue details... STATUS

Title-level request scenarios

  1. 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.

  2. 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.

  3. 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.

  4. 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

  • to store ECS TLRs (entity describing the initial information about the request - instanceId, date-time, info from mod-search, tenant IDs it works with, …)

  • to be able to track statuses

  • to track ECS TLR and one-to-many relations to single-tenant TLRs

  • (warning) Need to design data schema(-s) - this will appear along with WBS

  • (warning) Need to design a set of ECS TLR statuses

  • Liquibase

5

Add API endpoints for TLR mgmt and CRUD support

  • create ECS TLR request

  • read ECS TLR request by ID

  • update ECS TLR request by ID

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

  • This is where we can start with the simplified logic first and postpone a more sophisticated approach to the Walk phase. E.g., the proposed option may look like this: get a list of tenants and information about how many items are in each of them. If there is only one tenant on the list, we work with him. If there are several tenants in the list, we select the one with the most items (this increases the likelihood of finding an item) and work with it

  • Update ECS TLR with a chosen tenantId

  • Need to design 1-to-many relation between ECS TLR and single-tenant TRL

3-5

Implement a call from the Central tenant’s mod-tlr to the Data tenant’s mod-circulation

  • Assumption: the TLR-support feature flag is enabled in the Data tenant’s mod-circulation

  • We can use one of the two following API endpoints - the one used for the Front-end (exact TLR request type needs to be specified), or the other used for requests from discovery (TLR request type can be defined as a result of Page/Recall/Hold selection). The second one is more appropriate for the Crawl phase though we would need to implement something else in the Walk phase. The option with sequential selection Page/Recall/Hold is very good for the first phase. Subsequently, the following logic can be implemented: make a Page request to each tenant (one by one) and check whether the item can be taken right now. If it fails, try a Recall request to each tenant and wait until you succeed. If it fails, make a Hold without an expiration date and wait until the item appears somewhere.

  • Since there is an explicit requirement that non-fulfilled Congressional Loan requests remain open in perpetuity, the expiration period must be set without restrictions or have some significant value (this will be clarified later, in the process of more detailed analysis).

  • In a regular single-tenant installation, when creating a TLR request, you can specify its type. In this case, a list of possible types and associated service points is formed on the back-end by searching through all known items and checking the circulation rules for them. In the case of ECS TLR, information about items and rules may not be available at the time the request is created. So the Page/Recall/Hold sequence seems justified in this case.

  • (question) What pick-up service point should be specified and used for TLR requests? (pre-defined? or one from the list of all available service points?) (warning) The requester should specify a pickup service point however the Data tenant can be not aware about it so it’s required to mock it somehow (note: mod-dcb does the same as a part of DCB transaction)

  • (question) How to specify circulation rules for such a request? Can we assume that the circulation rules are the same for the whole LoC? Using the Data tenants' circulation rules is the most straightforward option (this is how it will work if we do nothing)

3-5 to make an API call

+ 3-5 to address questions with service points and circulation rules

Add Kafka integration

  • For Page/Recall types of TLR we will have the item ID immediately in the response, so won’t need to wait

  • For Hold we would need to listen to a Kafka topic for events related to single-tenant TLR request status changes - it should change to OPEN In transit

5-10 ((warning) 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

  • when creating a request for an item, mod-circulation needs to learn to accept an optional parameter with a TLR ID, and if it is present, learn to find the corresponding TLR and use it instead of creating a new request

  • (warning) review the process of communication between mod-dcb and 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

  • new setting

  • call to mod-circulation (for Data Tenant) or to mod-tlr (for Central Tenant)

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.

  • (question) Can Central Tenant have its own collections/inventory?

  • (question) 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

  • No labels