Spike: MODKBEKBJ-390 - describe design for "Single tenant multiple EBSCO KBs" scenario
Participants:
Role | Name | Approval |
---|---|---|
Solution Architect | ||
Java Lead | ||
Product Owner |
Spike points:
Storing EBSCO KB Credentials
Existing Solution:
Currently, mod-configuration
stores EBSCO KB Credentials as 3 separate config files, such as follows
KB Credentials API Key { "id": "b5dbb466-f941-4ef0-9a8f-ff6003dbb5eb", "code": "kb.ebsco.apiKey", "value": "XXXX", "module": "EKB", "enabled": true, "metadata": { "createdDate": "2020-03-17T15:22:04.098", "updatedDate": "2020-03-17T15:22:04.098+0000", "createdByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b", "updatedByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b" }, "configName": "api_access", "description": "EBSCO RM-API API Key" } | KB Credentials Url { "id": "9ef1c0c9-b774-4a1d-9f3f-1399e9a0292e", "code": "kb.ebsco.url", "value": "https://test.url", "module": "EKB", "enabled": true, "metadata": { "createdDate": "2020-03-17T15:22:04.052", "updatedDate": "2020-03-17T15:22:04.052+0000", "createdByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b", "updatedByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b" }, "configName": "api_access", "description": "EBSCO RM-API URL" } | KB Credentials Customer Id { "id": "ba80d8c1-a6c5-4df0-9b32-b35960c3a68b", "code": "kb.ebsco.customerId", "value": "test", "module": "EKB", "enabled": true, "metadata": { "createdDate": "2020-03-17T15:22:04.154", "updatedDate": "2020-03-17T15:22:04.154+0000", "createdByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b", "updatedByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b" }, "configName": "api_access", "description": "EBSCO RM-API Customer ID" } |
Proposed Solution:
- move configuration from
mod-configuration
tomod-kb-ebsco-java
- store configuration information(
apiKey, url, customerId
) as one entity in db. DB schema, json schema and sample payload file can be found below.
Method | Path | Permission(s) | Response | Note(s) |
---|---|---|---|---|
GET | /eholdings/kb-credentials | kb-ebsco.credentials.collection.get | 200 OK(with collection) | |
POST | /eholdings/kb-credentials | kb-ebsco.credentials.collection.post | 201 Created(with record) | |
GET | /eholdings/kb-credentials/{credId} | kb-ebsco.credentials.item.get | 200 OK(with record) | {credId} - UUID of the credential |
PUT | /eholdings/kb-credentials/{credId} | kb-ebsco.credentials.item.put | 204 No Content | {credId} - UUID of the credential |
DELETE | /eholdings/kb-credentials/{credId} | kb-ebsco.credentials.item.delete | 204 No Content | {credId} - UUID of the credential |
The appropriate files attached below:
DB schema | |
Json Example | KB Credentials JSON example { "id": "2ffa1940-2cf6-48b1-8cc9-5e539c61d93f", "type": "kbCredentials", "attributes": { "name": "University of Massachusetts - Amherst", "apiKey": "XXXX", "url": "YYYY", "customerId": "ZZZZ" }, "metadata": { "createdDate": "2020-03-17T15:22:04.098", "updatedDate": "2020-03-17T15:23:04.098+0000", "createdByUserId": "1f8f660e-7dc9-4f6f-828f-96284c68a250", "updatedByUserId": "6893f51f-b40c-479d-bd78-1704ab5b802b", "createdByUsername": "john_doe", "updatedByUsername": "jane_doe" } }
|
Json schema |
Configuration cache
kb-ebsco-java sequence diagram
codex-ekb sequence diagram
UI mockups
Storing association between user and settings(EBSCO KB Credentials)
Proposed Solution:
Method | Path | Permission(s) | Response | Note(s) |
---|---|---|---|---|
GET | /eholdings/kb-credentials/{credId}/users | kb-ebsco.credentials.users.collection.get | 200 OK(with collection) | {credId} - UUID of the credential |
POST | /eholdings/kb-credentials/{credId}/users | kb-ebsco.credentials.users.collection.post | 201 Created(with record) | {credId} - UUID of the credential |
PUT | /eholdings/kb-credentials/{credId}/users/{userId} | kb-ebsco.credentials.users.item.put | 204 No Content | {credId} - UUID of the credential {userId) - UUID of a user |
DELETE | /eholdings/kb-credentials/{credId}/users/{userId} | kb-ebsco.credentials.users.item.delete | 204 No Content | {credId} - UUID of the credential {userId) - UUID of a user |
The appropriate files attached below:
DB schema | It means that we have
It means that:
| |||||||||||||||||
Json Example | ||||||||||||||||||
Json schema |
UI mockups
Update mapping between credentials and user
Option #1 - add PUT collection endpoint
- UI sends full collection of users assigned to a credential(see json example above) to PUT /eholdings/kb-credentials/{credId}/users
- back-end selects records tied to credential and removes them
- back-end inserts new records based on data received
Option #2 - use separate endpoints
- on each update (assignment user to a credential) UI will send request to PUT /eholdings/kb-credentials/{credId}/users/{userId}
- back-end adds record based on credential and user id
- on each removal (unassignment user from a credential) UI will send request to DELETE /eholdings/kb-credentials/{credId}/users/{userId}
- back-end removes record based on credential and user id
Summary
Association between KB Credentials and access status types
To implement the association between KB Credentials and access status types several changes should be made:
DB schema
It means that we have
This approach will provide the ability to separate assignment-data between each KB credentials |
Endpoints
Method | Old endpoint | New endpoint | Request body | Response status | Response body |
---|---|---|---|---|---|
GET | /eholdings/access-types | /eholdings/kb-credentials/{credId}/access-types | 200 OK | ||
POST | /eholdings/access-types | /eholdings/kb-credentials/{credId}/access-types | 201 Created(with record) | ||
GET | /eholdings/access-types/{atId} | /eholdings/kb-credentials/{credId}/access-types/{atId} | 200 OK | ||
PUT | /eholdings/access-types/{atId} | /eholdings/kb-credentials/{credId}/access-types/{atId} | 204 No Content | ||
DELETE | /eholdings/access-types/{atId} | /eholdings/kb-credentials/{credId}/access-types/{atId} | 204 No Content |
JSON schemas that will be used (changes will be affected only for Access Types Collection Item Schema):
Access status type to record (package, resource) mapping and filtering implementation
Endpoints that will be affected:
Method | Endpoint | Action | Notes |
---|---|---|---|
GET | /eholdings/packages | filtering | Most interactions with DB must be updated. In most cases, we need to update only ' SELECT ... FROM access_types WHERE credentialsId = ? AND ...; In other cases SQL-queries need to be updated by joining SELECT ... FROM access_types_mapping atp JOIN access_types at ON at.id = atp.accessTypeId WHERE ... AND at.credentialsId = ?; |
POST | /eholdings/packages | mapping | |
PUT | /eholdings/packages/{packageId} | mapping | |
GET | /eholdings/packages/{packageId}/resources | filtering | |
PUT | /eholdings/resources/{resourceId} | mapping | |
GET | /eholdings/providers/{providerId}/packages | filtering | |
GET | /eholdings/titles | filtering |
Association between KB Credentials and custom labels
Endpoints are needed to be changed
Method | Old endpoint | New endpoint | Request body | Response status | Response body |
---|---|---|---|---|---|
GET | /eholdings/custom-labels | /eholdings/kb-credentials/{credId}/custom-labels | 200 OK | ||
PUT | /eholdings/custom-labels | /eholdings/kb-credentials/{credId}/custom-labels | 200 OK |
JSON schemas that will be used (changes will be affected only for Custom Labels Collection Item Schema):