This question has shown up in my email box a number of times over the past couple of days. My guess, it’s related to the youtube videos recently posted demonstrating how to setup and use MarcEdit directly with Alma.
- Windows Version: https://youtu.be/8aSUnNC48Hw
- Mac Version: https://youtu.be/6SNYjR_WHKU
Folks have been curious how this work was done, and if it would be possible to do this kind of integration on their local ILS system. As I was answering these questions, it dawned on me, others may be interested in this information as well — especially if they are planning to speak to their ILS vendor. So, here are some common questions currently being asked, and my answers.
How are you integrating MarcEdit with the ILS?
About 3 years ago, the folks at Koha approached me. A number of their users make use of MarcEdit, and had wondered if it would be possible to have MarcEdit work directly with their ILS system. I love the folks over in that community — they are consistently putting out great work, and had just recently developed a REST-based API that provided read/write operations into the database. Working with a few folks (who happen to be at ByWaters, another great group of people), I was provided with documentation, a testing system, and a few folks willing to give it a go — so I started working to see how difficult it would be. And the whole time I was doing this, I kept thinking – it would be really nice if I could do this kind of thing with our Innovative Interfaces (III) catalog. While III didn’t offer an API at the time (and for the record, as of 4/17/2017, they still don’t offer a viable API for their product outside of some toy API for dealing primarily with patron and circulation information), I started to think beyond Koha and realized that I had an opportunity to not just create a Koha specific plugin but use this integration as a model to develop an integration framework in MarcEdit. And that’s what I did. MarcEdit’s integration framework can potentially handle the following operations (assuming the system’s API provides them):
- Bibliographic and Holdings Records Search and Retrieval — search can be via API call, SRU or Z39.50
- Bibliographic and Holdings Records creation and update
- Item record management
I’ve added tooling directly into MarcEdit that supports the above functionality, allowing me to plug and play an ILS based on the API that they provide. The benefit is that this code is available in all versions of MarcEdit, so once the integration is created, it works in the Windows version, the Linux version, and the Mac version without any additional work. If a community was interested in building a more robust integration client, then I/they could look at developing a plugin — but this would be outside of the integration framework, and takes a significant amount of work to make cross-platform compatible (given the significant differences in UI development between Windows, the MacOS, and Linux).
This sounds great, what do you need to integrate my ILS with MarcEdit?
This has been one of the most common questions I’ve received this weekend. Folks have watched or read about the Alma integration, and wondered if I can do it with their ILS. My general answer, and I mean this, is that I’m willing to integrate any ILS system with MarcEdit, so long as they can provide the available API end points that make it possible to:
- Search for bibliographic data (holdings data is a plus)
- Allow for the creation and update of bibliographic data
- Utilize an application friendly authentication process, that hopefully allows the tool to determine user permissions
This is a pretty low bar. Basically, an API just needs to be present; and if there is one, then integrating the ILS with MarcEdit is pretty straightforward.
OK, so my ILS system has an API, what else do I need to do?
This is where it gets a bit trickier. ILS systems tend to not work well with folks that are not their customers, or who are not other corporations. I’m generally neither, and for the purposes of this type of development, I’ll always be neither. This means that getting this work to happen generally requires a local organization within a particular ILS community to champion the development, and by that, I mean either provide the introductions to the necessary people at the ILS, or provide access to a local sandbox so that development can occur. This is how the Alma integration was first initiated. There were some interested folks at the University of Maryland that spent a lot of time working with me and with ExLibris to make it possible for me to do this integration work. Of course, after getting started and this work gained some interest, ExLibris reached out directly, which ultimately made this a much easier process. In fact, I’m rarely impressed by our ILS community, but I’ve been impressed by the individuals at ExLibris for this specifically. While it took a little while to get the process started, they do have open documentation, and once we got started, have been very approachable in answering questions. I’ve never used their systems, and I’ve had other dealings with the company that have been less positive, but in this, ExLibris’s open approach to documentation is something I wish other ILS vendors would emulate.
I’ve checked, we have an API and our library would be happy to work with you…but we’ll need you to sign an NDA because the ILS API isn’t open
Ah, I neglected above to mention one of my deal-breakers and why I have not at present, worked with the APIs that I know are available in systems like Sirsi. I won’t sign an NDA. In fact, in most cases, I’ll likely publish the integration code for those that are interested. But more importantly, and this I can’t stress enough, I will not build an integration into MarcEdit to an ILS system where the API is something that must be purchased as an add-on service, or requires an organization to purchase a license to “unlock” the API access. API access is a core part of any system, and the ability to interact, update, and develop new workflows should be available to every user. I have no problem that ILS vendors work with closed sourced systems (MarcEdit is closed source, even though I release large portions of the components into the public domain, to simplify supporting the tool), but if you are going to develop a closed source tool, you have a responsibility to open up your APIs and provide meaningful gateways into the application to enable innovation. And let’s face it, ILS systems have sucked at this, and much to the library community’s detriment. This really needs to change, and while the ability to integrate with a tiny, insignificant tool like MarcEdit isn’t going to make an ILS system more open, I personally get to make that same choice, and I have made the choice that I will only put development time into integration efforts on ILS systems that understand that their community needs choices and actively embraces the ability for their communities to innovate. What this means, in practical terms, is if your ILS system requires you or I to sign an NDA to work with the API, I’m out. If your ILS system requires you or their customers to pay for access to the API through additional license, training, or as an add-on to the system (and this one particularly annoys me), I’m out. As an individual, you are welcome to develop the integrations yourself as a MarcEdit plugin, and I’m happy to answer questions and help individuals through that process, but I will not do the integration work in MarcEdit itself.
I’ve checked, my ILS system API meets the above requirements, how do we proceed?
Get in touch with me at reeset@gmail.com. The actual integration work is pretty insignificant (I’m just plugging things into the integration framework), usually, the most time consuming part is getting access to a test system and documenting the process.
Hopefully, that answers some questions.
–tr