110 likes | 209 Views
Developer Meets Developer Meeting Jerusalem, November 2010 Jiří Rataj University of Economics, Prague www.vse.cz. Integration between Aleph and external payment systems. University of Economics. Aleph from 2003 130.000 titles, 240.000 items, 3 branches, ~50 staff
E N D
Developer Meets Developer Meeting Jerusalem, November 2010 Jiří Rataj University of Economics, Prague www.vse.cz Integration between Aleph and external payment systems
University of Economics • Aleph from 2003 • 130.000 titles, 240.000 items, 3 branches, ~50 staff • 13.000 active patrons, >60.000 payment transactions/year • MULTIDATA Praha – Ex Libris systems support & distributor in Czech Republic and Slovakia, ~20 Aleph customers
Payment systems interfaces • National Technical Library, Prague (STK) • Czech University of Life Sciences, Prague (CZU) • University of Economics (UEP, not yet in production) • University of South Bohemia in České Budějovice (JCU, not yet in production)
STK • GUI has PS as default payment mode • Fully automatic payments • Existing z31: sql update, PS “pay” request ↔ response → sql commit (paid) / rollback • Computed fines (not in z31): X Server bor-info, PS “block” request (all fines plus debit balance), PS response not relevant for Aleph (not paid, decreased disposable PS credit) • XML request / response over https, proprietary protocol
CZU • Default GUI payment mode is Cash • “External System” payment mode • SmartCard Terminal connected to network (or to staff PC) • GUI ↔ Aleph server (external program) ↔ SmartCard Terminal, patron intervention (PIN enter) • SOAP proprietary protocol
Challenges • Not well documented – all three versions of “Aleph and e-Payments*.pdf” on docportal have the same misleading tab_external_program description
Challenges • External program input • Aleph passes too few possible arguments to an external program, necessary usage of sql for obtaining more data (like card number from z308) • Program parameters are “id”, “sum”, “credit”, “action” and “client-ip-addres”, not z31-*
Challenges • External program output • Reply value of “00\n...\n” shall be required for “payment accepted” result but is not – Aleph accepts empty response (i.e. after external program error or timeout) • External program reply message (transaction no.) goes to Z31_PAYMENT_IDENTIFIER • Only 20 characters accepted for VARCHAR(30) • Can be overriden by GUI “Payment identifier” (30 possible characters from GUI)
USAGE STATISTICS • STK: 99.6% payments through PS, 97% in fully automatic mode without staff or patron intervention • CZU: 1-6% payments through PS, 0% without staff and patron intervention
Questions? • Jiří Rataj • rataj@cuni.cz