Course Reserves
(UXPROD-791)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q2 2020 | Parent: | Course Reserves |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Kelly Drake | Assignee: | Kelly Drake |
| Resolution: | Done | Votes: | 0 |
| Labels: | courses, po-mvp, team-mvp | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
| Σ Original Estimate: | Not Specified | Original estimate: | Not Specified |
| Sub-tasks: |
|
||||||||||
| Epic Link: | Course Reserves | ||||||||||
| Front End Estimate: | Very Small (VS) < 1day | ||||||||||
| Front End Estimator: | Mike Taylor | ||||||||||
| Back End Estimator: | Kurt Nordstrom | ||||||||||
| Development Team: | Thor | ||||||||||
| PO Rank: | 80.3 | ||||||||||
| Rank: Chalmers (Impl Aut 2019): | R5 | ||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||
| Rank: Cornell (Full Sum 2021): | R2 | ||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 |
| Description |
|
Develop functionality for integration of Course Reserves with Discovery platforms such as VuFind and EDS as well as other Course Reserves platforms such as Ares. Adhere to LTI standards for LMS and Courseware. |
| Comments |
| Comment by Mike Taylor [ 23/Sep/19 ] |
|
Kelly Drake Is there any particular reason why this issue is listed as blocking
|
| Comment by Kelly Drake [ 23/Sep/19 ] |
|
Mike Taylor No idea why it's listed as blocking. I'll try and take that off. |
| Comment by Mike Taylor [ 23/Sep/19 ] |
|
That's better, thanks! |
| Comment by Mike Taylor [ 25/Sep/19 ] |
|
Most of this will be done in the back-end, hence the low front-end estimate. |
| Comment by Mike Taylor [ 31/Oct/19 ] |
|
We discussed this in today's call. First thing: although there are various integrations we want to support (VuFind, EDS, Ares), the one needed by FLO early in the process is VuFind, so we aim to focus our effort on that. I have accordingly created sub-task
Second thing: there are two basic approaches we can take to this work. A. Provide a facility in the Course Reserves UI for exporting the courses-and-reserves information in a format that the integration target (e.g. VuFind) can ingest. It is then up to the integration target to periodically obtain such an export dump and import it. B. Have the integration target (e.g. VuFind) periodically poll the Course Reserves module to obtain the information it needs, bypassing the UI. During the call, we felt that approach A was preferable because it made fewer requirements on the maintainers of the integration-target installations. But on further reflection, that's not really true, as it requires them to go in via a UI they may not be familiar with to obtain an export dump, then run a manual process. So I now propose what I think is a better approach: C. A command-line script — separate from both the UI and the back-end module — issues requests to the back-end and assembles the results into the form required by the integration partner. Then maintainers can either run this process and its corresponding import manually or automate in whatever way they find easiest. This is the most flexible approach; and as a bonus, the script can be written by any of the developers, so it can be allocated to whichever of us has the least other work. Third thing: when generating export dumps, it will be nice to have the option of doing so incrementally, i.e. including only records that have been added or changed since the last export. But this is potentially complex to do — e.g. how do you indicate removed records? — so we will postpone it until we have the basic export and other basic Course Reserves functionality done. |
| Comment by Mike Gorrell [ 31/Oct/19 ] |
|
Have you talked to Demian Katz of VuFind about these options - and pros/cons of each? |
| Comment by Demian Katz [ 31/Oct/19 ] |
|
VuFind is quite flexible when it comes to course reserves – we offer two entirely distinct mechanisms to support them (one which does real-time lookups in the ILS via APIs, and one which relies on a Solr index maintained in VuFind), and when it comes to the "Solr index" approach, we offer a variety of options for pushing that data over (real-time API mechanism or arbitrary spreadsheet ingester). That's good news in the sense that you should be able to make this work one way or another; it's perhaps bad news in the sense that it doesn't give you a single obvious strategy for moving forward. In any case, I'm happy to answer questions here or set aside time for a quick call if I can help in any way! |
| Comment by Kelly Drake [ 31/Oct/19 ] |
|
Demian Katz Which option would be the most elegant? In the short term we are working with two variables.
|
| Comment by Demian Katz [ 31/Oct/19 ] |
|
Kelly Drake, if you can expose an API that provides the fields that VuFind expects, that gives the most flexibility, because it allows both the real-time route and the local-index route (since the local indexer can use the same mechanism as the real-time interface to populate the index). However, that assumes that our data models neatly align (which they may or may not – VuFind's assumptions were initially inherited from Voyager but have grown to accommodate many other systems), and it is probably more work than a simple CSV exporter. Bottom line: I think the API route is the "best" solution in terms of opening up the most options, but a simple export tool is almost certainly less work, and perhaps a better "minimum viable product." |
| Comment by Paul Hoffman [ 31/Oct/19 ] |
|
Personally, I prefer method D: an "observer" or "subscriber" on the FOLIO side of things is kept informed on three kinds of events/changes: (1) CRUD on courses, instructors, etc.; (2) CRUD on the objects that tie together holdings/items and reserves; and (3) circulation of things that are on reserves. This observer then translates these changes to the model that VuFind follows and "pushes" the changes to VuFind. But FOLIO doesn't seem to have any provision for "hooks" or "observers" or "subscriptions" or similar patterns. Our current practice is to periodically run a big ugly query against Voyager (and a few small, bearable queries). Currently, we do this every five minutes and it takes 10-15 seconds each time. As long as we can avoid this kind of nasty brute-force approach, I will be happy. |
| Comment by Mike Gorrell [ 01/Nov/19 ] |
|
Demian Katz how does VuFind know when to check the API for potential updates to Course Reserves information, when using API integration? |
| Comment by Demian Katz [ 01/Nov/19 ] |
|
Mike Gorrell, when configured in "real time" mode, VuFind queries the API whenever a user performs a course reserves query. When configured in "local index" mode, there is a command-line script that pulls data from the API and regenerates the index, and this can be scheduled as a cron job. |
| Comment by Mike Taylor [ 01/Nov/19 ] |
|
Demian Katz Great to hear how flexible VuFind is in this regard. We can certainly make one or more of these approaches work. If there is an impedence mismatch between the APIs that the Course Reserves module supplies natively and data model that VuFind wants to see, we can build a gateway pretty easily. We'll know more when the Course Reserves module has solidified further. Paul Hoffman Your "Method D" is elegant, but a lot more work. Given the extremely challenging timescales for Course Reserves development, that approach would be at best a "Version 2" priority. Some kind of periodic polling gets the job done in the mean time. |
| Comment by Demian Katz [ 01/Nov/19 ] |
|
Mike Taylor, sounds good to me! Let me know if you want to discuss the data model in more detail when the time comes. |
| Comment by Mike Taylor [ 01/Nov/19 ] |
|
Thanks, Demian Katz, I will do that! (I keep mistyping your name as "Debian", I guess my fingers have memorised that sequence and they override my brain!) |
| Comment by Paul Hoffman [ 01/Nov/19 ] |
|
Mike Taylor I agree that my Method D is not right for the near term, but I would love to see a system of hooks or a pub-sub implementation at some point down the road. |
| Comment by Mike Taylor [ 01/Nov/19 ] |
|
So would we all! |