platform icon indicating copy to clipboard operation
platform copied to clipboard
verified publisher icon wellcomecollection

Axiell Collections Requesting integration research

Open kenoir opened this issue 8 months ago • 1 comments

This issue is to research the use of Axiell Collections as a potential replacement for the existing Sierra requesting public catalogue integration.

Using https://webapi.axiell.com/Topics/Home.htm

The output of this work will be a document describing:

  • Are there any major blockers to this proceeding?
  • What are the risks and opportunities to this approach?
  • What further information do we need to draw a conclusion?
  • What are the potential knock-on effects for a CMS/LMS sync?

kenoir avatar May 12 '25 15:05 kenoir

Requirements

  • GET requesting status for an item, ie. can it be requested at all, ever? This is recorded by the catalogue-pipeline and makes it so that the catalogue-api /items endpoint only gets hit for items that can be requested
  • GET availability status of a "requestable" item, ie. is there already a hold on it? Has its status changed (eg. from "open" to "temporarily unavailable")?
  • GET the location of an item (to figure out when it can be available in the RMR)
  • POST a hold on an item
  • GET list of holds for a user
  • CRUD operations for patron account

agnesgaroux avatar May 27 '25 09:05 agnesgaroux

Axiell Collections web api doesn't expose /patron, /items or /hold endpoints like the ones we use in Sierra to perform operations related to patrons and items requesting

However we have the option of creating dedicated databases to cover these needs Once the databases and API have been configured, the Write API allows for record insert, update and delete. The Search API covers read functionality The web API covers user authentication/login https://webapi.axiell.com/Topics/User%20authentication%20setup.html but it is unclear how a service such as the catalogue-api request service would authenticate

  • Risks

Unfamiliarity with the Axiell Collections database and API configuration

More effort needed to define API and database to fit our needs, in a system we won't have ownership of (Managed by collection product line eventually?), with other stakeholders

LMS still to be defined, which will affect data sync.

  • Opportunities

Redefine the data sync requirements: provided item requesting is the only functionality that makes the data sync necessary, we can pull only the data that is strictly necessary

Redefine "rules for requesting": currently what makes an item "requestable" is based on a complex combination of fields and rules that are duplicated across the platform. There is room for improvement here, in consultation with the Collection teams, to make this a more explicit property on the items

Ability to configure databases and API to our needs

  • Further information needed

Confirm that the CALM/Sierra sync exists only to enable items requesting

What data would need to be sync'd in order to replicate the item requesting functionality currently provided by Sierra?

  • Potential knock-on effect on CMS/LMS sync

agnesgaroux avatar May 29 '25 07:05 agnesgaroux