1. External Integrations Nathan Mealey, PSU

2. Key Integrations ●Authentication ●Patron loading ●Proxy setup ●Bursar out ●Invoices ●S/FTP servers ●*Everything demoed can be tested in sandbox now

3. Integrations ●There are other integrations (e.g. Z39.50) ●But these are all intertwined o How you load patrons affects authentication and matchpoints for bursar o How you setup FTP servers affects setup of other integrations o...

4. S/FTP Servers ●Alma uses FTP servers for data transfers ●Supports only FTP and SFTP ●FTP servers are setup separately from integrations ●Every integration uses a defined FTP server ●You could have as few as one...or many more

5. S/FTP Servers (cont’d) ●Setup (in Alma) is very simple ●Note Allowed FTP Servers table is not available during implementation

7. Patron Loading ●External patrons loaded as XML records in a larger XML file ●Max size for XML file = 4GB o Basically, you can load all patrons in one file ●XML sample and XSD file available in Alma developers network

8. Patron Loading (cont’d) ●Patrons loaded as external users (view sample) ●External fields can be edited in Alma but will be overwritten at next sync ●External users can have internal fields that will not be overwritten

9. Creating Patron XML Records ●Manually create and export a patron in Alma that mirrors your finished patron records ●Hand code a single patron record and test loading it ●Generate a single patron record and test loading it ●Generate a full patron record and load it

10. Patron Loading-Recommendations ●Start ASAP - it takes longer than you think to get it right ●Be sure to use field codes and not labels o Exporting sample records helps with this ●Plan your user IDs before doing your first full patron load ●Test early and often

11. Authentication ●Two authentication paths to plan for o Alma o Primo o Summit? ●User types will influence your authentication options o External users (users synced from an external data source) have to use external auth o Internal users can use either internal or external auth

12. Alma Authentication ●Available methods o Alma internal authentication o LDAP o Shibboleth ●Out of the box, C4 should plan on setting up staff users as internal users, even if they’ll be using LDAP or Shibboleth later on

13. Primo Authentication ●Available methods o Alma internal authentication o LDAP o CAS o Shibboleth ●Methods can be combined o Example: CAS for campus patrons and Alma internal for community borrowers o To do this, open a case with SF (example)example

14. Setting up Primo Authentication ●Work with ExL directly ●Make sure you’re identifiers (primary and additional) are setup properly ●Remember: Primary ID=not case sensitive, Additional IDs=case sensitive o Primo requires Additional IDs to be lowercase!

15. Proxy Setup ●Your proxy is setup in External Integrations ●Eresources and full-text services are setup to use the defined proxy ●Demo

16. Exporting Fines & Invoices ●Both will require you to work with your central IT ●XML files are exported that will need to be mapped and imported into campus financial system

17. Bursar Out ●Used for exporting fines/fees to campus financial system ●Selected fines/fees are exported in a single XML file o Similar to patrons ●Can be scheduled or run manually ●Exported XML is pretty bare-bones o Includes name, ID, item title, fine code, fine amount

18. Bursar Out (cont’d) ●After fines/fees are exported they are marked as closed in Alma ●You can setup multiple integrations for bursar out o E.g. export different fines/fees for different groups of patrons o Or export fines for different patron groups at different intervals

19. Bursar Out: Basic Setup ●Number of days before export ●Minimum amount to export ●User identifier to export with each fine o Must match the user record in financial system ●What fine/fees to export ●What user groups to export ●What library to export fines for

20. Bursar Out Recommendations ●List of fine codes available on SILS Docs o https://docs.orbiscascade.org/silsdocs/functional%2 0areas/systems/data-loading.html https://docs.orbiscascade.org/silsdocs/functional%2 0areas/systems/data-loading.html ●Test by creating fines by hand o Overdues cannot be done like this, and must be engineered ●Can be tested in Alliance sandbox if you are already live

21. Exporting Invoices ●Same as bursar, used for exporting invoices to campus financial system ●Invoices ready to be sent will be in status “Waiting to be sent“ ●Sent invoices will be in status “Sent to ERP”

22. Exporting Invoices Setup ●Pretty simple overall o Schedule (or not) o Where to drop files ●Hardest part is testing if you’re already live o Same as bursar, Alliance sandbox is a good option for this

23. Importing Invoice Payments ●The flip-side of exporting invoices ●Not required o Invoices awaiting payment can be manually updated ●Can be scheduled or run manually ●Two use cases o Importing real payment information o Importing financial system reference info

24. Importing Invoices Setup ●Payments import with two statuses o PAID o REJECTED ●Grab sample XML file from developer zone ●Hand-code XML import file to match with an exported invoice ●Share hand-coded file with whoever is creating XML file

25. More Info On SILS Docs ●https://docs.orbiscascade.org/silsdocs/functi onal%20areas/systems/https://docs.orbiscascade.org/silsdocs/functi onal%20areas/systems/ ●When in doubt, email the Systems Working Group with questions: sils- systemsreps@orbiscascade.orgsils- systemsreps@orbiscascade.org