integration between aleph and external payment systems developer meets developer meeting jerusalem,...
TRANSCRIPT
Integration between Aleph and external payment systems
Developer Meets Developer MeetingJerusalem, November 2010
Jiří RatajUniversity of Economics, Praguewww.vse.cz
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
