primerjalna analiza sinhrone in asinhrone obdelave …

Diplomsko delo visokošolskega strokovnega študija Smer: informatika v organizaciji in managementu

PRIMERJALNA ANALIZA SINHRONE IN ASINHRONE OBDELAVE PLAČILNEGA

ZAHTEVKA

Mentor: doc. dr. Uroš Rajkovič Kandidat: Matjaž Križaj

Kranj, april 2012

ZAHVALA Zahvaljujem se mentorju doc. dr. Uroš Rajkoviču za strokovno pomoč, nasvete in priporočila, ki so mi bila v veliko pomoč pri pisanju diplomske naloge. Zahvala ge. Mateji Maček, moji sodelavki v Poštni Banki Slovenije d.d., za pomoč pri analizi plačilnega zahtevka, g. Milku Osmaniju, prijatelju in strokovnjaku na področju strojne opreme, komunikacij in relacijske baze podatkov, gdč. Alji Osmani za pomoč pri prevodu in prijatelju g. Urošu Jurišiču za lektoriranje diplomske naloge.

POVZETEK V diplomski nalogi je opisan plačilni zahtevek kot plačilna inštrukcija, ki jo plačnik posreduje do banke s pomočjo določene aplikativne rešitve. Opisane so aplikativne rešitve, kot so elektronsko bančništvo, šalterska aplikacija ali zaledna interna aplikacija, s katerimi je mogoče takšen proces izvajati. Opisana sta oba možna načina obdelave, sinhroni in asinhroni. Podane so analize obeh načinov, problemi, ki se pojavijo, in rešitve, kako najbolje optimizirati posamezen način in se približati popolnemu nadzoru nad samo obdelavo, od začetka do konca. Oba načina vključujeta prednosti in slabosti ter podrobno analizo obojih, kar lahko služi kot koristna informacija novemu naročniku pri odločitvi za nakup storitve, ki jo ponuja zunanji izvajalec. Dodani so slikovni prikazi posameznega procesa obdelave. Za uspešno implementacijo asinhrone rešitve je potrebno natančno uskladiti vhodne in izhodne strukture datotek, ne glede na protokol prenosa iz enega sistema na drugega, in podatke neposredno ali preko komunikacijskih stavkov obdelati na svojem sistemu in v svojih aplikativnih rešitvah. V primeru asinhrone obdelave je pomembna predvsem zanesljivost in varnost našega sistema. Če imamo možnost uvedbe sinhrone obdelave, je končna rešitev za vse akterje elegantnejša, odzivnost uspešnosti obdelav je v realnem času in naš nadzor nad transakcijami je popoln. Največja slabost so stroški in kadri, ki so potrebni pri zagotavljanju neprekinjenega delovanja in varovanja sistema. Problem predstavlja vsaka nadgradnja, dopolnitev ali sprememba na enem ali drugem sistemu, saj sta sinhrono povezana in v tem primeru pride do nadzorovanega izpada obeh. Zahtevana je hitra odzivnost strokovnega kadra v primeru nepričakovanega izpada komunikacij, sistema ali baze podatkov enega ali drugega izvajalca, ki zagotavljata sinhrono obdelavo plačilnih zahtevkov. V nasprotnem primeru zelo hitro izgubimo zaupanje obstoječih kot tudi potencialnih komitentov. Zavedamo se, da je lahko naša ocena subjektivna. Na podlagi izkušenj in analiz, ki smo jih pridobili pri razvoju, testu in implementaciji obeh rešitev na našem sistemu, ugotavljamo, da je asinhrona rešitev primernejša, predvsem pa celostno ugodnejša za večino podjetij, ki bodo uvajala opisane storitve za svoje komitente.

KLJUČNE BESEDE

- plačilni zahtevek - sinhron - asinhron - proces

ABSTRACT In the thesis, there is a description of payment claim in form of a payment instruction, which the payer forwards to the bank with the help of a certain applicative solution. There are descriptions of those applicative solutions with which we are able to implement the process. Those are electronic banking, front end application or back end internal application. There are descriptions of both possible methods of processing i.e. synchronous and asynchronous method. Also, there are included analyses of both methods, problems that may occur and solutions for how to most optimize individual technique and come closer to full control of the process, from beginning to end. Both methods have benefits and costs and detailed analyses of both, which should be helpful to customer while choosing which service, that is offered by external supplier, to purchase. Visual displays are added for each treatment processes. For a successful implementation of asynchrony solution it is essential to precisely coordinate internal and external structure of the files, regardless to the protocol of transferring from one system to the other and directly or through communication sentences, process the data on your system and in your application solutions. In case of asynchrony process, reliability and safety of our system is very important. If we have an option of introducing a synchrony process, the final solution is more elegant for all factors; reactivity of successfulness of the processes is in realistic time and our control of transactions full. The biggest weaknesses are the expenses and personnel, which are necessary for providing constant operation and protection of the system. Every upgrade, completion or change on one of the two systems is a problem, because the systems are synchronically linked and in this case it comes to controlled failure of both. Quick reactivity of professional employee is required in case of unexpected failure of communications, the system or the data base, one of the two operators, that assures synchrony process of payment claims. Otherwise we lose the trust of our existing as well as potential customers very quickly. We realise that our evaluation can be subjective. On the basis of our experiences and analysis, which we gained through the development, the tests and the implementation of both solutions on our system, we find that our asynchrony solution is more suitable and more importantly, overall less expensive for most of the companies that are going to introduce previously described services for their clients.

KEYWORDS

- payment claim - synchronous - asynchronous - process

KAZALO

1. UVOD ............................................................................................................... 1

1.1. PREDSTAVITEV PROBLEMA ................................................................... 1

1.2. PREDSTAVITEV OKOLJA ......................................................................... 1

1.3. CILJI .......................................................................................................... 1

1.4. NAMEN ...................................................................................................... 1

1.5. METODE DELA ......................................................................................... 2

2. OBDELAVA PLAČILNIH ZAHTEVKOV ............................................................. 4

2.1. SINHRONA OBDELAVA ............................................................................ 4

2.2. ASINHRONA OBDELAVA .......................................................................... 5

2.3. PLAČILNI ZAHTEVEK ............................................................................... 7

2.4. IZVORNI ZUNANJI KANALI ....................................................................... 8

2.4.1. EB za fizične osebe - sinhrona ............................................................ 9

2.4.2. EB za pravne osebe - sinhrona ........................................................... 9

2.4.3. EB za pravne osebe - asinhrona ....................................................... 10

2.4.4. UPO – sinhrona ................................................................................ 11

2.4.5. UPO – asinhrona............................................................................... 12

2.4.6. Lastna zaledna aplikativna rešitev - sinhrona .................................... 12

2.5. SISTEM IN RELACIJSKA BAZA PODATKOV .......................................... 13

2.5.1. Sistem ............................................................................................... 13

2.5.2. Baza podatkov .................................................................................. 14

3. PROCESA OBDELAVE ZAHTEVKA ............................................................... 15

3.1. SINHRON PROCES ................................................................................ 15

3.2. ASINHRON PROCES .............................................................................. 16

4. KRITIČNA ANALIZA ........................................................................................ 20

4.1. RAZVOJ ................................................................................................... 20

4.2. PREDNOSTI SINHRONE IN SINHRONE OBDELAVE ............................ 21

4.2.1. Prednosti sinhrone obdelave ............................................................. 21

4.2.2. Prednosti asinhrone obdelave ........................................................... 22

4.3. SLABOSTI SINHRONE IN SINHRONE OBDELAVE ................................ 23

4.3.1. Slabosti sinhrone obdelave ............................................................... 23

4.3.2. Slabosti asinhrone obdelave ............................................................. 24

5. ZAKLJUČEK ................................................................................................... 26

LITERATURA IN VIRI ............................................................................................ 28

KAZALO SLIK ........................................................................................................ 28

KRATICE IN AKRONIMI......................................................................................... 29

Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Matjaž Križaj: Primerjalna analiza sinhrone in asinhrone obdelave plačilnega zahtevka Stran: 1

1. UVOD

1.1. PREDSTAVITEV PROBLEMA Problem je večplasten. Napravljena je končna analiza, ki pomaga naročniku sprejeti pravilno, poslovno smotrno in dokončno odločitev pri nakupu aplikativne rešitve, ki je odvisna predvsem od naročnikovega sistema, sistema ponudnika in zahtev uporabnika. V analizi smo poskušali prikazati vse morebitne nejasnosti, ki jih prinaša posamezen način, kot tudi njegove prednosti. Pri tem smo upoštevali vse zakonske in interne zahteve po varnosti in zanesljivosti obdelave podatkov, ki so, predvsem v finančnih ustanovah, podrobno opazovane in nadzirane.

1.2. PREDSTAVITEV OKOLJA Opis sinhrone in asinhrone obdelave plačilnega zahtevka se navezuje na delovanje v finančni inštituciji, banki, kjer sta bila uspešno implementirana oba načina. Zaradi varovanja poslovnih skrivnosti je analiza opisana brez tistih posebnosti in pravil, ki so izključno vezani na to banko in njen informacijski sistem ter poslovne procese. Sama velikost banke ni pomembna, saj je potrebno zagotoviti uspešno obdelavo in izvedbo ne glede na število samih zahtevkov. Specifika banke je ta, da obvladuje več kot 1700 zunanjih šalterjev v realnem času, dve podpori elektronskega bančništva za pravne osebe, eno podporo za fizične osebe ter zaledne aplikativne rešitve.

1.3. CILJI Cilj, ki smo ga zasledovali skozi nalogo, je razjasnitev enega in drugega načina obdelave. Prikazuje realno sliko in razkriva vse slabosti in prednosti, ki jih prinašata oba načina obdelave. Podrobno smo opisali potek obdelav, opozorili na probleme, ki se pojavljajo, ter predstavili tako rešitve, ki se že uspešno izvajajo, kot tudi nove rešitve.

1.4. NAMEN Naš glavni namen je bila približati sinhroni in asinhroni način obdelave tistim, ki o področju informatike in nadzoru transakcij niso dovolj strokovno seznanjeni oziroma



poznajo to problematiko le bežno. Naloga je smernica in pripomoček pri odločitvah, ki jih je potrebno sprejemati, ko gre za nakup in implementacijo zunanjih aplikacij, ki morajo omogočati sinergijske učinke z glavnim sistemom, ki ga ima naročnik ali uporabnik aplikacije.

1.5. METODE DELA Študija knjižnih virov Pri svojem diplomskem delu sem uporabil zelo malo študije knjižnih virov. Prvi razlog za to je pomanjkanje konkretno zapisanih analiz o sinhroni in asinhroni obdelavi. Drugi razlog je zamudno iskanje teh analiz. V določenih delih so delno uporabljeni samo nekateri od preučenih zapiskov. Študija elektronskih virov Elektronski viri so danes zelo razširjeni, lahko dostopni in iskanje le-teh je zelo enostavno, seveda za tiste, ki nam je računalnik osnovni pripomoček pri našem vsakdanjem delu. Kljub temu je tudi na spletu malo materiala, ki ga je bilo mogoče uporabiti v diplomski nalogi. Zbiranje ustnih virov Moj poklic je sistemska analiza in zaradi tega imam ob sebi veliko strokovnjakov, s katerimi sem izmenjal izkušnje na tem področju. Tudi zunanji sodelavci so mi bili v pomoč, dovolj je bil kakšen stavek ali pogovor, ki mi je dal določene smernice za uspešno delo. Ker večina moje diplomske naloge zajema že obstoječe procese, je bil ta del pridobivanja informacij zelo koristen in uporaben. Delovne izkušnje Delovne izkušnje so ključne pri celotni diplomski nalogi. Na tem področju imam že več kot 25 let delovnih izkušenj, ki pa niso ključne le pri vsebini. Izredno pomembno je znanje uporabe komercialne programske opreme, tvorba posameznih stavkov in zapisov in seveda priprava slik, ki ponazarjajo posamezne načine procesiranja. Tudi končna analiza in primerjava izhajata iz delovnih izkušenj, saj prav na teh procesih aktivno delujem 10 let.



Blok diagrami Znano je, da slika pove več kot zapisano besedilo. Prav zaradi tega sem si prizadeval večino opisanega prikazati tudi slikovno. Takšen način uporabljam tudi pri tekočem delu, pri pripravi analize novih, obstoječih ali dopolnjenih procesov.



2. OBDELAVA PLAČILNIH ZAHTEVKOV

2.1. SINHRONA OBDELAVA Sinhrona obdelava poteka v realnem času, kar je vidno tudi na sliki 1, v eni logični enoti dela (LUW). Nadzor sinhrone obdelave poteka od začetka do konca obdelave. Za lažje razumevanje si predstavljajmo sestanek štirih udeležencev v enem prostoru. Vsi štirje imajo popolni nadzor nad potekom pogovora in dogajanjem v prostoru, in čeprav zmeraj govori le eden, ostali trije točno vedno, kakšna je vsebina pogovora. Do prekinitve pride v primeru, če bi kdo od udeležencev zapustil prostor in tako izgubil stik z ostalimi tremi. Tudi pri sinhroni obdelavi je proces podoben. V sam proces obdelave je lahko vključenih več različnih sistemov in kanalov. (RAJKOVIČ et al.,2008) Pomembna sta popolni nadzor trenutnega statusa obdelave in predvsem možnost, da se v primeru prekinitve vzpostavi prvotno stanje. Opisano si poglejmo na sliki 1, ki prikazuje sinhrono obdelavo. O sinhroni komunikaciji torej lahko govorimo v primeru, ko poteka popolni nadzor sistema nad celotno obdelavo do končnega odgovora uporabniku o, uspešnem ali neuspešnem, zaključku posamezne obdelave. Pri sinhroni obdelavi lahko pride tudi do »nasilnih« oziroma nepredvidenih prekinitev:

• uporabnika do aplikacije, ki jo uporablja, • sistema do uporabnika in • sistema do sistema, če je več sistemov povezanih v enoten sinhroni proces.

Značilnost sinhronih obdelav, v kolikor pride do nepredvidene prekinitve, je ta, da se takšna obdelava v določenem delu procesa prekine in tako se izgubi nadzor nad potekom obdelave. Gre za tako imenovane izjeme (exceptions) prekinitve, kjer moramo vzrok poiskati naknadno. Poudariti je potrebno, da to niso vsebinske napake oziroma napake pravilnosti podatkov, temveč:

• prekinitve v komunikacijah (izpad električne energije, izpad povezovalnih linij, izpad diskov ...),

• prekinitve zaradi nepravilne programske kode, • prekinitve zaradi napačne transformacije podatkov in

(alfa numeričen podatek v numeričnega, večje v manjše, črke v datum ...).



Aplikacijski strežnik vhodnega kanala

Uporabnik - iniciator obdelave

PC

Start obdelave Sprejem zahtevka

Poslan odgovorPrejet odgovor

Obdelava poteka v realnem časusinhrono

Klic glavne obdelave

Obdelava OKzapis zahtevka v DB2

Odgovor o uspešnosti zapisa v DB2

Relacijska bazaDB2

Slika 1: Sinhrona obdelava

V kolikor pride na kateri točki do prekinitve ali vsebinske zavrnitve obdelave, se izvede rollback (povrnitev stanja pred začetkom obdelave) in se odgovor o napaki takoj posreduje uporabniku. V primeru uspešne obdelave na vseh točkah se izvede commit (potrditev zapisa) in se odgovor o uspešni obdelavi posreduje uporabniku.

2.2. ASINHRONA OBDELAVA Uporabimo primer lažjega razumevanja tudi pri asinhroni obdelavi. Imamo prav tako sestanek štirih udeležencev, vendar je vsak v svojem zaprtem prostoru. Vsi štirje obravnavajo en dokument, ki ga ima istočasno samo eden udeleženec. Vsak udeleženec prebere predhoden zapis na dokumentu in dopiše svoje mnenje ter dokument odnese naslednjemu udeležencu, mu le-tega brez ustne komunikacije preda in odide nazaj v svoj prostor. Zadnji prejemnik naredi isto kot predhodnik, torej prebere že zapisano in dopiše svoje itn. Samo tisti, ki ima trenutno dokument, točno ve, kaj na dokumentu piše, kaj bo sam zapisal in tudi kdaj bo predal dokument naslednjemu udeležencu. Ostali trije lahko samo čakajo in predvidevajo, kaj bo



zapisal nekdo drug, vsekakor pa nimajo nobenega nadzora nad samim potekom branja, dopisovanja in dostave dokumenta s strani drugih udeležencev. Če se torej osredotočimo na naš opisan problem, je značilnost asinhrone komunikacije oziroma asinhrone obdelave, ki jo prikazuje slika 2, ta, da se uporabnik oziroma iniciator nekega sporočila ali v našem primeru plačilnega zahtevka ne ukvarja s problemom povezave do sistema, kjer bo prišlo do nadaljnjega posredovanja in obdelave nekega drugega sistema, temveč samo pripravi željen dokument in ga potrdi za nadaljnjo obdelavo. V kolikor gre za dvosmerno asinhrono komunikacijo, pa v določenem časovnem zamiku pričakuje odgovor, kjer bo izvedel, ali se je njegova zahteva uspešno obdelala.

Aplikacijski strežnik vhodnega kanala

Uporabnik - iniciator obdelave

PC

Start obdelave Odložen zahtevek

Poslan odgovorPrejet odgovor

Obdelava poteka v časovnem zamiku- asinhrono

Obdelava OKzapis zahtevka v DB2

Odgovor o uspešnosti zapisa v DB2

Relacijska bazaDB2

Časovni interval

Prevzem zahtevka

Prevzem odgovora

Slika 2: Asinhrona obdelava

V kolikor pride do prekinitve ali vsebinske zavrnitve obdelave, se izvede rollback (povrnitev stanja pred začetkom obdelave) in se pripravi odgovor o napaki, ki se odloži na dogovorjeno področje, kjer ga bo po določenem času prevzel aplikacijski strežnik vhodnega kanala in ga posredoval uporabniku. V primeru uspešne obdelave se izvede commit (potrditev zapisa) in se pripravi odgovor o uspešni obdelavi, ki ga bo po določenem času prevzel aplikacijski strežnik vhodnega kanala in ga posredoval uporabniku.



2.3. PLAČILNI ZAHTEVEK V banko, proces je viden na sliki 3, dobimo zahtevo za izvedbo plačila iz različnih vhodnih kanalov: elektronskega bančništva pravnih oziroma fizičnih oseb in poštnega okenca. Zahteva za izvedbo plačila se med izvornim kanalom in zaledno aplikacijo v banki posreduje v standardizirani enotni dogovorjeni strukturi t. i. plačilnega zahtevka. Standardizirana struktura določa obveznost oziroma neobveznost podatka, tip in dolžino podatka ter opisuje morebitne omejitve podatka. Zaledna aplikacija v banki posredovane podatke v strukturi plačilnega zahtevka validira in na podlagi rezultata validacije:

• podatke plačilnega zahtevka zapiše v bazo podatkov, če je odgovor validacije pozitiven, ali

• plačilni zahtevek izvoru zavrne s pripadajočo kodo napake.

Proces validacije je odvisen od tega, kam se plačilo usmeri, in od vrste vhodnega obrazca. Glede usmeritve lahko plačila lahko delimo na:

• plačila znotraj banke, • plačila znotraj države, • čezmejna plačila v območju evra in • plačila v tujino.

Plačilni zahtevek podpira sledeče vrste vhodnih obrazcev:

• posebno položnico, • plačilni nalog BN02, • univerzalni plačilni nalog UPN, • čezmejno plačilo RP01, • čezmejno plačilo STSE, • plačilo v tujino 1450 in • devizni prenos sredstev. (ZBS, 2010)



Slika 3: Posredovanje zahteve med vhodnim kanalom in banko

2.4. IZVORNI ZUNANJI KANALI Pri obdelavi plačilnih zahtevkov imamo v naši banki v aktivni uporabi sledeče izvorne kanale:

• EB za fizične osebe (fizična_oseba_EBF – sinhrona obdelava), • EB za pravne osebe (podjetje_EBP1 – sinhrona obdelava), • EB za pravne osebe (podjetje_EBP2 – asinhrona obdelava), • UPO (negotovinsko plačilo – sinhrona obdelava), • UPO (gotovinsko plačilo – asinhrona obdelava) in • lastna zaledna aplikativna rešitev (sinhrona obdelava).

EB počasi izriva klasično plačevanje plačilnih zahtevkov, ki ga opravimo na bančnem ali poštnem okencu, v zadnjem času pa tudi na Petrolovih servisih in Tuševih poslovalnicah, kjer lahko plačila izvajamo le z gotovino. Računalniki so postali stalnica tudi v naših domovih ter predvsem mlajša in srednja generacija se poslužujeta možnosti, da obveznosti (plačila) izvajata iz domačega naslonjača. Prav zaradi povečanja obsega elektronskega poslovanja je potrebno imeti vse pod popolnim nadzorom ter v največji možni meri zmanjšati morebitne anomalije in nepravilnosti. Vsi smo še kako občutljivi, kadar gre za naša finančna sredstva, in prioriteta vsake bančne ustanove je, da zagotovi pravilnost, zanesljivost, kakovost in varnost svojih storitev.



2.4.1. EB za fizične osebe - sinhrona

Fizična_oseba_EBF - sinhrona obdelava Komunikacija obdelave poteka med fizično osebo in banko, preko CICS-a. Uporabnik pošilja posamezne plačilne zahtevke v realnem času in po potrditvi vnosa počaka na takojšen odgovor o uspešnosti izvedene obdelave. Gre za sinhroni način, kar pomeni, da je transakcija nadzorovana od začetka do konca. V kolikor pride na kateri točki sprejema in obdelave transakcije do napake, prekinitve ali vsebinske zavrnitve, se negativni odgovor takoj pošlje uporabniku, ki lahko postopek ponovi, popravi napačne vsebinske podatke ali prekliče ponovitev zahteve.

2.4.2. EB za pravne osebe - sinhrona Podjetje_EBP1 - sinhrona obdelava Komunikacija obdelave poteka med podjetjem EBF1 in banko preko CICS-a. Uporabnik v podjetju pripravi plačilne zahtevke, ki se nahajajo v enem paketu. Po elektronskem podpisu tega paketa se obdelava, transakcija prične izvajati na bančnem strežniku, in sicer preko vmesnika. Vmesnik prevzame le številko paketa in se poveže na bazo EB, kjer se postopek obdelave izvaja tako, da se najprej poiščejo vsi pripadajoči plačilni zahtevki tega paketa, nato pa se vsak posamezno obdela v celoti. Po posamezni obdelavi vsakega plačilnega zahtevka tega paketa se preveri uspešnost obdelave.

a) Plačilni zahtevek se zavrne, v tabeli zahtevkov na EB se zabeleži status neuspešnosti obdelanega plačilnega zahtevka in se izvede commit, kar pomeni, da je obdelava uspešno zaključena. Uspešnost obdelave namreč ne izkazuje uspešnost iz vsebinskega, temveč iz procesno transakcijskega vidika.

b) Plačilni zahtevek je uspešno obdelan in se v prvem koraku procesa zabeleži v bazo banke, v drugem koraku se na EB zabeleži status uspešnosti obdelave zahtevka in se izvede commit, kar pomeni, da je bila obdelava uspešno zaključena. Vmesnik nadaljuje z naslednjim plačilnim zahtevkom iz istega paketa in ta proces se nadaljuje tako dolgo, dokler niso vsi plačilni zahtevki tega paketa uspešno transakcijsko obdelani.

c) Celoten proces obdelave zahtevkov enega paketa se zaključi z ažuriranjem statusa paketa na EB, in sicer:

• v kolikor je bil v paketu vsaj eden plačilni zahtevek vsebinsko zavrnjen, dobi paket status neuspešno obdelan in dodaten komentar »vsaj 1 zahtevek v paketu je zavrnjen«, ali

• v kolikor so bili v paketu vsi zahtevki uspešno vsebinsko obdelani in zapisani v bazo banke uspešno zabeleženi in pripravljeni za nadaljnjo posredovanje v plačilni promet banke, dobi paket status uspešno obdelan in dodaten komentar »vsi zahtevki so uspešno obdelani«, ali



• v kolikor je bil v paketu vsaj eden plačilni zahtevek z datumom valute vnaprej, kar pomeni, da se bo dokončno obdelal in izvajal v prihodnosti, dobi paket status v čakanju in dodaten komentar »vsaj eden plačilni zahtevek je v čakalni vrsti«.

Pri obdelavi paketa gre za izredno hitre odzivne čase, ki se merijo v desetinkah sekunde, kar pomeni, da uporabnik takoj prejme odgovor o statusu paketa, ki ga je posredoval v obdelavo, in lahko takoj pregleda posamezne plačilne zahtevke, predvsem tiste, ki so bili vsebinsko zavrnjeni, in postopek ponovi, ko vsebinsko napako popravi. V opisanem primeru je potrebno poudariti, da morata oba poslovna segmenta, EB in banka, uporabljati isto bazo, saj drugače ni mogoče na noben način zagotoviti popolne sinhronosti oziroma imeti celotno transakcijo popolnoma pod nadzorom. Različni sta lahko instanci, kjer se nahajajo tabele EB-ja in sistema banke. V kolikor bi bili bazi različni, bi se moral izvesti nov connect, kar pa bi takoj prekinilo nadzor nad dosedanjim potekom obdelave in transakcija ne bi bila več sinhrona, temveč asinhrona.

2.4.3. EB za pravne osebe - asinhrona Podjetje_EBP2 - asinhrona obdelava Komunikacija obdelave poteka med podjetjem EBF2 in banko v točno določenih časovnih intervalih, ki so dogovorjeni med obema podjetjema. V bistvu gre za dva popolnoma ločena sistema, ki pa se ob dogovorjenem času povežeta po pravilih, ki so dogovorjena in zapisana. Izmenjujeta si datoteke in izvajata obdelavo na svojem sistemu. Seveda se obdelave dogajajo vsaka na svojem »dvorišču«, kar pomeni, da niti uporabnik na strani EB, niti sistemski analitiki ali vsebinski skrbniki v banki, ne vedo, kako poteka določena obdelava na drugi strani. Gre torej za tipično asinhrono komunikacijo. Uporabnik v podjetju, v aplikativnem okolju EB, pripravi vse plačilne zahtevke, ki jih želi posredovati banki. Ko zaključi z vnosom, elektronsko podpiše pripravljene zahtevke, ki se običajno nahajajo v enem paketu, in s tem zaključi. Sistem EB vse podpisane pakete, za enega uporabnika in eno banko, združi v datoteko in jo odloži na določeno področje, ki se nahaja na njihovem strežniku. Ta postopek priprave se lahko izvaja takoj, ko so paketi podpisani, ali pa ob točno določenem časovnem intervalu, kar je odločitev posameznega podjetja oziroma načina izvajanja aplikativne rešitve. Na drugi strani sistem banke ob točno določenih intervalih preverja skupno področje, ali so odložene kakšne nove datoteke. Ko sistem banke ugotovi, da so nove datoteke pripravljene, jih prenese na svoj sistem in prične z obdelavo. Za vsak



plačilni zahtevek se pripravi odgovor, ki se zapiše v datoteko, in na koncu obdelave se datoteka ali več datotek prenese in odloži na skupno področje, kjer jo bo pobral in obdelal sistem EB. Kdaj bo uporabnik dobil odgovor o uspešnosti obdelave plačilnih zahtevkov, ki jih je pripravil, je odvisno od dogovorjenega časa izmenjave datotek. V našem primeru gre za 20-minutne časovne intervale, kar pa ne pomeni, da uporabnik čaka na odgovor minimalno 20 minut, temveč da je lahko ta čas maksimalno 40 minut, če bi se zahtevki pripravili takoj po zadnji časovni obdelavi. Sistem EB ima časovne preseke na 5, 15, 25, 35, 45 in 55 minut, sistem banke pa na 10, 20, 30, 40 in 50 minut ter ob uri. Tako smo poskušali doseči optimalen časovni interval med pripravo, obdelavo in posredovanjem odgovora o uspešnosti obdelave uporabniku. Poudariti je potrebno, da se takšne izmenjave ne morejo izvajati na krajši interval, saj lahko v takšnem primeru prihaja do večjih problemov, ki bi se kazali v tem, da bi sistem lahko pričel ponovno obdelovati datoteke, ki jih že ima v obdelavi. Seveda ta možnost obstaja tudi sedaj, vendar je izredno majhna in tudi nadzorovana, saj se datoteke v obdelavi zaklenejo in so tako za sistem nedostopne. Enako bi se lahko zgodilo tudi v primeru krajšega intervala, vendar sta praksa in test pokazala, da je takšnega zaklepanja preveč in zaradi tega vendarle obstaja veliko večja verjetnost, da pride do sistemske prekinitve in neuspešnosti obdelave.

2.4.4. UPO – sinhrona Negotovinsko plačilo Komunikacija obdelave poteka med UPO (Pošta Slovenije) in banko preko CICS-a. Banka nima svojih bančnih okenc, temveč to storitev za njo pogodbeno opravlja Pošta Slovenije, ki ima najmočnejšo in najštevilčnejšo mrežo »šalterjev« v Sloveniji. Istočasno lahko do sistema banke pride 1470 uporabnikov. Uporabnik odda plačilni zahtevek (obrazec) na UPO, kjer ga poštni delavec vnese v aplikativno rešitev in ga potrdi. V tem trenutku se vzpostavi komunikacijska povezava med sistemom PS in banko, ki tudi prične z obdelavo v realnem času. Izvedejo se vse logične in vsebinske kontrole in generira se odgovor o uspešnosti obdelave, ki se takoj posreduje nazaj na UPO, kjer poštni delavec zaključi obdelavo z izpisom potrdila ali pa v primeru vsebinske napake slednjo sporoči uporabniku. Zaradi specifičnosti procesa negotovinskega plačila, kar pomeni prenos denarnih sredstev iz izvornega računa na ciljni račun, ki zahteva tudi preverbo trenutnega stanja na izvornem računu, je ta transakcija le sinhrona in popolnoma nadzorovana, saj morajo biti denarna sredstva zagotovljena, da se lahko denar tudi dejansko prenese na ciljni račun. Stanje na izvornem računu se namreč istočasno zniža za zahtevan znesek na plačilnem zahtevku.



2.4.5. UPO – asinhrona Gotovinsko plačilo Komunikacija obdelave poteka med UPO (Pošta Slovenije) in banko, vendar ne v realnem času, temveč asinhrono. Gre za paketne prenose, ki se izvajajo vsakih 30 minut. Uporabnik odda plačilni zahtevek (obrazec) na UPO, kjer ga poštni delavec vnese v aplikativno rešitev in ga potrdi. Uporabnik tudi preda znesek plačilnega zahtevka v gotovini, kar pomeni, da so sredstva za izvedbo plačila na ciljni račun takoj zagotovljena. Vse potrebne formalno vsebinske kontrole (pravilnost in obstoj ciljnega računa, sklica, zneska, datuma ...) se izvedejo v sami UPO aplikativni rešitvi in zaradi tega ne pride do takojšnje povezave med PS in banko. V kolikor je plačilni zahtevek vsebinsko ustrezen, se ta zabeleži v bazo PS na regionalni strežnik. Po določenem časovnem intervalu se prenese na glavni strežnik, kjer se vsi plačilni zahtevki združujejo v pakete po 100 plačilnih zahtevkov. Ob dogovorjenih urah se sproži postopek prenosa na bančni strežnik, kjer vmesnik obdela celoten paket plačilnih zahtevkov in jih zapiše v bazo DB2, kjer se dokončno obdelajo. Procesno bi lahko tudi gotovinska plačila izvajali sinhrono in v neposredni povezavi, in sicer eden po eden, vendar so bile v začetku (leta 2001) komunikacijske povezave še vezane na ADSL linije in je vsaka transakcija pomenila strošek. Ker v tem času še EB ni bilo tako razširjeno in je večina ljudi plačevala položnice in plačilne naloge prav na poštah, je bil strošek povezave za en plačilni zahtevek sicer zanemarljiv, vendar je ta številka ob določenih datumih (pokojnine, plače) presegla številko 400.000 nalogov na dan. Trenutno se gotovinska plačila še izvajajo na enak, paketni način, vendar novi zakoni narekujejo (UPN), da je potrebno vsak plačilni zahtevek obravnavati posamezno, kar bo v prihodnosti narekovalo tudi spremembo komunikacije med PS in banko.

2.4.6. Lastna zaledna aplikativna rešitev - sinhrona Naša banka ima tudi lastne aplikativne rešitve, kjer imajo vsebinski skrbniki možnost vnosa posameznega plačilnega zahtevka interaktivno. Aplikacija deluje na sistemu banke in seveda na lastni relacijski bazi. Ob vnosu se izvajajo vse potrebne interaktivne vsebinske kontrole in plačilni zahtevek se zapiše v bazo, ko so vsi podatki pravilni in obdelava uspešno zaključena. Transakcija je popolnoma sinhrona in zagotavlja največjo možno varnost in zanesljivost, ki jo sistem in baza podatkov nudita.



2.5. SISTEM IN RELACIJSKA BAZA PODATKOV

2.5.1. Sistem Infrastruktura informacijskega sistema banke, ki je prikazan na sliki 4, se nahaja na dveh lokacijah, primarni in rezervni. Vsi ključni gradniki (strežniki, mrežna oprema, komunikacijske povezave, napajanje in diskovni podsistemi) informacijske infrastrukture so podvojeni. S tem banka zagotavlja neprekinjeno delovanje v okvirih, kot so določeni z notranjimi pravilniki in so v skladu s pravili Banke Slovenije. Osnovni gradnik predstavljata strežnika tipa UNIX, v našem primeru IBM Power Sistem. Razpoložljivost je zagotovljena z dvema ločenima lokacijama, avtomatizacija postopka preklopa izvajanja procesov iz primarne na rezervno lokacijo je izvedena z implementacijo programske opreme HACMP (High Availability Cluster Multiprocessing). Podvojen je tudi diskovni podsistem za hrambo podatkov. Dodatno varovanje zagotavljata dve tračni knjižnici na obeh lokacijah. V primeru popolnega izpada primarne lokacije se izvede avtomatski preklop na rezervno lokacijo. Potreben čas avtomatskega preklopa je 15 minut. Vsa programska oprema se izvaja na operacijskem sistemu IBM AIX (UNIX). To je robusten večprocesorski sistem, ki zagotavlja učinkovito in optimalno uporabo strojnih sredstev (procesorji, delovni spomin, vhodno-izhodne enote). Komunikacija s sistemom poteka preko različnih mrežnih in optičnih protokolov:

• SAN (Storage Area Network) za priklop diskovnih podsistemov, • TCP/IP za komunikacijo znotraj in zunaj banke, • FTP (File Transfer Protokol) za prenos datotek in • SNA (Systems Network Architecture) za povezavo s Pošto Slovenije (UPO).

Kot centralni transakcijski sistem se uporablja CICS v povezavi z relacijsko bazo podatkov DB2. Zagotavlja konsistenco transakcij (LUW) in veliko število transakcij v eni časovni enoti. Večinoma se uporablja v velikih sistemih (banke, letalske družbe, borze itn.), kjer moramo zagotoviti obdelavo velikega števila istočasnih transakcij.



Slika 4: Primarni in rezervni sistem banke

2.5.2. Baza podatkov Centralno bazo podatkov predstavlja IBM DB2 relacijska baza. Baza tega tipa omogoča širino shranjevanja različnih tipov podatkov (podatki, slike, XML, PDF…). Je odporna na različne tipe napak, kot je nepredviden izpad sistema. S svojo arhitekturo zagotavlja avtomatsko vzpostavitev (recovery) in konsistenco podatkov. Imamo več instanc podatkovne baze, ki se uporabljajo v različne namene:

• razvojno, • testno, • produkcijsko in • arhivsko.



3. PROCESA OBDELAVE ZAHTEVKA

3.1. SINHRON PROCES V zgodovini je komunikacija najprej potekala le ob prisotnosti udeležencev v istem prostoru in času, razvoj komunikacijskih medijev pa je omogočil prostorsko in časovno distanco med udeleženci. (ŠKERLEP, 2010) Sinhrona komunikacija pomeni, da so vsi udeleženci prisotni v realnem času, istočasno. Nekateri primeri sinhrone komunikacije so:

• telefonski pogovor, • pogovor dveh ali več oseb v ali na enem prostoru in • sestanki v podjetjih. (Definethat, Technical Definitions:,2010)

Če je za računalniško posredovano komunikacijo prostorska distanca pravilo, pa lahko poteka sočasno ali ne-sočasno glede na dejstvo, ali so udeleženci komunikacije sočasno (hkrati) prisotni ali ne. V našem vsakdanjem življenju sta vedno prisotna oba načina komunikacije. Pred razvojem novih tehnologij je bila sinhrona komunikacija veliko bolj prisotna, saj druge možnosti niso bile tako razvite. Danes obstajajo predvsem tri popularna orodja, ki omogočajo sinhrone dvosmerne konverzacije prek medija teksta po načelu mnogi z mnogimi: pogovorni kanal (chat,

talk) na lokalnih strežnikih ali na predstavitvenih mestih v okviru WWW, IRC (Internet Relay Chat), ki tvori zelo popularen sistem komuniciranja prek več tisoč komunikacijskih kanalov, ter MUD (Multiple User Domain) sistemov, ki tvorijo t. i. “na tekstu osnovano virtualno resničnost” (text-based virtual reality), v kateri lahko uporabniki poleg sinhrone in asinhrone medosebne in skupinske komunikacije gradijo tudi softwerske objekte, ki tvorijo elemente teh virtualnih svetov. Trenutno so popularna tradicionalna orodja vseh treh vrst konverzacije omejena na tekstualno komuniciranje, ki je blizu vsakdanji konverzaciji, zato lahko zapišemo, da gre za tekstualno konverzacijo. Uporabnik tipka sporočila, ki se istočasno izpisujejo na ekran vseh udeležencev sinhrone komunikacijske interakcije. V praksi se ta tip komuniciranja uporablja večinoma za neformalno klepetanje, precej manj pa za profesionalno komuniciranje. Področje sinhronih dvosmernih konverzacij pa prav v zadnjih letih doživlja velike spremembe. V zadnjih nekaj letih so se pojavila orodja, ki omogočajo sinhroni dvosmerni prenos zvoka (npr. Internet Telephone), in orodja, ki omogočajo avdiovizualen prenos in so zametek videofona (npr. CU-SeeMe). Na osnovi MUD sistemov pa so se v letih 1995/6 začeli pojavljati prvi, zaenkrat še okorni



multimedijski virtualni svetovi, ki so v tekstualno konverzacijo vključili še dvodimenzionalne grafične objekte, npr. The Palace, obstajajo pa tudi že virtualni svetovi s tridimenzionalnimi grafičnimi objekti (po VRML protokolu), npr. Black Sun. Na osnovi ekstrapolacije omenjenih trendov razvoja lahko sklepamo, da bo v naslednjem desetletju mogoče sinhrono dvosmerno komunicirati prek več kanalov oziroma medijskih formatov v simuliranih tridimenzionalnih virtualnih svetovih.

3.2. ASINHRON PROCES Asinhrona dvosmerna komunikacija je zelo prisotna v današnjem času. Enostavno bi jo lahko opisali na način jaz tebi, po določenem času pa ti meni. Seveda pri asinhroni komunikaciji nikdar točno ne vemo, kdaj bomo odgovor prejeli oziroma, če ga bomo sploh prejeli. Asinhrona komunikacija namreč ne zahteva, da so vse strani, ki so vpletene v sporočilo, prisotne in na voljo v realnem času oziroma ves čas. Danes najbolj poznani načini asinhrone komunikacije so:

• Elektronska pošta je najbolj enostaven način asinhrone izmenjave sporočil med dvema ali več uporabniki, zato od nastanka računalniških omrežij nastopa kot najpogosteje uporabljano orodje dvosmerne komunikacije. Prevzemanje aktivne vloge sporočevalca je izjemno enostavno. Elektronska pošta lahko služi najrazličnejšim komunikacijskim namenom: lahko je uporabljena za povsem neformalno intimno komuniciranje, lahko pa za neosebno formalno komunikacijo, ki je vezana na institucionalno komuniciranje in poklicno sodelovanje, npr. za komuniciranje med neko institucijo in njeno stranko. Pomembno je, da je lahko isto pismo hkrati poslano na več naslovov, zato lahko služi komuniciranju v okviru (običajno manjših) skupin. (Škrlep, 2010)

• Računalniške konference so asinhroni način posredovanja tekstualnih sporočil v (običajno večji) skupini. Obstajata dva principa: pri prvem, tj. “Listserver” strežniku, uporabnik, ki ima dostop do računalniške konference, pošlje svoje sporočilo na strežnik, ki ga avtomatsko odpošlje vsem članom skupine; pri drugem, tj. USENET, uporabnik pošlje sporočilo na avtomatizirani USENET strežnik, ki sporočilo shrani na javno dostopni bazi podatkov, tako da ga lahko bere vsakdo, ne samo osebe, ki so naročene na računalniško konferenco. Oba mehanizma računalniških konferenc predstavljata zelo učinkovit in izjemno popularen način skupinske komunikacije po načelu mnogi z mnogimi. USENET je povsem javen način skupinskega komuniciranja, ker so sporočila urejena v hierarhijo tematsko urejenih in preglednih direktorijev, ki so javno dostopni. Listserver

konference pa so nekoliko manj dostopne, saj se mora posameznik na njih najprej prijaviti; lahko so odprtega tipa (kdor se prijavi, je avtomatsko uvrščen na konferenco, v kateri lahko aktivno sodeluje) ali zaprtega tipa (dostopne so samo določeni skupini ljudi). V praksi se uporabljajo za diskusije med



uporabniki s podobnimi interesi in preferencami, pri čemer gre lahko za resne diskusije o povsem strokovnih temah ali pa za klepetanje o ljubiteljskih ali povsem trivialnih temah. Pomembno je, da računalniške konference omogočajo nastajanje interesnih skupin na globalni oziroma planetarni ravni. (ŠKERLEP, 2010)

• Kratka sporočila (kratica SMS - Short Message Service) so tehnologija na mobilnih telefonih in tudi na računalnikih. Omogočajo prenos besedilnih sporočil do 160 znakov, nekateri ponudniki omogočajo tudi več (razdelijo jih na več krajših sporočil). Nekaj čas je bila storitev možna tudi na računalnikih, zaradi zlorab pa ni več. Obstajajo spletne strani in ponudniki, ki to še omogočajo, vendar so storitve plačljive ali pa vsebujejo reklamna sporočila. Novejša tehnologija, ki omogoča prenos slik, se imenuje MMS.

• JMS JAVA EE sporočilni sistemi (Java Message Service) omogočajo asinhroni način komunikacije med enotami sistema. Uporaba sporočilnih sistemov je smiselna: - v kolikor ne zahtevamo istočasne komunikacije med prejemniki in

pošiljatelji sporočil, - ko potrebujemo zanesljiv odgovor od prejemnika sporočila, a nimamo

časovne omejitve za odgovor, - želimo zasnovati sistem, ki je šibko sklopljen (loosey coupted), - komuniciramo med aplikacijami in sistemi na različnih platformah ter

napisanih v različnih programskih jezikih in - v kolikor predvidevamo, da je prejemnik sporočila določen čas

nedosegljiv in ga morajo sporočila počakati. JMS sestavljajo:

- ponudnik, ki implementira JMS vmesnike in skrbi za povezavo z ustreznim sistemom,

- odjemalci, programi ali komponente, ki sprejemajo ali pošiljajo sporočila, - sporočila, objekti, ki se prenašajo med JMS odjemalci, in - administrirani objekti, ki jih administrator ustvari za uporabo odjemalcev.

To so predvsem cilji za sporočila in tovarne povezav, ki zahtevajo konfiguracijo glede na lokacijo namestitve aplikacije.

JMS podpira dve vrsti pošiljanja sporočil: - en prejemnik (point-to-point), kar pomeni, da ima vsako sporočilo

samo enega naslovnika (slika 5). Sporočila se nalagajo v FIFO (first in first out) vrsto, kjer čakajo na dostavo. Obstoj prejemnika ni nujen, ko pošiljatelj pošlje sporočilo, prejemnik pa mora potrditi prejem sporočila; in



Slika 5: En prejemnik (povezava od točke do točke) - asinhroni proces

- več prejemnikov (publish) pomeni, da je lahko sporočilo namenjeno več prejemnikom, ki se morajo za sprejemanje sporočil "naročiti" na temo (slika 6). Naročniki ne dobijo sporočil, ki so bila poslana pred prijavo. Sporočila lahko nekaj časa počakajo, da bo naročnik na voljo.

Se prijavidobi

Slika 6: Več prejemnikov



Poleg elektronske pošte je najpogosteje uporabljana vrsta računalniško posredovane komunikacije način komunikacijske izmenjave, pri katerem sporočevalec shrani svoje komunikacijske vsebine (datoteke) na strežniku, ki je sprejemalcem dostopen preko interneta. Pri tem načinu sprejemalcu sporočilo ni dostavljeno, ampak ga mora sam poiskati in ga odpreti. Tradicionalno ta način komunikacije v anglosaškem svetu imenujejo “information sharing” ali “information

retrieval”, v zadnjem letu pa so začeli uporabljati naziv “pull media” (v nasprotju s “push medija”). Gre v bistvu za asinhrono enosmerno komunikacijo, ki je potencialno množična, saj lahko isto datoteko “odpre” ali prenese na svoj računalnik velika množica uporabnikov. Vendar pa je občinstvo le potencialno množično, saj večino na strežnikih dostopnih sporočil odpre le majhna skupina uporabnikov. Enosmerna asinhrona komunikacija pa je zelo pomembna, saj se uporabniku internet v tem modusu kaže kot ogromna baza podatkov ali še bolje - kot ogromna knjižnica. (KRIŽEVNIK, VIRAG, ZORKO, JURIČ, 2011) • e-izobraževanje Sistemi za upravljanje e-izobraževanja predstavljajo informacijske rešitve, ki temeljijo na internetu in spletnih tehnologijah. Informacijska infrastruktura omogoča sinhrono in asinhrono komunikacijo, zato najboljši sistemi za upravljanje e-izobraževanja vključujejo obe vrsti komunikacije. Asinhrona komunikacija omogoča uporabniku prilagojeno časovno uporabo učnega gradiva. Skupnega sodelovanja udeležencev ni, izobraževalni proces pa se izvaja predvsem z branjem ali s predvajanjem video ali avdio posnetka. Sodelovanje z drugimi udeleženci v izobraževalnem procesu je omejeno na uporabo interne e-

pošte, ki omogoča komunikacijo z izbranimi prejemniki sporočil v sistemu in je posebej primerna za individualne konzultacije študentov z mentorjem/tutorjem in neposredne komunikacije med posamezniki. Tudi diskusijski forumi so osrednje asinhrono komunikacijsko orodje, s katerimi mentor organizira delo študentov. (ARH, RAJKOVIČ, BORKOR JERMAN, 2010)

• e-dokumentacija Ustrezna dokumentacija je ključnega pomena za upravljanje procesov tudi na področju zdravstvene nege. Gre za celovito spremljanje podatkov o pacientu na klinični poti, ki se nanašajo na zdravstveno nego. Taka dokumentacija omogoča sledljivost, transparentnost, selektivnost, spremljanje in analize, kar vodi v izboljšanje procesov in sistemov ter povečanje varnosti pacienta in članov zdravstvenega tima. E-dokumentacija ne pomeni le prenovo dokumentacije same, ampak predvsem prenovo obstoječih procesov. (RAJKOVIČ et al., 2008)



4. KRITIČNA ANALIZA

4.1. RAZVOJ Pred analizo in razlago prednosti in slabosti obeh načinov izvajanja obdelav predstavljamo naš pogled na razvoj implementiranih rešitev in težave, ki so se pojavile pri načrtovanju in izvedbi končne rešitve. Pri obeh načinih obdelave so enakovredno vključeni tako sistem banke kot sistemi zunanjih izvajalcev. Sinhrona obdelava Razvoj priprave rešitve za sinhrono obdelavo je zajemal integracijo z zunanjimi sistemi izvajalcev PS za UPO, prvim zunanjim izvajalcem za EB za pravne osebe in Banko Koper kot distributerjem transakcij, ki nastanejo na bankomatih in POS terminalih. Pošta Slovenije - UPO Pri integraciji s PS je bilo največ dela in težav pri pripravi skupnega komunikacijskega zapisa, ki je moral vsebovati vse parametre in podatke, ki so bili potrebni za obdelavo posamezne transakcije, ne glede na posel oziroma ne samo za plačilne zahtevke. Komunikacijskega stavka nismo prilagajali količini podatkov posameznih poslov, temveč smo si zastavili cilj, da pripravimo enotni stavek, ki bo dovolj širok, da bo različnost vsebine po poslih pokrita v celoti. Zelo pomembni so bili dogovorjeni protokoli izmenjave rezultatov obdelave posamezne transakcije. Predvsem pri zavrnjenih transakcijah je bilo potrebno predvideti vse možne kombinacije, do katerih lahko pride. Razvoj je potekal več let in še danes, ko je sistem utečen, se lahko pojavijo problemi, ki jih ni bilo mogoče predvideti na začetku. Bankomati in POS Zelo podoben način se je uvedel pri avtorizacijah transakcij, ki nastanejo na bankomatih in POS terminalih pri poslovanju dvigovanja gotovine. Prvi zunanji izvajalec EB za pravne osebe Pri zunanjem izvajalcu EB, kjer smo se dogovorili za popolnoma sinhrono obdelavo, je bil del procesa podoben komunikaciji z UPO. Največja razlika in posledično določena težava se je pojavila pri načinu ažuriranja tabel relacijske baze, za katero skrbi zunanji izvajalec. Prvi pogoj je bila enaka baza podatkov DB2. Zaradi pravic dostopanja do njihovih tabel so le-te na drugi instanci, kar še vedno zagotavlja nadzor ene logične enote dela. To pomeni, da se v primeru napake na katerem koli koraku obdelave vrnemo na začetno stanje, brez skrbi, da bi prišlo do napačnega zapisa podatkov v njihovih ali naših tabelah (ROLLBACK). Ob uspešni celotni obdelavi pa se podatki v realnem času zapišejo v vseh tabelah (COMMIT). Asinhrona obdelava Razvoj priprave rešitve za asinhrono obdelavo je zajemal integracijo z zunanjimi sistemi izvajalcev PS za UPO in drugim zunanjim izvajalcem za EB za pravne



osebe. V primerjavi z implementacijo sinhronih transakcij in obdelav sta bila razvoj in priprava veliko lažja, hitrejša in predvsem poznana. Pošta Slovenije - UPO Pri integraciji s PS smo uvedli t. i. paketno pošiljanje vseh transakcij, ki so na UPO nastale samo v aplikativni rešitvi PS (OFFLINE). Sistem PS intervalno zbira podatke o plačilnih zahtevkih, ki so bili poravnani z gotovino in ni bilo potrebe po dodatnem preverjanju na našem sistemu v realnem času. Na svojem glavnem strežniku grupira plačilne zahtevke in jih zapisuje največ do 100 v en paket, in sicer zaporedno do velikosti 32k. V 30-minutnih presekih pošlje PS te pakete do našega sistema, kjer se ti plačilni zahtevki posamezno obdelajo in se s spremenjenim statusom o uspešnosti obdelave pošljejo nazaj na strežnik PS. Drugi zunanji izvajalec EB za pravne osebe Gre za klasično izmenjavo datotek, katerih strukturo je določil in posredoval zunanji izvajalec. Datoteke se izmenjujejo v 10-minutnem intervalu. Naš sistem prevzame pripravljene datoteke s plačilnimi zahtevki, ki so odložene na dogovorjenem področju sistema, ki ga nadzoruje zunanji izvajalec. Po prevzemu se izvede obdelava na sistemu banke. Informacije o uspešnosti ali neuspešnosti se zabeležijo v novo datoteko, ki jo po koncu obdelave sistem banke odloži na dogovorjeno področje v dogovorjeni strukturi. Sistem zunanjega izvajalca te datoteke prevzame, jih obdela in tako uporabnik dobi informacijo o uspešnosti in izvedbi obdelave plačilnih zahtevkov, ki jih je pripravil in podpisal. Datotek je več vrst, odvisno od vrste plačilnega zahtevka (domači, tuji, konverzije, kompenzacije, stanja itn.).

4.2. PREDNOSTI SINHRONE IN SINHRONE OBDELAVE

4.2.1. Prednosti sinhrone obdelave Največji prednosti sinhrone obdelave sta popolni nadzor obdelave in hitrost odziva sistema do uporabnika. Uporabnik v realnem času pridobi odgovor, ali je bila njegova zahteva po izvedbi plačilnega zahtevka uspešna ali ne. Zaradi tega ima možnost, da v primeru zavrnitve zaradi vsebinske napake, le-to takoj odpravi in ponovno poda zahtevo za izvedbo. Prav tako ne izgublja v današnjem času prepotrebnega časa ob čakanju odgovora in se lahko v primeru uspešne obdelave takoj preusmeri na druga dela in naloge, ki jih ima pred seboj. Hitrost obdelav se zaradi komunikacij in sistemov, ki jih imamo danes na voljo, merijo v desetinkah sekunde in uporabnik ima dejansko občutek, da se vse dogaja v prostoru, kjer se nahaja tudi sam. Po analizi prioritet uporabe aplikativnih rešitev, ki jih omenjajo uporabniki, si sledijo:

• hitrost (sinhrona), • zanesljivost (sinhrona, asinhrona), • enostavnost (sinhrona, asinhrona), • dostopnost (pogojno sinhrona, asinhrona) in • vizualna privlačnost aplikacije (sinhrona, asinhrona).



Velika prednost sinhrone obdelave je torej obveščanje uporabnika o napakah v realnem času. Velikokrat se zgodi, da uporabnik ne ve, da bo njegova zahteva o plačilu izvedena šele naslednji delovni dan, saj ne moremo od njega pričakovati, da bo obvladoval vsa pravila, ki obstajajo v bančnem sistemu. V primeru sinhrone obdelave je o tem takoj obveščen in sam se odloča o tem, ali bo plačilni zahtevek kljub temu posredoval, ali pa bo počakal na naslednji delovni dan in postopek ponovil. Sinhrona obdelava je danes želja oziroma skoraj zahteva večine uporabnikov, ki elektronsko poslovanje obvladujejo do potankosti in si brez njega težko zamislijo svoje poslovanje ali delo, tako na delovnem mestu kot v privatnem življenju. To dokazuje povečana uporaba elektronskega poslovanja za fizične osebe, bankomati, mobilna telefonija, kamor štejemo mobilne storitve, kot so plačevanje, naročanje, pogovori, internet itn.

4.2.2. Prednosti asinhrone obdelave Če analiziramo samo obdelavo plačilnih zahtevkov, ne najdemo ravno veliko prednosti. Največja prednost za uporabnika je komunikacijska neodvisnost od sistema, ki obdeluje pripravljene in poslane zahtevke. Uporabniku se ni potrebno obremenjevati s tem, ali sistem, ki bo izvedel obdelavo, v tem trenutku deluje ali ne. Popolnoma neodvisno si lahko pripravi plačilne zahtevke, jih elektronsko podpiše in pošlje v izvajanje. Takoj zatem lahko z delom prekine in kasneje preveri, ali so bili vsi pripravljeni in poslani zahtevki uspešno obdelani. Vendar pa tudi v tem primeru ne sme biti prevelike časovne razlike med pripravo, obdelavo in prejetjem odgovora o uspešnosti obdelave. Pri prednostih asinhrone obdelave se lahko dotaknemo tudi računalniških podjetij, ki razvijajo in prodajajo aplikativne rešitve za elektronsko poslovanje. Prav asinhronost jim omogoča, da implementirajo želeno rešitev neodvisno od platforme sistema naročnika, ki bo te plačilne zahtevke obdeloval. Edina zahteva, ki jo morata izpolniti obe pogodbeni strani, je uskladitev komunikacijskih stavkov oziroma struktur datotek, ki se bodo pošiljale in prejemale med sistemoma. Določiti se mora protokol prenosa teh datotek in definirati sporočila o morebitnih napakah pri prevzemu ali prenosu datotek kot tudi natančen komentar o vsebinski napaki, ki bo uporabniku nedvoumno pokazala, kateri podatek je izpolnil napačno oziroma zakaj je bil zahtevek zavrnjen. Tako lahko podjetje, ki razvija aplikativne rešitve, neodvisno sodeluje z več pogodbenimi partnerji, pri tem pa jim ni potrebno spreminjati in prilagajati same rešitve. Ta prednost se kaže ob morebitnih spremembah te rešitve, saj se mora dodelati le ena rešitev, ki se potem implementira vsem pogodbenim partnerjem.



V kolikor pa bi želeli prikazati prednosti asinhrone obdelave v celoti, pa bi morali upoštevati vse procese, ki se štejejo med asinhrono obdelavo in smo jih že opisali. Za osvežitev lahko vzamemo elektronsko pošto ali pošiljanje kratkih sporočil s pomočjo mobilnega telefona – SMS, ki sta danes najbolj razširjena med prebivalstvom našega planeta. Pri asinhroni komunikaciji namreč nismo odvisni od prisotnosti prejemnika, istočasno lahko isto sporočilo posredujemo več osebam, ne zanima nas, kakšen informacijski sistem ima prejemnik, prav tako ne, kakšen je njegov model telefona itn.

4.3. SLABOSTI SINHRONE IN SINHRONE OBDELAVE

4.3.1. Slabosti sinhrone obdelave Slabosti sinhrone obdelave so povezane z delujočimi komunikacijami med sistemi, pravilnim delovanjem aplikacij in vmesnikov ter dostopnostjo relacijske baze. V kolikor vsi "udeleženci", ki sodelujejo pri sinhroni obdelavi, delujejo brezhibno, je obdelava hitra in zanesljiva. Velik problem nastane, če pride do izpada katerega od naštetih "udeležencev". Problem prekinjene komunikacije se kaže že na začetku, ko se uporabnik želi prijaviti v sistem in mu to ne uspe. V tistem trenutku v večini primerov nima informacije, zakaj prijava ni mogoča, kot tudi ne, kdaj bo komunikacija spet vzpostavljena. V tem primeru gre za t. i. izredne izpade, na katere nimamo neposrednega vpliva. Slaba volja uporabnikov nastaja tudi takrat, ko pride do planiranih izpadov, ki so vezani na redna vzdrževanja sistemov in komunikacij, prenose novih rešitev iz testnega okolja v produkcijo, arhiviranje, prehode ob novem letu itn. Uporabniki so sicer v takšnih primerih opozorjeni nekaj dni vnaprej, da sistem določen čas ne bo deloval, kljub temu pa marsikdo to spozna šele ob prijavi, ko ima tudi dejansko namen plačevati t. i. položnice. V večini primerov sicer ne prihaja do problemov z zamudnimi obrestmi v primeru zamude plačila dan ali dva, saj večina velikih podjetij (podjetja za telekomunikacijske storitve, elektro distributerji, komunalna podjetja ...) ne zaračunavajo zamudnih obresti. Seveda pa je zmotno prepričanje, da pa je to mogoče izvesti v asinhroni obdelavi. V tem primeru imamo res možnost pripraviti plačilne zahtevke, jih podpisati in zaključiti z delom, vendar tudi v tem primeru do obdelave pride šele, ko je sistem na drugi strani ponovno pripravljen na izvajanje obdelav. Razlika je le v tem, da se uporabnik tokrat ne obremenjuje, kdaj bo ta čas, pri sinhroni obdelavi, pa ne more narediti ničesar, dokler se sistem dejansko ne vzpostavi. Poudariti pa moramo, da se planirane prekinitve izvajajo večinoma v času, ko je obremenitev najmanjša in v dnevih, ko plačilni sistemi in druge inštitucije ne opravljajo svojih storitev (sobota popoldan, nedelja in prazniki). V kolikor uporabnik pravočasno prebere sporočilo o planirani prekinitvi, si lahko kakšen dan prej vse



plačilne zahtevke pripravi in jih posreduje v čakalno vrsto, kar pomeni, da je datum valute plačila tisti delovni dan, ko bo sistem ponovno deloval.

4.3.2. Slabosti asinhrone obdelave Slabost asinhrone obdelave je naša informiranost o tem, ali je bil plačilni zahtevek uspešno obdelan ali ne. Zavedati se moramo, da so pri obdelavah plačilnih zahtevkov prisotna določena pravila poslovanja. Kot primer lahko navedemo plačilo, ki se mora uspešno zaključiti v tekočem dnevu. V kolikor se to plačilo izvaja med različnima bankama, se mora upoštevati ura delovanja t. i. plačilnih sistemov, ki se na delovni dan zaključijo ob 16.30. V kolikor banka, ki bo plačilo izvedla (prenos sredstev iz izvornega računa našega uporabnika do ciljnega računa prejemnika, ki ima račun na drugi banki), ne uspe pravočasno "poslati" plačilno inštrukcijo v plačilni sistem, bo ta zahteva banke zavrnjena in bo uporabnik o tem obveščen šele po določenem času. Večina uporabnikov, ki uporabljajo aplikativne rešitve, ki delujejo na asinhroni način, pregleda uspešnost obdelave poslanih zahtevkov šele naslednji dan, saj ne čakajo pred računalnikom toliko časa, da bi se vsi procesi te obdelave izvedli do konca. Tako lahko pride do slabe volje, še posebej, če je kakšen zahtevek zavrnjen v petek in uporabnik nima več možnosti vsebinskega popravka zavrnjenega zahtevka do ponedeljka, saj plačilni sistemi čez vikend ne delujejo. V kolikor, hipotetično, v soboto odide na dopust za teden dni, ugotovi veliko prepozno, da plačilo ni bilo izvedeno in da bo morebiti zaradi tega moral plačati zamudne obresti. Naslednja slabost je tekoče stanje na računu. Pri pravnih osebah je to veliko manjša ovira, saj se stanje tekoče spremlja in se točno ve, kdaj in koliko je podjetje potrošilo. Pri fizičnih osebah je slika nekoliko drugačna. Prav v segmentu priprave in pošiljanja plačilnih zahtevkov je velika razlika med fizičnimi in pravnimi osebami. Medtem ko je razumljivo, da se velika večina plačilnih zahtevkov za pravne osebe pripravlja in pošilja v dopoldanskem času, pa specifičnih ur za fizične osebe ni. Obstajajo dokaj razporejeni časovni intervali, v katerih fizične osebe izvajajo te storitve. Veliko več je uporabe ob večernih in celo nočnih urah kot v dopoldanskem času, kar je normalno, saj je večina ljudi takrat v službah. Tako večina uporabnikov zaradi časovnega zamika rezultate uspešnosti obdelave preveri šele naslednji dan in to je lahko v določenih primerih velik problem. Poudariti je treba, da pri asinhronem poslovanju tudi podatek o stanju pridobimo v časovnih presekih, ko pride do sinhronizacije prometa in trenutnega evidenčnega stanja med aplikativnim strežnikom in sistemom banke, kjer se analitično poslovanje nahaja. Predvidevajmo torej, da je pred pošiljanjem plačilnega zahtevka na mojem računu 100 enot. Na tem računu pa imam pooblaščenca, ki je v tem trenutku pred



bankomatom, saj nujno potrebuje 40 enot. V času moje priprave plačilnega zahtevka imam še vedno informacijo o stanju 100 enot, znesek na plačilnem zahtevku pa je 80 enot. Zahtevek pripravim in podpišem. Zahtevek se odloži na aplikacijskem strežniku in čaka, da ga bo v dogovorjenem časovnem terminu prevzel in obdelal sistem moje banke. V tem času je moj pooblaščenec na bankomatu (sinhrona obdelava) dvignil 40 enot in posledično takoj znižal evidenčno stanje na mojem računu na 60 enot. Sam ugasnem računalnik in prekinem z delom, saj sem prepričan, da bo moj plačilni zahtevek uspešno obdelan, ker imam dovolj stanja na računu. V dogovorjenem terminu sistem banke prevzame plačilni zahtevek in prične z obdelavo. V prvem koraku preveri, ali je na mojem računu dovolj stanja za uspešno obdelavo zahtevka. Ker je na zahtevku znesek 80 enot, moje stanje pa prikazuje še 60 enot razpoložljivega stanja, se zahtevek seveda zavrne. Sistem banke odgovor o neuspešni obdelavi zapiše v datoteko in jo odloži na dogovorjeno področje, kjer ga bo, spet v dogovorjenem časovnem intervalu, pobral in obdelal aplikacijski strežnik. Naslednji dan preverim status poslanega plačilnega zahtevka in ugotovim vzrok zavrnitve. Seveda lahko postopek ponovim, če bom medtem zagotovil dovolj enot na svojem računu, v kolikor pa teh enot nimam, pa lahko nastane velik problem. In kaj, če gre v tem primeru za zadnji dan plačila dohodnine, preživnine ali računa za nekaj, kar nujno potrebujem?



5. ZAKLJUČEK Cilj opravljene analize je bila pot do lažje odločitve, kateri način obdelave naj izbere naročnik zunanje aplikativne rešitve. Ugotovili smo, da odločitev vendarle ni tako enostavna, saj en in drugi način pogojujeta tudi sinergijo med različnimi sistemi. V kolikor ima podjetje samo en sistem in v sklopu le-tega izključno lastne aplikativne rešitve, je razumljivo, da bodo obdelave plačilnih zahtevkov potekale sinhrono. V naši banki imamo obe rešitvi, prav tako pa smo uspeli implementirati aplikativno rešitev zunanjega izvajalca, kjer naš sistem spreminja statuse plačilnih zahtevkov v naši in njihovi bazi podatkov. Za takšno delovanje pa je pogoj, da so vse tabele na isti bazi, medtem ko so na različnih instancah. Seveda pa je to neke vrste unikat, saj zunanja podjetja večinoma ne dopuščajo te možnosti posega v njihov podatkovni model, saj želijo ohraniti neodvisnost od drugega sistema. V Sloveniji je bolj razširjena asinhrona komunikacija med vhodnimi kanali in sistemi bank, saj je ponudnikov in kakovostnih rešitev malo in tako imajo ta podjetja možnost postavljati pogoje pri implementaciji, kar posledično pomeni, da se naročnik ne more vedno odločiti za aplikativno rešitev po svojih in uporabnikovih željah, prav tako pa zelo težko vpliva na končno ceno produkta. Če lahko govorimo, da je ponudnikov malo, pa je bank, za velikost trga v Sloveniji, relativno veliko in tako so skoraj prisiljene, da uporabnikom ponudijo vse tisto, kar jim nudi tudi konkurenca. To velja predvsem za pravne osebe, ki prehod od ene banke k drugi pogojujejo tudi z načinom elektronskega poslovanja, ki so ga bila vajena že v preteklosti. Tako pridemo do začaranega kroga, znotraj katerega največji kos pogače pristane v rokah podjetij, ki takšne aplikativne rešitve razvijajo. Fizične osebe kot uporabniki elektronskega poslovanja nimajo odločujočega vpliva na odločitev banke pri nakupu aplikacije. Tem je veliko pomembneje, kakšni pogoji poslovanja jim bodo ponujeni na osebnem nivoju, kakšne obresti lahko pričakujejo pri kreditih ali depozitih, kolikšna je višina provizije pri plačevanju plačilnih nalogov, v kakšni višini lahko imajo odobren limit na osebnem računu itn. Sama aplikativna rešitev elektronskega poslovanja jim predstavlja le pripomoček, da lahko iz domačega naslonjača izvajajo storitve, za katere bi drugače morali v vrsto pred bančno okence. Opravljena analiza torej ne izpolnjuje prvotno zastavljenega cilja, tj. pomagati naročniku pri odločitvi nakupa aplikativne rešitve, v celoti, kljub temu pa razkriva marsikatero skrivnost, ki ostane uporabnikom in naročnikom nerazjasnjena, ker ne poznajo celotnega procesa enega in drugega načina obdelave. Plačilni zahtevki bodo vedno prisotni v našem vsakdanjiku, pa naj bodo v papirnati ali v elektronski obliki. Pomembno narašča le število tistih, ki si svojega poslovanja ne morejo več predstavljati brez elektronske oblike, saj generacije, ki prihajajo, papirja skoraj ne



poznajo več. In prav zaradi tega je pomembno vedeti, kaj pomeni sinhrona in kaj asinhrona obdelava, in verjamemo, da je pričujoča analiza uspela to razliko prikazati v celoti.



LITERATURA IN VIRI • ŠKERLEP Andrej, Model računalniško posredovane komunikacije:

tehnološka matrica in praktična raba v družbenem kontekstu http://uploadi.www.ris.org/editor/1223536219pojmovanje.pdf, 11.11.2010

• ARH Tanja, RAJKOVIČ Vladislav, JERMAN BLAŽIČ Borka, Tehnološko podprto izobraževanje – uporabnost in primernost sistemov za upravljanje e-izobraževanja,

http://www.e5.ijs.si/attachments/145/tanja_arh.pdf, 14.11.2010

• Definethat, Technical Definitions: What is Asynchronous/Synchronous Communication? Asynchronous/Synchronous Communication Definition, http://www.definethat.com/define/270.htm, 10.11.2010

• Business Dictionary, Synchronous transmission – definition, http://www.businessdictionary.com/definition/synchronous-

transmission.html, 10.11.2010

• RAJKOVIČ Uroš, ŠUŠTERŠIČ Olga, RAJKOVIČ Vladislav. Upravljanje procesov bolnišnične zdravstvene nege z e-dokumentacijo. Vizita, okt. 2008

• KRIŽEVNIK Marcel, VIRAG Jernej, ZORKO Jernej, JURIČ Matjaž B., Pregled ključnih tehnologij Java Enterprise Edition, Ljubljana, april 2011

• ZBS, združenje bank Slovenije, NAVODILO o obliki,vsebini in uporabi UNIVERZALNEGA PLAČILNEGA NALOGA, Navodilo za predajanje in prejemanje podatkov o plačilnih zahtevkih, dopolnjeno zaradi zahtev uvedbe UPN, marec 2010

KAZALO SLIK Slika 1: Sinhrona obdelava ....................................................................................... 5

Slika 2: Asinhrona obdelava ..................................................................................... 6

Slika 3: Posredovanje zahteve med vhodnim kanalom in banko............................... 8

Slika 4: Primarni in rezervni sistem Banke .............................................................. 14

Slika 5: En prejemnik (povezava od točke do točke) - asinhron proces .................. 18

Slika 6: Več prejemnikov ........................................................................................ 18



KRATICE IN AKRONIMI PS: Pošta Slovenije PZ: Plačilni zahtevek EB: Elektronsko bančništvo LUW: Logična enota dela (logical unit of work) UPO: Univerzalno poštno okence Pošte Slovenije CICS: Informacijski sistem za nadzor (Customer information control system) DB2: Relacijska baza COMMIT: Dokončna potrditev uspešnosti zapisa ali popravka v bazi DB2 ROLLBACK: Povrnitev prejšnjega stanja

primerjalna analiza sinhrone in asinhrone obdelave …

Documents