This document outlines the basic process of creating a new sideload for Pika and some of the considerations for sideloading.
Table of Contents
The first step will be getting a file of MARC records from the eContent vendor of all items your patrons have access to. The filename should end with a .mrc extension. If your library needs to use proxy links for your patrons to access the content, please inform us how the proxy links should be set. You do not need to modify the MARC records to include the proxy links, we will add this as part of the sideload set up.
When you are getting the MARC file from the vendor, please contact us for an FTP account & credentials, include the Public IP of the machine you will upload the files from. We will create an account on our FTP server for your library to send us updated MARC files. The Public IP is needed to allow you to connect to the FTP server through our firewall.
If the URLs your library will use will be different from the URLs other libraries would use, it is easier to have a separate set of MARC records even if the collection from the vendor is similar to one from another library.
Pika can now modify eContent links if there is a reliable pattern to follow, so there are exceptions to this.
With the first file, we will do an initial set up on the test server for you to review.
The next major step will be setting up regular updates of the MARC data after the initial setup.
Tell us what kind of updates you will get from the vendor :
a full export (a MARC file of the entire collection)
adds/updates only (MARC file that only has updates and adds for the collection)
adds/updates, plus deletes (MARC file of updates and adds; another MARC file of records to be removed from the collection)
We will set it up so that when you have uploaded a MARC file to the FTP server, that data will be copied to the Pika servers and the online catalog will update with the next full index (usually overnight).
Once the setup on the test server is in a state you like, we can do the setup on the production server at your direction.
A sideload going live does not need to correspond with the code deployment schedule (unless the setup needed codework too.) We do like having an explicit approval message from you to put the sideload setup in production.
If these records are already in Sierra (or your ILS), they will need to be suppressed in Sierra when we put the side load on the production Pika server.
Please let us know if this collection is currently in your ILS.
The other issue is if these records were previously part of the export of records from the ILS that gets sent to EDS. If they are (maybe they are not because they are EBSCO items), they would not be part of the export to EDS once suppressed in the ILS. The records can be included again in the EDS export, but it also requires EDS to create a custom URL for them by filling out a new custom catalog questionnaire (which I have been told has a fee associated with it).
This is an example of where the sideloaded collection will be shown in Pika search facet for the eContent Collection.
