2019-04-26 - System Operations and Management SIG Agenda and Notes

Craig and Matt discussed edge APIs today, what we can do with them , and how to build them. They also discussed the interesting work they have been doing recently on SIP2.

A Confluence page providing an overview is here.

What does SysOps want to get out of edge APIs? Many people wanted to use them for integrations. There are several examples of how to do integrations with edge APIs, which should make it easier. All of these use the edge common framework. EBSCO discovery service uses an edge API.

API keys have three parts, a tenant id, institutional user,  some salt so that APIs cannot be guessed. Edge takes this API key and looks it up in a secure store, such as Vault. For testing, use a properties file. Edge looks at the credentials provided and logs into Okapi, getting back a token. The EBSCO discovery edge API then calls RTAC, which then calls mod circulation and mod inventory, etc, just like any other module in Folio, and results get propagated back. RTAC is real-time availability and access. With EDS, it is conducting a search and gets status information on items.

Different secure stores can be used and what you wish to cache in edge modules can be configured. This is all in edge common framework.

Use edge vertical 2, Vertical 1 will be deprecated. A good use-case for customizing caching is to optimize performance. There is a facility for generating and parsing API keys. Edge can be used for real-time traffic or for batch, depending on what you need. The Edge API is in the Folio API docs page.

Edge modules are built just like any other module. Put a jar inside a container, and build the container. There are module descriptors,, but those are only used for dependency checks. Since edge modules are not being routed through Okapi to the other APIs, it is the other way around, requests only come from the edge module and are routed to Okapi. It is a client of Okapi, and modules that sit behind Okapi.

Edge APIs are not on the standard 9130 port, they are on their own port.

Development of Edge APIs should be easy once you have done one of them and understand how they work.

SIP2 uses a tcp-based protocol, and traffics in raw packets. Therefore Matt had to write his own handler. SIP2 is for self-test machines. Logins are done directly, and stored in the edge API, similar to edge patron. SIP2 is not stateless but it does retries like a stateless system.

How do you deal with errors? SIP2 to checks that the records are corrects and that the connection is live. Need to build retry logic on the Folio side. Matt is only working with SIP2 test tools at this point , not actual self-checkout machines. MeeScan also uses SIP2. There is an open-source SIP2 built by Evergreen that runs a php client in kiosk mode. Evergreen open-source checkout is linked here.

SIP2 passes ids and passwords in the clear. People use ssh tunneling to get around this. Harry says SIP2 needs to be redone completely.

Many Folio institutions have self-checkout machines. Patty has a spreadsheet on who has what here.

MeeScan is a SIP2 app that is popular at Chicago. The app talks to the Bintech server, and Bintech talks to the OLE ils. SIP2 is from Bintech to the OLE ils. Harry says that it would be nice to replace SIP2 with an new secure protocol, that just uses commodity hardware with phones and PCs. Maybe we should do that with our Folio project.