Uploaded image for project: 'FOLIO'
  1. FOLIO
  2. FOLIO-664

Get feedback on Bulk User Import prerequisites

    XMLWordPrintable

Details

    Description

      Bulk user import will be realized using institution made scripts which are doing institution specific data retrieval, transformation and calling the FOLIO API to update the users database. During the UM-SIG meetings it was identified that FOLIO's mod-users have existing API endpoints which can support the bulk user import functionality. But there are some mismatches which need to be solved:

      • User import action needs to be an atomic / transactional operation and modifications needs to be rolled back if an issue occurs. The user insert endpoint is only inserting base user data, additional structures like address entities have to be added in a separate call. If an address insertion fails, the script have to manually rollback changes which is cumbersome to do.
      • The insert API call (correctly) fails, if the user already exists in the system. However in the script there should be a way to do an "update-if-exists" operation if some fields of an existing user changes in the source system. Currently this can only be done, by doing a separate query to check if the user already exists and instead of the POST endpoint, the PUT endpoint should be called. This again adds complexity to the script.

      I see two ways to solve this:

      • Create an additional “insert-or-update-with-all-user-data” API call which atomically inserts or updates a user with each and every field. This solve the issue, however it's against the REST principles.
      • Leave the existing REST calls intact (creating no duplicates) but add transaction opening/committing/rollback capability to the existing REST API. As an example how this can be done, see Fedora's REST API Transaction support: https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API+-+Transactions This might be also usable with other scenarios of the FOLIO REST API calls, not just mod-users, but it's definitely a more complex thing to implement.

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                kszucs Katalin Lovagné Szűcs
                istvan_nagy István Nagy
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 1 day, 2 hours
                    1d 2h

                    TestRail: Runs

                      TestRail: Cases