Információrendszer-architektúrák 6.

Az előadások a következő témára: "Információrendszer-architektúrák 6."— Előadás másolata:

1 Információrendszer-architektúrák 6.
Tranzakció – kezelés Tranzakció-fogalom, példák ACID ismérvek teljesítése Batch és online tranzakciókezelés Distributed TPS, ACP protokoll Esetek

2 EZ ITT A PROBLÉMA…..

3 A tranzakció fogalma Az üzleti tranzakció egy olyan esemény, amely teljesíti az ún. ACID ismérveket: az input adatok kezelése az adatbázistól (információs rendszertől) elkülönülten, nagy biztonsággal történik, a sikeres tranzakció eredménye viszont azonnal megjelenik minden szükséges feldolgozási ponton (így az input forrásnál is: feedback). Tranzakció-kezelő Rendszer (TPS) az olyan információs rendszer, amely összegyűjti, tárolja, módosítja és visszakeresi egy üzleti rendszer tranzakciós folyamatainak adatait.

4 Példák tranzakciókra Adatbázis-tétel módosítása, lekérdezés
Lakás megvétele, szerződés aláírása Vásárlás készpénzért boltban („egylábú”) Részvény jegyzése a tőzsdén Áru beérkezése bizonylattal raktárba („többlábú”: például több tétel is jöhet egyidőben azonos szállítótól) Pénz-átutalás kezdeményezése Tágabban: beérkező levél, fax iktatása-továbbítása!

5 „Késleltetett” tranzakciók
Tranzakciók (sorozatát) a felhasználó kezdeményezheti, míg a végrehajtó rendszer ezeket egy későbbi időpontban sorozatban hajtja végre Példa: banki átutalás végrehajtása éjjel, teljesítése reggeli üzemkezdetkor Példa: Több módosítás elvégzése egy adatbázisban úgy, mintha egyetlen művelet lenne. Az elvégzett módosítások nem kerülnek azonnal végrehajtásra, csak akkor, amikor erről külön rendelkezünk. Emiatt megoldható a tranzakció ún. visszagörgetése, amellyel eldobjuk a módosításokat, és a tranzakció előtti állapotot állítjuk vissza. Az ilyen tranzakciók használata nagyobb biztonságot ad, sőt, több felhasználós architektúráknál elengedhetetlen.

6 Üzleti tranzakciók A gazdasági folyamatok sikere nagymértékben az időszerűségen és a megbízhatóságon egyszerre múlik: a gyorsaság nem jelenthet alacsonyabb hibatűrést. Példa: Érdeklődésre ajánlat, megrendelésre visszaigazolás, versenytárgyalásra reagálás, pénz-átutalásra visszaigazolás, szupermarket pénztári vonalkód, RFID leolvasás raktárban, ERP esemény könyvelése, folyamatirányítás, termelés-irányítás, public információs tájékoztató rendszer lekérdezése, helyfoglalás, web-aukció, stb. Az ún. „üzleti tranzakció-feldolgozás” témájában nemzetközi szervezetek dolgoznak: Association for Work Process Improvement Transaction Processing Performance Council. Perc? Sec? Millisec? Óra? Egy nap????? Keressünk további példákat!

7 Az üzleti igény és az architektúrák
A LAN/WAN hálózati rendszerek teljesen átalakítják a vevő-kiszolgálási folyamatokat: Értékesítés, pénzügyek, tájékoztatás, megrendelés-felvétel, jegyeladás, közigazgatás, hatóságok, stb. Ehhez a feldolgozó szervezet front-office részlegének közvetlenül hozzá kell férnie a váratlanul felbukkanó (bejelentkező: call center, Web portál) ügyfél adataihoz (lényegében real-time) Példa: bankok és pénzügyi intézmények – ez már nem luxus, hanem alapfeltétellé vált! Előnye: ha már úgyis „helyben kell elintézni”, akkor intézzük el teljesen, adjunk másra ajánlatot, vigyük teljesen végig a folyamatot – ez javítja a készpénz-áramlást. Példa: biztosítás helybeni megkötése és az első részlet befizettetése Integrált architektúra: a látszatra elkülönült rendszerek azonos adatbázison dolgoznak – ATM készpénz-felvétel, fiókok ügyfélforgalma, levélben érkező tranzakciók back-office feldolgozása, iratok szkennelése és kézi feldolgozása, s mindennek irattározása - egyetlen rendszerben!.

8 Tranzakciós alap-architektúrák
Desktop PC, egyfelhasználós Az OS tranzakciói Alkalmazási szoftverek tranzakciói Nagygépes terminál OS elérése LAN operációs rendszer ügyfél-kiszolgálás („distributed data capture”) Alkalmazási szoftver adatbázis-kezelése (ERP) Web-szerver hívás-fogadása

9 Az Idaho Tax Office esete: „24 óra”
The Idaho State Tax Commission serves approximately 1.5 million individuals and 68,000 non-farm businesses within a 2000 square mile territory. With barely sixteen individuals per square mile and only six large communities, including Boise, the state capital, the Tax Commission collects taxes and fees electronically, through mail-in or drop-in payments at district offices. Taxes include, but are not limited to, income, sales, mine, beer,wine, tobacco, and fuel. In 2001, the Idaho State Tax Commission upgraded its automated mail-in tax processing system and began offering electronic filing of payments. Though initially a huge improvement over manual processing, the technology had progressed, and so had the state’s requirements.

10 It became obvious that the system needed additional automation
It became obvious that the system needed additional automation. The Tax Commission was plagued with dropin payments to district offices. Although small in number, these payments were not automated. Additionally, the remote nature of the district offices made timely transport of the items to the central processing location in Boise very difficult. Making matters worse, state law requires that payments be processed within 24 hours of receipt. In order to make the processing deadline, each district office would post payments manually and then deposit the checks locally. This caused an even larger issue for the state. Because the items were not imaged, they were not archived in GenTax, the system-of-record. Missing images of the actual payment document (check, money order, etc.) caused problems downstream for customer service and research departments. The Tax Commission needed a system that could meet the state’s requirement that all dollars and item counts of daily payments be reconciled to the state’s GenTax system of record. At present, mail-in payments which are centrally processed provided this capability, thus completing the audit trail but the state wanted the district office drop-in payments to be reconciled in the same way.

11 From a technical standpoint, the state needed a low-cost method to capture and process documents at the earliest point of entry into the transaction cycle. The state also needed the new system to seamlessly integrate with its existing central remittance processing system, TMS Image™. “All this and the goal was not to create an operational and processing burden on the district office personnel who have historically known very little of check or image processing,” said Gordon Alleman, tax automated systems manager. In order to expand its tax processing capabilities, improve customer service and meet state deadlines, the Idaho State Tax Commission, opted to install a remote image capture solution from J&B Software. “We had been using TMS Image as our central remittance processing system for four years. We had considered other solutions but by integrating J&B’s Networked Deposit Machine (NDM) we were provided with a low-cost method to capture and process documents at the earliest point of entry into the transaction cycle,”said Gordon. J&B’s NDM is an open architecture remote capture solution based on industry-standard server, network and operating system components. NDM’s small footprint, intuitive interface, easy deployment and “scan and send” features meant the organization could roll out this product to several branches with minimal training and impact on branch operations. With seamless interfaces to item processing systems from J&B and others,NDM also supplies management reports to optimize cash management and real-time information feeds to legacy accounting systems. Once captured, checks can be deposited electronically for same-day clearing through an ACH network (Back Office Conversion) or Check 21 Image Exchange directly with banks.With NDM,manual check handling is reduced and cash management is improved.

12 The NDM provides the following features and capabilities:
• Touch-screen PC and scanner have a very small footprint – perfect for back counter operations • Data and image capture using desktop check scanner with MICR and OCR recognition • Transmission status monitoring • Reporting – end of day reports listing captured documents • Minimal intervention by district office personnel • Front-ends existing remittance processing solution (TMS) – CAR/LAR, keying and balancing. Extract and image hand-off to GenTax • Easy to install • Positions district offices to move to Check 21 Image Exchange Image quality and usability assurance Sophisticated MICR parsing “I was really impressed with the smooth integration.We installed and trained each of the Field Offices and had each one of them in production spending only one day at each site,”said Justine Weaver, remittance processing supervisor.“ Our district office personnel weren’t afraid to work with the systems either. The NDM is more efficient, more user friendly, and more dependable.”

13 Benefits of a new remote-capture transaction-processing system
The decision to implement NDM has delivered tremendous benefits to the Idaho State Tax Commission. Most important was the significant reduction in costs related to manual processing at the district offices. These savings are being realized in the reduced time to prepare daily deposit reports.“Each of the district offices are realizing savings anywhere from one half hour to two hours of daily processing time,”said Renee Marsh, project coordinator. Customer service capabilities are dramatically improved. Customer representatives can now find district office information almost instantaneously through the GenTax system. Brokerage, banking, check cashing, retail organizations and select state governments with multiple branch locations typically process checks manually at each branch. Every step in this manually-intensive process adds time and is an additional chance for error. Clearing can take three to five days by the time the paper checks are shipped to the central processing office and then deposited to the bank. Moreover, training newly hired branch associates associates to learn the manual check process, adds cost and reduces productivity. All this changed since the passing of Check 21. Prices of capture hardware and software as well as bandwidth have plummeted as more and more customers look to automate their processing. There are many low cost capture devices on the market today which can be integrated with thin client remote capture solutions. Today, remote capture solutions have sophisticated workflow engines and employ complex image recognition technology, which extend beyond the capturing and processing of remote deposits

14 TPS architektúra-jellemzők 1.
Rapid feldolgozás A gyorsaság az üzletben elsőrendű követelménnyé vált. Minél fejlettebb az ICT technológia, annál többre tart igényt az ügyfél (ti. összehasonlítást tesz - versenyelőnyt biztosít a gyorsaság!) A TPS rendszereket úgy kell megtervezni, hogy a változó ügyfél-igényre a tranzakciókat virtuálisan „azonos időben” hajtsák végre: jelenjen meg a beavatkozáshoz-reagáláshoz szükséges adat az elvárt időben, s maga a feldolgozás is menjen végbe elviselhető (ügyfél-)időben. Speciális példa: web-lapok letöltése, átlinkelési ideje

15 TPS architektúra-jellemzők 2.
Megbízhatóság Az ügyfél nem viseli el a (gépi) rendszer hibáit. A TPS rendszert úgy kell tervezni, hogy egy hibás tranzakció semmiképpen sem „csusszanhat vissza” a hálózatra, s így maga a háttér-rendszer mindig működőképes, elérhető „operational” állapotban marad. A TPS rendszerben tehát beépített biztonsági felületeknek kell működniük, s hiba esetén hatékony recovery helyreállító eljárásoknak kell működésbe lépniük: ebből a felhasználó nem vehet észre (majdnem) semmit. Mérőszámok: tolerancia-szintek, hiba-ráták, rendelkezésre állási idő százalékban (pl ) Alaptechnika: authorizáció (belépési jogosultságok ellenőrzése, lejárati idők, hierarchia, stb.)

16

17 TPS architektúra-jellemzők 3.-4.
Standardizálás A tranzakcióknak pontosan azonos módon kell lefutniuk minden standard bemenet esetén. Olyan tömegű tranzakciót kell kezelni, hogy nem engedhetők meg kivételes eljárások, extrém megoldások (ha egy adat hiányzik, akkor hiányzik és nem indulunk!). Ezért a tranzakciós felület-tervezés hihetetlen precizitással kell informálja a (laikus) ügyfelet, vagy a (alacsony képzettségű) alkalmazottat: nincs kivétel, minden eset egyforma és biztonságos. Ellenőrzött hozzáférés Mivel a TPS rendszerek rendkívül erőteljes üzleti eszközöknek bizonyulnak, alaposan ki kell építeni a hozzáférési jogosultságok ellenőrzésének rendszerét. A korlátozott hozzáférésű eljárások (Restricted Access Processes) biztosítják, hogy csak feljogosított, kiképzett, ellenőrzött (naplózott) hozzáférések legyenek lehetségesek – a feljogosított felhasználó sem fejezhet be hibásan egy tranzakciót (lásd előző jellemző!)

18 TPS architektúra-követelmények AC/ID
Atomicitás: csak sikeres művelet zárható le. Vagy végigment az input procedúra, vagy nem. Példa: Ha elindul egy pénz-átutalás, csak akkor válik érvényessé, ha a levonás (egyik számla) és a bevételezés (másik számla) mindkét folyamata ellenőrzött és engedélyezett. Ha bármelyikkel probléma van (pl. mínuszba fordul, vagy zárolt, stb.), a tranzakció nem megy végbe. „A tranzakció egy atom: nem darabolható. Mindent vagy semmit” – Commit/Abort) Konzisztencia: abortált tranzakció által érintett objektum (fájl, rekord) sértetlen marad. A TPS rendszer egy halom műveleti szabály együttese: ezek biztosítják a rendszer integritását. Ha egy szabály például előírja, hogy minden tranzakció pozitív értékkel fogadható csak be, akkor minden negatív rétékű kezdeményezést vissza kell utasítani. EZ biztosítja, hogy a rendszer „egy hangon énekel”.

19 TPS architektúra-követelmények AC/ID
Izoláció: a tranzakciók egymástól teljesen elszigetelve futnak. Pénz-átutalás esetén a küldő számla egyenlegének ellenőrzése és a a fogadó számla elérhetőségének ellenőrzése két tranzakció. Az eredmények összevetése és a kezdeményezés visszaigazolása egy újabb tranzakció. Tartósság: sikeres tranzakció eredményét csak másik sikeres tranzakció módosíthatja, rendszerhiba nem. Ha lefut egy tranzakció, az eredmény nem módosítható, a folyamat nem tehető semmisssé. Minden tranzakció naplózásra kerül (log). Ha az adott tranzakció felesleges, hibás input kezdeményezés volt, akkor egy újabb tranzakció az eredményt módosíthatja, de nem teheti „meg-nem-türténtté” az előzőt. EZEK Az ACID-ismérvek BIZTOSÍTJÁK AZT, HOGY A TPS RENDSZER MÓDSZERTANILAG SZABVÁNYOS, MEGBÍZHATÓ MÓDON ÉPÜLJÖN FEL. TR-eljárás tehát: hozzáférés, ellenőrzés, dialógus,feldolgozás,visszaigazolás

20 A TPS két alapesete „Kötegelt”, késleltetett TPS Erőforrás-kímélő megoldásként az üzleti tranzakciókat folyamatosan lehet „regisztrálni” (input, ellenőrzés, input feedback, tárolás, naplózás), vagy az input folyamatot egy adott (rövid) idő-periódusra lehet szorítani. Ha az architektúra képtelen lenne a hatalmas tranzakció-számot kezelni, akkor ez egy kisebb igényű, de olcsóbb (adott esetben nélkülözhetetlen – pl. APEH) megoldás. PÉLDÁK: hitelkártya-átutalások havi összegzése, stb.

21 A TPS két alapesete Valósidejű feldolgozás (Real Time Processing)
Sok üzleti folyamatban „azonnali” válaszokra van szükség. Ez lehet egy óra, egy perc, egy másodperc, vagy még rövidebb (műszaki) időtartam. Példa: - bankfiókban az ügyfél érdeklődik, kezdeményez, dialógust folytat - HelpDesk, Suppor Center, Call Center telefon, - vállalkozás hitelképességét ellenőrzik - rendőrség körözött autót lát - ?????????

22 A TPS workflow 1. A WF egy lépésének elemei:
Az előzőek miatt a TP mindig egy feszes munkafolyamat (workflow): Az üzleti tranzakció minden fázisa a WF egy adott lépése A WF egy lépésének elemei: Work Planning – A lépés terve: Előző munkafolyamatok tapasztalata alapján kialakított eljárás, a következő lépések figyelembevétele. Work Receiving and Arrival Reporting – Munka-fogadás –s Beérkezési dokumentáció: az újonnan érkezett „munka” kontrollja és könyvelése, naplózása. Figylem: eközben a „provesszor” (legyen ez bármi) általában még nem dolgozik! Work Monitoring – A munkák felügyelete, ellenőrzése: Az összes feldolgozásra váró munka áttekintése, sorbarendezése, erőforrás-tervezése, ütemezése. Work Processing and Recording – Feldolgozás és Regisztrálás: A munka(lépés) elvégzése, az eredmények rögzítése (valamilyen dokumentum létrehozása).

23 A TPS workflow 2. Work Routing – Munka továbbítása: HA a munkaállapota eléri az előírtat, továbbítjuk a következő feldolgozási állomásra. Work Evaluation – Értékelés: Periodikus időközökben a munka(fázist) ellenőrizni kell. Ez teszi lehetővé az 1. lépés (tervezés) hitelesítését. Ha a folyamatok gyorsak, ezt szoftverekkel kell végezni. Maga a TP teljes folyamata is egy workflow. A lépések kölcsönösen függenek (dependence), a felhasználói tapasztalatok alapján maga az egész folyamat módosítható.

24 A TPS következményei Az adatbázis-manager szoftvernek disztributív, elosztott módon kell tranzakciós kérésekre reagálnia A DBMS adott feltételekkel mondhat vétó-t egy tranzakciós kérésre (abort) A DBMS egy Atomic Commitment Protocol-t (ACP) futtat annak eldöntésére, hogy egy tranzakció sub-tranzakciói mind helyesen lefutottak-e Az ACP egy következménye: ha egy fázis adott időn belül nem ad választ, a DBMS „Abort”-nak minősíti Az ACP utasíthatja a DBMS-t, hogy várjon, amíg a lépés hibáját (pl. ismétléssel) kijavítja