Determine instructions for the integration of the Aeon request service with PULFALight

[jrgriffiniii]

Please see the existing documentation referenced in https://github.com/projectblacklight/arclight/issues/650#issuecomment-525792114

[jrgriffiniii]

There exists a test area in the institutional Aeon installation that we are permitted to use for testing integration. We have been provided with a set of credentials for using a separate, dedicated account for developing integration with the request service (please see the information shared in Shared-ITIMS-Passwords\aeon on LastPass)

[jrgriffiniii]

Normally the config/repositories.yml contains the mapping of form field elements which are used in order to construct the Aeon HTTP request:

      request_mappings:
        static:
          Notes: ''
          scheduledDate: ''
          AeonForm: 'EADRequest'
          RequestType: 'Loan'
          GroupingIdentifier: 'ItemVolume'
          GroupingOption_ReferenceNumber: 'Concatenate'
          GroupingOption_ItemNumber: 'Concatenate'
          GroupingOption_ItemDate: 'FirstValue'
          GroupingOption_CallNumber: 'FirstValue'
          GroupingOption_ItemVolume: 'FirstValue'
          GroupingOption_ItemInfo1: 'FirstValue'
          GroupingOption_Location: 'FirstValue'
        accessor:
          DocumentType: document_type
          Site: site
          Location: location
          ItemTitle: title

static identifies the field values which are constant between Aeon requests, and accessor specifies the SolrDocument methods which should be invoked in order to retrieve these values on a per-Document basis.

However, from my findings on the PULFA 2.0 application, there are form field names, which themselves, are dynamically generated:

{name: "ItemSubTitle_32101037692462", value: "Boyd, Alice: Correspondence, 4 ALsS to Cosmo Monkhouse"},
{name: "ItemTitle_32101037692462", value: "William Bell Scott Collection"},
{name: "ItemDate_32101037692462", value: "1890-1891"},
...

Unfortunately, I cannot find a means by which to generate these without overriding Arclight::Requests::AeonExternalRequest

[jrgriffiniii]

I have been progressing with this on https://github.com/pulibrary/plantain/compare/issues-39-jrgriffiniii-aeon-integration

[jrgriffiniii]

As repository configuration data is used in order to provide the Aeon configuration, I am going to try and override this as well (otherwise there will just be duplication here).

[jrgriffiniii]

https://github.com/pulibrary/plantain/commit/c04361d390f180281fcf970e67c48475353286ab overrides and introduces some Classes which render it possible to work with the Aeon request endpoint for containers which do not belong to any repository. Further, there were also dynamically-generated field names transmitted in the POST request which required some significant customization.

[jrgriffiniii]

What had been blocking me was finding where precisely the Aeon request number is generated from, and I've tracked this to https://github.com/pulibrary/pulfa/blob/production/webapp/xsl/component2html.xsl#L589

[jrgriffiniii]

I've been copying and comparing the POST form values between https://findingaids.princeton.edu/collections/C0959#arrangement and my ArcLight branch. I've matched them both, but I suspect that I might also be missing cookie values in the request forwarded to Aeon.

[jrgriffiniii]

The documentation for this should include the information which is transmitted to the Aeon web APIs.

[sdellis]

This is how an Aeon request works in PULFA 2.0: https://github.com/PrincetonUniversityLibrary/pulfa/wiki/How-Aeon-Requests-are-created-in-PULFA

[jrgriffiniii]

Progress has been made on this from https://github.com/pulibrary/pulfalight/tree/issues-39-jrgriffiniii-aeon-pulfa-indexing and https://github.com/pulibrary/pulfalight/tree/issues-39-jrgriffiniii-aeon-integration

[jrgriffiniii]

This should be advanced by pairing with the product owners and observing how users normally interact with the existing Aeon request workflow.

[tpendragon]

Requests are implemented. Follow on tickets will get created as we find issues.