- Dale Arntson
- Chris Creswell
- Robbie Douglas
- Johannes Drexl
- Harry Kaplanian
- Tod Olson
- Philip Robinson
- Jason Root
- Florian Ruckelshausen
- Catherine Smith
- Brandon Tharp
- Ian Walls
- Patty Wanninger
We went through the most recent action items.
Chris Creswell talked to Michelle Suranofsky about patron lookup functionalities in NCIP. There is a Jira ticket - SIP2-25Getting 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 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 (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-409Getting issue details... STATUS and there is a closed umbrella ticket which was changed from epic to umbrella a year ago and then closed: - UXPROD-26Getting 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
SysOps-related issues in Reporting LDP integration
Recording of the July 29 Reporting SIG meeting:
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.
Harry walks us through the blocker issues.
UXPROD-1438: Process for tracking data-related API schema changes
UXPROD-1414: Complete documentation of data attributes in module APIs
FOLIO-1839: Enable incremental requests for all records since last request
Jo suggests postgres replication for builing the LDP (data warehouse).
|Update on question of synchronization and incremental loading during migration||Ingolf|
This is strictly speaking part of the Data Migration group's work.
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
Ingolf gives an update on migration plans and timelines in Germany (as described above).
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)
|Data base upgrades without complete reload of the data||Ingolf|
|Question from Ingolf (maybe to Tod / TC)||Ingolf||will LDP be part of the MVP ? - This has not been decided, yet.|
|Vacation||Ingolf on vacation Aug 9 - Aug 31st. Harry will convene.|