ajkiessl
commented
6 months ago Some more notes on this from the Grad School can be found here: https://pennstateoffice365.sharepoint.com/:w:/r/sites/GraduateSchool-UniversityLibrariesWorkingGroup/_layouts/15/Doc.aspx?sourcedoc=%7BF3F3337C-2D9B-44C6-B1C7-6AE997CA1248%7D&file=ETD%20to%20LP%20Meeting%20Agenda.docx&action=default&mobileredirect=true
I've labeled this an epic since there are several components to it that can be broken out into their own issues.
The first component is to pull and store the "Candidate Number" (SSR_RS_CANDIT_NBR ) for students from LionPATH (LP). This will be added to the end of the student program data we are already getting. Considering this, I also assume that each record will have a unique candidate number. So, if a single student has a Master's Thesis and Dissertation record, each would have their own candidate number. This number can then be used to identify which record should be updated in LionPath when we send data back to LionPath.
The next part is sending data back to LionPath. We discussed a REST API, but never who would be building it and who would be building an integration with it. Some of the data requires real-time updates, so in this case we would probably have to export from ETDA into some webservice that the LP team has built. For more general data that does not need real-time updates, we could just have a simple REST API on our end for the LP team to integrate with. The LP team has a document with the data needed, and how it maps up with data in ETDA.
The final component is to let LP know when a submission has been cancelled or administratively rescinded. Submissions can be deleted in ETDA by admins, so we could send a request out to LP at that point to update a record in their system letting them know it's been deleted. We also automatically delete some submissions if they are no longer in LP. We don't store any information about things that have been rescinded.