DCB Integration
Submitted | Jun 15, 2023 |
---|---|
Approved | |
Status | DONE |
Impact | high |
Arch Ticket | |
Prod ticket |
Glossary
Term | Description |
---|---|
DCB | Direct Consortia Borrowing System |
DCB Search UI | Consolidated search for items across a consortium |
Item | Physical or virtual item |
Patron | Patron registered in borrowing institution |
Executive Summary
Integration with DCB allows support for cross-ILS circulation of items. FOLIO can participate in cross-ILS circulation in the role of requester institution, owning institution, and pickup location. DCB will act as an orchestrator for coordinating multi-system circulation transactions. The main goal from the perspective of internal integration implementation for FOLIO is to provide circulation for external items without affecting the existing local circulation flow. FOLIO is implemented as an application with microservice architecture and should reuse the same approach for integration with DCB. The current direction of FOLIO's technological stack suggests that the approach should include integration with third-party systems through edge modules and implementation of microservices should be based on a spring-way approach.
One of the main obstacles to the implementation is that FOLIO's inventory contains information regarding items and circulation of items that are out of inventory context boundaries and overlap with circulation context. This is the reason that it is a challenge to create a virtual item for the FOLIO installation so that it wouldn't leak the properties of virtual items in search results of local items. The target solution for this requires the migration of information related to circulation from inventory and moving it to the context of the circulation module.
The circulation flow inside FOLIO is implemented in a "manager/storage" approach as a RAML module and provides additional limitations because of the complexity of introducing new changes to the circulation module. Because of time constraints, the target solution might be difficult to implement. so it is proposed to create an interim solution that can be used as a basis for migration of the circulation module to spring-way in the future. The solution requires the introduction of a circulation item that would abstract the circulation information from the inventory context. The new module will be implemented as a separate circulation-item module that should serve as a proxy/adapter between the circulation module and the inventory module.
Requirements
Functional Requirements
Supported use cases described in https://folio-org.atlassian.net/browse/UXPROD-4325
Business Flow Diagram: https://miro.com/app/board/uXjVP9HDWqw=/?moveToWidget=3458764545695411304&cot=14
Scenario 1: Circulation from Lending library to Pickup Library
Scenario 1: Circulation from Lending library to Borrowing Library
Non-Functional Requirements
Modifiability: The solution should be loose-coupled and support the existing circulation flow
Performance: FOLIO edge modules should answer under <X> ms
Security: FOLIO edge modules should authorize DCB requests through the API keys mechanism
Scalability: new microservices should support a microservice architecture approach and be stateless
Constraints
API communication from DCB to FOLIO should follow a polling approach. FOLIO should provide a set of related REST APIs
Status check requests can happen with high frequency because of the polling mechanism
The integration implementation should be finished inside ECS initial release.
Risks
Possible additional UI work for different modules related to Umbrella approach.
Assumptions
DCB uses a polling approach to communicate with FOLIO. Hence FOLIO should provide REST API endpoints
DCB is able to authenticate patron. Patron identity is supplied by DCB and known to the FOLIO borrowing library.
DCB is able to provide information on the requested item to the lending library. Item information is known through RTAC and reflects up-to-date information from the inventory of FOLIO
The pickup location can be separate from the borrowing library.
In case the lending or pickup institution was changed DCB should create a new transaction
Request canceling can happen at any point in the lifetime of the borrowing/lending request
FOLIO should support borrowing, lending, and pickup role. Implementation should support the following action for requests:
Creation of virtual patrons in lending and pickup libraries
Creation of virtual items in borrowing and pickup libraries
Creation/update/cancel/status for the lending request
Creation/update/cancel/status for borrowing request
Creation/update/cancel/status for pickup request
Solution Options
Solution | Description | Pros | Cons | HLE | Decision | |
---|---|---|---|---|---|---|
1 | Migration of all of mod-circulation to new spring module | Introduction of new circulationItem that would abstract the actual item from the circulation process. Implementation requires moving properties related to the process of circulation from |
|
| ||
2 | Introduction of virtual item/patron in a separate module | Introduction of new circulationItem that would abstract the actual item from the circulation process. Implementation requires moving properties related to the process of circulation from |
|
| XXL | Declined. Introduction of virtual item requires additional virtualizing of inventory entities like instance/holding etc. |
3 | Supporting existing API for the creation of temporary items/patrons | The implementation should use existing API and approach with the creation of temporary patrons/items. |
|
| M-L | Declined. Usage of suppression from discovery mechanism involves side-effects in different FOLIO applications like OAI-PMH, mod-search, data-export |
4 | Implementation of the creation of virtual patrons and items inside of existing |
|
| |||
5 | Implemenation of virtual item with single instance/holding object | Only item is virtualized. Single Instance and holding is created in inventory and used for all DCB Items in lending and pickup libraries. |
|
| In Discussion. Aligned with strategic vision |
Target Architecture (Solution Option 2)
The solution consists of the following components:
edge-dcb
- microservice responsible for providing REST API for DCB and API key authorization.mod-dcb
- microservice responsible for persisting state of DCB transactions and coordination of internal calls inside FOLIO. Should listen for updates frommod-circulation
to reflect the state of DCB transactions to external consumers.mod-circulation-item
- should implement an adapter/proxy approach for the virtual item or patron for circulation. The adapter/proxy approach should allow the breaking of dependency between circulation and actual/virtual items. The module should be able to:Create/Get/Update virtual item (circulationItem)
Substitute calls to
mod-inventory
for items and when the request is related to DCB return Virtual Item
Mod-circulation - should not require significant changes
Diagram Source: Volaris-DCB.drawio (2).xml
API Contracts
Open API Description: API Contract
Entity Relationship Diagram
The target solution introduces a new abstraction for an item in circulation context: CirculationItem. This serves as a proxy for items that are present in mod-inventory and, in case of borrowing and pickup libraries, they represent an item that exists in other institutions. DCB Transaction represents a facade object for the synchronization of different entities in FOLIO.
Interaction Sequence Diagram
Coordination of transactions in different libraries is the responsibility of DCB. The communication mechanism is polling from DCB.
State-Transition Diagram
Scenario: Lending Library to Pickup Library
Scenario: Lending Library to Borrowing Library
Work Breakdown Structure
edge-dcb:
Create a module based on edge-common-spring
implement API contracts and proxy calls to
mod-dcb
mod-dcb:
Create a module based on mod-spring-template
Create liquibase scripts for database structure for DCBTransaction, DCBItem, and DCBPatron entities
Create circulation items in
mod-circulation-item
Create temporary patron in
mod-patron
Listen for updates on the circulation process in
mod-circulation
mod-circulation-item:
Create a module based on mod-spring-template
Create a proxy method for fetching items from
mod-inventory
supporting Item contract schemaCreate liquibase scripts for database structure for CirculationItem
mod-circulation:
Adjust calls for item fetching from
mod-inventory
tomod-circulation-item
using multiple interfaces
Impact Analysis
Module | Impact | Modification Size Estimation | Risk of Regression | |
---|---|---|---|---|
1 |
| Change calls for items to proxy | S | High |
2 |
| Might require changes from | S | High |
3 |
| Might require changes from | M | High |
Concerns related to virtual items
Problem statement 1 - Creation of Virtual Item without its related data
If the idea is to create only virtual item record with limited columns as mentioned in the design then that will not be sufficient to perform the check-in/checkout process with the existing code of mod-circualtion
.
Explanation:
In the existing mod-circulation
code the checkin/checkout code fetches the item and then fetches the item's related entities (the entire schemas) based on its holdingsRecordId, materialTypeID, permanentLoanTypeId, and effectiveLocationId. These are required attributes in the inventory-storage item's table.
The related data of an item plays a key role. It has to be present or simulated for further steps of the check-in/checkout process otherwise the process will break.
Concerns:
If the circulation_item table does not contain the related data then how to handle the virtual item's related data? What would be the source for this related data of a virtual item?
Tight coupling of item interface with the new module API's. Will we duplicate the schemas for the items related data in our new module?
If the related item data is simulated then it will lead to hardcoding the data for holding, instance, loan etc. That means these entities would be fake and will be needed to satisfy the checkin/checkout flow.
As of now we have anlayzed use cases like checkin/checkout. But, this will impact other use cases like Renew, Cancellation, Fee/Fines.
The mod-circulation code will need more changes than expected to handle the virtual item's related data for example:
The new get circulation item by barcode API to get the item.
To get the item's related data either more API's have to be put in place in the new module mod-circulation-item, or, has to be managed in circulation module maybe by hardcoding the values.
The new put circulation item API will be called to update the item status and other attributes.
After the check-in/check-out, if we click end patron action session, we can see the following error: Failed to send notice for patron action session: referenced item was not found.
For the loan section in the UI, there are empty columns because UI calls
circulation/loans
and it requires a change in the related API.
Problem statement 2 - Virtual Item/Temporary Patron on-screen behavior
Concern:
There are times when a virtual item/virtual patron can be visible on Folio UI. In this case modifications are needed to disable hyperlinks like "item detail". A few columns might not have all the details to display and might display null/blank. This will require effort to identify such scenarios and fix them in appropriate modules.
Problem statement 3 - DCB's material, location, and patron group matchup with folio, and its circulation rules
Concerns:
DCB will be the source of data for its material type, location, patron group, etc. But, how will these mappings be matched with FOLIO's material, location, and patron group, or, will they not match up and be created separately dedicated for DCB? If they will be created for DCB then where and how will they be created and maintained?
Will DCB have a dedicated circulation policy and also be equipped with a fall-back policy? Will every DCB's material type, and patron group have its own circulation rule? How will these rules be created/maintained?
Open Questions/tasks
Question | Owner | Response | |
---|---|---|---|
1 | What is Projected transaction volume? | @Tim Auger | If we define as a transaction as the initiation of a request through a terminal state like "item returned to home library" or "patron cancellation" then it's about 350k/year for MOBIUS. For other consortium it could be significantly higher (1.25M/year). If we are talking about volume of individual message pairs, multiple the number by 5x. |
2 | What is the frequency of status requests in polling DCB mechanism? | @Ian Ibbotson (Use this one) / @Marc Johnson | |
3 | Provide Groovy scripts | @Ian Ibbotson (Use this one) | #!/usr/bin/env groovy // Use this file by starting up a groovy shell (groovysh) and then issuing :load ./testscript.groovy - the colon is important! import groovy.grape.Grape Grape.addResolver(name:'mvnRepository', root:'https://central.maven.org/maven2/')
/* // oc.getInstancePage() String new_instance_id = java.util.UUID.randomUUID().toString(); String instance_id_at_sgcl='1234567114@SGCL';
def institution_data = oc.getInstitutions(); // These should all be LOOKUPORCREATE String new_item_id = java.util.UUID.randomUUID().toString(); println("Create holding"); println("result of create holding: ${ch}") */ Thread.sleep(1000); Map item = [ println("Create item ${item}"); println("Done"); |
4 | Post information on Chalmers temp patron capability | @Tim Auger | I really don't think Chalmers is something we want to copy. It is a different set of use cases. |
5 | Can you provide transaction ID when POST API creates DCB Transaction (Ian proposed to use internal DCB transaction UUID)? | @Kalibek Turgumbayev | @Ian Ibbotson (Use this one): Yes |
6 | Can DCB cancel current transaction in case of significant changes and start new one (with new transactionID)? Significant changes include:
| @Kalibek Turgumbayev | @Ian Ibbotson (Use this one): Yes, we can, but this suggests a workflow where either we don't create a patron request until after we have established who will lend it, or we create churn in the FOLIO system by creating and deleting an arbitrary string of transactions - that is pretty awful UX IMO. We can absolutely use the supplier request UUID as a transaction ID and close out the transaction as we move down the rota. I woudn't design a system this way given a choice, but we will adapt to what we are given. |
7 | What data has DCB besides item title and UUID? Could DCB include following into request to edge-dcb (DCBTransaction in API Contract):
| @Kalibek Turgumbayev | @Ian Ibbotson (Use this one): DCB Knows these things but I would prefer to create first class location/service point records and point to them than have circ item level properties. |
8 | Provide list of material types/ patron groups that exist in DCB | @Kalibek Turgumbayev | @Ian Ibbotson (Use this one): No - that isn't how this works. FOLIO provides US with a list of material types and patron groups and then we map the central data to what a target system has so that what we place in a target system is what YOU know about - FOLIO needs to provide US with this data. |
9 | Confirm the API Exchange flow:
| @Kalibek Turgumbayev | @Ian Ibbotson (Use this one): We can work with that - the devil will be in the detail - getting it implemented ASAP Is the important thing. |
10 | Question from DCB to the Volaris team: Our understanding now is that we will be provided with edge APIs that represent proxies of the existing interfaces and we will NOT write the V1 implementation against the new circ interface. Therefore, the critical path for DCB is on the intermediary Facade pattern interfaces and NOT on the new circ interfaces - is that correct? | @Ian Ibbotson (Use this one) | @Kalibek Turgumbayev: Yes. The implementation of facade gives us opportunity to change internal implementation of circ interfaces independently.
|