MASARYKOVA UNIVERSITA FAKULTA INFORMATIKY

MASARYKOVA UNIVERSITA FAKULTA INFORMATIKY

Vyuzˇitı´ platebnı´ch termina´lu˚ v integrovany´ch rˇesˇenı´ch

DIPLOMOVA´ PRA´CE

Toma´sˇ Bukal

Brno 2006

Prohla´sˇenı´ Prohlasˇuji, zˇe tato pra´ce je my´m pu˚vodnı´m autorsky´m dı´lem, ktere´ jsem vypracoval samostatneˇ. Pra´ce byla rˇesˇena jako soucˇa´st vy´vojovy´ch pracı´ ve firmeˇ SoNet, orientovana´ na vyuzˇitı´ platebnı´ch termina´lu˚, a me´ vlastnı´ prˇ´ınosy explicitneˇ vyjmenova´va´ kapitola 8 te´to pra´ce, Za´veˇr. V pra´ci rˇa´dneˇ cituji s uvedenı´m u´plne´ho odkazu na prˇ´ıslusˇny´ zdroj vsˇechny zdroje, prameny a literaturu, ktere´ jsem prˇi vypracova´nı´ pouzˇ´ıval nebo z nich cˇerpal.

ii

Zada´nı´ Cı´lem pra´ce je vytvorˇenı´ sady programu˚, ktere´ budou podporovat vyuzˇitı´ platebnı´ch termina´lu˚ v integrovany´ch rˇesˇenı´ch (pokladna, parkovacı´ automat, elektronicka´ cˇerpacı´ stanice apod.). ˇ esˇenı´ bude zameˇrˇeno na: R • Nutne´ u´pravy bankovnı´ch protokolu˚ • Na´vrh a implementaci ECR protokolu • Automatickou uza´veˇrku a inicializaci termina´lu ´ pravy relevantnı´ch toku˚ procesu˚ •U • Tvorbu ovladacˇu˚ ´ pravu komunikacˇnı´ch protokolu˚ •U

Vedoucı´ pra´ce doc. Ing. Jan Staudek, CSc.

iii

Shrnutı´ Software pro platebnı´ termina´ly Hypercom Optimum T2100 a H2200 je napsa´n v jazyku C ve vy´vojove´m prostrˇedı´ Cross Studio, ktery´ vyuzˇ´ıva´ prˇekladacˇ gcc. Termina´l H2200 je bezobsluzˇny´ narozdı´l od termina´lu T2100. To znamena´, zˇe tento termina´l nevyzˇaduje vysˇkolenou obsluhu a slouzˇ´ı prˇ´ımo za´kaznı´ku˚m. Typicke´ vyuzˇitı´ je naprˇ. jako platebnı´ modul v parkovacı´ch automatech, v cˇerpacı´ch stanicı´ch a podobny´ch rˇesˇenı´ch bezhotovostnı´ch syste´mu˚. Dalsˇ´ı typ termina´lu nese oznacˇenı´ T2100, ktery´ narozdı´l od vy´sˇe uvedene´ho obsluhu vyzˇaduje. Typicke´ pouzˇitı´ je v supermarketech a obchodech, kde se prˇ´ımo platba kartou nabı´zı´. Jednotlive´ polozˇky na´kupu jsou zada´ny obsluhou do pocˇ´ıtacˇe, ktery´ pru˚beˇzˇneˇ pocˇ´ıta´ vy´slednou sumu. Konecˇna´ cˇa´stka, ktera´ musı´ by´t za´kaznı´kem za zakoupene´ zbozˇ´ı zaplacena, je posla´na na platebnı´ termina´l, jenzˇ provede platbu. Aby oba termina´ly mohly by´t prˇipojeny k ru˚zny´m syste´mu˚m, byl vyvinut protokol, ktery´ prˇeda´va´nı´ zpra´v zajisˇt’uje. Tato komunikace mu˚zˇe probı´hat s libovolny´m zarˇ´ızenı´m prˇes rozhranı´ RS-232. V te´to pra´ci je popsa´na komunikace termina´lu se syste´mem ovla´dajı´cı´ za´vory a vyda´vajı´cı´ parkovacı´ lı´stky, se syste´mem cˇerpacı´ch stanic a pokladnı´m softwarem. Jelikozˇ zobrazeny´m textu˚m a informacˇnı´m zpra´va´m termina´lu˚ by meˇlo rozumeˇt co nejvı´ce uzˇivatelu˚, oba typy jsou vybaveny jazykovy´mi mutacemi. Podporovane´ jazyky jsou zakompilova´ny prˇ´ımo do aplikace, nenı´ tedy mozˇne´ bez za´sahu do zdrojovy´ch textu˚ prˇidat prˇeklady do jiny´ch jazyku˚.

Klı´cˇova´ slova Sı´t’ovy´ model OSI, protokol, ISO 8583, SPDH, RS-232, Hypercom, H2200, T2100, K1100, RS-Net, platebnı´ karta, autorizacˇnı´ centrum, transakce, zˇurna´l

iv

Obsah 1 2 3

4

5

6

´ vod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . U 1.1 Pozˇadavky na termina´l . . . . . . . . . . . . . . . . Neˇco ma´lo do zacˇa´tku... . . . . . . . . . . . . . . . . . . Hypercom rˇesˇenı´ . . . . . . . . . . . . . . . . . . . . . . 3.1 Stazˇenı´ aplikace . . . . . . . . . . . . . . . . . . . . 3.2 Inicializace . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Nastavenı´ konfiguracˇnı´ch dat — TMS . . . 3.2.2 Za´kladnı´ struktura TMS dat . . . . . . . . . 3.2.3 Prˇenos inicializacˇnı´ch dat . . . . . . . . . . 3.3 Automaticka´ uza´veˇrka a inicializace termina´lu . . ´ pravy Base application pro termina´l T2100 . . . . . . U ´ cˇtenky . . . . . . . . . . . . . . . . . . . . . . . . 4.1 U 4.2 Vstupnı´ data . . . . . . . . . . . . . . . . . . . . . . 4.3 Bankovnı´ protokoly . . . . . . . . . . . . . . . . . . 4.3.1 ISO 8583 . . . . . . . . . . . . . . . . . . . . 4.3.2 SPDH . . . . . . . . . . . . . . . . . . . . . . 4.4 ECR protokol . . . . . . . . . . . . . . . . . . . . . Tvorba aplikace pro termina´l H2200 . . . . . . . . . . . 5.1 SDK do zacˇa´tku... . . . . . . . . . . . . . . . . . . . 5.1.1 Analy´za a specifikace vy´vojove´ho projektu 5.1.2 Analy´za a specifikace ECR protokolu . . . 5.1.3 Na´vrh aplikace a vytvorˇenı´ procesu˚ . . . . 5.1.4 Vytvorˇenı´ datovy´ch struktur . . . . . . . . ´ prava TMS tabulek . . . . . . . . . . . . . 5.1.5 U 5.1.6 Implementace inicializace termina´lu . . . . 5.1.7 Implementace protokolu ISO 8583 . . . . . 5.1.8 Tvorba process flow . . . . . . . . . . . . . 5.1.9 Zada´va´nı´ PINu . . . . . . . . . . . . . . . . 5.2 Pouzˇity´ hardware . . . . . . . . . . . . . . . . . . . ECR protokol . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Hlavicˇka protokolu . . . . . . . . . . . . . . . . . . 6.2 Data za´visla´ na typu zarˇ´ızenı´ . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 5 6 7 7 7 8 9 11 12 14 14 15 16 16 17 19 20 20 20 21 21 22 23 23 23 24 25 26 28 28 29

1

Obsah 6.2.1 Parametry prˇ´ıkazu˚ . . . KISS protokol . . . . . . . . . . 6.3.1 Forma´t zpra´v . . . . . . 6.3.2 Komunikace . . . . . . . Prˇ´ıjem zpra´vy . . . . . . Odesı´la´nı´ zpra´vy . . . . 6.4 Chybove´ zpra´vy . . . . . . . . . 6.5 Chyba komunikace . . . . . . . Implementace . . . . . . . . . . . . . 7.1 Podmı´neˇny´ prˇeklad . . . . . . . Za´veˇr . . . . . . . . . . . . . . . . . . ´ pravy bankovnı´ch protokolu˚ 8.1 U 8.2 Na´vrh a implemetace . . . . . . 8.3 Vyrˇesˇen proble´m s(e) ... . . . . . 8.4 Shrnutı´ . . . . . . . . . . . . . . 6.3

7 8

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

30 30 31 32 32 32 33 34 36 37 38 38 38 39 39

2

Kapitola 1

´ vod U Existence platebnı´ch karet snizˇuje starosti o finance jejich majitelu˚m, nemusı´ mı´t peneˇzˇenky plne´ papı´rovy´ch a kovovy´ch mincı´, odpada´ starost s tı´m, kolik peneˇz si vzı´t do restaurace, atd. V zahranicˇ´ı lze takte´zˇ platit kartou i vybı´rat z bankomatu, cˇa´stecˇneˇ odpada´ potrˇeba navsˇteˇvovat smeˇna´rny, abychom zı´skali cizı´ meˇnu. Banky poskytujı´ periodicke´ prˇehledne´ vy´pisy, ve ktery´ch si majitel u´cˇtu mu˚zˇe vyhleda´vat jednotlive´ transakce, kontrolovat cˇa´stky, mu˚zˇe zjistit, kolik peneˇz utratil a kolik vydeˇlal za meˇsı´c i za rok. Bezhotovostnı´ platebnı´ styk je pohodlneˇjsˇ´ı nejen pro majitele, ale i pro obchodnı´ky, platebnı´ karty se tudı´zˇ v soucˇasnosti pouzˇ´ıvajı´ v hojne´ mı´rˇe. Pra´veˇ proto, zˇe se platebnı´ karty staly soucˇa´stı´ beˇzˇne´ho zˇivota, je potrˇeba rozsˇ´ırˇit jejich pouzˇitelnost a umozˇnit pohodlneˇjsˇ´ı platby. Tato pra´ce je zameˇrˇena na 3 syste´my, ktere´ jsou denneˇ ve velke´ mı´rˇe vyuzˇ´ıva´ny. Snad nejstarsˇ´ı ze syste´mu˚, do ktere´ho se vyplatı´ implementovat mozˇnost bezhotovostnı´ch plateb, je na´kup zbozˇ´ı, potravin, platba ubytova´nı´, platba v restauracˇnı´ch zarˇ´ızenı´ch, atp., zkra´tka syste´m obchodu. Implementace bezhotovostnı´ch plateb v tomto syste´mu nebude prˇ´ılisˇ na´rocˇna´. K pokladneˇ, ktera´ pocˇ´ıta´ vy´sledne´ obnosy peneˇz, je prˇipojen platebnı´ termina´l, jenzˇ provede strhnutı´ vypocˇ´ıtane´ cˇa´stky z u´cˇtu za´kaznı´ka. Pokladna posı´la´ pozˇadavky na termina´l, ktery´ po jejich zpracova´nı´ odesı´la´ do autorizacˇnı´ho centra transakce informujı´cı´ bankovnı´ syste´m o provedene´ platbeˇ kartou. Tato transakce je nazy´va´na Purchase (Prodej). Autorizacˇnı´ odpoveˇd’ je transformova´na v termina´lu na odpoveˇd’ pro pokladnu, ktera´ ji zpracuje. Zpeˇtna´ odpoveˇd’ je bud’ kladna´ cˇi za´porna´ v za´vislosti mimo jine´ na stavu u´cˇtu pla´tce. Cı´love´ zarˇ´ızenı´ je pote´ uveˇdomeˇno, zda penı´ze z u´cˇtu za´kaznı´ka byly prˇevedeny na u´cˇet obchodnı´ka, poprˇ´ıpadeˇ zda se transakce neprovedla. Cely´ podsyste´m bezhotovostnı´ platby v jednoduchosti rˇesˇ´ı problematiku tak, zˇe prˇi platbeˇ kartou termina´l obdrzˇ´ı cˇa´stku a cˇ´ıslo karty, tato data posˇle na autorizacˇnı´ centrum v prˇedem dohodnute´m forma´tu a odpoˇ a´dne´ jine´ vstupy a veˇd’, at’kladnou cˇi zamı´tavou, posˇle zpeˇt na pokladnu. Z vy´stupy subsyste´m bezhotovostnı´ch plateb nema´. Dalsˇ´ı oblastı´, kde je mozˇne´ vyuzˇ´ıt syste´mu bezhotovostnı´ch plateb, jsou 3

´ vod 1U provozovny cˇerpacı´ch stanic. Samozrˇejmeˇ, zˇe je mozˇne´ okopı´rovat tento syste´m od vy´sˇe uvedene´ho, ale tentokra´t se pra´ce bude zaby´vat na´vrhem bezobsluzˇne´ho syste´mu. V samotne´ cˇerpacı´ stanici nenı´ potrˇeba obsluhy, ktera´ by obstara´vala platby na termina´lech, zde si kazˇdy´ za´kaznı´k provede platbu za nabrane´ pohonne´ hmoty sa´m. Prˇi prˇ´ıjezdu na cˇerpacı´ stanici za´kaznı´k zastavı´ u vybrane´ho stojanu, ktery´ chce pouzˇ´ıt k doplneˇnı´ na´drzˇe. Pote´ prˇistoupı´ k termina´lu, ktery´ je umı´steˇn ve venkovnı´ch prostora´ch tak, aby byl lehce dostupny´ a neprˇehle´dnutelny´, a vlozˇ´ı do neˇj svoji platebnı´ kartu. Termina´l pomocı´ transakce Preauthorization (Prˇedautorizace) provede zablokova´nı´ minima´lnı´ cˇa´stky na u´cˇtu za´kaznı´ka. Pokud je zablokova´nı´ u´speˇsˇne´, za´kaznı´kovi je povoleno termina´lem zvolit stojan, u ktere´ho bude cˇerpat. Zvoleny´ stojan je odblokova´n a prˇipraven k pouzˇitı´. Po natankova´nı´ ky´zˇene´ho objemu paliva mu˚zˇe za´kaznı´k sednout do vozidla a opustit cˇerpacı´ stanici. Prˇi vra´cenı´ pistole do stojanu syste´m cˇerpacı´ stanice vysˇle zpra´vu termina´lu, ktera´ obsahuje konecˇnou cˇa´stku a dalsˇ´ı u´daje potrˇebne´ k platbeˇ a termina´l provede strhnutı´ obnosu z u´cˇtu za´kaznı´ka. V tomto na´vrhu rˇesˇenı´ jsou prova´deˇny 2 po sobeˇ jdoucı´ transakce, z nichzˇ jedna zablokuje cˇa´stku na u´cˇtu za´kaznı´ka a druha´ strhne z tohoto u´cˇtu konecˇnou cˇa´stku, za kterou bylo porˇ´ızeno palivo. Prˇi druhe´m vlozˇenı´ karty termina´l je schopen vytisknout u´cˇtenku z transakce, ktera´ strhla skutecˇnou cˇa´stku z u´cˇtu. Dnesˇnı´ doba, ve ktere´ neusta´le naru˚sta´ pocˇet automobilu˚, nutı´ k vy´stavbeˇ parkovacı´ch mı´st usnadnˇujı´cı´ za´kaznı´ku˚m pohodlneˇjsˇ´ı prˇ´ıstup do na´kupnı´ch obchodu˚, na´kupnı´ch center, do strˇedu˚ meˇst i do mı´st, kde je vysˇsˇ´ı hustota lidı´. Za parkovacı´ mı´sta se musı´ platit, takzˇe i v tomto prˇ´ıpadeˇ se nabı´zı´ mozˇnost vyuzˇitı´ platebnı´ch termina´lu˚. Prˇece jen se mnohokra´t stalo, zˇe rˇidicˇ nema´ cˇ´ım zaplatit, protozˇe nema´ drobne´. Mu˚zˇe take´ disponovat kovovou mincı´ s veˇtsˇ´ı hodnotou, jenzˇe parkovacı´ automaty nerozmeˇnˇujı´. Tento syste´m mu˚zˇe by´t takte´zˇ rˇesˇen pomocı´ bezobsluzˇne´ho, bezhotovostnı´ho platebnı´ho termina´lu. V te´to pra´ci je navrzˇen na´sledujı´cı´ postup prˇi pouzˇitı´ parkovacı´ho automatu. Prˇi prˇ´ıjezdu na parkovisˇteˇ pu˚vodnı´ parkovacı´ syste´m prˇeda´ karticˇku za´kaznı´kovi, na ktere´ je ulozˇen cˇas prˇ´ıjezdu. Pokud chce za´kaznı´k opustit parkovisˇteˇ, musı´ tuhle karticˇku vlozˇit do automatu urcˇene´ho pro tyto platby. Parkovacı´ automat vypocˇ´ıta´ z rozdı´lu obou cˇasu˚ dluzˇnou cˇa´stku, kterou opeˇt posˇle na termina´l, ktery´ provede platbu. Podobneˇ jako u prvnı´ho prˇ´ıpadu i v tom to rˇesˇenı´ je odpoveˇd’ odesla´na zpeˇt automatu, ktery´ ji vyhodnotı´, a bud’ zpeˇt na karticˇku zapı´sˇe povolenı´ odjezdu (pokud platba probeˇhla u´speˇsˇneˇ) a nebo zobrazı´ chybovou zpra´vu a za´kaznı´k musı´ pouzˇ´ıt jiny´ zpu˚sob platby, poprˇ´ıpadeˇ zavolat odpoveˇdnou osobu. Po u´speˇsˇne´ platbeˇ je pouzˇita u vy´jezdu oznacˇena´ karticˇka vlozˇenı´m do jine´ho zarˇ´ızenı´ parkovacı´ho syste´mu, ktere´ zvedne za´voru a umozˇnı´ 4

´ vod 1U odjezd automobilu. Komunikacˇnı´ protokol mezi termina´lem a libovolny´m syste´mem je v podstateˇ jednoduchy´. Jelikozˇ syste´my mohou vyzˇadovat zarˇ´ızenı´ druhe´ho syste´mu a jednotlive´ komponenty mohou volat sluzˇby jiny´ch komponent druhe´ho syste´mu, byl navrzˇen protokol, ktery´ obsahuje smeˇrove´ informace (zdroj a cı´l, podobneˇ jako u IP komunikace). Protokol podporuje zası´la´nı´ zpra´v z neˇjake´ho zarˇ´ızenı´ A neˇjake´mu zarˇ´ızenı´ B a zajistı´, aby zarˇ´ızenı´ B mohlo odeslat zpra´vu zpeˇt zarˇ´ızenı´ A. Cela´ komunikace je vystaveˇna na modelu OSI. Kompletnı´ protokol obsahuje i nizˇsˇ´ı vrstvy, ktere´ zarucˇujı´ potvrzova´nı´ prˇijaty´ch zpra´v a znovu posı´la´nı´ ztraceny´ch. Protokol obsahuje sadu prˇ´ıkazu˚ pro kazˇde´ zarˇ´ızenı´, prˇ´ıkazy se deˇlı´ do neˇkolika skupin (syste´move´, uzˇivatelske´, na´sobne´ a informacˇnı´).

1.1 Pozˇadavky na termina´l Prˇi prˇ´ıchodu za´kaznı´ka a vlozˇenı´ jeho karty do termina´lu musı´ by´t prˇecˇteny informace o karteˇ (Track 2). Tyto informace mimo jine´ obsahujı´ PAN (Primary Account Number), cozˇ je cˇ´ıslo karty. Kazˇdy´ typ karty ma´ sve´ prˇedcˇ´ıslı´ a podle neˇj termina´l vyhleda´ na´zev karty, ktery´ pouzˇije k zobrazenı´ na displeji a na u´cˇtence. Podpora vı´ce bankovnı´ch protokolu˚. Termina´l musı´ by´t schopen rozlisˇit dle typu karty, jaky´ protokol pouzˇ´ıt resp. u ktere´ho centra ma´ by´t transakce autorizova´na.

5

Kapitola 2

Neˇco ma´lo do zacˇa´tku... Absolvova´nı´m se´rie sˇkolenı´ porˇa´dane´ firmou Hypercom kazˇdy´ u´cˇastnı´k kromeˇ velke´ho mnozˇstvı´ dokumentace zı´skal vy´vojove´ prostrˇedı´ pro tvorbu aplikacı´ pro zmı´neˇne´ uvedene´ typy termina´lu˚ a jeden vy´vojovy´ termina´l. Tento termina´l se vizua´lneˇ od produkcˇnı´ch lisˇil tı´m, zˇe meˇl na leve´ straneˇ vy´vod pro hardwarovy´ ladı´cı´ na´stroj, pomocı´ neˇhozˇ bylo mozˇno ko´d aplikace v termina´lu krokovat. Soucˇa´stı´ byl takte´zˇ uka´zkovy´ za´kladnı´ program platebnı´ aplikace zvany´ Base application, ktery´ obsahoval za´kladnı´ funkcˇnost (zobrazova´nı´ a procha´zenı´ menu, za´kladnı´ bankovnı´ protokol ISO 8583, meˇl zabudova´nu podporu tisku u´cˇtenek a dalsˇ´ı). Base application je vlastneˇ nejvysˇsˇ´ı vrstva softwarove´ho balı´cˇku dodane´ho prˇi sˇkolenı´. Z du˚vodu veˇtsˇ´ı pouzˇitelnosti zdrojove´ho ko´du aplikace je doda´va´no takte´zˇ HSDK (Hypercom Software Development Kit) a EMV kernel. Hypercom SDK obsahuje rˇadu funkcı´, ktere´ umozˇnˇujı´ prˇ´ıstup k hardwaru termina´lu. Pomocı´ desı´tek funkcı´ mu˚zˇe aplikace ovla´dat displej, tiska´rnu, externı´ komunikacˇnı´ port a port urcˇeny´ k prˇipojenı´ pin padu a vestaveˇny´ reproduktor. Je mozˇno rovneˇzˇ pomocı´ implementovany´ch funkcı´ termina´l restartovat a take´ jej uve´st do stavu, ve ktere´m je schopen nahra´vat vzda´leneˇ nove´ aplikace.

6

Kapitola 3

Hypercom rˇesˇenı´ Novy´ termina´l nema´ v sobeˇ prakticky zˇa´dnou softwarovou vy´bavu, jen firmware obsahujı´cı´ aplikacˇnı´ manazˇer slouzˇ´ıcı´ pro nastavenı´ termina´lu tak, aby byl schopen sta´hnutı´ platebnı´ aplikace, cozˇ je zpocˇa´tku asi nejdu˚lezˇiteˇjsˇ´ı.

3.1 Stazˇenı´ aplikace Termina´l je potrˇeba nastavit tak, aby byl schopen prˇipojit se na vzda´leny´ bod, ktery´ umozˇnˇuje stazˇenı´ aplikace. Kazˇdy´ typ termina´lu musı´ mı´t nastaveny ru˚zne´ parametry. Dial-up termina´lu je nutne´ nastavit telefonnı´ cˇ´ıslo, termina´lu komunikujı´cı´mu prˇes TCP/IP je potrˇeba sdeˇlit cı´lovou IP adresu a port. Samozrˇejmeˇ termina´l komunikujı´cı´ prˇes TCP/IP protokol musı´ mı´t nastavenu svoji IP adresu, masku sı´teˇ, ve ktere´ se nacha´zı´ a samozrˇejmeˇ bra´nu. Existujı´ i termina´ly s jiny´m typem prˇipojenı´, ale princip je stejny´. Vzˇdy musı´ by´t nastaven cı´lovy´ bod pro prˇ´ıjem aplikace.

3.2 Inicializace Samotne´ sta´hnutı´ aplikace do termina´lu neuvede termina´l do provozuschopne´ho stavu. Stejneˇ jako programy urcˇene´ pro beˇh ve zna´my´ch operacˇnı´ch syste´mech potrˇebujı´ prˇecˇ´ıst si sve´ nastavenı´, aby plnily spra´vnou funkci, stejneˇ tak i aplikace ulozˇene´ v termina´lu potrˇebujı´ mı´t neˇjake´ nastavenı´. Neˇktera´ rˇesˇenı´ spocˇ´ıvajı´ v ulozˇenı´ vesˇkery´ch potrˇebny´ch u´daju˚ prˇ´ımo s pomocı´ aplikace. Tahle metoda nenı´ prˇ´ılisˇ vhodna´, jelikozˇ technik musı´ ulozˇit do termina´lu vesˇkere´ informace drˇ´ıve nezˇ jej posˇle do provozu. Pokud vyda´va´ vı´ce termina´lu˚ jednomu obchodnı´ku, je nucen vsˇechny u´daje rucˇneˇ prˇepsat do vsˇech odesı´lany´ch kusu˚, i pokud jsou u´daje totozˇne´. Base application ma´ implementova´nu efektivneˇjsˇ´ı metodu nastavenı´ termina´lu. Tato metoda se nazy´va´ inicializace. Konfiguracˇnı´ data jsou ulozˇena ve staticke´ pameˇti, kde permanentneˇ zu˚sta´vajı´ jak po restartu termina´lu, tak i po jeho vypnutı´. Data je mozˇno sa-

7

3 Hypercom rˇesˇenı´ mozrˇejmeˇ prˇepsat. Podobneˇ jako stahova´nı´ aplikace i inicializace vyzˇaduje nastavenı´ cı´love´ho bodu, aby mohla by´t konfigurace prˇenesena. Toto nastavenı´ se takte´zˇ prova´dı´ v aplikacˇnı´m manazˇeru, rovneˇzˇ se zada´vajı´ hodnoty stejne´ho vy´znamu — telefonnı´ cˇ´ıslo, IP adresa, maska, bra´na. Je patrne´, zˇe konfiguracˇnı´ data jsou stahova´na vzda´leneˇ prˇes komunikacˇnı´ port. Aplikacˇnı´ manazˇer umozˇnˇuje nastavit ru˚zne´ cı´love´ stanice pro stazˇenı´ aplikace a inicializaci, ale v praxi se jedna´ o jedno a tote´zˇ mı´sto. Jak ma´ cı´lova´ stanice rozhodnout, zda termina´l pozˇaduje sta´hnutı´ aplikace cˇi sta´hnutı´ konfiguracˇnı´ch dat? Pro obeˇ sluzˇby se pouzˇ´ıva´ protokol ISO 8583, ktery´ v za´hlavı´ obsahuje identifika´tor pro smeˇrovacˇ. Blok pouzˇity´ pro smeˇrova´nı´ je nazy´va´n TPDU, jeho velikost je 40 bitu˚. Struktura zacˇ´ına´ u´vodnı´mi 8mi bity identifikujı´cı´, zˇe se jedna´ pra´veˇ o TPDU. Na´sleduje 16 bitu˚, ve ktery´ch je ulozˇen identifika´tor cı´le a zbyly´ch 16 bitu˚ je urcˇeno k za´znamu zdrojove´ho identifika´toru. Ke smeˇrova´nı´ dat se pouzˇ´ıvajı´ koncentra´tory, ktere´ obsahujı´ downlinkove´ a uplinkove´ karty, ktere´ mohou by´t pouzˇity pro ru˚zne´ typy komunikacı´. Je mozˇne´ na koncentra´tor poslat data vyta´cˇeny´m prˇipojenı´m (prˇes telefonnı´ linku na dialup downlinkovou kartu) a prˇeposlat da´le protokolem TCP/IP (IP uplinkovou kartou) neˇjake´mu programu. Ktera´ data jsou posla´na na kterou uplinkovou kartu je da´no pra´veˇ cı´lovy´m identifika´torem, nazy´vany´m NII. Protokolu ISO 8583 je veˇnova´n samostatny´ oddı´l v kapitole Bankovnı´ protokoly. 3.2.1 Nastavenı´ konfiguracˇnı´ch dat — TMS Zkratka TMS znamena´ Term-Master System. Tento syste´m navrzˇeny´ firmou Hypercom umozˇnˇuje vzda´lene´ nahra´va´nı´ konfiguracˇnı´ch parametru˚. Obsahuje sadu programu˚ slouzˇ´ıcı´ k vytvorˇenı´ databa´ze z definicı´ tabulek, modifikaci konfiguracˇnı´ch dat, spra´veˇ uzˇivatelsky´ch u´cˇtu˚ a samozrˇejmeˇ obsahuje serverovou aplikaci, pomocı´ nı´zˇ je mozˇno sta´hnout aplikaci do termina´lu a prove´st jeho inicializaci. Jak jizˇ vy´sˇe bylo zmı´neˇno, konfiguracˇnı´ data jsou ulozˇena v databa´zi. Kazˇda´ polozˇka tabulky je nejen identifikova´na na´zvem a typem jak je tomu u SQL databa´zı´, ale obsahuje i dalsˇ´ı polozˇky, ktere´ jsou vyuzˇity pro specifikaci vstupnı´ch ovla´dacı´ch prvku˚ ve formula´rˇi, do ktere´ho se data zada´vajı´. Nejdu˚lezˇiteˇjsˇ´ı a za´rovenˇ nejpouzˇ´ıvaneˇjsˇ´ı jsou na´sledujı´cı´ polozˇky: Name: slouzˇ´ı jen k pojmenova´nı´ zadane´ hodnoty. Type: podle typu se rozlisˇuje, jaky´m zpu˚sobem se s daty pracuje. T oznacˇuje textovy´ na´pis, I index, P ukazatel do jine´ tabulky, N rˇ´ıka´, zˇe se jedna´ o cˇ´ıslo ulozˇene´ v BCD, A oznacˇuje rˇeteˇzec a L identifikuje jeden bit bitove´ho pole, ktere´ je ve formula´rˇi zna´zorneˇno pomocı´ zasˇkrta´vacı´ho polı´cˇka (checkbox). 8

3 Hypercom rˇesˇenı´ Width: urcˇuje, kolik bajtu˚ v databa´zi zabı´ra´ dana´ polozˇka. Hodnota 1 u typu N oznacˇuje BCD cˇ´ıslo v intervalu 00—99. Def: implicitnı´ hodnota, ktera´ je vlozˇena do databa´ze prˇi vytvorˇenı´ nove´ho profilu. U bitovy´ch map je pouzˇ´ıva´no oznacˇenı´ prˇ´ıtomnosti jednicˇkove´ho bitu jako Y a nulove´ho jako N. Page: aktua´lnı´ stra´nka formula´rˇe, do ktere´ho jsou zada´va´ny hodnoty. Row, Column: sourˇadnice oznacˇujı´cı´ rˇa´dek a sloupec, na neˇmzˇ je umı´steˇna dana´ polozˇka. Label: vyuzˇitı´ je pouze u polozˇek typu T a L. Ve formula´rˇi je u ovla´dacı´ho prvku zobrazen prˇ´ıslusˇny´ text. Special: zde lze zadat uprˇesnˇujı´cı´ prˇ´ıkazy pro dane´ polı´cˇko. Prˇ´ıkaz invert naprˇ´ıklad invertuje hodnotu u polozˇek typu L, tudı´zˇ Y znamena´ hodnotu bitu nula a N naopak hodnotu jedna. Zada´vanı´ rˇeteˇzcu˚ je umozˇneˇno implicitneˇ pouze velky´mi pı´smeny. Prˇ´ıkaz mixedcase povolı´ pouzˇ´ıt i maly´ch pı´smen. Prˇ´ıkazy mohou vytva´rˇet rolovacı´ seznamy (combobox) obsahujı´cı´ na´zvy polozˇek seznamu jine´ tabulky. Naprˇ´ıklad pokud pro termina´ly existujı´ ru˚zne´ sady fontu˚, je mozˇne´ pro dany´ termina´l vybrat font ze seznamu. Prˇ´ıkazy umozˇnˇujı´ prove´st odlisˇne´ reakce na uda´losti: filtrova´nı´, prˇ´ıkazy na pra´ci s blokem dat a jine´. Pomocı´ databa´ze lze sestavit formula´rˇ, do ktere´ho jsou zada´va´na data. Zobrazova´nı´ prova´dı´ program Profile Manager, ktery´ prˇecˇte jednotlive´ polozˇky tabulky, vygeneruje formula´rˇ a do jednotlivy´ch polı´cˇek formula´rˇe vepı´sˇe hodnoty z databa´ze. Uzˇivatel ma´ mozˇnost data zmeˇnit, ktera´ jsou upeˇt ulozˇena zpeˇt do databa´ze. 3.2.2 Za´kladnı´ struktura TMS dat Profile Manager k ukla´da´nı´ konfiguracˇnı´ch dat pouzˇ´ıva´ dveˇ okna. Jedno z nich obsahuje seznam tabulek, ktere´ jsou pouzˇity v nastavenı´ termina´lu. Poklepa´nı´m na neˇjakou polozˇku se ve druhe´m okneˇ zobrazı´ jednotlive´ za´znamy. Prˇi poklepa´nı´ na neˇjaky´ za´znam se zobrazı´ formula´rˇ s nastavenı´m. Jak jizˇ bylo vy´sˇe zmı´neˇno, termina´l musı´ spra´vneˇ zvolit autorizacˇnı´ centrum podle pouzˇite´ platebnı´ karty, pokud jejı´ rozsah ma´ ulozˇen v nastavenı´. K zobrazenı´ vztahu˚ mezi jednotlivy´mi tabulkami se v Profile Manageru pouzˇ´ıva´ strom, ktery´ je zobrazen pra´veˇ ve druhe´m okneˇ s jednotlivy´mi za´znamy pro danou tabulku. Na´sledujı´cı´ obra´zek zna´zornˇuje zobrazenı´ stromu. Seznam autorizacˇnı´ch center se nacha´zı´ v tabulce Acquirer a vydavatele´ karet v tabulce Issuer. Z obra´zku je patrne´, zˇe karty CARD01 a CARD02 jsou autorizova´ny v autorizacˇnı´m centru ACQ01 a karty CARD03, CARD04 a CARD05 naopak 9

3 Hypercom rˇesˇenı´

Obra´zek 3.1: Struktura TMS dat

v ACQ02. Pro veˇtsˇ´ı na´zornost na na´sledujı´cı´m obra´zku je zna´zorneˇna cˇa´st formula´rˇe tak, jak je pouzˇ´ıva´na prˇi editaci polozˇek. Na vyobrazene´ cˇa´sti je mozˇne´ videˇt, jake´ nastavenı´ existuje pro autorizacˇnı´ centrum. V autorizacˇnı´m syste´mu ma´ kazˇdy´ termina´l sve´ nastavenı´, je tedy nutne´, aby v Profile Manageru existovala mozˇnost nastavit Card Acceptor Terminal. Tento identifika´tor oznacˇuje termina´l v databa´zi autorizacˇnı´ho centra. Pokud je v nastavenı´ ulozˇeno vı´ce teˇchto center, kazˇde´ musı´ mı´t ulozˇeno spra´vne´ cˇ´ıslo termina´lu, aby byla mozˇna´ zpeˇtna´ identifikace. V TMS je tedy ulozˇen seznam identifika´toru˚ fyzicky´ch termina´lu˚, ktere´ byly nainstalova´ny, a kazˇde´ jejich autorizacˇnı´ centrum obsahuje identifika´tor logicke´ho termina´lu v dane´m autorizacˇnı´m syste´mu. Jeden obchodnı´k mu˚zˇe mı´t nainstalova´no vı´ce termina´lu˚. V tomto prˇ´ıpadeˇ kazˇdy´ termina´l obsahuje jine´ hodnoty polozˇky Card Acceptor Terminal, ale stejny´ identifika´tor pro polozˇku se jme´nem Card Acceptor Merchant. Jak bylo rˇecˇeno drˇ´ıve, termina´l musı´ by´t vybaven schopnostı´ sdeˇlit smeˇrovacı´mu zarˇ´ızenı´, kam jsou data urcˇena. Zpra´vu tvorˇ´ı dle nastavenı´ TPDU for Async Message a NII. Acquirer tabulka umozˇnˇuje ulozˇenı´ telefonnı´ho cˇ´ısla i IP adresy autorizacˇnı´ho centra, z cˇehozˇ plyne, zˇe pro IP termina´l i dialup termina´l existujı´ stejne´ definice tabulek, pouzˇ´ıva´ se stejny´ software pro editaci zmeˇn a prˇenastavit termina´l komunikujı´cı´ prˇes TCP/IP na termina´l pouzˇ´ıvajı´cı´ vyta´cˇene´ prˇipojenı´ je jednoduche´ a rychle´. Tabulky pro autorizacˇnı´ centrum obsahujı´ dalsˇ´ı komunikacˇnı´ nastavenı´, ktere´ bude popsa´no v na´sledujı´cı´ch kapitola´ch.

10

3 Hypercom rˇesˇenı´

Obra´zek 3.2: Tabulka konfigurace prˇipojenı´ k autorizacˇnı´mu centru

3.2.3 Prˇenos inicializacˇnı´ch dat Aby byl prˇenos konfigurace co mozˇna´ nejme´neˇ problematicky´ na cˇtenı´ prˇijaty´ch dat termina´lem a jejich rozdeˇlenı´ do jednotlivy´ch polı´cˇek formula´rˇu˚, jsou data za sebou bina´rneˇ posı´la´na v porˇadı´, v jake´m jsou ulozˇena v databa´zi. A pra´veˇ nejen zde je vyuzˇito informacı´ o jednotlivy´ch polı´cˇka´ch v definici tabulky. Zda hodnota atributu ma´ by´t posla´na cˇi nikoliv, oznacˇuje informace o typu dane´ho polı´cˇka. Nenı´ nutne´ sı´tı´ posı´lat jednotlive´ texty na formula´rˇi majı´cı´ informacˇnı´ schopnost pro uzˇivatele vypovı´dajı´cı´, k cˇemu je dane´ polı´cˇko pouzˇito. Termina´l zajı´majı´ pouze hodnoty. Sı´tı´ se posı´lajı´ pouze typy A (rˇeteˇzec), N (BCD cˇ´ıslo) a L (bitove´ pole). Sı´la tohoto rˇesˇenı´ je v tom, zˇe pokud aplikace v termina´lu ma´ definovane´ struktury jejı´zˇ jednotlive´ prvky jsou za sebou serˇazeny prˇesneˇ tak, aby korespondovaly s obsahem a porˇadı´m dat v databa´zi, je jednoduche´ ulozˇit hodnoty na spra´vne´ adresy jednotlivy´ch polozˇek struktury. Pro jednotlive´ tabulky (struktury) je v termina´lu ve staticke´ pameˇti vyhrazeno mı´sto, na ktere´ se konfiguracˇnı´ nastavenı´ ukla´da´. Procedura ukla´da´nı´ nastavenı´ je 11

3 Hypercom rˇesˇenı´ tedy velice prosta´. Prˇ´ıchozı´ data tabulky se ulozˇ´ı prˇesneˇ za sebou do pameˇti na vyhrazene´ mı´sto tak, jak prˇisˇly a aplikace k jednotlivy´m polozˇka´m prˇistupuje prˇes prvky struktury. Vesˇkera´ data tabulek jsou ulozˇena ve staticke´ pameˇti kvu˚li permanentnı´mu ulozˇenı´. Pokud je termina´l vypnut nebo restartova´n, nebylo by prˇ´ılisˇ uzˇitecˇne´ prova´deˇt neusta´le inicializace. Nemluveˇ o vy´voji a ladeˇnı´ aplikacı´. Mu˚zˇe se ale na druhou stranu sta´t, zˇe se neˇjaka´ data prˇepı´sˇ´ı. Do neˇktere´ z tabulek prˇibude nova´ hodnota a to zpu˚sobı´ posunutı´ ostatnı´ch struktur ulozˇeny´ch v pameˇti za zmeˇneˇnou tabulkou. Vsˇe je osˇetrˇeno. Jednotlive´ struktury obsahujı´ bezprostrˇedneˇ za svy´m poslednı´m prvkem kontrolnı´ soucˇet LRC a prˇed kazˇdou strukturou je ulozˇen jeden bajt identifikujı´cı´, zˇe se jedna´ o inicializovanou tabulku. Prˇi zmeˇneˇ libovolne´ hodnoty v libovolne´ tabulce se prˇepocˇ´ıta´va´ LRC a ukla´da´ bezprostrˇedneˇ za poslednı´ polozˇku struktury. Kdyzˇ termina´l vstoupı´ do za´kladnı´ho stavu, ve ktere´m je prˇipraven na vstup uzˇivatele, kontroluje u vsˇech tabulek hodnoty LRC i hodnotu identifikujı´cı´ho bajtu. Za´kladnı´ stav nasta´va´ po startu termina´lu, po ukoncˇenı´ transakce cˇi po skoncˇenı´ pru˚chodu v menu.

3.3 Automaticka´ uza´veˇrka a inicializace termina´lu Inicializaci termina´lu vzˇdy prova´dı´ technik spolu s obsluhou termina´lu. Cˇasto se sta´va´, zˇe obchodnı´k by ra´d meˇl jiny´ na´pis na u´cˇtence, jine´ porˇadı´ rˇa´dku˚ v za´hlavı´ nebo by si prˇa´l libovolnou zmeˇnu. V tomto prˇ´ıpadeˇ nenasta´va´ zˇa´dna´ komplikace. Obchodnı´k zavola´ do servisu a sdeˇlı´ sve´ pozˇadavky, ktere´ technik promı´tne do TMS nastavenı´ a za rovneˇzˇ jeho pomoci obchodnı´k prova´dı´ inicializaci termina´lu. Pokud se jedna´ o zmeˇnu nastavenı´ jednoho termina´lu, nenasta´va´ nikde zˇa´dny´ proble´m. Trosˇku se veˇc komplikuje, pokud na straneˇ servisu je potrˇeba udeˇlat neˇjaky´ za´sah. Instalovany´ch termina´lu˚ v provozu mu˚zˇe by´t i tisı´ce, a pokud je potrˇeba prove´st zmeˇny nastavenı´ u vsˇech, pak je cˇasoveˇ a financˇneˇ na´rocˇne´ vsˇem obchodnı´ku˚m volat a rˇesˇit s nimi inicializaci termina´lu. Pro tento prˇ´ıpad byla implementova´na v aplikaci funkce automaticke´ inicializace. Hlavnı´m du˚vodem, procˇ vznikla tato nova´ funkcˇnost, je stahova´nı´ novy´ch aplikacı´. Bude-li chtı´t banka upravit aplikaci, at’ uzˇ se jedna´ o zmeˇnu u´cˇtenek, prˇida´nı´ novy´ch funkcı´, poprˇ´ıpadeˇ zmeˇnu chova´nı´, je potrˇeba prove´st hromadne´ stazˇenı´ aplikace. Nastavenı´ automaticke´ inicializace je prova´deˇno v TMS, kde je zada´n cˇasovy´ interval, po jehozˇ uplynutı´ musı´ termina´l udeˇlat inicializaci. Tento interval je uda´va´n ve dnech. Pokud je hodnota nastavena na 1, automaticka´ inicializace je prova´deˇna kazˇdy´ den,

12

3 Hypercom rˇesˇenı´ pokud 0, automaticka´ inicializace je neaktivnı´. Jelikozˇ pomocı´ inicializace se stahuje vesˇkere´ nastavenı´ termina´lu, je potrˇeba mı´t prˇed touto akcı´ pra´zdny´ zˇurna´l (vyhrazene´ mı´sto v pameˇti pro uchova´va´nı´ schva´leny´ch transakcı´). Pak by mohlo nastat prˇepsa´nı´ dat, chybne´ prˇirˇazenı´ indexu˚, cozˇ by meˇlo za na´sledek sˇpatne´ prˇirˇazenı´ na´zvu˚ karet k transakcı´m, tudı´zˇ dı´ky posunutı´ dat by termina´l mohl poskytovat chybne´ vy´sledky. Z tohoto du˚vodu je kontrola automaticke´ inicializace prova´deˇna azˇ po uza´veˇrce. Termina´l zkontroluje, zda jizˇ uplynul zadany´ interval a pokud ano, provede automatickou inicializaci. Jelikozˇ je inicializace prova´deˇna azˇ po uza´veˇrce, je mozˇne´ prˇi nastavenı´ hodnoty intervalu na 1, kdy by meˇl by´t termina´l inicializova´n kazˇdy´ den, zˇe termina´l nepozˇa´da´ o sta´hnutı´ konfiguracˇnı´ch dat neˇkolik dnı´, pokud beˇhem teˇchto dnı´ nebude provedena uza´veˇrka. Termina´l je vybaven dalsˇ´ı automatickou funkcˇnostı´ a tou je automaticka´ uza´veˇrka. V beˇzˇne´ praxi by meˇla by´t prova´deˇna uza´veˇrka kazˇdy´ den, aby banky mohly zaha´jit prˇesun peneˇz z u´cˇtu˚ za´kaznı´ku˚ na u´cˇet obchodnı´ku˚ u transakcı´ Purchase a nebo naopak u transakcı´ Refund. Nastavenı´ automaticke´ uza´veˇrky se prova´dı´ opeˇt v TMS. Do polı´cˇka urcˇene´ho pro tuto funkci je zada´va´n cˇas (hodina, minuta) automaticke´ uza´veˇrky. Dı´ky nastavenı´ prˇesne´ho cˇasu je mozˇno termina´lu˚m sdeˇlit, kdy mohou prove´st uza´veˇrku tak, aby vı´ce termina´lu˚ nedeˇlalo stejny´ u´kol v jednu dobu a tı´m zahltily linky, prˇ´ıpadneˇ prˇetı´zˇily autorizacˇnı´ centrum.

13

Kapitola 4

´ pravy Base application pro termina´l T2100 U Pu˚vodnı´ aplikace dodana´ spolu s vy´vojovy´m balı´cˇkem by bez u´prav nezvla´dla uspokojit za´kaznı´ky ani u´speˇsˇneˇ projı´t certifikacemi. Tato aplikace obsahuje pouze za´kladnı´ funkcˇnosti, aby vy´voja´rˇ meˇl neˇjaky´ za´klad a nemusel vyvı´jet naprˇ. user interface, ktery´ je docela slozˇity´ a je prˇenosny´ na jine´ typy termina´lu˚.

Obra´zek 4.1: Termina´l T2100

´ cˇtenky 4.1 U Na prˇa´nı´ za´kaznı´ka jsou upravova´ny u´cˇtenky, ktere´ termina´l tiskne prˇi kazˇde´ transakci. Aby u´prava u´cˇtenek a tvorba novy´ch byla efektivnı´ a v ko´du prˇehledna´, firma Hypercom vyvinula a pouzˇila v Base application svu˚j jakoby programovacı´ jazyk, ktery´ pra´veˇ velice usnadnˇuje pra´ci s u´cˇtenkami. Jednotlive´ prˇ´ıkazy majı´ prˇirˇazenu hodnotu pomocı´ maker. Kazˇdy´ pouzˇity´ prˇ´ıkaz v programu zabı´ra´ pra´veˇ jeden bajt v pameˇti. Prˇ´ıkazy mohou mı´t take´ parametry, ktery´ch mu˚zˇe by´t libovolny´ pocˇet. Jelikozˇ vytvorˇeny´ ”ko´d” k tvorbeˇ u´cˇtenky je vlastneˇ pole bajtu˚, tak stejneˇ jako prˇ´ıkazy tak i jejich parametry zabı´rajı´ v pameˇti jeden bajt na pouzˇity´ parametr.

14

´ pravy Base application pro termina´l T2100 4U Termina´l umozˇnˇuje tisk fontu˚ ru˚zny´ch velikostı´ a stylu˚, podporuje zarovna´nı´ vlevo, vpravo a na strˇed, umozˇnˇuje tisk obra´zku˚ i cˇa´rovy´ch ko´du˚. Vesˇkery´ tento tisk je mozˇny´ pomocı´ vytvorˇene´ho jazyka, ktery´ podporuje i podmı´nky, takzˇe nabı´zı´ mozˇnost vytvorˇit u´cˇtenku vypadajı´cı´ prˇehledneˇ, dynamicky se meˇnı´cı´ dle nastavenı´ termina´lu, chova´nı´ karty, apod. Prˇ´ıklad definice u´cˇtenky, ktery´ tiskne text, jenzˇ je definova´n v tabulce Issuer, tucˇny´m fontem zobrazı´ na u´cˇtence na´zev karty, ktera´ byla pouzˇita prˇi platbeˇ a v za´vorce zobrazı´ informaci, zda data karty byla prˇecˇtena z magneticke´ho prouzˇku protazˇenı´m karty cˇtecˇkou a nebo zda cˇ´ıslo karty bylo zada´no manua´lneˇ na kla´vesnici termina´lu: IF, FLD_ADDTEXT, FLD_F, FLD_ADDTEXT, FC_TRIM, LINE, ENDIF, LINE, DOUBLE, TXT, Card, IF, FLG_ISS, ISOPT21, IS21_GROUPNAME, CARD_GROUPNAME, ELSE, FLD_F, FLD_CNAME, FC_TRIM, ENDIF, ’ ’, ’(’, IF, CND_MAN, ’K’, ELSE, ’C’, ENDIF, ’)’,NORMAL,

4.2 Vstupnı´ data Za´kladnı´ chova´nı´ platebnı´ aplikace musı´ podporovat vstup uzˇivatelem zada´vany´ch dat. Tato data jsou posı´la´na na autorizacˇnı´ centrum, kde jsou oveˇrˇena a transakce je bud’ schva´lena cˇi zamı´tnuta. Schva´lene´ transakce jsou uchova´va´ny v pameˇti termina´lu (zˇurna´l). V za´vislosti na typu transakce jsou od uzˇivatele pozˇadova´na rozdı´lna´ data. Pro zjednodusˇenı´ je dobre´ toto chova´nı´ vysveˇtlit na platebnı´ transakci Purchase a na transakci Void. Prˇi pru˚beˇhu transakce Purchase je od uzˇivatele pozˇadova´no cˇ´ıslo platebnı´ karty za´kaznı´ka, ktere´ mu˚zˇe obsahovat bud’ PAN a expiraci, pokud se jedna´ o manua´lnı´ zada´nı´ cˇ´ısla karty, a nebo kompletnı´ Track 2, ktery´ obsahuje jesˇteˇ dodatecˇne´ informace o karteˇ. Track2 je zı´ska´n prˇ´ımo z magneticke´ho prouzˇku karty, tudı´zˇ lze rozpoznat, zˇe transakce byla provedena za prˇ´ıtom15

´ pravy Base application pro termina´l T2100 4U nosti karty. Jakmile jsou zada´ny informace o pouzˇite´ karteˇ, na´sleduje zada´nı´ cˇa´stky, ktera´ ma´ by´t strhnuta z u´cˇtu za´kaznı´ka. Vsˇechna potrˇebna´ data jsou zna´ma a termina´l mu˚zˇe poslat transakci na autorizacˇnı´ centrum. Pokud je transakce schva´lena, termina´l ulozˇ´ı transakci do zˇurna´lu. Stornova´nı´ transakce mu˚zˇe by´t provedeno bez prˇ´ıtomnosti karty i bez zada´nı´ cˇa´stky. Tato transakce vyzˇaduje pouze cˇ´ıslo u´cˇtenky, podle ktere´ho termina´l vyhleda´ data k transakci v zˇurna´lu a odesˇle na autorizacˇnı´ centrum. Uzˇivatel nepotrˇebuje zada´vat zˇa´dna´ ostatnı´ data, protozˇe v zˇurna´lu je ulozˇeno cˇ´ıslo karty, cˇa´stka i cˇas transakce ke zrusˇenı´. Jak jizˇ bylo neˇkolikra´t zmı´neˇno, dodana´ aplikace prˇi sˇkolenı´ neobsahuje vı´ce funkcı´, ktere´ jsou pozˇadova´ny. Jedna´ se naprˇ´ıklad o zada´va´nı´ specificke´ho cˇ´ısla RRN, ktere´ je vyzˇadova´no prˇi stornova´nı´ transakce Preauthorization completion. Aplikace byla vybavena take´ o volbu jazyka u´cˇtenky uzˇivatelem. Pu˚vodnı´ Base application meˇla mozˇnost pouze vy´beˇru jazyku pro celou aplikaci. To znamena´, zˇe texty zobrazene´ na displeji a tisknute´ na u´cˇtenka´ch byly ve stejne´m jazyce.

4.3 Bankovnı´ protokoly ´ prava vstupnı´ch dat s sebou ruku v ruce nese i to, zˇe vznika´ nutnost U zadana´ data prˇene´st prˇed definovany´ protokol autorizacˇnı´mu centru. Jsou pouzˇ´ıva´ny 2 za´kladnı´ protokoly ISO 8583 a SPDH. Protokoly se za´sadneˇ lisˇ´ı a to nejen forma´tem posı´lany´ch dat, ale i koncepcı´ pravidel komunikace s autorizacˇnı´m centrem. 4.3.1 ISO 8583 Tento protokol patrˇ´ı do skupiny protokolu˚ vyuzˇ´ıvajı´cı´ zˇurna´l, cozˇ v praxi znamena´, zˇe je mozˇne´ pracovat s transakcemi, ktere´ protokol zpracoval jizˇ drˇ´ıve, ale jesˇteˇ prˇed uza´veˇrkou. Narozdı´l od na´sledneˇ popsane´ho protokolu SPDH, ISO 8583 nabı´zı´ mozˇnost stornova´nı´ libovolne´ transakce, ktera´ je ulozˇena v zˇurna´lu. Jelikozˇ protokol vyuzˇ´ıva´ zˇurna´l, musı´ termina´l ukla´dat vesˇkere´ transakce, ktere´ jsou pomocı´ neˇj provedeny a autorizova´ny. Prˇi samotne´ uza´veˇrce jsou v prvnı´ fa´zi posı´la´ny jen soucˇty transakcı´ — pocˇet debetnı´ch operacı´ a soucˇet jejich cˇa´stek, pocˇet kreditnı´ch operacı´ a soucˇet jejich cˇa´stek. Pokud se soucˇty na termina´lu neshodujı´ se soucˇty, ktere´ jsou uvedeny v autorizacˇnı´m centru, je termina´lu odesla´na odpoveˇd’, ve ktere´ je uvedeno, zˇe se soucˇty neshodujı´. V tomto prˇ´ıpadeˇ je nucen termina´l vsˇechny

16

´ pravy Base application pro termina´l T2100 4U sve´ transakce postupneˇ poslat na autorizacˇnı´ syste´m. Jakmile je prˇenos dat ukoncˇen, je ukoncˇena i uza´veˇrka a s prvnı´ transakcı´ je zalozˇen zˇurna´l novy´. Termina´l ke kazˇde´ transakci generuje jedinecˇne´ cˇ´ıslo u´cˇtenky, ktere´ se sta´va´ identifika´torem jednotlivy´ch transakcı´ a je posı´la´no v autorizacˇnı´m pozˇadavku. Pokud termina´l posˇle autorizacˇnı´ pozˇadavek a nevra´tı´ se mu odpoveˇd’, existuje pravdeˇpodobnost, zˇe zpra´va na autorizacˇnı´ host dosˇla, ale odpoveˇd’ se ztratila. Samozrˇejmeˇ se mu˚zˇe take´ sta´t, zˇe pozˇadavek nebyl prˇijat. V kazˇde´m prˇ´ıpadeˇ termina´l musı´ poslat reversal (specia´lnı´ Void transakce), ktery´ obsahuje pra´veˇ toto cˇ´ıslo u´cˇtenky, aby mohla by´t transakce ze syste´mu vymaza´na. Pokud byl autorizacˇnı´ pozˇadavek obdrzˇen, transakce je ze syste´mu vymaza´na, v opacˇne´m prˇ´ıpadeˇ transakce v syste´mu nikdy nebyla, tudı´zˇ se v obou prˇ´ıpadech jedna´ o konzistentnı´ stav. Odpoveˇd’ autorizacˇnı´ho centra by´va´ v obou prˇ´ıpadech kladna´. Protokol pouzˇ´ıva´ 8mi bitove´ ko´dova´nı´. Na zacˇa´tku zpra´vy se nacha´zı´ TPDU, 64bitova´ bitmapa, pote´ na´sledujı´ samotna´ data, ktera´ jsou reprezentova´na seznamem za sebou jdoucı´ch polı´cˇek prˇesneˇ definovany´ch typu˚. Pra´veˇ bitmapa urcˇuje, ktera´ polı´cˇka jsou pouzˇita a ktera´ nejsou. Z toho plyne, zˇe mu˚zˇe by´t celkem 64 polı´cˇek. Prˇi cˇtenı´ dat protokolu jeden ukazatel cˇte jednotlive´ bity v bitmapeˇ, a pokud prˇecˇte hodnotu 1, zjistı´ pozici bitu, prˇecˇte polı´cˇko definovane´ho forma´tu a pokracˇuje, dokud neprˇecˇte vsˇechna data. Protokol obsahuje neˇkolik datovy´ch typu˚, hodnoty mohou by´t prˇesneˇ definovane´ de´lky a nebo promeˇnne´. Polı´cˇko obsahujı´cı´ hodnotu promeˇnne´ de´lky ma´ na sve´m zacˇa´tku vlozˇenu informaci o de´lce hodnoty, ktera´ je ulozˇena v BCD. Dı´ky tomuto forma´tu protokol nabı´zı´ jednodusˇsˇ´ı a rychlejsˇ´ı cˇtenı´ dat. Jednotliva´ data ulozˇena v polı´cˇka´ch, za´kladnı´ typ je bud’ textovy´ (a—z, A—Z), cˇ´ıselny´ (0—9) a nebo specia´lnı´ (nenı´ definova´no protokolem). Tyto typy lze mezi sebou libovolneˇ kombinovat, vsˇechny znaky zı´ska´me pouzˇitı´m typu textove´ho, cˇ´ıselne´ho a specia´lnı´ho. 4.3.2 SPDH Protokol SPDH je vyvinuty´ spolecˇnostı´ ACI. Jak jizˇ bylo uvedeno vy´sˇe, narozdı´l od protokolu ISO 8583 nevyzˇaduje zˇurna´l, protokolu postacˇuje pouze uchova´va´nı´ celkovy´ch soucˇtu˚. Kazˇda´ autorizovana´ transakce je zanesena pra´veˇ do teˇchto soucˇtu˚, ktere´ obsahujı´ podobne´ informace jako u protokolu ISO 8583. V za´kladu se jedna´ opeˇt o pocˇet debetnı´ch operacı´ a jejich soucˇty a samozrˇejmeˇ o pocˇet kreditnı´ch operacı´ a jejich soucˇty. Prˇi uza´veˇrce jsou celkove´ sumy posla´ny na autorizacˇnı´ centrum, ktere´ zasˇle v odpoveˇdi sve´ soucˇty k porovna´nı´. Uza´veˇrka je vzˇdy schva´lena´, ale termina´l musı´ vytisk17

´ pravy Base application pro termina´l T2100 4U nout, zda soucˇty na termina´lu a v autorizacˇnı´m centru souhlası´ cˇi nikoliv. Pokud soucˇty nesouhlası´, proble´m se neprˇena´sˇ´ı na termina´l, ale reklamace jsou prova´deˇny v bance. Take´ v protokolu SPDH je pouzˇ´ıvana´ transakce reversal, ale trosˇku v jine´m smyslu a take´ ve vı´ce typech. Jelikozˇ protokol SPDH nepouzˇ´ıva´ zˇurna´l, nelze stornovat libovolnou transakci, ale pouze tu, ktera´ byla provedena jako poslednı´. Pokud nastane prˇ´ıpad, kdy termina´l vysˇle pozˇadavek a neobdrzˇ´ı odpoveˇd’, za´lezˇ´ı na konfiguraci autorizacˇnı´ho softwaru. Pokud umozˇnˇuje takzvany´ Timeout reversal, termina´l jej zasˇle. Aby se jednotlive´ transakce vyhnuly nekonzistentnı´mu stavu, veˇtsˇinou je s SPDH zpra´vou spojena i nizˇsˇ´ı vrstva POS2, ktera´ obstara´va´ potvrzova´nı´ zpra´v. V prˇ´ıpadeˇ, zˇe pozˇadavek se cestou ztratı´, vsˇe je v porˇa´dku, konzistentnı´ stav nenı´ narusˇen. Jestlizˇe pozˇadavek byl obdrzˇen a byla posla´na i odpoveˇd’, kterou termina´l neobdrzˇel, protokol POS2 neposlal potvrzenı´ prˇijetı´ a transakce je zrusˇena v autorizacˇnı´m centru. Dalsˇ´ı typ reversalu je User reversal. Tento typ termina´l posı´la´, pokud termina´l vyzˇaduje podpis na u´cˇtence a obsluha termina´lu po schva´lene´ transakci sdeˇlı´, zˇe podpis nesouhlası´. Pote´ je ihned vysla´n User reversal a drˇ´ıve schva´lena´ transakce je v autorizacˇnı´m centru smaza´na. Poslednı´ typ je Controller reversal, ktery´ posı´la´ termina´l, pokud nastala chyba ve zpracova´nı´ transakce v neˇktery´m z jeho procesu˚. V SPDH zpra´va´ch mu˚zˇe by´t vyuzˇito posı´la´nı´ MAC sˇifry a pokud termina´l neshleda´ tuto sˇifru validnı´, provede Controller reversal. To same´ se deˇje prˇi vytazˇenı´ cˇipove´ karty beˇhem transakce, kdy termina´l zjistı´, zˇe karta byla vytazˇena a nema´ k nı´ prˇ´ıstup. K tvorbeˇ zpra´vy pro User reversal a Controller reversal je pouzˇita odpoveˇd’ z prˇedem autorizovane´ transakce. Kazˇda´ zpra´va ma´ v hlavicˇce definova´n typ. Vysˇle-li termina´l financˇnı´ transakci, dostane na ni odpoveˇd’ a bude chtı´t prove´st neˇjaky´ typ reversalu, v odpoveˇdi zmeˇnı´ typ z financˇnı´ transakce na dany´ typ reversalu a takhle upravenou odpoveˇd’ posˇle na autorizacˇnı´ centrum. Z tohoto chova´nı´ protokolu lze snadno vycˇ´ıst, zˇe transakce uskutecˇneˇne´ prˇed poslednı´ transakcı´ nelze stornovat. V praxi se tento nedostatek rˇesˇ´ı vra´cenı´m peneˇz na u´cˇet za´kaznı´ka transakcı´ Refund (Na´vrat). Protokol SPDH pouzˇ´ıva´ 7mi bitove´ ko´dova´nı´. Protokol ma´ definova´nu hlavicˇku, pote´ na´sledujı´ data, definova´na jednotlivy´mi polı´cˇkami oddeˇleny´mi specia´lnı´mi znaky. V hlavicˇce protokolu je ulozˇeno sekvencˇnı´ cˇ´ıslo transakce (2 bajty), cˇ´ıslo termina´lu, cˇ´ıslo obchodnı´ka, datum a cˇas transakce, typ, podtyp a ko´d transakce, vlajky pro zpracova´nı´ pozˇadavku a ko´d odpoveˇdi. Na´sledujı´cı´ polı´cˇka obsahujı´ doplnˇujı´cı´ data. Kazˇde´ polı´cˇko je uvozeno znakem abecedy a pra´veˇ tento znak urcˇuje, o jake´ polı´cˇko se jedna´. Protokol rozezna´va´ velikost pı´smen, tudı´zˇ naprˇ´ıklad pı´smeno ”b” oznacˇuje 18

´ pravy Base application pro termina´l T2100 4U zasˇifrovany´ PIN blok a pı´smeno ”B” oznacˇuje cˇa´stku. V protokolu nejsou zˇa´dna´ polı´cˇka definova´na na pevnou de´lku, hodnota za jednotlivy´mi znaky musı´ by´t ukoncˇena specia´lnı´m znakem FS (field separator, hodnota 0x1c).

4.4 ECR protokol ECR protokol slouzˇ´ı ke komunikaci termina´lu s pokladnou. Tato Komunikace je pouzˇita v obchodech prˇi platba´ch kartou. Za´kaznı´k poda´va´ prodavacˇce zbozˇ´ı, ktere´ chce zakoupit, prodavacˇka zbozˇ´ı nacˇte do pokladny naprˇ. pomocı´ cˇa´rove´ho ko´du. Prˇi platbeˇ pokladna vypocˇ´ıta´ vy´slednou sumu zbozˇ´ı a vysˇle termina´lu zpra´vu o tom, aby strhl danou cˇa´stku z u´cˇtu za´kaznı´ka. Obsluha termina´lu jizˇ nezada´va´ cˇa´stku, pouze prota´hne kartou za´kaznı´ka a prˇ´ıpadneˇ zkontroluje, zda cˇ´ıslo karty je shodne´ s cˇ´ıslem zobrazeny´m na termina´lu. ECR protokol je vı´ce popsa´n ve zvla´sˇtnı´ kapitole, kterou si urcˇiteˇ zaslouzˇ´ı.

19

Kapitola 5

Tvorba aplikace pro termina´l H2200 Termina´l H2200 je bezobsluzˇny´. To znamena´, zˇe termina´l prˇ´ımo pouzˇ´ıvajı´ za´kaznı´ci a obsluha v tomhle prˇ´ıpadeˇ nenı´ nutna´. Bezobsluzˇny´ termina´l vyzˇaduje pouze zada´nı´ PINu. Ostatnı´ kontroly a zada´va´nı´ cˇa´stky obsluhou je v tomto prˇ´ıpadeˇ bezprˇedmeˇtne´.

Obra´zek 5.1: Termina´l H2200

5.1 SDK do zacˇa´tku... K tomuto typu termina´lu nebyla doda´na zˇa´dna´ Base application, sestavova´nı´ aplikace probı´halo zcela od zacˇa´tku a bylo postaveno cˇisteˇ na SDK pro tento termina´l. Pra´ce na vy´voji se uskutecˇnila v na´sledujı´cı´ch fa´zı´ch:

5.1.1 Analy´za a specifikace vy´vojove´ho projektu Jako jedna z nejdu˚lezˇiteˇjsˇ´ıch fa´zı´ je pra´veˇ tato. Je potrˇeba mı´t vizi, jak se termina´l bude chovat, s jaky´mi zarˇ´ızenı´mi prˇes jake´ porty a jak bude komunikovat, jaky´m zpu˚sobem nava´zˇe zpeˇtnou vazbu se za´kaznı´kem prˇi zada´va´nı´ PINu a jak se termina´l bude chovat co mozˇna´ nejuniverza´lneˇji.

20

5 Tvorba aplikace pro termina´l H2200 5.1.2 Analy´za a specifikace ECR protokolu Jak jizˇ drˇ´ıve bylo zmı´neˇno, nutnostı´ je kla´st velky´ du˚raz na protokol, ktery´ ma´ komunikovat s ostatnı´mi syste´my. Zˇa´da´ se robustnost, spolehlivost a univerza´lnost pouzˇitı´. Jelikozˇ termina´l je zarˇ´ızenı´, ktere´ plnı´ jen svoji malou cˇa´st v komplikovaneˇjsˇ´ım rˇesˇenı´, je zrˇejme´, zˇe se v syste´mu nemusı´ nacha´zet osamoceno. Nevy´hodne´ rˇesˇenı´ vı´ce syste´mu˚ je, aby kazˇdy´ cˇla´nek meˇl naprˇ. vlastnı´ displej, tiska´rnu, kla´vesnici, apod., pak by se obsluha syste´mu stala komplikovana´ a rˇesˇenı´ by bylo velice neprˇehledne´. Protokol byl navrzˇen tak, aby umozˇnˇoval sdı´lenı´ zarˇ´ızenı´, ktera´ jsou prˇipojena k jiny´m cˇa´stem syste´mu. Z du˚vodu pouzˇitı´ rozhranı´ RS-232 u termina´lu H2200 je v protokolu zabudovany´ kontrolnı´ soucˇet u kazˇde´ zpra´vy, implementova´no je cˇ´ıslova´nı´, potvrzova´nı´ a znovu posı´la´nı´ zpra´v. 5.1.3 Na´vrh aplikace a vytvorˇenı´ procesu˚ Za´kladnı´ procesy byly navrzˇeny dle pozˇadavku˚ okamzˇite´ho pouzˇitı´. Kazˇde´ zarˇ´ızenı´ v termina´lu, ktere´ je pouzˇito v aplikaci, ma´ svu˚j vlastnı´ proces. Dı´ky tomuto rˇesˇenı´ lze reagovat ihned na zmeˇnu stavu vsˇech zarˇ´ızenı´. Hlavnı´ proces prˇi startu termina´lu prova´dı´ kontrolu termina´lu, inicializuje ostatnı´ procesy a vypisuje informace o verzi syste´mu beˇhem startu aplikace. Po inicializaci vsˇech potrˇebny´ch modulu˚ zu˚sta´va´ ve smycˇce a zpracova´va´ pozˇadavky ostatnı´ch procesu˚ a prˇeda´va´ odpoveˇdi i posı´la´ prˇ´ıkazy. Jizˇ dlouho zminˇovany´ ECR proces obstara´va´ komunikaci s externı´m syste´mem. Proces je zodpoveˇdny´ za posı´la´nı´ a prˇ´ıjı´ma´nı´ zpra´v. Vyuzˇ´ıva´ ke sve´ cˇinnosti sı´t’ovy´ vrstvovy´ model OSI. V modelu jsou implementova´ny moduly, ktere´ tvorˇ´ı pra´veˇ ECR zpra´vu, ktera´ je posle´ze prˇenesena komunikacˇnı´m portem. Proces pouzˇ´ıva´ 3 buffery, aby dosa´hl optimalizace vy´konu. Cˇtecı´ buffer je pouzˇit na ulozˇenı´ prˇijate´ zpra´vy. Prˇi zpracova´nı´ prˇ´ıkazu termina´l musı´ odpovı´dat sta´le na dotazy externı´ho syste´mu, prˇecˇtena´ data jsou z cˇtecı´ho bufferu prˇenesena do bufferu pro zpracova´nı´. Cˇtecı´ buffer je opeˇt pouzˇit ke cˇtenı´ zpra´v. Trˇetı´ buffer je odesı´lacı´. Do neˇj jsou ulozˇena data potrˇebna´ k posla´nı´ k externı´mu syste´mu. Beˇhem posı´la´nı´ dat je mozˇnost jak ukla´dat prˇ´ıchozı´ data do cˇtecı´ho bufferu, tak i zpracova´vat drˇ´ıve prˇijatou zpra´vu. Termina´l musı´ by´t schopen beˇhem sve´ cˇinnosti take´ komunikovat s bankou a za´rovenˇ prova´deˇt i jine´ u´kony. Mezi procesy byl zarˇazen dalsˇ´ı, jehozˇ u´kolem je komunikace s autorizacˇnı´m centrem. I kdyzˇ se jedna´ v podstateˇ o tu stejnou cˇinnost jako u ECR procesu, komunikace s autorizacˇnı´m centrem je o mnoho jednodusˇsˇ´ı. Dotazy z externı´ch syste´mu˚ mohou prˇicha´zet neu-

21

5 Tvorba aplikace pro termina´l H2200 sta´le a termina´l musı´ by´t schopen pozˇadavky okamzˇiteˇ zpracovat. Jinak je tomu pra´veˇ u autorizace transakcı´. V prvnı´ fa´zi termina´l vysˇle pozˇadavek a cˇeka´ na odpoveˇd’. Po jejı´m prˇijetı´ prˇecˇte jednotlive´ hodnoty z prˇ´ıchozı´ch dat a koncˇ´ı komunikaci. Termina´l tedy iniciuje jako prvnı´ komunikaci s autorizacˇnı´m centrem, ktere´ po prˇijetı´ pozˇadavku z termina´lu odpovı´. Jina´ komunikace na tomto kana´lu neprocha´zı´. Z du˚vodu absence vı´ce portu˚ na termina´lu H220 je nutnost jeden port rozsˇ´ırˇit. Vytvorˇenı´m splitteru se proble´m zjednodusˇil. Jedna´ se o zarˇ´ızenı´ obsahujı´cı´ 3 komunikacˇnı´ porty. Data jsou vysı´la´na ze zdrojove´ho portu a prˇeposla´na na jeden ze zbyly´ch dvou, dle nastavenı´. Jelikozˇ na termina´lu H2200 se nacha´zejı´ pouze rozhranı´ RS-232, byl splitter navrzˇen tak, aby obstara´val prˇepı´na´nı´ mezi rozhranı´mi stejne´ho typu. V aplikaci prˇepı´na´nı´ portu˚ rˇesˇ´ı ovladacˇ prˇipojeny´ na proces, ktery´ nastavuje a vypı´na´ RTS signa´l na externı´m portu termina´lu. Prˇ´ıkazem je posla´n pozˇadavek procesu, aby prˇepnul komunikaci bud’ smeˇrem k autorizacˇnı´mu centru nebo smeˇrem na PIN pad. Jakmile je signa´l prˇepnut a je mozˇnost data vysı´lat na port, proces ozna´mı´ tuto skutecˇnost nastavenı´m uda´losti. Pokud nenı´ potrˇeba pozˇadavkem zmeˇnit smeˇr komunikace, uda´lost pro povolenı´ posı´la´nı´ dat je nastavena ihned. Poslednı´ proces je pouzˇit k ovla´da´nı´ cˇtecˇky karet. Termina´l nemu˚zˇe cˇ´ıst kartu na vyzˇa´da´nı´, za´kaznı´k mu˚zˇe vlozˇit kartu, i kdyzˇ o tento u´kon nebyl pozˇa´da´n. V tomto prˇ´ıpadeˇ je termina´l povinen kartu za´kaznı´ku vra´tit. U syste´mu˚, u ktery´ch existuje mozˇnost platby jak peneˇzi, tak i platebnı´ kartou, je vy´hodne´ pouzˇitı´ pra´veˇ tohoto procesu. Externı´ syste´m cˇeka´ bud’ na vlozˇenı´ peneˇz, poprˇ´ıpadeˇ na vlozˇenı´ platebnı´ karty. Jakmile je karta do termina´lu vlozˇena, proces posˇle hlavnı´mu procesu zpra´vu o tom, zˇe nastala uda´lost vlozˇenı´ karty, hlavnı´ proces vytvorˇ´ı informacˇnı´ prˇ´ıkaz o te´to skutecˇnosti a posˇle ji ECR procesu, ktery´ sestavı´ zpra´vu a posˇle ji externı´mu syste´mu, jenzˇ zablokuje mozˇnost vlozˇenı´ peneˇz. 5.1.4 Vytvorˇenı´ datovy´ch struktur Vy´voj aplikace pro bezobsluzˇny´ termina´l zacˇ´ınala implementacı´ ECR protokolu, aby byla mozˇnost programa´tora s termina´lem neˇjaky´m zpu˚sobem komunikovat. Jakmile termina´l rozpozna´va´ jednotlive´ prˇ´ıkazy, dalsˇ´ım krokem je nutnost jeho nastavenı´, tedy inicializace. Definice datovy´ch struktur je nutny´m dalsˇ´ım krokem. Jelikozˇ TMS tabulky jsou velice podobne´ pro termina´l T2100, byly pouzˇity i datove´ struktury ze zdrojovy´ch ko´du˚ pra´veˇ tohoto termina´lu. Polı´cˇka, ktera´ se zdajı´ by´t na prvnı´ pohled navı´c a nikdy nepouzˇitelna´, majı´ 22

5 Tvorba aplikace pro termina´l H2200 svu˚j vy´znam. Naprˇ´ıklad zu˚sta´vajı´ texty za´hlavı´ a za´patı´ na u´cˇtenky, i kdyzˇ termina´l nema´ tiska´rnu. Jak jizˇ drˇ´ıve bylo zmı´neˇno, pouzˇity´ ECR protokol umozˇnˇuje sdı´lenı´ zarˇ´ızenı´, tudı´zˇ texty jsou posı´la´ny ve zpra´va´ch syste´mu˚m, ktere´ umozˇnˇujı´ tisk. V tabulce Acquirer zu˚stalo nastavenı´ telefonnı´ch cˇ´ısel, pokud by bylo pouzˇito za´lohove´ rˇesˇenı´ s pouzˇitı´m externı´ch modemu˚. Tabulka Issuer zu˚sta´va´ beze zmeˇny. Ty´ka´ se nastavenı´ karet, ktere´ je u obou aplikacı´ naprosto stejne´. Samozrˇejmeˇ, zˇe pokud jsou neˇjaka´ polı´cˇka nepotrˇebna´, nahradı´ se v budoucnu jiny´mi a nebo se odstranı´ tak, aby existovala zpeˇtna´ kompatibilita s dosud nainstalovany´mi syste´my. Umaza´nı´ polı´cˇka, ktere´ nenı´ poslednı´ pouzˇ´ıvane´ ve strukturˇe, znamena´ posunutı´ na´sledujı´cı´ch polı´cˇek a tı´m ztra´ta kompatibility. ´ prava TMS tabulek 5.1.5 U Tabulky z termina´lu T2100 sice do jiste´ mı´ry dostacˇovaly, ale prˇece jen ne u´plneˇ. Aby termina´l H2200 mohl by´t instalova´n i v zahranicˇ´ı, musı´ po spusˇteˇnı´ aplikace zobrazit na´pisy v jazyce dane´ zemeˇ. Termina´l je pouzˇity´ ve vı´ce syste´mech, proto by se meˇl lisˇit i zobrazeny´ text, ktery´ je zobrazen, kdyzˇ termina´l je nevyuzˇ´ıva´n za´kaznı´ky. Tento text mu˚zˇe by´t trˇeba ”Parkovacı´ automat”, mu˚zˇe by´t i zobrazeno ”Dobry´ den” a nebo termina´l v necˇinne´m stavu cˇeka´ na vlozˇenı´ karty s textem ”Vlozˇte kartu”. Aby chova´nı´ termina´lu bylo co nejvı´ce prˇizpu˚sobitelne´, bylo prˇida´no do tabulky Terminal dalsˇ´ı nastavenı´. 5.1.6 Implementace inicializace termina´lu Inicializace termina´lu H2200 probı´ha´ podobneˇ jako u termina´lu T2100. Server, ktery´ poskytuje inicializacˇnı´ data, je stejny´, tudı´zˇ i protokol je stejny´. Prˇi implementaci inicializace termina´lu byl pouzˇit ko´d z aplikace pro termina´l T2100. Bylo zapotrˇebı´ pa´r u´prav, ktere´ nevyzˇadovaly stahova´nı´ neˇkolika tabulek, ktere´ nebyly pouzˇity vu˚bec. Byl odstraneˇn vesˇkery´ ko´d a vesˇkere´ za´vislosti, ktere´ byly se smazany´mi tabulky spjaty. 5.1.7 Implementace protokolu ISO 8583 Podobneˇ jako u inicializace termina´lu byl i zde vyuzˇit ko´d z termina´lu T2100, ktery´ sestavoval a cˇetl zpra´vy ve forma´tu ISO 8583. Termina´ly bezobsluzˇne´ a termina´ly vyzˇadujı´cı´ obsluhu majı´ urcˇite´ odlisˇnosti, ktere´ se projevı´ v datech posı´lany´ch na autorizacˇnı´ syste´m i na samotne´m chova´nı´ protokolu. Hodnoty jednotlivy´ch polı´cˇek zu˚sta´vajı´ ve veˇtsˇ´ı mı´rˇe stejna´ u obou typu˚ termina´lu˚, lisˇ´ı se jich jen ma´lo. Jedna´ se naprˇ. o Message typ a Processing 23

5 Tvorba aplikace pro termina´l H2200 code prˇi transakci Preauthorization void. Navı´c je zde pouzˇito nove´ polı´cˇko Currency code, sdeˇlujı´cı´ syste´mu, jaka´ meˇna je pouzˇita. Chova´nı´ protokolu je pozmeˇneˇno u chova´nı´ transakce Preauthorization. Tato transakce rezervuje na u´cˇtu za´kaznı´ka obnos, ktery´ je posla´n na autorizacˇnı´ centrum. Cˇa´stka nenı´ strhnuta z u´cˇtu, je pouze zablokova´na, aby obchodnı´k meˇl jistotu, zˇe za´kaznı´k disponuje alesponˇ teˇmito financemi. Tato transakce je velice vyuzˇ´ıva´na hotely, kdy za´kaznı´ku˚m prˇi ubytova´nı´ je pra´veˇ touto transakcı´ zablokova´na cˇa´stka, takzˇe hotel o tuto cˇa´stku neprˇijde. Prˇi ukoncˇenı´ pobytu je provedena transakce Preauthorization completion, ktera´ obsahuje cˇa´stku, kterou musı´ host opravdu zaplatit. Transakce Preauthorization se v termina´lu neuchova´va´, z du˚vodu jeho male´ pameˇti. Pokud by kazˇdy´ host v hotelu provedl prˇedautorizaci, bylo by ulozˇeno uzˇ mnoho dat a transakce by nemusely by´t provedeny z du˚vodu nedostatku pameˇti. Takte´zˇ vyhleda´va´nı´ by bylo o mnoho pomalejsˇ´ı a tudı´zˇ cela´ pra´ce s termina´lem. Termina´l T2100 prˇedautorizace neukla´da´ do zˇurna´lu, k dokoncˇenı´ prˇedautorizace je potrˇeba zna´t cˇ´ıslo u´cˇtenky, ktere´ je opsa´no z vytisknute´ u´cˇtenky prˇi prˇedautorizaci. U bezobsluzˇne´ho termina´lu H220 je pra´veˇ nutnost ukla´da´nı´ prˇedautorizace z neˇkolika du˚vodu˚. Za´kaznı´k nebude opisovat cˇ´ıslo u´cˇtenky do termina´lu, jedna´ se prˇece o bezobsluzˇny´. A navı´c pokud nastane neˇjaka´ chyba a nebo si za´kaznı´k rozmyslı´ platbu, nemusı´ opeˇt navsˇteˇvovat termina´l a rusˇit transakci, protozˇe termina´l si pamatuje potrˇebna´ data a je schopen ji zrusˇit automaticky. 5.1.8 Tvorba process flow Process flow u jednotlivy´ch rˇesˇenı´ vzˇdy zacˇ´ına´ cˇtenı´m karty. Termina´l obdrzˇ´ı prˇ´ıkaz ke cˇtenı´ karty a nebo implicitneˇ po startu aplikace cˇeka´ na vlozˇenı´ karty. Jakmile je karta vlozˇena, termina´l posı´la´ zpra´vu prˇes externı´ port ECR protokolem sousednı´mu syste´mu, ktere´mu ozna´mı´, zˇe karta byla vlozˇena. Ve zpra´veˇ jsou uvedeny za´kladnı´ informace o karteˇ: cˇ´ıslo karty, expirace a jme´no karty. Jakmile je zpra´va odesla´na, termina´l cˇeka´ na dalsˇ´ı pokyn. Ve zpra´veˇ je nutne´ uve´st, zda bylo cˇtenı´ karty u´speˇsˇne´. Karta sice mohla by´t vlozˇena, ale trˇeba opacˇnou stranou, mu˚zˇe by´t expirova´na, ale take´ nemusı´ by´t vlozˇena vu˚bec a cˇtenı´ karty se ukoncˇ´ı vyprsˇenı´m cˇasove´ho limitu. O vsˇem je informova´n sousednı´ syste´m, ktery´ rozhoduje, jak bude transakce pokracˇovat. Bud’ necha´ kartu vra´tit a nebo bude vyzˇadovat autorizaci v bance. Veˇtsˇinou nasta´va´ druha´ mozˇnost, prˇi ktere´ termina´l prˇijme zpra´vu s typem transakce, kterou ma´ prove´st a vesˇkery´mi potrˇebny´mi u´daji k vykona´nı´ transakce. Jakmile je prˇijmuta autorizacˇnı´ odpoveˇd’, termina´l posı´la´ informace o transakci externı´mu syste´mu, ktery´ prˇika´zˇe termina´lu, aby vra´til 24

5 Tvorba aplikace pro termina´l H2200 kartu. Nynı´ nasta´va´ konec procesu platby a termina´l cˇeka´ na dalsˇ´ı pokyny. Cely´ process flow komunikace je navrzˇen tak, aby termina´l byl schopen prˇijı´mat pozˇadavky externı´ch syste´mu˚ a plnil je. Prˇece jen termina´l je jen platebnı´ modul a tudı´zˇ nema´ mnoho pravomocı´ ovlivnit chova´nı´ cele´ho syste´mu. Aplikace je navrzˇena tak, aby zvla´dala vı´ce pozˇadavku˚. Nejen aby termina´l byl schopen odpovı´dat na dotazy beˇhem transakce, ale aby umeˇl i vykona´va´nı´ prˇedesˇly´ch pozˇadavku˚ ukoncˇit (ukoncˇit platebnı´ transakci, cˇtenı´ karty, apod.). 5.1.9 Zada´va´nı´ PINu Jediny´ vstup, ktery´ se od drzˇitele karty pozˇaduje beˇhem transakce na termina´lu, je zada´va´nı´ PINu. K tomuto u´cˇelu slouzˇ´ı PIN pad, ktery´ je prˇipojen na splitter. PIN pad je zarˇ´ızenı´, ktere´ je urcˇeno k vy´pocˇtu kryptograficky´ch dat, zvla´sˇteˇ pro vy´pocˇet MAC pro zpra´vu a pro generova´nı´ PIN bloku˚. Uzˇivatelem zadana´ hodnota PIN je zasˇifrova´na algoritmem, do ktere´ho vstupuje jak pra´veˇ zadany´ PIN, tak i cˇ´ıslo karty a vsˇe je zako´dova´no algoritmem 3DES s pouzˇitı´m master klı´cˇe, ktery´ je ulozˇen v PIN padu. Tento klı´cˇ nelze z PIN padu zˇa´dny´m zpu˚sobem prˇecˇ´ıst, prˇi narusˇenı´ PIN padu je klı´cˇ vymaza´n z pameˇti. Nahra´va´nı´ klı´cˇe probı´ha´ v bezpecˇne´ mı´stnosti banky, v te´to mı´stnosti je v urcˇitou dobu jen jeden cˇloveˇk, ktery´ zada´va´ pu˚lku master klı´cˇe do sˇifrovacı´ho zarˇ´ızenı´. Po zada´nı´ jedne´ pu˚lky odcha´zı´ z mı´stnosti a vcha´zı´ do nı´ druhy´ cˇloveˇk, ktery´ zna´ druhou pu˚lku. Sˇifrovacı´ zarˇ´ızenı´ posı´la´ zasˇifrovany´ master klı´cˇ do PIN padu, ktery´ prˇ´ıchozı´ data deko´duje a ulozˇ´ı cˇisty´ klı´cˇ na danou pozici (index). PIN pad (oznacˇenı´ K1100) komunikuje prˇes rozhranı´ RS232. Komunikace je nastavena na rychlost 115 200 baudu˚, 8 bitu˚, zˇa´dna´ parita a jeden stop bit. Samozrˇejmeˇ PIN pad disponuje nastavenı´m teˇchto parametru˚, ale v aplikaci je pouzˇito prˇesneˇ tato konfigurace. Jak uzˇ tomu bylo drˇ´ıve, zarˇ´ızenı´ komunikujı´cı´ prˇes stejne´ rozhranı´ pouzˇ´ıvajı´ textovy´ protokol. I v prˇ´ıpadeˇ PIN padu K1100 je pouzˇity´ protokol vy´robcem textovy´. Aplikace sestavı´ pozˇadavek, nastavı´ splitter tak, aby komunikoval s PIN padem, a vysˇle data, ktera´ obsahujı´ mimo jine´ index klı´cˇe, ktery´ se pouzˇ´ıva´ prˇi sˇifrova´nı´, cˇ´ıslo karty, pracovnı´ klı´cˇ a text k zobrazenı´ na displeji (naprˇ. ”Zadejte PIN”). Data, ktera´ jsou vra´cena v odpoveˇdi, obsahujı´ pozˇadovany´ PIN blok, ktery´ je zasla´n na autorizacˇnı´ centrum v pozˇadavku na schva´lenı´ transakce. Tento blok je rozsˇifrova´n a zadany´ PIN oveˇrˇen.

25

5 Tvorba aplikace pro termina´l H2200

5.2 Pouzˇity´ hardware Aby termina´l mohl komunikovat s uzˇivatelem, je potrˇeba, aby byl vybaven displejem. Vstup uzˇivatele je rˇesˇen prˇed dodany´ PIN pad, kde uzˇivatel zada´va´ svu˚j PIN v pru˚beˇhu transakce. Aby obeˇ zarˇ´ızenı´ nemeˇla zvla´sˇtnı´ port pro prˇipojenı´, termina´l obsahuje konektor pouze pro PIN pad, ke ktere´mu je prˇipojen textovy´ displej obsahujı´cı´ 4 rˇa´dky po 20ti sloupcı´ch. Jelikozˇ termina´l disponuje pouze dveˇma rozhranı´mi RS-232 nastala potrˇeba rozsˇ´ırˇit pocˇet portu˚ a prˇidat konvertor na IP, protozˇe k termina´lu je prˇivedena IP linka. V sekci, ktera´ je veˇnova´na problematice tvorby jednotlivy´ch procesu˚, je zmı´neˇno zarˇ´ızenı´ nazvane´ splitter. Jedna´ se o zarˇ´ızenı´, ktere´ rozsˇirˇuje jeden port na dva s omezenı´m, zˇe v jednu chvı´li lze komunikovat pouze s jednı´m zarˇ´ızenı´m prˇipojeny´m k jednomu cˇi druhe´mu portu. Splitter je velmi maly´ch rozmeˇru˚. Kabelem, na jehozˇ konci byl prˇipojen konektor RJ-45 s 10ti piny, je prˇipojen k termina´lu. Krajnı´ 2 piny jsou pouzˇity pro napa´jenı´ PIN padu. Na samotne´m splitteru, jsou umı´steˇny 2 konektory, opeˇt RJ-45 s 10ti piny pro zapojenı´ PIN padu a druhy´ CANNON DB-9 samice, pro zapojenı´ kabelu, ktery´ slouzˇ´ı k prˇenosu dat do IP koncentra´toru. Z du˚vodu absence takove´ho zarˇ´ızenı´ byla zada´na zaka´zka externı´ firmeˇ, ktera´ splitter dodala.

Obra´zek 5.2: Splitter RS-Net je komplikovaneˇjsˇ´ı zarˇ´ızenı´, konvertuje prˇ´ıchozı´ data z rozhranı´ RS-232 na TCP/IP a posı´la´ je prˇes beˇzˇneˇ pouzˇ´ıvany´ konektor RJ-45 UTP kabelem. Aby RS-Net poslal data na spra´vny´ cı´l, musı´ by´t prˇ´ıchozı´ data od termina´lu vybavena TPDU. Konvertor obsahuje v sobeˇ prˇes webove´ rozhranı´ nastavitelnou tabulku, ve ktere´ je rˇecˇeno, ktere´ NII je posı´la´no na jakou IP adresu a port. RS-Net mu˚zˇe mı´t v jednom cˇase otevrˇeno pouze jedno pojenı´, ale tato funkcˇnost je plneˇ dostacˇujı´cı´. Konvertor je pouzˇit ke 26

5 Tvorba aplikace pro termina´l H2200 komunikaci s autorizacˇnı´m centrem, nikdy neprobı´ha´ komunikace soucˇasneˇ s vı´ce centry za´rovenˇ.

Obra´zek 5.3: Sche´ma zapojenı´ potrˇebne´ho hardwaru k termina´lu H2200

27

Kapitola 6

ECR protokol ECR protokol slouzˇ´ı ke komunikaci termina´lu s ostatnı´mi zarˇ´ızenı´mi. Zkratka ECR znamena´ Electronic Cash Register, tedy pokladnu. U termina´lu T2100 je tento protokol pouzˇit ke komunikaci pra´veˇ s pokladnou, ale u bezobsluzˇne´ho termina´lu H2200 je protokol pouzˇit ke komunikaci s externı´m syste´mem a sdı´leny´mi zarˇ´ızenı´mi. Data jsou posı´la´na v textove´ podobeˇ — 7mi bitove´ ko´dova´nı´. Hlavicˇka struktury zpra´vy se skla´da´ z 5ti bajtu˚. Prvnı´ bajt oznacˇuje typ zpra´vy. Hodnota prvnı´ho bajtu mu˚zˇe by´t 0 oznacˇujı´cı´ prˇ´ıkaz (naprˇ. dotaz na verzi termina´lu), 1 je pouzˇita pro informacˇnı´ zpra´vu (naprˇ. byla vlozˇena karta), 2 je posı´la´na ve zpra´veˇ informujı´cı´, zˇe prˇijata´ zpra´va je chybna´. Nejedna´ se o chybu nizˇsˇ´ıch vrstev prˇi prˇecˇtenı´ sˇpatne´ho kontrolnı´ho soucˇtu. Zpra´va majı´cı´ v prvnı´m bajtu hodnotu 2 sdeˇluje, zˇe na termina´l prˇisˇla zpra´va, ktera´ nemu˚zˇe by´t zpracova´na. K dany´m typu˚m existujı´ odpoveˇdi na zpra´vy. Tyto typy majı´ hodnotu prvnı´ho bajtu zveˇtsˇenou o 5 oproti zpra´veˇ, na kterou odpovı´dajı´. Posˇle-li jeden uzel druhe´mu zpra´vu s hodnotou prvnı´ho bajtu 0, odpoveˇd’ druhe´ho syste´mu bude obsahovat hodnotu prvnı´ho bajtu cˇ´ıslo 5. Dı´ky tomuto syste´mu lze urcˇit, zda se jedna´ o dotaz cˇi odpoveˇd’. Na´sledujı´cı´ 2 bajty oznacˇujı´ zarˇ´ızenı´, ze ktere´ho data odesˇla a podobneˇ poslednı´ 2 bajty oznacˇujı´, ktere´mu zarˇ´ızenı´ jsou data urcˇena. Zbytek dat ECR zpra´vy za´visı´ na zarˇ´ızenı´, jenzˇ zpra´vu obdrzˇ´ı.

6.1 Hlavicˇka protokolu V hlavicˇce protokolu je jednotlivy´m polozˇka´m prˇirˇazen pra´veˇ tolik bajtu˚, kolik by meˇlo postacˇovat i prˇ´ıpadne´mu rozsˇ´ırˇenı´. Jeden bajt vyhrazen pro typ prˇ´ıkazu je dostacˇujı´cı´. Typ zpra´vy zvy´sˇeny´ o 5 znamena´ odpoveˇd’. Za´kladnı´ch typu˚ mu˚zˇe tedy by´t azˇ 5 s hodnotami 0 azˇ 4. Nynı´ je v protokolu vyuzˇito pouze dvou hodnot (0 pro prˇ´ıkazove´ zpra´vy, 1 oznacˇujı´cı´ zpra´vy informacˇnı´), ktere´ budou postacˇovat jesˇteˇ po dlouhou dobu, pra´veˇ proto nenı´ nutne´ prˇ´ılisˇ naddimenzova´vat tuto polozˇku. Jinak je tomu se zdrojovy´mi a cı´lovy´mi zarˇ´ızenı´mi. Zatı´m protokol pouzˇ´ıva´ v rea´lne´m prostrˇedı´ 5 zarˇ´ı-

28

6 ECR protokol zenı´: samotny´ termina´l, cˇtecˇka platebnı´ch karet, PIN pad, displej a zarˇ´ızenı´ oznacˇujı´cı´ sousednı´ syste´m. Pokud by zdrojove´mu a cı´love´mu zarˇ´ızenı´ byl v protokolu prˇirˇazen jeden bajt mohlo by se rˇ´ıci, zˇe polovina hodnot je obsazena a v za´sadeˇ dalsˇ´ı zarˇ´ızenı´ uzˇ termina´l nema´ prˇipojeno. Zdrojove´mu a cı´love´mu zarˇ´ızenı´ jsou prˇirˇazeny 2 bajty z du˚vodu mozˇne´ho rozsˇ´ırˇenı´. Jakmile protokol bude pouzˇ´ıva´n v dalsˇ´ıch projektech, existuje rea´lna´ mozˇnost, zˇe i zarˇ´ızenı´ mohou prˇiby´vat. Naprˇ´ıklad ve vy´sˇe uvedene´m seznamu nenı´ tiska´rna, ktera´ mu˚zˇe by´t vyzˇadova´na ke sdı´lenı´. Typu˚ zarˇ´ızenı´ mu˚zˇe by´t vı´ce a nemusı´ se zrovna jednat jen o takova´, ktera´ jsou fyzicky prˇipojena na termina´l poprˇ´ıpadeˇ jsou umı´steˇna v externı´m syste´mu. Pokud by neˇjake´ zarˇ´ızenı´ poskytovalo vı´ce funkcı´, ktere´ by pracovaly s urcˇity´mi daty, urcˇity´m zpu˚sobem cˇi neˇjak specificky a teˇch funkcı´ by bylo vı´ce (naprˇ. 10 a vı´ce), je mozˇne´ vytvorˇit virtua´lnı´ zarˇ´ızenı´, ktere´ bude poskytovat tuto funkcˇnost. Snad jako prˇ´ıklad je mozˇne´ uve´st trˇeba sˇifrovacı´ zarˇ´ızenı´, ktere´ poskytuje mnoho algoritmu˚ pracujı´cı´ s klı´cˇi ulozˇeny´mi v termina´lu. Takove´ sˇifrovacı´ zarˇ´ızenı´ by pak mohlo mı´t tolik funkcı´, kolik je implementova´no sˇifrovacı´ch algoritmu˚ v aplikaci. Takovy´chto zarˇ´ızenı´ mu˚zˇe by´t samozrˇejmeˇ vı´ce, za´lezˇ´ı na dane´m rˇesˇenı´ zadane´ho projektu.

6.2 Data za´visla´ na typu zarˇı´zenı´ Bezprostrˇedneˇ za hlavicˇkou jsou umı´steˇny 2 bajty, ktere´ jsou poslednı´mi daty oznacˇujı´cı´ stejne´ho vy´znamu, nazy´vane´ identifika´tor prˇ´ıkazu. Ovsˇem jejich hodnoty uzˇ znamenajı´ neˇco jine´ho v za´vislosti na zarˇ´ızenı´, ktere´ je pouzˇito v hlavicˇce. Tyto bajty oznacˇujı´ identifika´tor, ktery´ spolu s hodnotou cı´love´ho zarˇ´ızenı´ jednoznacˇneˇ urcˇujı´, jaky´ forma´t dat na´sleduje. Naprˇ´ıklad hodnota identifika´toru 10 u termina´lu sdeˇluje, zˇe se jedna´ o transakci Preauthorization, stejna´ hodnota u cˇtecˇky karet oznacˇuje prˇ´ıkaz pro cˇtenı´ karty a u displeje mu˚zˇeme pomocı´ te´to hodnoty zobrazit text. Prˇ´ıchozı´ zpra´va je prˇecˇtena a prˇeposla´na zarˇ´ızenı´m, ktery´m na´lezˇ´ı. Kazˇde´ zarˇ´ızenı´ zna´ ke kazˇde´mu identifika´toru forma´t dat, tudı´zˇ je schopno data prˇecˇ´ıst korektneˇ, poprˇ´ıpadeˇ ozna´mit chybu. Hodnoty jednotlivy´ch identifika´toru˚ majı´ sve´ opodstatneˇnı´. Funkce, jenzˇ jednotliva´ zarˇ´ızenı´ nabı´zejı´, jsou rozdeˇlena do neˇkolika skupin. V jake´ skupineˇ lezˇ´ı dany´ identifika´tor je mozˇne´ rozeznat podle hodnoty prvnı´ho bajtu. Cˇ´ım vı´ce se funkce blı´zˇ´ı samotne´mu hardwaru, tı´m majı´ nizˇsˇ´ı hodnotu prvnı´ho bajtu identifika´toru. Pokud funkce obsahujı´ i dalsˇ´ı cˇinnost, poprˇ´ıpadeˇ pokud jsou uzˇ komplikovaneˇjsˇ´ı a sta´vajı´ se z nich sluzˇby, majı´ tuto hodnotu vysˇsˇ´ı. Mezi syste´move´ funkce termina´lu, majı´cı´ prvnı´ bajt identifika´toru

29

6 ECR protokol nulovy´, patrˇ´ı inicializace (02), stazˇenı´ aplikace (03), restart termina´lu (04), za´kladnı´ nastavenı´ termina´lu (07) a informace o verzi (08). Na´sleduje skupina bankovnı´ch transakcı´, jenzˇ patrˇ´ı do hlavnı´ funkcˇnosti termina´lu, majı´cı´ identifika´tor zacˇ´ınajı´cı´ hodnotou 1. Na´sleduje skupina, ktera´ slouzˇ´ı k dotazova´nı´ termina´lu na soucˇasny´ stav (zda termina´l cˇeka´ na vlozˇenı´ karty, ukoncˇenı´ transakce, apod.), pote´ skupina funkcı´, ktere´ umı´ nastavit termina´l uzˇivatelem (volba jazyka) a zatı´m jako poslednı´ je skupina funkcı´ urcˇena pro pra´ci se zˇurna´lem. Mozˇna´ by se hodilo uve´st prˇ´ıklad, ktery´ by ilustroval jasneˇji rozdeˇlenı´ funkcı´ do skupin. Cˇtecˇka karet obsahuje 2 syste´move´ funkce 00, ktere´ znemozˇnı´ vkla´da´nı´ platebnı´ch karet do cˇtecˇky a 01, prˇesneˇ opacˇna´ funkce. Obeˇ funkce se chovajı´ ”tisˇe”, nikdo nepozna´, zˇe cˇtenı´ karty bylo povoleno cˇi znemozˇneˇno. Naopak rozsˇ´ırˇene´ funkce cˇtecˇky karet uzˇ prova´dı´ operace navı´c. Funkce 10 povoluje cˇtenı´ karty a prˇitom zobrazı´ na´pis ”Vlozˇte kartu” na displeji, funkce 12 vysune kartu a na displeji zobrazı´ text ”Odeberte kartu”. Text svı´tı´ na displeji dokud nenı´ karta vlozˇena resp. odejmuta. 6.2.1 Parametry prˇı´kazu˚ Parametrizova´nı´ prˇ´ıkazu˚ je pouzˇito pro prˇesneˇjsˇ´ı specifikova´nı´ cˇinnosti, ktera´ ma´ by´t vykona´na zarˇ´ızenı´m. Neˇktere´ prˇ´ıkazy parametry nevyzˇadujı´ (inicializace, stazˇenı´ programu, restart, atd.), ale u jiny´ch prˇ´ıkazu˚ jsou parametry nutne´ (vesˇkere´ platebnı´ transakce vyzˇadujı´ minima´lneˇ cˇa´stku, ktera´ ma´ by´t strzˇena z u´cˇtu). Data musı´ by´t posla´na v prˇesneˇ dane´m forma´tu. Pokud u prˇ´ıkazu nevyzˇadujı´cı´ zˇa´dny´ parametr bude neˇjaky´ posla´n, prˇ´ıkaz se neprovede. Stejneˇ tak parametry musı´ by´t posı´la´ny v dane´m porˇadı´ a jednotlive´ parametry musı´ by´t spra´vne´ho typu, protozˇe v prˇ´ıpadeˇ odlisˇnosti nebude opeˇt prˇ´ıkaz proveden. Parametr mu˚zˇe by´t bud’ cˇ´ıselny´, nebo textovy´. Jednotlive´ parametry jsou definova´ny svojı´ prˇesnou velikostı´, tudı´zˇ majı´ pevnou de´lku, a nebo jejich de´lka mu˚zˇe by´t promeˇnliva´, v takove´mto prˇ´ıpadeˇ musı´ za parametrem na´sledovat oddeˇlovacı´ znak. U kazˇde´ho parametru je definova´na jeho de´lka v bajtech, oznacˇujı´cı´ maxima´lnı´ de´lku parametru, pokud se jedna´ o hodnotu s promeˇnlivou de´lkou, a nebo oznacˇujı´cı´ prˇesnou de´lku (u dat s prˇesnou velikostı´). Pocˇet parametru˚ prˇirˇazeny´ch k prˇ´ıkazu nenı´ protokolem omezen.

6.3 KISS protokol Vy´sˇe uvedeny´ protokol slouzˇ´ı pouze pro prˇenos zpra´v mezi sdı´leny´mi zarˇ´ızenı´mi, pra´veˇ proto je potrˇeba tento protokol obalit do nizˇsˇ´ı vrstvy, ktera´ 30

6 ECR protokol obslouzˇ´ı prˇenos zpra´v mezi dveˇma fyzicky´mi syste´my spojeny´mi prˇes rozhranı´ RS-232. Pro obalenı´ byl pouzˇit na´sledujı´cı´ protokol. KISS protokol podporuje chronologicke´ porˇadı´ zası´la´nı´ zpra´v cˇ´ıslova´nı´m posı´lany´ch zpra´v. Prˇi korektnı´m prˇijetı´ zpra´vy je posı´la´n ACK (acknowledgement) s cˇ´ıslem dane´ zpra´vy, aby vysı´lajı´cı´ byl uveˇdomeˇn o korektnı´m prˇijetı´ jim vyslane´ zpra´vy. Zpra´vy jsou posı´la´ny s hlavicˇkou a s ukoncˇovacı´mi daty zpra´vy, aby prˇ´ıjemce mohl rozpoznat, kde se nacha´zı´ zacˇa´tek zpra´vy a kde jejı´ konec a mohl rozpoznat, zda v prˇijate´ zpra´veˇ nebyla obsazˇena chyba. Prˇi detekci chyby nebo prˇi ztra´teˇ zpra´vy protokol znovu posı´la´ zpra´vu se sekvencˇnı´m cˇ´ıslem poslednı´ korektneˇ dorucˇene´ zpra´vy. Opakovanı´ zpra´vy je nastaveno na 10 a cˇas, po ktery´ se cˇeka´ na potvrzenı´ zpra´vy, je 1.5 sekundy. 6.3.1 Forma´t zpra´v Zpra´vy jsou posı´la´ny ve forma´tu STX, NUM, DATA, ETX, CRC1, CRC2. Hodnoty STX start of text) a ETX (end of text) oznacˇujı´ zacˇa´tek a konec zpra´vy. Pokud data obsahujı´ tyto hodnoty, musı´ prˇed nimi by´t jesˇteˇ znak DLE datalink escape proto, aby data ve zpra´veˇ byla vzata opravdu jako data a ne chybneˇ, naprˇ´ıklad oznacˇujı´cı´ konec zpra´vy. Pokud v datech je obsazˇen znak DLE, musı´ by´t prˇed neˇj vlozˇen takte´zˇ znak DLE, v opacˇne´m prˇ´ıpadeˇ by byl odstraneˇn z dat zpra´vy. CRC1 a CRC2 jsou bajty vypocˇ´ıtane´ algoritmem CRC, jehozˇ vstup zacˇ´ına´ od hodnoty NUM a koncˇ´ı ETX, obeˇ hodnoty jsou ve vy´pocˇtu obsazˇeny. Algoritmus je pouzˇit azˇ pote´, co je upraveno polı´cˇko DATA, tedy azˇ po prˇida´nı´ potrˇebny´ch znaku˚ DLE. Prˇed vy´pocˇtem kontrolnı´ho soucˇtu jsou CRC1 a CRC2 nastaveny na 0. Algoritmus pouzˇ´ıva´ polynom x16 + x15 + x2 + x.

Obra´zek 6.1: Forma´t dat KISS protokolu

Obeˇ komunikujı´cı´ strany majı´ sve´ pocˇ´ıtadlo sekvencˇnı´ch cˇ´ısel. Prvnı´ zpra´veˇ, ktera´ je vyslana´ prˇi inicializaci protokolu, je prˇirˇazeno sekvencˇnı´ cˇ´ıslo 255. Ostatnı´ zpra´vy jizˇ neobsahujı´ stejnou hodnotu, ale postupneˇ jsou zpra´va´m cyklicky prˇirˇazova´ny hodnoty 0—254. Sekvencˇnı´ cˇ´ıslo 255 je urcˇeno pouze pro inicializaci protokolu, tudı´zˇ je mozˇno detekovat spusˇteˇnı´ druhe´ho syste´mu (naprˇ. po restartu). Po korektneˇ prˇijate´ zpra´veˇ prˇijı´majı´cı´ strana vysı´la´ informaci o tom, zˇe 31

6 ECR protokol zpra´va byla v porˇa´dku dorucˇena. K tomuto u´cˇelu postacˇuje poslat 2 bajty. Prvnı´ je pra´veˇ informace o tom, zˇe zpra´va byla korektneˇ prˇijata a druhy´ bajt sdeˇlı´ protokolu, o jakou zpra´vu se jedna´: ACK, NUM. V prˇ´ıpadeˇ, zˇe zpra´va byla dorucˇena chybna´, tudı´zˇ se neshoduje vypocˇ´ıtane´ CRC pro prˇijatou zpra´vu s CRC k prˇijate´ zpra´veˇ prˇipojene´, protokol vysˇle NAK (not ACK) bez sekvencˇnı´ho cˇ´ısla a vysı´lajı´cı´ opakuje prˇenos zpra´vy.

Obra´zek 6.2: Forma´t ACK zpra´vy

6.3.2 Komunikace Prˇ´ıjem zpra´vy Prˇi prˇ´ıjmu dat mezi STX a ETX je inicializova´n cˇasovacˇ, ktery´ nastavı´ interval, po ktery´ se cˇeka´ na prˇ´ıjem na´sledujı´cı´ch dat. Po jeho uplynutı´ jsou vesˇkera´ prˇijata´ data zahozena. Stejny´ zpu˚sob chova´nı´ protokolu je i v prˇ´ıpadeˇ, kdy pocˇet obdrzˇeny´ch znaku˚ prˇesa´hne velikost bufferu pro ulozˇenı´. Jakmile je cela´ zpra´va prˇijata, protokol zkontroluje CRC a v prˇ´ıpadeˇ, zˇe hodnota vypocˇ´ıtana´ z prˇijate´ zpra´vy odpovı´da´ hodnoteˇ CRC ve zpra´veˇ obsazˇene´, protokol posˇle ACK a na´sledneˇ sekvencˇnı´ cˇ´ıslo zpra´vy, pote´ je provedena dalsˇ´ı kontrola zpra´vy. V opacˇne´m prˇ´ıpadeˇ je zasla´n NAK a zˇa´dna´ na´sledujı´cı´ kontrola se neprova´dı´. Nynı´ protokol ma´ v bufferu umı´steˇna data, ktera´ byla vysla´na z externı´ho syste´mu. Porovna´ sekvencˇnı´ cˇ´ıslo pra´veˇ prˇijate´ zpra´vy a sekvencˇnı´ cˇ´ıslo poslednı´ prˇijate´ zpra´vy, pokud jsou shodna´, zpra´va je ignorova´na. Lisˇ´ı-li se tyto dveˇ hodnoty, ze zpra´vy jsou odstraneˇna vesˇkera´ kontrolnı´ data (STX, ETX, CRC1, CRC2, DLE) a zpra´va je prˇeda´na vysˇsˇ´ı vrstveˇ. Odesı´la´nı´ zpra´vy V prˇ´ıpadeˇ, zˇe aplikace vyzˇaduje poslat data a protokol sestavı´ korektnı´ zpra´vu (musı´ mı´t inkrementova´no sekvencˇnı´ cˇ´ıslo oproti poslednı´ poslane´ zpra´veˇ) prˇ´ımo urcˇenou k posla´nı´ externı´mu syste´mu, jsou data vysla´na a je take´ inicializova´n cˇasovacˇ, ktery´ uveˇdomı´ protokol o uplynutı´ cˇasove´ho intervalu. Nynı´ mohou nastat na´sledujı´cı´ uda´losti:

32

6 ECR protokol

Obra´zek 6.3: Process flow prˇ´ıjma´nı´ zpra´vy

• Prˇijat NAK nebo uplynutı´ cˇasove´ho intervalu: protokol znovu posı´la´ prˇedchozı´ zpra´vu a inicializuje znovu cˇasovacˇ. • STX prˇijato: protokol zapocˇne prˇ´ıjem zpra´vy a inicializuje cˇasovacˇ. • Prˇijat ACK: pokud nena´sleduje sekvencˇnı´ cˇ´ıslo, zpra´va je zahozena a je inicializova´n cˇasovacˇ. V opacˇne´m prˇ´ıpadeˇ zkontroluje sekvencˇnı´ prˇijate´ cˇ´ıslo se sekvencˇnı´m cˇ´ıslem zpra´vy naposledy vyslane´. Pokud jsou stejna´, prˇenos byl u´speˇsˇny´. Pokud se lisˇ´ı, posı´la´nı´ zpra´vy se opakuje.

6.4 Chybove´ zpra´vy V prˇ´ıpadeˇ, zˇe data na u´rovni protokolu KISS jsou v porˇa´dku, ale nasta´va´ chyba na u´rovni vysˇsˇ´ı, ve zpra´va´ch posı´lany´ch mezi jednotlivy´mi zarˇ´ızenı´mi. Pokud zpra´va byla posla´na na neexistujı´cı´ zarˇ´ızenı´, protokol nemu˚zˇe zpra´vu zamı´tnout zasla´nı´m NAK. Du˚vodu˚ k tomu je neˇkolik: nejedna´ se o 33

6 ECR protokol

Obra´zek 6.4: Process flow odesla´nı´ zpra´vy

chybu kontrolnı´m soucˇtu, NAK zpra´va by tedy mohla by´t chybneˇ pochopena, posla´nı´ takove´to zpra´vy snizˇuje rychlost vy´meˇny dat, posı´la´ se znovu prˇedesˇla´ zpra´va namı´sto zamı´tnutı´, nelze rozumneˇ reagovat na tuto zpra´vu. K tomuto u´cˇelu byl vytvorˇen novy´ identifika´tor zpra´vy s cˇ´ıslem 98 oznacˇujı´cı´, o jakou chybu se jedna´. Jelikozˇ mohou nastat pouze trˇi prˇ´ıpady, parametry pro tento identifika´tor se zjednodusˇujı´. Chyba mu˚zˇe nastat naprˇ´ıklad v chybneˇ zadane´m cˇ´ısle cı´love´ho zarˇ´ızenı´, neexistujı´cı´m prˇ´ıkazu pro dane´ zarˇ´ızenı´, poprˇ´ıpadeˇ ve sˇpatne´m forma´tu dat. Parametry obsahujı´ chybovy´ ko´d, cˇ´ıslo zarˇ´ızenı´, u ktere´ho nastala chyba a chybny´ identifika´tor prˇ´ıkazu. Protokol umozˇnˇuje prˇesneˇ definovat chybu, ktera´ v prˇenosu zpra´vy nastala.

6.5 Chyba komunikace I kdyzˇ opeˇtovne´ posla´nı´ zpra´vy prˇi nedorucˇenı´ zajisˇt’uje KISS protokol, zpra´va prˇesto nemusı´ by´t dorucˇena, pokud je komunikacˇnı´ kabel vadny´ nebo pokud v syste´mu na druhe´ straneˇ nastala neˇjaka´ chyba a dostal se do stavu, kdy nemu˚zˇe prˇijı´mat data. Obecneˇ v ECR protokolu je mozˇnost vyuzˇ´ıt mechanizmus, ktery´ informuje o nedorucˇenı´ odeslane´ zpra´vy. Reakce na 34

6 ECR protokol tuto uda´lost mu˚zˇe by´t ru˚zna´, ale veˇtsˇinou by aplikace meˇla po urcˇite´ dobeˇ otestovat, zda je jizˇ komunikacˇnı´ linka v porˇa´dku. V prˇ´ıpadeˇ, zˇe externı´ syste´m byl restartova´n, jeho opeˇtovne´ spusˇteˇnı´ lze rozeznat prˇ´ıchozı´ zpra´vou se sekvencˇnı´m cˇ´ıslem 255. Chova´nı´ externı´ho syste´mu a termina´lu H2200 ohledneˇ nedorucˇenı´ ECR zpra´vy je podobne´ k chova´nı´ platebnı´ho termina´lu a autorizacˇnı´ho centra ohledneˇ nedorucˇenı´ financˇnı´ transakce. V sekci veˇnovane´ bankovnı´m protokolu˚m je zmı´neˇno, zˇe o vesˇkere´ zachova´nı´ konzistence je v rezˇii termina´lu. Pokud se nepodarˇ´ı jemu dorucˇit zpra´vu od autorizacˇnı´ho centra, je povinova´n poslat reversal, ktery´ prˇedchozı´ transakci stornuje. H2200 je vlastneˇ zarˇ´ızenı´, ktere´ zprostrˇedkova´va´ komunikaci s autorizacˇnı´m centrem. Pra´veˇ proto konzistence transakcˇnı´ch dat byla rˇesˇena tak, zˇe externı´ syste´m posˇle v ECR zpra´veˇ unika´tnı´ syste´move´ cˇ´ıslo a termina´l ulozˇ´ı vesˇkera´ data transakce do zˇurna´lu drˇ´ıve, nezˇ jsou vysla´na na autorizacˇnı´ centrum. Jakmile je transakce provedena a termina´l jizˇ ma´ odpoveˇd’, posı´la´ ji v ECR zpra´veˇ externı´mu syste´mu, ktery´, kdyzˇ detekuje vyprsˇenı´ cˇasove´ho dı´lu urcˇene´ho k odpoveˇdi, musı´ poslat na termina´l zpra´vu storno, jenzˇ musı´ obsahovat syste´move´ cˇ´ıslo prˇedchozı´ transakce. Pokud opeˇt neobdrzˇ´ı odpoveˇd’, na displej vypı´sˇe zpra´vu ”Mimo provoz” a informuje o sve´m stavu rˇ´ıdı´cı´ centrum, kde cely´ syste´m monitorujı´ vysˇkolenı´ pracovnı´ci. Dalsˇ´ı prˇ´ıpad, kdy je nutne´ detekovat chybu komunikace, je pokud za´kaznı´k vlozˇ´ı do termina´lu platebnı´ kartu, ale informace o vlozˇenı´ karty nebude dorucˇena. I tento prˇ´ıpad nesmı´ by´t rˇesˇen cˇisteˇ aplikacı´ v termina´lu, ktery´ by meˇl kartu po nedorucˇenı´ zpra´vy vysunout. Mohla by nastat situace, kdy za´kaznı´k opustı´ stojan, aby prˇivolal obsluhu a jeho neprˇ´ıtomnosti bude karta vytazˇena a tudı´zˇ mu˚zˇe by´t ky´mkoliv odcizena. Tento stav je rˇesˇen pomocı´ obsluhy, ktera´ jde se za´kaznı´kem ke stojanu a bud’ zavola´ do kontrolnı´ho centra, aby vyslali pozˇadavek na termina´l s prˇ´ıkazem vra´cenı´ karty, poprˇ´ıpadeˇ restartujı´ termina´l, ktery´ automaticky vracı´ kartu prˇi jeho spousˇteˇnı´. Existuje samozrˇejmeˇ vı´ce funkcı´ na komunikaci mezi termina´lem a externı´m syste´mem, ale konzistence transakcˇnı´ch dat a majetek za´kaznı´ku˚ jsou nejcitliveˇjsˇ´ı hodnoty v syste´mu. Prˇi nedorucˇenı´ odpoveˇdı´ ostatnı´ch zpra´v je pouze vypsa´no na displeji ”Mimo provoz”.

35

Kapitola 7

Implementace Hypercom SDK nabı´zı´ mnoho funkcı´, jak pracovat s prostrˇedky, ktere´ nabı´zı´ termina´l. V knihovna´ch je obsazˇen ko´d slusˇne´ho operacˇnı´ho syste´mu, ktery´ umozˇnˇuje aplikaci prˇistupovat k souborove´mu syste´mu termina´lu, vytva´rˇet procesy a prˇepı´nat je pomocı´ kooperativnı´ho multitaskingu, nabı´zı´ mozˇnost pouzˇitı´ synchronizacˇnı´ch objektu˚ jaky´mi jsou semafory a uda´losti. HSDK nabı´zı´ funkce pracujı´cı´ s jednotlivy´mi porty termina´lu pomocı´ neblokujı´cı´ch vola´nı´, tudı´zˇ je mozˇnost beˇhem cˇtenı´ cˇi za´pisu dat na port prova´deˇt i jine´ operace ve stejne´m procesu, ktery´ operaci vyvolal. Kooperativnı´ multitasking znamena´, zˇe syste´m neprˇepı´na´ procesy podle sve´ho pla´novacı´ho algoritmu, ale kazˇdy´ proces uvolnˇuje procesor ostatnı´m procesu˚m. K tomuto u´cˇelu byla vytvorˇena funkce void SDK RelinqCPU(void), ktera´ ukoncˇ´ı pra´veˇ spusˇteˇny´ proces, vra´tı´ obsluhu operacˇnı´mu syste´mu, jenzˇ vybere na´sledujı´cı´ proces, ktery´ spustı´. Vy´beˇr je definova´n algoritmem Round Robin, procesy jsou tedy prˇepı´na´ny cyklicky za sebou ve stejne´m porˇadı´. Funkce SDK RelinqCPU slouzˇ´ı cˇisteˇ pro prˇepı´na´nı´ procesu˚ bez vykona´nı´ neˇjake´ sluzˇby navı´c. Operacˇnı´ syste´m prˇeda´va´ rˇ´ızenı´ i v prˇ´ıpadeˇ jiny´ch funkcı´, aby byl naplno vyuzˇit vy´kon procesoru a ostatnı´ procesy nezaha´lely. Mezi takove´to funkce patrˇ´ı samozrˇejmeˇ ty, ktere´ doka´zˇ´ı pozastavit proces po zvoleny´ cˇasovy´ interval, i takove´, ktere´ pracujı´ s hardwarem. Prˇed pouzˇitı´m portu je nutne´ jej inicializovat a otevrˇ´ıt, beˇhem te´to procedury opeˇt docha´zı´ k prˇepnutı´ procesu˚. Jelikozˇ cele´ HSDK pracuje na nı´zke´ u´rovni a prˇeva´zˇneˇ s hardwarem termina´lu, veˇtsˇina funkcı´ prˇi vola´nı´ umozˇnˇuje prˇepnout proces. Dı´ky podporˇe operacˇnı´ho syste´mu je mozˇne´ vytvorˇit prˇehledny´ ko´d aplikace, cˇ´ımzˇ se zdrojove´ texty sta´vajı´ cˇitelne´ a jednodusˇe upravovatelne´. Rozdeˇlenı´ jednotlivy´ch celku˚ do procesu˚ prˇina´sˇ´ı vy´hodu, kdy se programa´tor mu˚zˇe zameˇrˇit pouze na funkci procesu, na jeho vstupy a vy´stupy a okolnı´ ko´d jej nemusı´ zajı´mat. Komunikaci mezi procesy nezajisˇt’uje operacˇnı´ syste´m, vy´meˇna zpra´v musı´ by´t explicitneˇ naprogramova´na. S pouzˇitı´m sdı´leny´ch dat, semaforu˚ a multitaskingu lze prˇeda´va´nı´ zpra´v implementovat. 36

7 Implementace Proces, ktery´ obstara´va´ neˇjakou sluzˇbu v aplikaci, cˇeka´ na nastavenı´ uda´losti tak, zˇe v cyklu zkontroluje, zda nenastala dana´ uda´lost. Tato kontrola je prova´deˇna cˇtenı´m sdı´leneho bajtu v pameˇti, pokud je nulovy´, uda´lost nenastala. Nastavenı´ uda´lostı´ tedy probı´ha´ pouze za´pisem hodnoty do globa´lnı´ promeˇnne´. Jestlizˇe nebyl detekova´n zˇa´dny´ pozˇadavek, je prˇeda´n procesor syste´mu. V prˇ´ıpadeˇ, zˇe hlavnı´ proces potrˇebuje vyuzˇ´ıt proces jiny´, zapı´sˇe naprˇed do sdı´leny´ch dat parametry potrˇebne´ k vykona´nı´ neˇjake´ sluzˇby a pote´ nastavı´ uda´lost na pozˇadovanou hodnotu. Prˇi zpracova´va´nı´ sluzˇby se role procesu˚ vymeˇnı´. Hlavnı´ proces cˇeka´ na uda´lost ukoncˇenı´ pozˇadavku a sluzˇba po provedenı´ potrˇebny´ch kroku˚ zapı´sˇe vy´sledek do sdı´leny´ch dat a pote´ nastavı´ uda´lost. Jelikozˇ komunikaci neobstara´va´ operacˇnı´ syste´m, ale cely´ na´vrh je v rezˇii programa´tora, musı´ si da´t pozor na vynulova´nı´ prˇ´ıznaku˚ uda´lostı´.

7.1 Podmı´neˇny´ prˇeklad Zdrojovy´ ko´d aplikace pro dany´ typ termina´lu je totozˇny´ pro vsˇechny za´kaznı´ky i prˇesto, zˇe kazˇdy´ za´kaznı´k ma´ jine´ pozˇadavky na chova´nı´ aplikace. Jak jizˇ bylo uvedeno v u´vodu pra´ce, cela´ aplikace je psa´na v jazyku C, ktery´ podporuje makra. Pomocı´ podmı´neˇne´ho prˇekladu je umozˇneˇno vytvorˇit pomocı´ jednoho zdrojove´ho ko´du ru˚zne´ aplikace v za´vislosti na definici maker v prˇekladu zdrojovy´ch souboru˚. Naprˇ´ıklad pokud aplikace ma´ mı´t podporu protokolu ECR, je prˇi prˇekladu definova´no makro MAKE ECR. Pak zdrojovy´ ko´d v bloku zacˇ´ınajı´cı´ na´veˇsˇtı´m #ifdef MAKE ECR a ukoncˇeny´ #endif je prˇelozˇen a obsazˇen v bina´rnı´ aplikaci. V praxi mu˚zˇe nastat situace, kdy je neˇjaka´ slozˇiteˇjsˇ´ı funkcˇnost pozˇadova´na od vı´ce za´kaznı´ku˚, ale kazˇdy´ pozˇaduje jiste´ odlisˇnosti. Bylo by velice neefektivnı´ definovat makro kazˇde´mu za´kaznı´ku, zvla´sˇt’, kdyzˇ rˇesˇenı´ zasahuje do vı´ce souboru˚ se zdrojovy´m textem. Aby nenastala tato situace, ktera´ mu˚zˇe zpu˚sobit v aplikaci vı´cecˇetnou existenci stejne´ho ko´du, byt’jen trosˇku pozmeˇneˇne´ho, nenı´ proble´m rˇesˇen na u´rovnı´ podmı´neˇne´ho prˇekladu, ale vyuzˇije se nastavenı´ TMS, ve ktere´m se vytvorˇ´ı konfigurace pro chova´nı´ termina´lu. Pak se v aplikaci nacha´zı´ dany´ ko´d pouze jednou, i kdyzˇ obohaceny´ o podmı´nky, ktere´ jsou ve vy´sledne´m ko´du obsazˇeny.

37

Kapitola 8

Za´veˇr ´ pravy bankovnı´ch protokolu˚ 8.1 U • Modifikace dat platebnı´ch protokolu˚ — prˇida´va´nı´ a ubı´ra´nı´ polozˇek, zmeˇna typu˚ jednotlivy´ch polı´cˇek • Zmeˇna vkla´da´nı´ hodnot jednotlivy´ch polozˇek do bufferu • U SPDH zmeˇna hodnot v hlavicˇce za´visly´ch na typu transakce ´ prava protokolu tak, aby umozˇnˇoval obalenı´ do dalsˇ´ıch vrstev •U ´ prava chova´nı´ protokolu˚ — implementace mozˇnosti zpracova´nı´ vı´ce • U transakcı´ v jednom telefona´tu, jina´ pra´ce se zˇurna´lem z du˚vodu implementace vı´ce typu˚ reversalu˚

8.2 Na´vrh a implemetace • ECR protokolu, ktery´ je urcˇen ke komunikaci s externı´m zarˇ´ızenı´m • Automaticke´ inicializace termina´lu a automaticke´ho stazˇenı´ aplikace • Prˇihla´sˇenı´ obsluhy do termina´lu — kazˇdy´ ma´ svu˚j cˇ´ıselny´ login a cˇ´ıselne´ heslo • Procesu pro ukoncˇenı´ spojenı´, bylo docı´leno pruzˇneˇjsˇ´ıch odpoveˇdı´ termina´lu • Za´lozˇnı´ho prˇipojenı´ k autorizacˇnı´mu centru pomocı´ externı´ho modemu • Zmeˇna u´cˇtenek dle prˇa´nı´ za´kaznı´ka ´ prava process flow transakce, prˇida´nı´ neˇkolika obrazovek pro zı´ska´nı´ •U potrˇebny´ch u´daju˚ • Prˇida´nı´ vı´ce typu˚ reportu˚ — vy´pisu˚ transakcı´ ze zˇurna´lu • Kompletnı´ tvorba aplikace od zacˇa´tku pro termina´l H2200 pouzˇitı´m male´ cˇa´sti ko´du z aplikace pro termina´l T2100

38

8 Za´veˇr

8.3 Vyrˇesˇen proble´m s(e) ... • nedostatkem komunikacˇnı´ch portu˚ na termina´lu H2200, byl zada´n u´kol pro vytvorˇenı´ RS-232 splitteru • prˇevodem dat prˇ´ıchozı´ch z RS-232 rozhranı´ na protokol TCP/IP a zpeˇt • sdı´lenı´m externı´ch zarˇ´ızenı´ pomocı´ ECR protokolu

8.4 Shrnutı´ Dı´ky mozˇnosti pracovat na vy´sˇe uvedeny´ch aplikacı´ch mu˚zˇe programa´tor zı´skat schopnost vyznat se v cizı´m ko´du rozsa´hle´ aplikace, pochopit zamy´sˇlene´ postupy a rˇesˇenı´. Po blizˇsˇ´ım prozkouma´nı´ Base application se programa´torovi otevrˇe novy´ na´hled na veˇc, pochopı´ take´, jak by se meˇly psa´t aplikace strukturovaneˇ a prˇehledneˇ. Jakmile zvla´dne pochopit autorovu mysˇlenku a zı´skat znalost o zamy´sˇlene´m rˇesˇenı´, prˇecˇte urcˇite´ mnozˇstvı´ dokumentace, aby problematiku le´pe pochopil, teprve pak by meˇl prˇistoupit k u´prava´m veˇtsˇ´ıho softwaru. Prˇi pra´ci na te´to aplikaci si tvu˚rce cˇasem osvojı´ programovacı´ techniky, u´pravy aplikace jsou pro neˇj sta´le vı´ce jednodusˇsˇ´ı a sta´vajı´ se automaticke´. Zı´ska´va´ kompletnı´ prˇehled o architekturˇe aplikace, rozdeˇlenı´ ko´du do vı´ce zdrojovy´ch souboru˚ a zprvu vzda´lene´ rˇesˇenı´ je vı´ce prˇiblı´zˇeno. Dı´ky pochopenı´ cele´ Base application je mozˇne´ pokracˇovat s vy´vojem u´plneˇ nove´ aplikace, zalozˇene´ na podobne´m chova´nı´. Jelikozˇ vy´stavba aplikace pro termina´l H2200 byla zapocˇata u´plneˇ od zacˇa´tku, bylo nutne´ celou koncepci aplikace porˇa´dneˇ promyslet, aby se vyhnulo komplikacı´m s implementacı´. Aby vesˇkery´ zdrojovy´ text nemusel by´t vyvı´jen u´plneˇ od zacˇa´tku, bylo vyuzˇito pouzˇitelne´ho ko´du aplikace pro termina´l T2100. Prˇenos nebyl nikterak trivia´lnı´, jelikozˇ mezi aplikacemi je mnoho rozdı´lu˚ nejen v za´vislosti na rozdı´lu hardwaru. Vesˇkere´ pra´ce spojene´ s displejem, komunikacı´, tabulkami, process flow a s dalsˇ´ımi za´lezˇitostmi musely by´t upraveny z du˚vodu portova´nı´ na jinou platformu. Jelikozˇ v projektech rˇesˇene´ pomocı´ bezobsluzˇne´ho termina´lu je potrˇeba komunikovat s externı´m syste´mem vyvı´jeny´m dalsˇ´ı firmou, je potrˇeba se spolecˇneˇ domluvit na vy´voji process flow a celkoveˇ na cele´ koncepci rˇesˇenı´ problematiky. Cozˇ prˇina´sˇ´ı dalsˇ´ı zkusˇenost s integrova´nı´m aplikace do dalsˇ´ıch syste´mu˚. Aplikace do termina´lu˚ se budou nada´le vyvı´jet, nejedna´ se rozhodneˇ o konecˇna´ rˇesˇenı´. Bezobsluzˇny´ch syste´mu˚ bude prˇiby´vat, budou rˇesˇeny integrace s dalsˇ´ımi syste´my, dı´ky vy´voji technologie je pocˇ´ıta´no s portova´nı´m na 39

8 Za´veˇr dalsˇ´ı, nove´ platebnı´ termina´ly. Komunikace prˇes TCP/IP je zatı´m nesˇifrova´na, proto je pouzˇito dedikovany´ch linek mezi obchodnı´kem a autorizacˇnı´m centrem. Toto rˇesˇenı´ je na´kladne´. V te´to dobeˇ jizˇ byly zapocˇaty pra´ce na aplikaci podporujı´cı´ prˇenos dat pomocı´ SSL, k prˇenosu dat v tomto prˇ´ıpadeˇ lze pouzˇ´ıt k prˇenosu dat internet, ktery´ je dnes uzˇ beˇzˇnou za´lezˇitostı´.

40

Literatura [1] HYPERCOM: Hypercom Software Development Kit, December 2002 [2] HYPERCOM: New features in H2200 & K1100/K1200, Programers guide [3] HYPERCOM: Hypercom message specification, Version 3.4.1 [4] ACI: Standard POS Device Message Specifications Manual, Release 6.0 Version 5 [5] GPE: Dodatek k dokumentaci ACI, 9.6.2006 [6] GPE: POS SPDH MAC processing [7] TATRA BANKA: DOCUMENT FOR PoS & ATM CERTIFICATION, 8.2.2005 [8] SONET: ECR protocol specification, 1.3.2006 [9] DESIGNA: DESIGNA PIN-Pad Specification, 23.11.2005 [10] PROEDA: Communication with the SoNet Terminal, 24.1.2005 [11] CRC: CRC description, http://www.gpfn.sk.ca/ rhg/csc8550s02/crc.html

41