[Spike] Displaying retrieval service points for all member tenant requests in the central tenant

Hi @Irina Pokhylets , @Kalibek Turgumbayev
There are two proposed methods for implementation:

Method 1 - Implementing without the use of mod-search API to retrieve location data for the Data Tenant from the Central Tenant:

1. In the construction of the primary request JSON within mod-tlr, include the item representation which encompasses details about the item's effective location and retrieval service point. There is no requirement to store the effectiveLocationId within mod-circulation-item; continuation with the default DCB location storage is advised.

2. Within mod-circulation, the primary request will utilize the DCB location by default to conduct request formalities, but the retrievalServicePointName and itemEffectiveLocation will be derived from the Primary Request's initial representation, thus eliminating the need for location fetching.

3. A major challenge is the update/replace request process when details of the primary request are not passed containing the retrievalServicePointName and itemEffectiveLocation and this might get lost once the request is updated. This can be addressed within the mod-circulation code by retrieving the original primary request from the database and restoring the itemRepresentation before any updates to the request.

4. Assuming that the Primary Request represents the sole request type for the Central Tenant, it is unnecessary to introduce a feature flag; instead, the existing ecsRequestPhase value can be reused.

5. This method may not be the cleanest and could face challenges if the use cases for updating this Primary Request expand.

6. Backend Module changes are required in mod-tlr and mod-circulation. Estimated complexity ranges from medium to large.

Repository links:

• https://github.com/folio-org/mod-circulation/pull/1547/files

• https://github.com/folio-org/mod-tlr/tree/investigate_circ-2259

Method 2 - Implementing with the use of mod-search API to retrieve location data for the Data Tenant from the Central Tenant:https://s3.amazonaws.com/foliodocs/api/mod-search/s/mod-search.html#tag/search-consortium/operation/getConsortiumLocations

1. In mod-tlr, when creating a virtual item in mod-circulation-item, store the effectiveLocationId in the database.

2. In mod-circulation, when creating the primary request, utilize this effectiveLocationId from circ-item and retrieve the location using mod-search API either from the Central Tenant or, if unavailable, from this API https://s3.amazonaws.com/foliodocs/api/mod-search/s/mod-search.html#tag/search-consortium/operation/getConsortiumLocations

3. This approach ensures the primary request includes necessary details of effectiveLocation and retrievalServicePoint (PrimaryServicePointID).

4. While it's uncertain what the implications might be of using the Data Tenant’s location Id when creating the primary request, but maybe DCB location ID could be used as its done for today to determine the loanPolicy details.

5. When the primary request is updated it will go through almost the same cycle to determine the retrievalServicePointName and itemEffectiveLocation from the circ-item and mod-search api, therefore not to worry about loosing this data on an update.

6. Backend module changes would include mod-circulation-item, mod-circulation, and potentially mod-tlr. The estimated complexity could probably be of large tshirt size (might need +5 if some complications appear up).

Approach 2 is favored for its clarity and simplicity, although complexities might arise during actual implementation. The provided estimates are based on the best understanding of Primary Request flow as I believe that will be the only request for which the changes are required in Central Tenant side to use the retrievalServicePoint filter.
CC: @Steve Ellis , @Tetiana Gusar

@Alexander Kurash – pls add your comments or suggestions if any