Hi Gary, I should have clarified that from the beginning, sorry. We self-host Aeon so we have more freedom when it comes to accessing our data. I'm convinced that the WebPlatform used to talk to ILLiad could also be used to retrieve transaction information but it's not documented/supported so we've no incentive to pursue that route further. The API is therefore a separate application that allows for certain transactions to occur with the Aeon database. Not sure if it's still useful to anyone, but I can talk to my manager about putting the code on GitHub.
Best, Steelsen -----Original Message----- From: Code for Libraries [mailto:[email protected]] On Behalf Of Gary Thompson Sent: Monday, March 9, 2015 5:16 PM To: [email protected] Subject: Re: [CODE4LIB] Aeon api (was Get It Services / Cart) I am interested in access to Aeon data. We created an application that accepts a request from our catalog (Voyager) or from the Online Archive of California where users discover our finding aids. They can click on a link in either system, and our app pulls appripriate data from the other to provide a complete request to Aeon. It is submitted by calling a DLL on the Aeon server. The Atlas Systems programmers could only provide batch data via our sftp server to integrate with other systems, specifically for remote storage requests and billing/payments. (We could not use Aeon for billing, but needed to integrate it into our existing billing and payments systems.) I'm interested in your approach to api access. Can you directly access the Aeon database? /-- -- Gary Thompson -- Head of Software Development and Project Management -- Digital Initiatives & Information Technology -- UCLA Library -- 390 Powell -- voice: 310.206.5652 --/ On 3/9/2015 12:08 PM, Smith, Steelsen wrote: > Hi all, > > I'll note that we are using Aeon as a target and because of the need to both > request and efficiently read information out of it for this and other systems > we're working on an unofficial api interface. Would anyone else ever use > something like that? > > -sss > > > > From: Jennifer Vine <[email protected]> > Sent: Mar 9, 2015 2:12 PM > To: [email protected] > Subject: Re: [CODE4LIB] Get It Services / Cart > > Hi Shaun, > > Nope, we're not talking about Aeon, just Illiad - and just for Scan & > Deliver. We're going to use OpenURL + javascript to populate and submit the > Illiad document delivery form without the patron having to interact with it > at all. > > Special Collections requests will continue to use a combination of our > existing LAS paging and existing semi-manual processes. We're focusing on > improving the patron experience and simplifying the mediation process. > > > Jennifer Vine > User Experience Designer > Digital Library Systems & Services > Stanford University Libraries > > > On Mar 7, 2015, at 6:11 AM, Shaun Ellis <[email protected]> wrote: > >> Hi Jennifer, >> Sounds like a great project! When you refer to Illiad, are you talking about >> Aeon as well? It's another Atlas product that is basically an adaptation of >> Illiad with better handling of SC/archival data and workflows. That's what >> we use for Special Collections requests. >> >> We've been wanting to interface with it better, but have hit roadblocks in >> our attempts to improve the user experience because of a lack of API and >> single sign-on in Atlas products. I haven't looked at them in a while >> (though coincidentally was planning to next week), so I'd love to know if >> there are now ways to do this, or if not, how your team is planning on >> approaching it. >> >> Shaun Ellis >> User Interface Developer, Digital Initiatives >> Princeton University Library >> 609.258.1698 >> >> >> On 3/6/15 5:02 PM, J Vine wrote: >>> Steelsen, >>> >>> Maybe related but not quite what you're describing: we're developing a >>> requests application that will interface with a number of different >>> systems, including Illiad, Symphony, and LAS, for fulfilling the requests. >>> Specifically, we are: >>> >>> - adding a Scan & Deliver option for a subset of our materials, for >>> qualified users >>> - providing a single request process for off-campus materials, regardless >>> of where the material is located (currently the user must use vastly >>> different procedures depending on which offsite location the materials are >>> stored at - and a single archive may have materials in 2 or more different >>> locations) >>> >>> It's not a shopping cart model, and specifically doesn't solve the problem >>> of enforcing Special Collections request limits across multiple archives. >>> (In reality, for us, those limits are a little mushy, and all requests with >>> limits are mediated - that is, it's up to the division's public service >>> manager to decide whether an extra box will fit on the truck on Wednesday.) >>> >>> But in case it's useful, here's the current UI design spec: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stanford.box.com_s_vqiy70jdh8jqmgg3s39e6ivk717rfln2&d=AwIDAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=FlU_ig33o98uJUfe7Tv5TWs-EbGWSS7i3RH_JUJdg9A&m=6UdSZ1rrZoFsIaBjPrmRD533TzPnVtgTTUseUWocC28&s=TH9Wik3bsPQUcHInrWVqww3EIY3Mm-TqojGUzz8Paf0&e= >>> >>> Feel free to contact me with any questions. >>> >>> Jennifer Vine >>> User Experience Designer >>> Digital Library Systems & Services >>> Stanford University Libraries -- -- Gary Thompson -- Project Manager -- Digital Initiatives & Information Technology -- UCLA Library -- 390 Powell -- voice: 310.206.5652 --
