Spike: MODKBEKBJ-267 - Use new HoldingsIQ endpoints with multiple staging areas and Delta Reports

Owned by Andrii Paias (Deactivated)
Last updated: Jan 08, 2020
2 min read

MODKBEKBJ-267 - Getting issue details... STATUS

The main goal of this spike is to investigate how we can use new HoldingsIQ endpoints to load only new changes for holdings, instead of loading the entire snapshot each time.

1) Sequence Diagram of proposed new process


The process will be very similar to the current one (described in Spike: MODKBEKBJ-255 - Harden process to load holdings ).
But it will have few differences:

1) To get status of most recent snapshot we need to get a list of recent transactions from "GET /{custid}/reports/holdings/transactions",

and then get the status of most recent transaction by calling "GET reports/holdings/transactions/{id}/status"

2) If most recent snapshot is too old then to create new snapshot we need to call "POST /reports/holdings" and store transactionId

3) LoadServiceFacade needs to return transactionId after snapshot is created (by calling HoldingsService#snapshotCreated and sending id in the message)

4) transactionId for previously loaded snapshot has to be stored in database, so that it's possible to create delta between new transactionId and previous transactionId.

If snapshot wan't previously loaded then it's possible to fallback on old logic, we just need to load holdings from  "GET /reports/holdings/transactions/{transactionId}", instead of from "GET /holdings"

5) LoadServiceFacade#startLoading now needs to first create a delta by calling "POST /reports/holdings/deltas" and then waiting for "GET reports/holdings/deltas/{id}/status" to return status "COMPLETED".

It also needs to use new endpoints "GET /reports/holdings/deltas/{deltaReportId}" to load changes, for each page of loaded changes it will call HoldingsService#processChanges.

6) Currenlty HoldingsService saves holdings in batches by calling "HoldingsRepository#saveHoldings", new HoldingsService#processChanges will call batch methods "saveHoldings", "updateHoldings" or "deleteHoldings", depending on the type of change.

Possible types of changes are "HOLDING_ADDED, HOLDING_UPDATED, HOLDING_DELETED, HOLDING_UPDATED_ADDED_COVERAGE, HOLDING_UPDATED_DELETED_COVERAGE".

For HOLDING_ADDED call saveHoldings.

For HOLDING_UPDATED, HOLDING_UPDATED_ADDED_COVERAGE, HOLDING_UPDATED_DELETED_COVERAGE call updateHoldings

For HOLDING_DELETED call deleteHoldings

7) folio-holdingsiq-service needs to be updated with all new endpoints from https://developer.ebsco.com/interactive/holdingsiqbeta#/


2) Implementation in mod-kb-ebsco-java

Since new HoldingsIQ API is still in beta, I propose to preserve old implementation and add ability to switch between two implementations.

Most of the process is the same so we can use template method pattern:

We will move most of the logic to AbstractLoadServiceFacade class.

Two classes will extend it:

DefaultLoadServiceFacade (class that will have details related to current logic (e.g. it will call endpoint "GET /holdings" instead of "GET /reports/holdings/transactions/{transactionId}")),

TransactionLoadServiceFacade (class that will implement details for new logic).