Uploaded image for project: 'mod-kb-ebsco-java'
  1. mod-kb-ebsco-java
  2. MODKBEKBJ-331

SPIKE - How to store multiple HoldingsIQ/RM API credentials in mod-configuration

    XMLWordPrintable

Details

    • eHoldings Sprint 79
    • 5
    • Spitfire

    Description

      Business Context

      Consortium: A consortium is a group of libraries that may purchase resources as a group AND/OR share resources so that all their users has access to the resources across all libraries in the consortium. Sometimes these groups are created based on geography (for example Five Colleges are schools that are within a 10 mile radius of each other) or type of school (for example - Ivy League schools like Cornell/Harvard have a consortia)

      Example of a consortium that will use FOLIO: Five College (University of Massachusetts - Amherst, Smith College, Hampshire College, Mt. Holyoke, and Amherst College)

      Background: Each school that is a part of Five Colleges manages its own holdings and thus each school has its own EBSCO KB customerID and API encryption key. With FOLIO, Five Colleges will be a single tenant.

      What we must support

      • If the FOLIO customer is a single tenant with
        • has multiple libraries
        • whereby each school has its own EBSCO KB accounts, then we need to store each institution's EBSCO KB API credentials.
      • AND When a library staff member logs onto FOLIO, then the system must default to the library staff member's home EBSCO KB.
        • For example, Jack works for University of Massachusetts (UMASS). UMASS is a member of Five Colleges. When Jack logs onto FOLIO and accesses the eholdings app then he should see UMASS' eholdings.
        • Potentially we can leverage Locations > Service Points

      Please review requirements document: https://docs.google.com/document/d/19nksPGzk7d1x9QoCNbvAJeSi-cw22oB3g_dFGpHRDEM/edit

      Rough Screenshots

      When no location is setup

      Settings > Tenant > Locations

      One location setup and no values assigned

      Multiple locations setup

      Spike Questions/deliverables

      As part of MODKBEKBJ-292, we should be able to support multiple institutions within a tenant. Each institution will have its own set of RM API Creds. What's the best way to store them in mod-configuration?

      Also we need to consider a path for those tenants that already have RM API credentials configured BUT no location setup.

      Thought:
      When we get the list of institutions for a given tenant, we get the institution code -
      For Example:

      https://folio-snapshot-stable-okapi.aws.indexdata.com/location-units/institutions?query=cql.allRecords=1%20sortby%20name&limit=500
      

      Response:

      {
        "locinsts" : [ {
          "id" : "40ee00ca-a518-4b49-be01-0638d0a4ac57",
          "name" : "KĂžbenhavns Universitet",
          "code" : "KU",
          "metadata" : {
            "createdDate" : "2019-11-06T03:33:37.115+0000",
            "updatedDate" : "2019-11-06T03:33:37.115+0000"
          }
        } ],
        "totalRecords" : 1
      }
      

      We store kb.ebsco.url, kb.ebsco.customerId and kb.ebsco.apiKey now.
      Will it make sense to store "institution code" along with the customerId and apiKey?
      Should we assume that url is always going to be live url for each institution or should we store them separately for each institution as well?

      Acceptance Criteria:

      Document/Present to the team how each institution's credentials should be stored in mod-config.
      Create associated implementation story

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                Natalia Zaitseva Natalia Zaitseva
                sduvvuri Sobha Duvvuri
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases