2019-08-02 - System Operations and Management SIG Agenda and Notes

• new members ? no.
• note taker ? Harry and Ingolf.
• Review action items - See action items for notes

Meeting Notes:

We went through the most recent action items.

Christopher Creswell talked to Michelle Suranofsky about patron lookup functionalities in NCIP.  There is a Jira ticket SIP2-25 - Getting issue details... STATUS . SIP2 for FOLIO supports this today. Recommend Michelle review the current working SIP 2 functionality to see if it can be used for NCIP.  

We talked about RFID integration. Chalmers has this currently working with FOLIO. The GBV libraries will need this but we believe the hardware is older and might need special integration. The integration is on the vendor's side. Patty will check the details of this integration at Chalmers along with the material unlock at check out with RFID and report back to the group with the details.  Patty will also discuss with Uschi Klute The goal is to determine if the GBV equipment can connect in the same way.  If the GBV RFID equipment cannot connect to FOLIO in the same manner, we will create a new JIRA feature with more details to better specify and estimate the work needed.

According to Uschi Klute (private communication), RFID is for self-checkout/checkin, sorting systems and ASRS, and activating/deactivating the security strip of a book when it is checked out/in. A number of our (GBV) libraries use RFID, especially the larger university libraries. There is an Umbrella ticket: UXPROD-409 - Getting issue details... STATUS and there is a closed umbrella ticket which was changed from epic to umbrella a year ago and then closed: UXPROD-26 - Getting issue details... STATUS .

HK - For UXPROD-409, please search in JIRA for "SIP2".  There are about 70 features that have been built to support SIP2.  Also, have a look at UXPROD-498 which covers remote storage systems.  This is currently very active. UXPROD-1516 seems to cover high density automated storage as well.

HK closed UXPROD-409 as a duplicate.  

There is a post/discussion in the resource-access channel: https://folio-project.slack.com/archives/C3G05TF3R

https://drive.google.com/drive/folders/0B7G8S7WF6N20VE5Wa0I0STZGcjg

Please watch minutes 32:40 - 51:08 on "Reporting Blocker Issues". A blocker issue means that, if this JIRA ticket is not completed, LDP development cannot move forward.

Please think of issues that might arise for SysOps integration of the Reporting LDP.

Meeting Notes:

Harry walks us through the blocker issues.

One of the blocker issues has been removed : UXPROD-1431 - Getting issue details... STATUS . The others are  a work in progress.

Blockers:

UXPROD-1438: Process for tracking data-related API schema changes

UXPROD-1414: Complete documentation of data attributes in module APIs

• documentation of the module APIs is crucial and is not only needed for Reporting.

FOLIO-1839: Enable incremental requests for all records since last request

• Work is in progress.

Jo suggests postgres replication for builing the LDP (data warehouse).

This is strictly speaking part of the Data Migration group's work.

References:

2019-07-29 - Data Migration Subgroup Agenda and Notes

2019-07-30 Meeting notes Implementation group

Upshot: Old system and new system (FOLIO) will run in parallel (for a limited amount of time) at some institutions (in Germany), but synchronization is not needed.

In VZG/GBV, open loans will be closed in the old system and created anew in FOLIO. Thus no mapping and record matching for loans during migration is necessary. Bibs and Items will be migrated at once. Permanent loans and course reserves might be re-booked manually in FOLIO just before the go-live date (if these are not large amounts of datasets).

UB Mainz (HeBIS) : Acquisition and Loans are planned as big bang migration. Titles need not be migrated, because they are taken from a central system. The central system will be integrated as KB to FOLIO. Titles and holdings will have to be loaded to Inventory. But maybe there are also local titles which need to be migrated. External Users and Vendors might need to be migrated. Migration is not necessary for Orders (except subscriptions) and transaction data. A synchronization of both systems will be too effortful; a reproducable migration path for parts of the legacy data will suffice. Nevertheless, UB Mainz would call the migration scenario "trickle", as the information will be distributed over two systems for a longer period of time: Loans here, Acquisition there; old year here, new year there. But that doesn't mean that the same pieces of information need to be kept twice in two different places and need to be synchronized.

Leipzig: ERM data must be migrated for 4 tenants. A test system has been already established. Migration (tests) will start within the next few weeks, thus a little earlier than three month before go-live. During migration tests, the system will have to be upgraded. Currently, the system is on Q2.2. Go-live will presumably happen with Q4.1 or Q4.2. Migration will be done with scripts that take the data from the existing DB (triplestore), do a hard-coded mapping and import via the module APIs. The migration will be "ERM-focussed", which means migrating existing data to agreements, licenses, eUsage, orders, invoices, organizations and users. Also, some finance data will be created newly. The systems will run in parallel for a short period of time. In a first phase, the old system will be operative. A second date is called "go-live", and from that date on, the new system will be operative, while the old system will run as a backup. Finally, on a third date, the old system will be switched off. Automatic synchronization between the two systems is not needed.

-----

Chicago: We expect to do a Big Bang migration

Meeting Notes:

Ingolf gives an update on migration plans and timelines in Germany (as described above).

The plans for the other Implementers have been desribed here: 2019-07-30 Meeting notes. Philip Robinson , jroot , Christopher Creswell please add your notes for Cornell, TAMU and Lehigh.

Patty: Chalmers will also do the catalogization in a union catalog and will connect the union catalog (as a KB?) to FOLIO. There will be an online update mechanism between the union catalog and FOLIO. The union catalog is a LIBRIS system. The initial integration of the title data will be done offline.

Dale: Crucial is the development of the bulk loading APIs. Migration (of bibs and holdings) should not take more than 8 hours.

Cornell: We expect to do big bang. We've started talking about how much down time is acceptable for each area (ie, stop ordering when, keeping in mind that circ will need the smallest shut down but many other areas should be negotiable)

Is there news on UXPROD-1815 - Getting issue details... STATUS ? Especially, will this be available already in one of the Q3 releases ? (this is more like a question from me)

• This will probably be ready in Q4.