V dnesnej casti si povieme nieco o architekture systemov jednotlivych pobociek, resp. o sposobe ich pripojenia k centralnemu systemu. V druhej polovici sa zase oboznamite so sposobom ukladania dat do lokalnych databaz a ich aktualizacie s centralou...
Pobockovy subsystem
Pobockovy subsystem musi umoznit podporu a realizaciu operacii pobocky, spravu jej hotovosti a styk s (vacsinou centralnym) IT systemom banky. Z hladiska struktury a velkosti banky a najma architektury celeho bankoveho IT systemu mozno rozlisit niekolko zakladnych variantov zaclenenia pobockoveho systemu.
1. Pobockovy subsystem je priamo sucastnou centralneho bankoveho IT systemu. Obvykle ide o mensie banky alebo banky disponujuce vysoko spolahlivou a dostupnou prenosovou sietou umoznujucou vykonavat vsetky operacie z pobociek cez on-line terminalove spojenie. Tento variant je velmi efektivny z hladiska eliminacie existencie dalsieho hardwaru a programoveho vybavenia v jednotlivych pobockach. K dispozicii je (okrem obmedzeni danych pristupovymi pravami) rovnaka funkcionalita ako v ustredi banky, na ucely pobociek vsak musi byt funkcionalita centralneho systemu rozsirena o niektore (nie prilis narocne funkcie) - najma spravu hotovosti, zmenarenske operacie a pod. Zakladnou nevyhodou je, ze pri vypadku spojenia je pobocka uplne vyradena, nema k dispozicii udaje zo systemu, ani nudzovu off-line funkcionalitu.
2. Pobockovy subsystem je priamou sucastou jednotlivych uzlov distribuovaneho bankoveho IT systemu. Tentovariant je v mnohom podobny variantu c. 1. Ak je v banke len niekolko uzlov a ostatne pobocky su na ne pripojene pomocou siete on-line terminalov, ide vlastne opat o variant c. 1., nevztahuje sa vsak na jedno, ale na niekolko \"centier\" spracovania. Ak su (vzajomne ekvivalentne) uzly distribuovaneho systemu vo vsetkych pobockach banky, je odstranena zakladna nevyhoda variantu c. 1. - vyradenie pobocky pri vypadku spojenia, vznika vsak iny zavazny problem - extremna narocnost distribuovanych systemov na zlozitost a tym aj vykonnost spracovania (najma z hladiska medziuzlovej komunikacie pri vysokom pocte uzlov), na mnohonasobne pouzitie hardwaru a softwaru v ramci banky a v dosledku toho casto aj na naklady spojene s implementaciou a udrzbou systemu. (V niektorych pripadoch vsak distribuovany system z \"lacnych\" pocitacov moze vyjst lacnejsie ako centralizovany system vyuzivajuci mohutny a extremne drahy mainframe vypoctovy system.)
3. Pobockovy subsystem sa realizuje na oddelenych pobockovych vypoctovych systemoch, radovo jednoduchsich ako centralny system. Radovo vacsia jednoduchost pobockovych vypoctovych systemov je na hardwarovej a systemovo softwarovej urovni (vacsinou ide o siete PC LAN alebo PS/2 pocitacov), aj na aplikacne softwarovej urovni - t. j. funkcnej aj databazovej. Tieto pobockove vypoctove systemy spolupracuju s centralnym IT systemom (alebo s niekolkymi hlavnymi uzlami bankoveho distribuovaneho systemu) prostrednictvom prenosovej siete dat alebo dokonca aj formou davkovych prenosov suborov (v pripade absencie prenosovych liniek aj na magnetickych mediach). Pri tomto variante su specificke pobockove funkcie zaclenene len v pobockovych vypoctovych systemoch a naopak velka cast dat a funkcionality centralneho systemu nepotrebna pre (off-line) prevadzku pobocky nie je sucastou pobockoveho systemu. Ak dnes hovorime o pobockovom subsysteme, mame vacsinou na mysli prave tento variant - tak tomu bude aj vo zvysnej casti tejto kapitoly.
Komunikacia medzi pobockovymi a centralnym systemom sa najcastejsie realizuje v niekolkych rezimoch. Zakladnym rezimom je on-line prepojenie, ked pracovne stanice pobockovej LAN siete pracuju de facto ako klient centralneho systemu (serveru), v extremnych pripadoch len emuluju on-line terminal.
V pripade kratkodobych vypadkov spojenia mozu pobockove systemy prejst do tzv. rezimu \"Store and Forward\", ktory umozni de facto prostrednictvom vyrovnavacich komunikacnych pamati asynchronnu komunikaciu s centralnym systemom. Pobockovy system akceptuje lokalne zadavane data a prikazy, pokial mozno obsluhuje ich pomocou svojej off-line funkcionality a uchovava na neskorsie dokoncenie spracovania v spolupraci s centralnym systemom. Po obnoveni spojenia pobockovy system automaticky iniciuje dokoncenie spracovania uchovanych transakcii a informuje o tom uzivatela, vratane prezentacie pripadnych odoziev centralne systemu. Store and Forward system je vlastne prvy stupen degradacie bankoveho systemu pri poruchach komunikacie, oproti okamzitemu prechodu do off-line rezimu podstatne urychluje a menej obmedzuje proces spracovania.
Pri dlhsom vypadku spojenia prechadza pobockovy system do off-line rezimu, ked uz nepredpoklada opatovne nadviazanie spojenia, po ktorom by sa malo dokoncit spracovanie zadavanych dat a prikazov - tie sa ukladaju do (transakcnych) suborov, ktore sa (vacsinou v ramci spracovania konca dna pobocky) davkovo odosielaju na spracovanie do centralneho systemu po inej, zaloznej komunikacnej linke alebo na magnetickych mediach. V off-line rezime vyuziva pobockovy system trvale len svoju obmedzenu funkcionalitu a datovu zakladnu, a preto je vo svojich moznostiach podstatne degradovany. Off-line rezim sa casto pouziva ako standardny rezim spracovania v malych pobockach a zastupitelstvach, kde vzhladom na pocet realizovanych transakcii nie je efektivne priame on-line spojenie s centralou.
Stupen degradacie pri Store and Forward a predovsetkym pri off-line rezime je urceny predovsetkym rozsahom lokalnej databazy pobockoveho subsystemu a sposobom jej priebeznej aktualizacie vzhladom na centralnu (primarnu - \"master\") databazu. Je tu zrejmy kompromis medzi realizovanym rozsahom a aktualnostou lokalnej databazy a nakladnostou pobockoveho riesenia (tak z hladiska investicii pri implementacii systemu, ako aj z hladiska spotrebovaneho casu na vymenu dat a rychlosti a zataze komunikacnych liniek). Preto byvaju lokalne databazy oproti databazam centralneho systemu podstatne redukovane, napr. len na zakladne udaje vkladovych uctov \"domacich\" klientov danej pobocky - redukcia vychadza najma z vyhodnotenia obvyklej pocetnosti operacii, ktore chce pobocka v off-line rezime dalej promptne vykonavat.
Z hladiska aktualizacie databaz je najobvyklejsia denna (davkova) aktualizacia lokalnych databaz obrazom casti databaz (uctov) centralneho systemu - vacsinou v ramci spracovania zaciatku dalsieho dna. Na znizenie objemu prenasania dat sa niekedy prenasaju len polozky modifikovane v minulom dni. Dalsim vylepsenim je priebezna aktualizacia na zaklade zadavanych transakcii - relativne jednoducha je subezna aktualizacia lokalnej a centralnej databazy pri transakciach \"domacich\" klientov pobocky, ked pobocka aktualizuje svoju lokalnu databazu. Problemom zostava, ze lokalna databaza sa nebude aktualizovat pri transakciach nad ucty jej domacich klientov iniciovanych z inych zdrojov (z inych pobociek alebo automatizovanych interfejsov), udaje v lokalnej databaze maju stale len informacny charakter, aj ked sa uz viac blizia k aktualnemu real-time stavu. Tento problem by eliminovala len okamzita aktualizacia lokalnej databazy pobocky na zaklade akehokolvek pohybu nad ucty jej \"domacich\" klientov - to by vsak bolo velmi narocne na komunikaciu medzi systemami a na zlozitost riesenia. Preto sa tato moznost vacsinou nevyuziva a stupen rizika pouzitia neaktulanej informacie z lokalnej databazy pri off-line rezime spracovania je dalej obmedzeny organizacnymi opatreniami - napr. stanovenim max. limitu na vyber pri off-line rezime, telefonickym overovanim porovnania centralnej databazy pri vyssich vyberoch a pod.
Note: V nasledujucej casti popisem subsystem spravy penaznych prostriedkov.ddaemon
