Skip to main content

Moving P2P partner profiles from the NZ to the IZ

Problem: The NZ-managed partners have the same Codes as the equivalent partners in the RS Directory. This prevents an IZ from downloading the Directory partners until the NZ partners are removed.
Solution: To circumvent this roadblock, new NZ-managed partners will be created as temporary replacements. They will have new, unique codes that will not conflict with those in the directory. This will make the cleanup a longer process, but it prevents any service disruptions to your patrons (as well as with SUNY). 

Phase One

Configuration in the Network Zone

  1. Create the new Replacement Partners in the NZ
    • As I mentioned, the only data that needs to be unique is the Code; make this unique in whatever way you like, as long as it doesn't match the Directory. But all other details within the partners can be identical to the current NZ partners. 
  2. Once they have been created, distribute these Replacement partners to the IZs by running the "Distribute Resource Sharing Configuration" job in the NZ
  3. After which, the IZs should update any/all Rota Templates, replacing the Original NZ partners with the Replacement partners
  4. When the IZs are fully configured to use the Replacement partners, return to the NZ and mark the Original partners as Inactive,
  5. Then Distribute the changes again by running the "Distribute Resource Sharing Configuration" job in the NZ
    • This is just an extra step to ensure that no new requests are created with these Original partners
At this point, all new incoming/outgoing requests will be using the Replacement partners. Since this is the case, you will be free to begin removing the Original partners piece-by-piece from all remaining Active requests. This process will take a while, as any request (Borrowing or Lending) that has one of these Original SUNY partners as the Active partner will need to finish organically, waiting for the patron to return the item and/or ship the item back to the lender. But it's at this point that the cleanup can begin.

Initial Network Zone Cleanup

6. Once you have confirmed that Replacement partners are all working as expected (and I see no reason why they wouldn't), delete the Original partners from the NZ

  • This will remove the Original partners from some but not all IZs, but this is expected

7. Then distribute the deletion of the original partners by running the "Distribute Resource Sharing Configuration" job in the NZ

8. Wait 24 hours for these changes to be visible in Alma Analytics, then run a Lending and a Borrowing Analytics report (see image below) in the Network Zone; send to participants.

Partner Borrowing & Lending Request Cleanup

A. Clean up Lending Requests by updating the request status
  1. For
    TheLending statusRequests ofwith the requestsfollowing statuses, nothing needs to be done. We will let the lending workflow run its course until the request finally has a status of Completed
    • Being processed
    • Received by partner
    • Returned by partner
    • Shipped physically
    • Overdue request
  2. Lending Requests with the statuses below still have an "active" status according to Alma. Their status needs to be changed to one that Alma considers Inactive: Request Completed, Deleted, or any of the various Cancelled statuses
    • However,Expired
      • anything
    • Locate infailed
      • a
    • Rejected Rejectedthe statusborrower is still considered semi-Active by Alma, so these will need to be updatedrequest

To

  • change
    Thisa will need to be donestatus manually, follow the steps below in the Lending Requests Task List
    List.
    • Filter your results appropriately, expand the results to show 50 at a time, and you will be able to update requests in batches of 50 (there is no job that can do this in Alma)

     

    • B. Cleaning up Borrowing Requests
    1. TheFor sameBorrowing methodRequests usedthat forA) Lendinghave requeststhe canfollowing statuses, and B) the active partner is one of the 4 SUNY schools, nothing needs to be used,done. butWe therewill islet the lending workflow run its course until the request finally has a secondstatus optionof asComplete well.
      • Loaned item to patron
      • Instead,Physically youreceived canby library
      • Ready to be sent
      • Renewed by partner
      • Returned by patron
      • Returned item to partner
      • Shipped physically
    2. For all other borrowing requests, remove the Original SUNY partners from each BR's Rota
      3. Rota.
      • Active partners cannot be removed; only Pending and Rejected. This method, though, can only be one manually one request at a time, but allows you to cleanup the SUNY partners from any active BRs
    C. Wait until all active lending and borrowing requests (those with items checked out to patrons) have a status of Completed

    13. Once one (or more) of the Original partners have been cleaned up from an IZ, run the Distribute job in the NZ once again

      • If all of the requests were cleaned up, that partner will be removed
      • If not, you'll see the same error message indicating if any Borrowing and/or Lending requests remain
    This is effectively the entire process. Over time, clean up all of the Original partners as much as possible. As we discussed, a there will be requests that are still actively sharing with one of the SUNY partners, so we'll have to wait for these to finish via normal means. But, the upside is that once these requests finish, they won't need to be cleaned up - they'll be in the Completed status, so no longer active in the system.

    Eventually, all traces of the Original SUNY partners will be removed, and they will finally be fully deleted. Once that has occurred, it's time for the next phase. 

    Phase Two Cleanup

    • Once you're ready to begin, this is where you'll finally create the IZ-managed partners, as desired. Since the Original NZ partners are now deleted, each IZ can download the SUNY partners from the Directory, as desired
    • And in doing so, any Rotas and Rules can be updated to use these Directory partners
    • Once the IZs have fully switched to using Directory partners, the Replacement partners can now be deleted. The replacement partners will be marked as Inactive
    • Then distribute these Replacement partners to the IZs by running the "Distribute Resource Sharing Configuration" job in the NZ

    Then you will follow the remaining steps in Phase One, Initial Network Zone Cleanup and Partner Borrowing & Lending Request Cleanup, this time slowly removing requests associated with the temporary profiles.

    Additional Notes:
    • Like we discussed, this is going to be a long process. This is mostly due to having to wait on some requests to finish organically before partners can be deleted. But the advantage to all of the extra steps means that there will be functionally no disruptions of service to any/all patrons. And your RS staff will see little-to-no difference in their day-to-day work. 
    • Some requests might be troublesome - you can't find them when searching in Alma, they won't let you update their status, etc.
      • If these pop up, Ex Libris has methods to find and correct them, or just outright delete them if they are not needed
    • Lastly, I would not recommend bothering with this process in your PSBs.
      • If you don't need the PSBs for active Resource Sharing testing, it would be best to just wait for the August refresh, which will automatically copy Production settings to the PSBs

    *The "one IZ at a time, one partner at a time" method is for ease of tracking progress. By focusing on a single partner within a single IZ, you can fully complete the cleanup for that partner, then run the Distribute job to remove them, and then move on to the next partner on the list. But this is far from the only approach to this cleanup; this is just how I would approach the situation were I in your shoes.

    In reality, this cleanup can be handled by whatever method is most convenient for you all. You could focus on only Borrowing first, then do Lending second. Or you could work on both at the same time. You could focus on cleaning up one IZ at a time, or you could handle it as one large project for the whole network. Each IZ could be in charge of their own cleanup, performing it as quickly or as slowly as they need, and it wouldn't affect any of the other IZs. 
    Back to top