EFER, INTERFACE TERV ÉS MINTAPROGRAM INTÉZMÉNYEK RÉSZÉRE V 2.2.5 2014. február 13.
Dokumentum adatlap Projekt/modul megnevezése: Elektronikus fizetési és elszámolási rendszer Projekt/modul fantázia neve: EFER Projekt/modul azonosító: 177 01 Dokumentáció típusa: Interface terv és mintaprogram Verziószám: 2.2.4 Oldalszám címlappal, dokumentum adatlappal: 8080 Állapot: Jóváhagyott Kiadás kelte: 2009.11.18. Utolsó mentés kelte: 2014.02.13. Készítette: IND Fájlnév: EFER_IFint_v2.2.5_20140213.doc Kapják: KIFÜ, Getronics Dokumentáció tárgya: Interface terv és mintaprogram leírás az elektronikus fizetési és elszámolási rendszerhez Intézmények részére Ellenőrzések Név Dátum Aláírás Jóváhagyás Név Dátum Aláírás Módosítások Verzió Dátum Módosítás rövid leírása v0.3 2009.10.16. Első átadott verzió V1.4. 2009.10.30. Bekerültek a hiányolt hibakezelési lépések Új hibakód lista Eltérésjelentés fejezet (félkész állapotban, mivel még nincs lezárva a kérdés) V1.5 2009.11.07 Zalaszámmal egyeztetett módosítások V1.5.1 2009.11.16 Módosítások a PMISZK-val tartott egyeztetés (11.12) alapján V1.6.0 2009.12.16. ÁLRT miatt és Zalaszámmal egyeztetett módosítások V1.6.1 2010.01.06. Minor módosítások. V1.6.2 2010.02.22 RLRT döntési javaslat alapján módosított verzió V1.6.3 2010.04.08 ÁLRT változások követése V1.6.4 2010.07.02. Tesztelés utáni finomítások 2/80
2010.07.07 Intézményi konzultáció utáni finomítások, pontosítások V.1.7.0 2010.09.13. JMS és WS-RM miatti módosítások V.1.8.0 2010.10.20. 97-es hibakód kifejtése V.1.9.0 2010.11.10. Pontosítások V.1.9.1 2011.02.08. WS-Policy egységesítés V.1.9. 2 2011.03.03 Szolgáltatásdefiníció frissítése V.2.1.0 2011.03.15 szolgáltatásdefinicó frissítése V.2.2.0 2011.03.21 Hibakódok pontosítása, WSDL-ek és XSD-k aktualizálása V.2.2.1 2011.04.06 Igazgatási ügyazonosító KFM ellenőrzése törölve V.2.2.2 2011.04.11 JMS információk V.2.2.3 2011.05.23. Üzenet méret korlátok V.2.2.4 2013.01.28 VPOS pontosítás, kiegészítés V.2.2.5 2014.02.13 KTK kód adattípus változott A3 ról A8-ra 3/80
TARTALOMJEGYZÉK 1 Vezetői összefoglaló... 6 2 Bevezetés... 7 2.1 Fogalmak... 7 2.2 Rövidítések... 8 2.3 EFER áttekintés... 9 2.3.1 Az EFER feladata... 9 2.3.1.1 Fizetési folyamatok... 11 2.3.2 Az EFER szolgáltatás orientált működése... 14 2.3.3 EFER és környezete... 15 2.3.3.1 Az IT környezet... 15 2.3.3.2 Kommunikáció leírása... 17 2.3.3.3 Hibakezelés... 18 2.3.3.4 Megbízható üzenetváltás... 19 3 EFER ÉS AZ intézmények KÖZÖTTI KAPCSOLAT... 25 3.1 Fizetési kérelem átadása EFER-nek... 25 3.1.1 Folyamat leírása... 25 3.1.2 Adatkör leírás (IPP_EFER_FIZKER)... 26 3.1.3 Adatkör leírás (IPP_EFER_FIZKERVALASZ)... 28 3.2 Fizetési kérelem válasz nyugtázása az EFER felé... 28 3.2.1 Folyamat leírása... 2928 3.2.2 Adatkör leírás (IPP_EFER_FIZKERNYUGTA)... 29 3.2.3 Adatkör leírás (IPP_EFER_FIZKERNYUGTAVALASZ)... 29 3.3 Fizetési igérvény átadása intézménynek... 3029 3.3.1 Folyamat leírása... 30 3.3.2 Adatkör leírás (EFER_FIZIGERVENY)... 31 3.3.3 Adatkör leírás (EFER_FIZIGERVENYVALASZ)... 32 3.4 Elutasított fizetés átadása az intézménynek... 32 3.4.1 Folyamat leírása... 32 3.4.2 Adatkör leírás (EFER_ELUTASITOTTFIZIGERVENY)... 33 3.4.3 Adatkör leírás (EFER_ELUTASITOTTFIZIGERVENYVALASZ)... 34 3.5 Fizetési ígérvény átadása az EFER részére... 34 3.5.1 Folyamat leírása... 34 3.5.2 35 3.5.3 Adatkör leírás (IPP_FIZIGERVENY)... 35 3.5.4 Adatkör leírás (IPP_FIZIGERVENYVALASZ)... 37 3.6 Utalási adatok átadása az intézménynek... 37 4/80
3.6.1 Folyamat leírása... 38 3.6.2 Adatkör leírás (EFER_IPR_UTALAS)... 38 3.6.3 Adatkör leírás (EFER_IPR_UTALASVALASZ)... 39 3.7 Utalási megbízás analitika átadása az intézményeknek... 40 3.7.1 Folyamat leírása... 40 3.7.2 Adatkör leírás (EFER_IPR_UTALANALITIKA)... 40 3.7.3 Adatkör leírás (EFER_IPR_UTALANALITIKAVALASZ)... 41 3.8 Tranzakciós díjak adatainak átadása az intézményeknek... 42 3.8.1 Folyamat leírása... 42 3.8.2 Adatkör leírás (EFER_INT_DIJANALITIKA)... 43 3.8.3 Adatkör leírás (EFER_INT_DIJANALITIKAVALASZ)... 43 3.9 FMSZ-ek és azok fizetési megoldásainak lekérdezése EFER-től (IPP_FMSZLISTAKER)... 44 3.9.1 Folyamat leírása... 44 3.9.2 Adatkör leírás (IPP_FMSZLISTAKER)... 44 3.9.3 Adatkör leírás (IPP_FMSZLISTA)... 45 3.10 Fizetés hiba átadása intézmény számára (EFER_INT_FIZHIBA)... 46 3.10.1 Folyamat leírása... 46 3.10.2 Adatkör leírás (EFER_INT_FIZHIBA)... 47 3.10.3 Adatkör leírás (EFER_INT_FIZHIBAVALASZ)... 48 3.11 Az EFER aktív tesztelése (EFER_AKTIV_TESZT)... 49 3.11.1 Adatkör leírás (EFER_AKTIV_TESZT)... 49 3.11.2 Adatkör leírás (EFER_AKTIV_TESZT_VALASZ)... 49 3.12 Adattípusok... 49 3.13 Hibakódok... 52 3.14 Mintaprogram... 53 4 Mellékletek... 54 4.1 1. melléklet: Szolgáltatás és adat-definíciók... 54 4.1.1 Az EFER által nyújtott szolgáltatások... 54 4.1.1.1 EFERIntezmenyService.wsdl... 54 4.1.1.2 EFERIntezmenyService.xsd... 59 4.1.2 Az intézmény által nyújtott szolgáltatások... 66 4.1.2.1 IntezmenyService.wsdl... 66 4.1.2.2 IntezmenyService.xsd... 71 5/80
1 VEZETŐI ÖSSZEFOGLALÓ A közigazgatás hatékonysága növelésének, az elektronikus közszolgáltatások bővítésének, az elektronikus ügyintézési folyamatok kiteljesítésének egyik fontos, mára kikerülhetetlenné vált eszköze az elektronikus fizetés általánossá tétele a közigazgatásban. A Pénzügyminisztérium Informatikai Szolgáltató Központ (PMISZK) Elektronikus fizetés megvalósítása címmel Elektronikus Közigazgatás Operatív Program projektjavaslatot nyújtott be, melynek eredményeként a Közreműködő Szervezet és a PMISZK által vezetett konzorcium Támogatási Szerződést kötött a projekt megvalósítására. A projekt célja az Elektronikus Fizetési és Elszámolási Rendszer (EFER), valamint az Intézményi Pénztár Program (IPP) létrehozása, amely intézmények számára nyújt szolgáltatást a piacon elérhető korszerű elektronikus fizetési megoldások integrálásával. Jelen dokumentum célja, hogy áttekintő képet nyújtson az EFER rendszerről valamint, hogy bemutassa az intézmény fizetési és elszámolási folyamatban betöltött szerepét, az üzleti folyamatok technikai megvalósítását és a csatlakozáshoz szükséges interface-k leírását. 6/80
2 BEVEZETÉS Jelen dokumentum definiálja az EFER rendszer intézményi kapcsolatának interface terv és mintaprogram leírását. 2.1 FOGALMAK Fogalom Kérésüzenet Szinkron üzenet Üzenetváltás típusa Válaszüzenet Tag (ejtsd: teg) Whitespace karakter Magyarázat A kommunikációt indító üzenet. Nem átviteli protokoll szintű fogalom, hanem üzleti fogalom. Bár a https átviteli protokollt általában szinkronnak, a JMS átviteli protokollt pedig aszinkronnak tekintik, jelen dokumentumban ahol nem emeljük ki külön átviteli protokolltól függetlenül fogalmazunk. Az üzenet küldője akkor tekinti elküldöttnek a kérésüzenetet, ha adott időn belül (t) a fogadó fél válaszüzenetet küld vissza. A küldő fél a válaszüzenet megérkezéséig felfüggeszti a folyamatát, vagyis megvárja a válaszüzenetet. Ha nem jön válaszüzenet adott időn belül, a küldő megismételheti a kérésüzenetet és ismételten várakozhat a válaszüzenetre. A t idő értéke maximum perces nagyságrendű. A t idő értéke kommunikációs esetenként van meghatározva a dokumentumban, és az időtúllépés elnevezéssel hivatkozunk rá. A t tehát az az idő, amennyit a küldő fél maximum vár a szinkron válaszüzenet megérkezéséig. A t technikai (kommunikációs) időtúllépés. Ha válaszüzenet nem érkezik meg t időn belül, a hívónak a kérésüzenet elküldését újra kell próbálnia. Az újrapróbálkozások javasolt maximális száma 2, az egyes újrapróbálkozások megkezdése között pedig javasoltan 2*t időt kell hagyni. A válaszüzenet feldolgozásának módja. A kérésüzenetre adott válasz. Lehet csak nyugtázó jellegű, de tartalmazhat üzletileg értékes adatokat is. Angol elnevezés. XML-ben használatos elem, címke, amely rendelkezik névvel, rendelkezhet konkrét értékkel (az XMLben a tag értéke a <tag-név> és </tag-név> közötti rész), ill. gyermekekkel. Maga az XML hierarchikusan felépített tagekből áll. A gyermek-tag egy adott tag gyermekét jelenti. Az alábbi karakterek valamelyike: szóköz, tabulátor, vertikális tabulátor, új lap karakter, újsor karakter, kocsivissza karakter. 7/80
2.2 RÖVIDÍTÉSEK Fogalom B2B EFER FMSZ JMS SOAP VPOS WSDL WS-AT WS-RM WS-Sec Magyarázat A Business-to-Business a vállalatok, szervezetek között, elektronikus úton megvalósuló gazdasági kapcsolatok öszszességét jelenti. Egységes Fizetési és Elszámolási Rendszer Fizetési Megoldás Szolgáltató A Java Message Service (JMS) API egy üzenetkezelési szabvány, amely elsősorban JEE platformon futó alkalmazások számára teszi lehetővé üzenetek létrehozását, küldését, fogadását és olvasását. Amennyiben SOAP transzfer protokollként használják, önmagában megvalósítja a megbízható üzenetváltást. Az EFER által megkövetelt JMS verzió: 1.1 A Simple Object Access Protocol rövidítése. Egy elsősorban heterogén rendszerek közötti - üzenetküldésre használt, XML-alapú formátum. Az SOAP formátumot használó üzenetek azután különböző protokollok segítségével továbbíthatók. Legelterjedtebb protokoll a http. Az EFER által használt verzió: SOAP 1.1. Virtual Point Of Sale Web Services Description Language Web Services Atomic Transaction Web service szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti tranzakcionális viselkedést képes megvalósítani a kétfázisú commit protokollra támaszkodva. Az EFER által megkövetelt verzió: WS-AT 1.0 (http://specs.xmlsoap.org/ws/2004/10/wsat/wsat.pdf) OASIS Web Services Reliable Messaging Protocol Web service szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti megbízható üzenetváltást tesz lehetővé komponens, alkalmazás vagy hálózati hibák kompenzálása miatt. Az EFER által használt verzió: WS-RM 1.1 (http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1- spec-cd-04.pdf). (Az EFER alatti WS stack WS-RM releváns szabványok verziói: WS-ReliableMessaging v1.1, WS- ReliableMessaging Policy v1.1.) OASIS SOAP Message Security szabvánnyal kapcsolatos protokoll, mely elosztott alkalmazások közötti biztonságos üzenetváltást tesz lehetővé. Az EFER számára a szabvány használata azért szükséges, mert biztosítja az üzenetek sértetlenségét és hitelességét az által, hogy az üzenetek fejléce tartalmaz egy az üzenet törzséből képzett - digitális aláírás, 8/80
mellyel az üzenet ellenőrizhető. Az EFER által használt verzió: WS-Sec 1.1 (http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-specos-soapmessagesecurity.pdf). (Az EFER alatti WS stack WS-Sec releváns szabványok verziói: WS-Security v1.1, WS-SecurityPolicy v1.1, WS-Trust v1.0, WS- SecureConversation v1.0.) XSD XML Schema Definition 2.3 EFER ÁTTEKINTÉS 2.3.1 Az EFER feladata Az EFER rendszer lehetővé teszi, hogy a lehető legszélesebb körben elérhetővé váljanak a teljesen elektronikus közszolgáltatások, aminek magától értetődő része, hogy a szolgáltatások ellenértékének (illetékek, díjak, stb.) kiegyenlítése, továbbá más, állammal szembeni fizetési kötelezettségek megfizetése is történhessen elektronikusan. A központi elektronikus fizetési szolgáltatás az intézményi szakrendszerek számára lehetővé teszi az elektronikus és hagyományos ügyintézéshez illeszkedő elektronikus fizetési megoldások felkínálását az ügyfelek számára, garantálja a befizetett díjösszegek célszámlákra történő eljuttatását. A fizetési kötelezettség-teljesítés megállapításának előfeltétele minden esetben, hogy a befizetés szakrendszerbeni egyedi azonosításra alkalmas ügyszámmal és a fizetéshez kapcsolódóan pénzügyi ügyazonosítóval rendelkezzen. Az EFER-ben megvalósított főbb folyamatok: A fizetési folyamat támogatása Az ügyfél eljárást kezdeményez az intézménynél, vagy bekapcsolódik az intézmény által indított ügyintézési folyamatba. Az ügyintézés során az intézményi szakrendszerben megállapításra kerül a fizetési kötelezettség (fizetendő összeg, jogcím), amelyet az ügyfél tudomására kell hozni. A szakrendszerben ekkor képződik az ügyszám. Az ügyintéző vagy (elektronikus ügyintézés esetén) az ügyfél az IPP-ben vagy ennek hiányában a szakrendszerben összeállítja a fizetési tranzakciót (azaz meghatározza az egyben fizetendő ügyeket, összegeket, jogcímeket), majd ehhez az IPP vagy a szakrendszer (gyűjtő) pénzügyi ügyazonosítót képez. Pénzügyi ügyanozosító felépítése Megnevezés Hossz Maszk intézményi azonosító 8 nnnnnnnn alrendszer azonosító 2 nn dátum 6 ééhhnn sorszám 7 nnnnnnn hossz összesen 23 9/80
Az ügyfél ezt követően meghatározza, hogy milyen módon kíván fizetni: hagyományos ügyintézés esetén ez bankkártyás (POS), mobil- vagy házibanki, készpénzátutalási megbízással vagy készpénzzel történő, illetve vegyes fizetés; elektronikus ügyintézés esetén bankkártyás (VPOS), mobil banki vagy házibanki fizetés lehet. Elektronikus fizetési megoldás választása esetén az ügyfél elindítja a fizetést Bankkártyás fizetés esetén: o Az ügyfél átadja az ügyintézőnek a bankkártyáját o Az ügyintéző a kártya ellenőrzését követően lehúzza a POS terminálon a bankkártyát, ezzel határozva meg a fizetéshez szükséges fizetői adatokat. o Az FMSZ elvégzi az authorizációt, és elindítja az ügyfél számlájának megterhelését célzó folyamatokat. Az authorizációt követően az FMSZ visszajelez az ügyfélnek és az IPP-nek (vagy a szakrendszernek) a tranzakció azonosító átadásával. Ez a visszajelzés az ún. fizetési ígérvény, amely a fizetés visszavonhatatlan megindításának elektronikus igazolása. o A fizetési ígérvény előállításának folyamata a következő: az FMSZ értesíti az ügyfelet, az IPP-t (vagy a szakrendszert) (továbbá a fizetési megoldáson belül az Ügyfél számlavezetőjét), majd az IPP értesíti a szakrendszert. o Házi-, mobilbankos és VPOS fizetés esetén:az IPP (vagy szakrendszer) továbbitja az EFER-nek a fizetési megoldásnak megfelelően kitöltött fizetési kérelmet. Az EFER a fizetési kérelem fizetéshez szükséges adatait továbbítja a megfelelő FMSZ felé. o Az ügyfél bejelentkezik az FMSZ fizetési felületre. o Az ügyfél jóváhagyja a fizetési tételt, az FMSZ elvégzi az authorizációt, és elindítja az ügyfél számlájának megterhelését célzó folyamatokat. Az authorizációt követően az FMSZ visszajelez az ügyfélnek és az EFER-nek a tranzakció azonosító átadásával. Ez a visszajelzés az ún. fizetési ígérvény, amely a fizetés visszavonhatatlan megindításának elektronikus igazolása. o Az EFER az FMSZ-től megkapott visszavonhatatlan fizetési igérvény alapján üzenetben értesíti az IPP-t (vagy a szakrendszert). Az üzenet tartalmazza az FMSZ által kiállított eredeti fizetési igérvényt is. A fizetési ígérvény birtokában az intézmény az ügyintézést folytatja vagy lezárja. Amennyiben a fizetési tranzakció sikertelen, az ügyfél új fizetési megoldást választhat az IPP-ben. Ezt követően az eljárás megegyezik az előzőekben leírtakkal. 10/80
2.3.1.1 Fizetési folyamatok 2.3.1.1.1 A Házibankos fizetési megoldás folyamata sd Fizetési folyamat HB Ügyfél Intézmény EFER FMSZ critical Fizetési kérelem befogadása Fizetés indítása() Fizetési megoldás = HB (HáziBank) IPP_EFER_FIZKER() EFER_FMSZ_AKTIV_TESZT() EFER_FMSZ_AKTIV_TESZT_VALASZ() EFER_FMSZ_FIZKER() EFER_FMSZ_FIZKERVALASZ() IPP_EFER_FIZKERVALASZ() IPP_EFER_FIZNYUG() IPP_EFER_FIZNYUGVALASZ() Ügyfél értesítése (opcionális) alt Sikeres fizetés Ügyfél fizet FMSZ felületén() FMSZ_EFER_FIZIGERVENY() FMSZ_EFER_FIZIGERVENYVALASZ() EFER_IPP_FIZIGERVENY() EFER_IPP_FIZIGERVENYVALASZ() alt Sikertelen fizetés Ügyfél elutasítja a tételt() FMSZ_EFER_ELUTASITOTTFIZIGERVENY() FMSZ_EFER_ELUTASITOTTFIZIGERVENYVALASZ() EFER_IPP_ELUTASITOTTFIZIGERVENY() EFER_IPP_ELUTASITOTTFIZIGERVENYVALASZ() 11/80
2.3.1.1.2 A Mobilbankos fizetési megoldás folyamata sd Fizetési folyamat... Ügyfél Intézmény EFER FMSZ critical Fizetési kérelem befogadása Fizetés indítása() IPP_EFER_FIZKER() EFER_FMSZ_AKTIV_TESZT() Fizetési megoldás = MB (MobilBank) EFER_FMSZ_AKTIV_TESZT_VALASZ() EFER_FMSZ_FIZKER() EFER_FMSZ_FIZKERVALASZ() IPP_EFER_FIZKERVALASZ() IPP_EFER_FIZNYUG() IPP_EFER_FIZNYUGVALASZ() Ügyfél megerõsítés SMS() Ügyfél megerõsítés válasz SMS() alt Sikeres fizetés FMSZ_EFER_FIZIGERVENY() FMSZ_EFER_FIZIGERVENYVALASZ() EFER_IPP_FIZIGERVENY() EFER_IPP_FIZIGERVENYVALASZ() Ügyfél értesítése (opcionális) alt Sikertelen fizetés FMSZ_EFER_ELUTASITOTTFIZIGERVENY() FMSZ_EFER_ELUTASITOTTFIZIGERVENYVALASZ() EFER_IPP_ELUTASITOTTFIZIGERVENY() EFER_IPP_ELUTASITOTTFIZIGERVENYVALASZ() 12/80
2.3.1.1.3 A VPOS fizetési megoldás folyamata sd Fizetési folyamat VPOS Intézményi interfészt használó online felület Ügyfél Intézmény EFER FMSZ critical Fizetési kérelem befogadása Fizetés indítása() IPP_EFER_FIZKER() Fizetési megoldás = VP (VPOS) EFER_FMSZ_AKTIV_TESZT() EFER_FMSZ_AKTIV_TESZT_VALASZ() EFER_FMSZ_FIZKER() EFER_FMSZ_FIZKERVALASZ() IPP_EFER_FIZKERVALASZ() IPP_EFER_FIZNYUG() IPP_EFER_FIZNYUGVALASZ() Átirányítás FMSZ VPOS-ra() alt Sikeres fizetés Ügyfél fizet VPOS-al() FMSZ_EFER_FIZIGERVENY() FMSZ_EFER_FIZIGERVENYVALASZ() EFER_IPP_FIZIGERVENY() EFER_IPP_FIZIGERVENYVALASZ() Ügyfél átirányítása intézményi felületre() alt Sikertelen fizetés Ügyfél fizetés sikertelen() FMSZ_EFER_ELUTASITOTTFIZIGERVENY() FMSZ_EFER_ELUTASITOTTFIZIGERVENYVALASZ() EFER_IPP_ELUTASITOTTFIZIGERVENY() EFER_IPP_ELUTASITOTTFIZIGERVENYVALASZ() Ügyfél átirányítása intézményi felületre() A fizetések elszámolásának folyamata 13/80
Az ügyintézés során elektronikusan megfizetett illetékek, díjak elszámolása az arra jogosultak, vagy kedvezményezettek felé a Magyar Államkincstárban az EFER szolgáltatásainak használatával történik. Az ügyintézés során megfizetett illetékek és díjak elszámolásának lebonyolítása, a kedvezményezettek részére történő felosztása érdekében az alábbi három információforrásból kell adatokat kapnia az EFER-nek: o Előírásokra vonatkozóan: Az intézményektől az ügyintézés során sikeresként jelzett fizetési tranzakciók adatai folyamatosan érkeznek. o Elindított fizetésekre vonatkozóan: A FMSZ naponta átadja az elindított és utalt fizetések teljes összegét, ezek analitikáját. o A Magyar Államkincstárhoz beérkezett összegekre vonatkozóan: A Magyar Államkincstár átadja az átvezetési számlakivonatokat a FMSZ által az intézményi átvezetési számlákra utalt teljes összegről. Ez az utalás bonyolításához szükséges időt figyelembe véve későbbi időpontban történik, mint az előző két forrásból érkező adatátvétel. Az EFER a fenti adatokat összehasonlítja. Az adategyeztetés úgy történik, hogy első körben az előírásokra vonatkozó és a FMSZ-tól érkezett analitikák hasonlíthatók össze. Ezt követően a számlakivonat átvétele után történhet meg a számlakivonaton szereplő összeggel való összehasonlítás. Az összegek és analitikák egyezése esetén elvégzi azok kedvezményezettenkénti (pl. APEH, VPOP, KEKKH, önkormányzatok, stb.) részösszegekre bontását (elszámolás). Eltérés esetén hibalista készül, amely alapján a hibakeresés, hibajavítás megkezdhető és elvégezhető. A hibát annak a szintnek, szervezetnek kell kijavítania, ahol az előfordult, de a hibakeresésben valamennyi érintettnek részt kell vennie. Az EFER átadja a KSZR-nek az átutalási megbízásokat. A KSZR a számla felett rendelkezésre jogosult által adott átutalási megbízás alapján a kedvezményezettnek járó összeget átutalja az intézmény bevételi célszámlájára. Az EFER az átutalási megbízások adatait átadja az intézményeknek a saját bevételeik elszámolása érdekében. A tranzakciós díj elszámolásának folyamata A FMSZ szolgáltatásáért tranzakciós díjat számol fel. A díjat várhatóan havonta egyszer határozza meg, amelyet átad az EFER részére. Az EFER a díjat a Megrendelő által rugalmasan változtatható paraméterek szerint felosztja a költségviselő intézmények szerint, majd azok adatait átadja az intézményeknek. A tranzakciós díj felosztásának módját, a paraméterek körét a rendszertervezés során Megrendelőnek meg kell határoznia. A díjak elszámolása a Megrendelő által meghatározott időszakonként történik. 2.3.2 Az EFER szolgáltatás orientált működése Az EFER, mint központi rendszer a külvilág felé - így az intézményi rendszerek felé is - szolgáltatásokat publikál. Az egyes szolgáltatások atomiak, közöttük nincs nem adatbázison alapuló állapottárolás, vagyis nincs munkamenet-kezelés. Adatbázison alapuló állapottárolást 14/80
végeznek a szolgáltatások a releváns üzleti objektumokon, és kezelik azok státuszát is. Az EFER által hívott szolgáltatások esetében az EFER kezeli az időtúllépést is (ld. szinkron üzenet fogalma). A szolgáltatások B2B kapcsolat révén érhetők el, csak informatikai rendszerek által és nem humán felhasználók által. Minden, EFER által megvalósított szolgáltatás szinkron jelleggel hívandó, vagyis minden esetben meg kell várni a hívó oldalon a magas szintű válasz megérkezését, a válasz megérkeztéig a hívónak blokkolódnia kell. Ha nem érkezik magas szintű válasz, a hívó a beküldött kérést nem tekintheti beérkezettnek, és meg kell ismételnie a hívást az egyes eseteknél leírt paraméterek szerint. 2.3.3 EFER és környezete telephely Intézmény Rendszere EFER IPP 1 HTTPS 2 4 Fizetési Megoldás Szolgáltató HTTPS 2.3.3.1 Az IT környezet Az EFER-rel való integráció megvalósítása érdekében az intézménynek rendelkeznie kell legalább egy olyan informatikai rendszerrel, amely képes SOAP üzenetváltáson alapuló kommunikációt kezelni mindkét irányban: vagyis képes ilyen technológiával szolgáltatásokat publikálni, ill. szolgáltatásokat hívni azt EFER-ből. Továbbá, támogatja az alábbi protokollok közül egynek a SOAP transzfer protokollként történő használatát: o https (preferált), a WS-RM (a megbízható üzenetváltás megvalósítása végett) és WS-AT (tranzakcionális viselkedés megvalósítása végett) kiterjesztések megvalósítása opcionális, ld. a Megbízható üzenetváltás fejezetet. 15/80
o JMS, az alábbi feltételekkel: Az EFER-hez csatlakozó Intézmény rendelkezik egy üzenetorientált middleware szerverrel, és a JMS kommunikációt Intézmény oldalon ez a szerver biztosítja. Nem elvárás, de erősen javasolt, hogy Intézmény oldalon is ugyanilyen típusú szerver álljon rendelkezésre, egyéb esetben az Intézmény EFER-be történő integrálásának részeként a két JMS implementációt összekötését is meg kell valósítani, mely bár konfigurációs feladat, technikai kockázatot jelent. A https átviteli protokollon képes kölcsönös SSL autentikációt kezelni; rendelkezik egy, az EFER tanúsítvány kiállítója által aláírt tanúsítvánnyal, amellyel azonosítja önmagát minden egyes kérés előtt. Illetve megbízik az EFER tanúsítványában. A JMS átviteli protokoll esetén a JMS alatti TCP/TLS protokolloni képes kölcsönös SSL autentikációt kezelni. Az intézmény EFER tanúsítvány kiállítója által aláírt tanúsítványa kliens tanúsítványként van felhasználva az SSL autentikáció során OU (Organizational Unit) mezőjének kötelezően a INT értéket kell tartalmaznia. Az EFER tanúsítvány kiállítója nem írja alá a tanúsítvány aláírási kérést, ha ez a kritérium nem teljesül. Meg kell valósítania a WS-Sec 1.1 szabványt, mert ez biztosítja az üzenetek sértetlenségét és hitelességét az által, hogy az üzenetek fejléce tartalmaz egy az üzenet törzséből képzett - digitális aláírás, mellyel az üzenet ellenőrizhető. Az aláíráshoz a jogszabályoknak megfelelően nem használhatja ugyanazon tanúsítványt, amit a transzfer protokoll kölcsönös SSL autentikációjánál. 2.3.3.1.1 JMS alapú kommunikáció A JMS átviteli protokollon történő SOAP kommunikációhoz szükséges infrastruktúra felépítése nem triviális, emiatt ebben a fejezetben külön kitérünk rá. Az irányelvek az alábbiak: Az EFER moduljai input üzenetsorokból olvasnak, és output üzenetsorokba írnak. Nincs olyan üzenetsor, ahonnan egyaránt olvasnának, és ahova egyaránt írnának. A tényleges JMS alapú kommunikációt a JMS-t implementáló szerverek, ill. a hozzájuk kapcsolódó kliens API-k végzik. Ez azt jelenti, hogy mind az EFER, mind az Intézmény oldalán rendelkezésre áll egy JMS szerver. A JMS üzenetek két fél közötti továbbítását a szerverek ill. a kliens API végzik. Ezek valósítják meg a két fél közötti hibatűrő és megbízható üzenetváltást is (pl. hálózati detektálása, kapcsolatok újrafelépítése, stb.). Az EFER oldali JMS implementáció a Sun Open Message Queue 4.3. Intézmény oldalon is ez a preferált JMS szerver, mert két ilyen szerver közötti kapcsolat kialakítása nem hordoz technikai kockázatot. Az input üzenetsorok lokálisak, vagyis a helyi szerveren léteznek fizikailag. Emiatt az adott fél mindig lokális üzenetsorból olvas. Az outout üzenetsorok távoliak, vagyis a fizikai üzenetsor a másik fél szerverén található. A JMS implementációtól függően lehetséges, hogy a távoli üzenetsorhoz létezik egy lokális üzenetsor is, mely transzfer céllal létezik. Emiatt az adott fél mindig távoli üzenetsorba tesz üzenetet. Az üzenetek fejlécében elhelyezésre kerülnek az alábbi String típusú propertyk: 1. CONTENT_TYPE= text/xml; charset=utf-8 (tartalma fixen ez legyen, idézőjelek nélkül, ennek megfelelően a message body-ban lévő SOAP XML kódolása is UTF-8 legyen) 2. TARGET_URI= x-jms://<host>:<port>/<qcf>/<q>?path=<service> ahol - host: az intézmény saját broker-jának hosztneve 16/80
- port: az intézmény saját broker-jának portja - az intézmény oldali QCF JNDI neve, amelyen keresztül az intézmény eléri az EFER-t - az intézmény oldali Q JDNI neve, amibe az intézmény az EFER-nek szánt üzeneteket adja fel - service: fixen EFERIntezmenyService (idézőjelek nélkül) Összességében mivel a rendszer szempontjából csak a formátum és a path paraméter értéke számít, így javasoljuk a következő konstans használatát: x-jms://www.example.com:1234/qcf/q?path=eferintezmenyservice A válaszüzenet kérésüzenethez történő párosításának alapja a JMSMessageID és JMSCorrelationID mezők. Ez azt jelenti, hogy a kérést kiszolgáló félnek olyan válaszüzenetet kell előállítania, melynek JMSCorrelationID-je a kérésüzenet JMSMessageID mezőjével egyezik meg. A JMSMessageID mező generálását a kérésüzenetben és a válaszüzenetben is a JMS szerver generálja, azokra nincs hatása egyik félnek sem. A felek a válaszüzenetre várakozás során időtúllépést figyelnek. Adott időn belül meg nem érkező válasz annak a tranzakciónak a visszavonását eredményezi, amelyben a válaszra várakozás történik. A fentiek alapján a következő történik, amikor az EFER az Intézmény 1 szolgáltatását hívja: 1. Tranzakció indul, az EFER elvégzi a szolgáltatásspecifikus műveleteket, majd elkészíti a kérésüzenetet. 2. Új tranzakció indul. 3. Az üzenet fizikailag a lokális transzfer üzenetsorba, a távoli üzenetsor lokális aliaszába vagy magába a távoli üzenetsorba kerül. A kérésüzenethez JMSMessageID generálódik a JMS szerver által. 4. Lokális traszfer vagy aliasz üzenetsor esetén a JMS szerver a kérésüzenetet eljuttatja az Intézmény 1 JMS szerverének lokális, input üzenetsorába. Az EFER Intézmény 1-hez tartozó output üzenetsora tehát az Intézmény 1 szemponjából lokális input üzenetsorra van kötve. Távoli üzenetsor esetén az üzenettovábbításért a kliens API felelős. 5. Az új tranzakció jóváhagyásra kerül. A folyamat a szolgáltatás elején indított tranzakcióban megy tovább. Az EFER várakozik a lokális input üzenetsorán olyan válaszüzenetre, melyben az előzőleg létrehozott kérésüzenet JMSMessageID mezője van beállítva JMSCorrelationID-ként. 6. Az Intézmény 1 előállítja a válaszüzenetet, és beállítja annak JMSCorrelationID mezőjébe a kérésüzenet JMSMessageID mezőértékét. Az elkészült üzenetet feladja a számára lokális transzfer üzenetsorba, a távoli üzenetsor lokális aliaszába vagy magába a távoli üzenetsorba. 7. Lokális traszfer vagy aliasz üzenetsor esetén a válaszüzenetet az Intézmény 1 JMS szervere eljuttatja az EFER lokális input üzenetsorába. Távoli üzenetsor esetén az üzenettovábbításért a kliens API felelős. 8. Az EFER fogadja a válaszüzenetet. 9. A tranzakció jóváhagyásra kerül. A fenti folyamat alapján végigkövethető az az eset is, amikor az Intézmény 1 hívja az EFER szolgáltatásait, annyi eltéréssel, hogy nincs új tranzakció indítva a válaszüzenet feladásakor. 2.3.3.2 Kommunikáció leírása 17/80
Mindig szinkron, push és kérdés válasz alapú. Ez azt jelenti, hogy mindig van egy a hívó által egy kérdés üzenetre meghatározott határidőn belül, a hívott fél által adott válaszüzenet. Push jellegű pedig azért, mert ha egy másik modulban vagy rendszerben megjelenik egy információ, amit át kell adni az EFER részére, akkor a vonatkozó rendszer felelőssége, hogy kezdeményezze az átadást, nem az EFER-é. A magasszintű protokoll az EFER és az intézmény között SOAP. A SOAP transzfer protokollja https vagy JMS lehet. JMS esetén a JMS implementáció a Glassfish-be integrált Sun Open Message Queue 4.3 üzenetorientált middleware szerver, amely képes összekapcsolódni és kapcsolatot fenntartani az intézmény oldalijms-t implementáló szerverrel. A https protokollon és a TCP/TLS protokollon kölcsönös SSL autentikáció előzi meg a két fél közötti kapcsolat felépülését. Az EFER és az intézmény megvalósítja a WS-Sec 1.1 szabványt. A SOAP szabványnak megfelelően a szolgáltatásokat és a velük kapcsolatos adatokat WSDL és XSD állományok írják le. Ezek tételesen az 1. mellékletben találhatók. A WS-Sec kiterjesztés biztosítja az üzenetváltások védelmi elvárásait, úgymint: Sértetlenség: Az üzenet nem volt harmadik fél által módosítva. Hitelesség: Annak biztosítása, hogy az üzenetet valóban a feladó küldte. Letagadhatatlanság: A küldő fél nem tudja letagadni, hogy az üzenetet ő és akkor küldte. Az EFER által támogatott SSL verzió: SSL V3. Az egyes szolgáltatásoknál látható példaüzenetek az egyszerűség kedvéért csak a törzsben lévő adatrészt tartalmazzák, a befoglaló SOAP borítékot nem, így nem láthatók a különböző WS kiterjesztések miatti addicionális tag-ek sem. Függetlenül attól, hogy mi a transzfer protokoll, a SOAP üzenetváltásnak megfelelően a kérés és a válasz üzenetek egyaránt XML formátumúak. Az üzenettípus hordozására az üzenetekben nincs dedikált adatmező - mint ahogy az a fix rekordhosszúságú, szöveges fájl alapú kommunikációnál megszokott -, hanem az üzenettípust a kérés és válasz Body nevű tagjében lévő egyetlen gyermek-tag neve azonosítja (ahogy az a kommunikációs esetekhez tartozó minta kérés- és válaszüzenetekben is látszik). Pl.: EFERfogadFizetesiKeres, EFERfogadFizetesiKeresResponse. Az üzenetekben található tételek száma maximum 5000 lehet. Ha ennél nagyobb tételszámú üzenetre van szükség, akkor azt darabolni kell. Az üzenetek mérete továbbá nem haladhatja meg a 1.5Mbyte-ot. 2.3.3.3 Hibakezelés A technikai és lekezeletlen hibák kezelése a szolgáltatásokban egységes módon történik. Általánosan igaz, hogy minden szolgáltatás maximum egy hibát pontosabban szólva annak hibakódját és hibaszövegét adhat vissza. Ez a hiba pedig a szolgáltatás során előforduló első hiba. A szolgáltatások tehát nem képesek egynél több hibát detektálni egy meghívás alkalmával. Ha nem fordult elő hiba, akkor a visszaadott hibakód 0 lesz, a hibaszöveg pedig üres. Speciális jelentéssel bír a 97-es hibakód, ld. a Megbízható üzenváltás fejezetet. A hiba leírása egy magyar nyelvű üzenet, a hibák értelmezéséhez azonban hibakatalógus mindenképpen szükséges, amelyben hibakód alapján lehet keresni. A hibaleírást nem javasolt intézményi oldalon felhasználói felületen megjeleníteni, csak naplóba kiíratni, mert a célja 18/80
a hibakeresés megkönnyítése, nem pedig a humán felhasználó felé történő közlése, a hiba elsődleges beazonosításására a hibakód szolgál. Ha EFER szolgáltatásokban hiba keletkezik, akkor a válasz, amennyiben képes megérkezni a hívó oldalára, mindig utal a hiba okára. Az alábbi típusú hibákat lehet megkülönböztetni. Technikai hiba: Minden olyan hiba, ami az EFER alsóbb rétegekből, de várt módon érkezik (pl.: az EFER szolgáltatás elveszti a kapcsolatot az adatbázisával). A hibát a réteg javítja hibatűrő mechanizmussal, ha lehetséges. A hiba akkor jut el az EFER legfelső szintjére, ha a javítás sikertelen volt (Pl.: többszöri próbálkozás a hálózati kapcsolat helyreállítására). A hiba lehet: kommunikációs hiba, valamely, EFER által használt külső szolgáltatás nem elérhető. Input validációs hiba: Inputok formai ellenőrzése (pl.: kötelezőség, megengedett értéktartománnyal való összehasonlítás) során keletkezett hiba. Az első hibás input blokkolja a szolgáltatást. Az EFER 1-es hibakóddal válaszol az üzenetetre. Üzleti logikai hiba: Olyan hiba, melyhez az alkalmazáslogikában külön ág tartozik, tehát várt hiba. Ide tartoznak az EFER által hívott külső szolgáltatások válaszában található üzleti hibák is. Tartozhatnak ide potenciális biztonságsértéssel kapcsolatos hibák is. Lekezeletlen hiba: Minden olyan hiba, mely a fenti hibatípusok egyikébe sem sorolható. Az egyes hibák kezelését illetően az alábbiakat kell megemlíteni: Az egyszeres nem alkalmazásmodul-szintű technikai hibákkal kapcsolatos hibatűrő mechanizmusért a detektáló réteg általában az alkalmazásszerver felel. Ide tartozik az adatbázis eléréssel kapcsolatos mechanizmus. A SOAP kommunikációval kapcsolatos hibatűrő mechanizmus megvalósítása átviteli protokoll függő: JMS esetén a JMS önmaga biztosítja, https esetén egyedileg fejlesztett, újraküldési mechanizmust alkalmazó megoldással biztosítjuk, ld. a Megbízható üzenetváltás fejezetet.a hiba üzenet nem tartalmaz Java stacktrace-t, sem specifikus hibaleírást. Input validációs hibák kezelése: minden szolgáltatás az inputok ellenőrzésével indul. Ha validációs hiba lép fel, akkor az üzleti válasz részeként az első hibás mezőnek megfelelő hibakód lesz beállítva. Az üzleti logikai hibákra vonatkozó üzenetek a szolgáltatásokban az üzleti válasz részeként kerülnek elküldésre a szinkron válaszüzenetben. Az alkalmazásmodul-szintű lekezeletlen hibák kezelése a szolgáltatásokban egységes módon kezelődik. Az üzleti válaszban lévő hibák átvitelére a hibakód és hibaleírás elnevezésű mezők szolgálnak. A hibakód egy 0-1000-ig terjedő szám, amit az EFER számként fog értelmezni, nem szabad kitölteni sem balról, sem jobbról semmilyen whitespace karakterrel, sem pedig 0-val. 2.3.3.4 Megbízható üzenetváltás A megbízható üzenetváltás során a kommunikáló felek újraküldési és nyugtázási mechanizmust használnak. Az újraküldés teljes egészében a hívó fél felelőssége. Az újraküldés és nyugtázás megvalósítására az alábbi lehetőségek adottak: 19/80
JMS átviteli protokoll esetén maga a JMS biztosítja, nem szükséges alkalmazásszintű implementáció. https átviteli protokoll esetén a WS-RM és WS-AT kiterjesztések biztosíthatják, nem szükséges alkalmazásszintű implementáció. https átviteli protokoll esetén alkalmazásszintű megoldás biztosíthatja. A fejezet további részeiben az utolsó esettel foglalkozunk. Az alábbiakban leírt elveket kell alkalmazni. 2.3.3.4.1 Újraküldés 2.3.3.4.1.1 AZ EFER, MINT SZERVER Ha az Intézmény nem kap választ a kérésére az EFER felől a beállított idő alatt időtúllépés, vagy hálózati probléma miatt, akkor megadott idő után megismétli azt, változatlan formában. A hívó hiba esetén az esetleges üzleti adatmódosításokat tartalmazó tranzakciót visszavonja. Ha az EFER olyan kérést kap, melynek az azonosítója már el van tárolva az adatbázisban, akkor ellenőrzi, hogy a többi kérésben szereplő - adat megegyezik-e az előzőleg beküldöttel. Ha igen, és az eredeti kérést egyébként sikeresen végrehajtotta, akkor az új kérés Ismételt beküldés (97-es kódú) hibakóddal tér vissza, a válaszban az EFER pedig elhelyezi az eredeti válaszüzenet összes adatát. Amennyiben az eredeti kérés üzleti hibára futott, akkor a megismételt válasz az eredeti kérés hibáját tartalmazza. Az Intézménynek az Ismételt beküldés státuszú üzeneteket sikeresnek kell tekintenie. Ha az Intézmény sikeres választ fogad az EFER felől a beállított időn belül, akkor az esetleges adatmódosításokat tartalmazó tranzakciót jóváhagyja. Az Intézmény felől az újraküldést addig kell ismételni, amíg sikeres vagy Ismételt beküldés választ nem kap. Itt tisztázzuk a 15-ös és 97-es kódok közti eltérést. A 15-ös hibakód azt mutatja, hogy ugyanaz a pénzügyi ügyazonosító más adatokkal került beküldésre, azaz egy azonosító alatt több ügy is fut. Ez a beküldő rendszer hibás működésére utal. A 97-es kód akkor kerül visszaadásra ha a beküldött kérés minden adata megegyezik az ugyanilyen pénzügyi ügyazonosítóval eltárolt kérésével. Ez kommunikációs hibára utalhat, de üzleti szempontból sikeres tranzakciónak minősül. 2.3.3.4.1.2 AZ EFER, MINT KLIENS Ebben az esetben, ha az EFER nem kap választ adott ideig, vagy kommunikációs hibát kap vissza, akkor megadott idő elteltével újraküldi az üzenetet. Az EFER hiba esetén az esetleges üzleti adatmódosításokat tartalmazó tranzakciót visszavonja. Az Intézmény oldaltól ugyanazon működés az elvárt, mint az EFER-től, amikor szerverként viselkedik. A lenti kommunikációs esetekben kitérünk arra is, hogy a küldő félnek milyen paraméterekkel kell megismételnie az üzenet elküldését. 2.3.3.4.2 Nyugtázás 2.3.3.4.2.1 FIZETÉSI KÉRELEM ESETÉN A fizetési kérelem feldolgozása ügyfél oldalon idő és a kommunikáló felek tranzakcionalitása miatt is kritikus folyamat, ezért az üzenetváltás megbízhatóságának növelése érdekében 20/80
technikai célú üzenetváltás is szükséges, ezek piros téglalappal vannak körberajzolva a következő ábrán. A megbízhatatlanság csökkentésére az üzenetek redundanciája szolgál. A feladó, amennyiben nem kap választ, többször megismétli a kérését. Az ismétlések segítenek az esetleges pillanatnyi hálózati problémák kikerülésében. 2.3.3.4.2.1.1 Lehetséges kommunikációs hibák és akciók A kommunikációs hiba mindegyik átmenet esetén azt okozza, hogy az adott üzenet nem érkezik meg a fogadó fél részére. 1: A hibát az intézmény észleli, a kérelmet adott alkalommal újraküldi, amíg le nem telik a próbálkozások száma, vagy sikeres választ nem kap. 2: A hibát az EFER észleli, az első kommunikációs hiba esetén hibát tartalmazó választ ad vissza az intézmény részére. Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával. 3: Az EFER azt észleli, hogy az FMSZ-től nem kapott választ adott időn belül, emiatt hibát ad vissza az intézmény számára. A hiba hatására az intézmény a kérelmet újra beküldi. Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával. 4: A hibát az EFER észleli, az első kommunikációs hiba esetén hibát tartalmazó választ ad vissza az intézmény részére. Ha az FMSZ sikeresnek észlelte a válasza átadását, akkor az EFER által beküldött ugyanazon kérelemre visszaadja ugyanazt a választ, melyet korábban visszaadott (97-es státusz). Az ebben a pontban bekövetkezett hiba esetén biztos, hogy a fizetési kérelem nem érkezett meg az FMSZ felé. Ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé, ami ennek hatására engedi az ügymenetet folytatni más fizetési megoldás választásával. 21/80
5: Az EFER azt észleli, hogy az FMSZ-től nem kapott választ adott időn belül, emiatt hibát ad vissza az intézmény számára. A hiba hatására az intézmény a kérelmet újra beküldi. Ebben a pontban bekövetkezett hibánál a fizetési kérelem már megérkezhetett az FMSZ-hez, ezt az EFER egyértelmű hibaüzenettel jelzi az intézmény felé. A intézmény ennek hatására, az esetleges dupla fizetések elkerülése miatt nem engedélyezi az ügymenet folytatását a hiba elhárításáig. 6: Az intézmény azt észleli, hogy az EFER-től nem kapott választ adott időn belül, ezért a kérelmet újra beküldi. Ha az EFER sikeresnek észlelte a válasza átadását, akkor az intézmény által beküldött ugyanazon kérelemre visszaadja az FMSZ-től korábban kapott választ. 7: A hibát az intézmény észleli, a kérelmet adott alkalommal újraküldi, amíg le nem telik a próbálkozások száma, vagy sikeres választ nem kap. 8: Az intézmény azt észleli, hogy az EFER-től nem kapott választ adott időn belül, ezért a nyugtát újra beküldi. Ha az EFER sikeresnek észlelte a válasza átadását, akkor az intézmény által beküldött ugyanazon nyugtára visszaadja ugyanazt a választ, melyet korábban visszaadott. 2.3.3.4.2.1.2 A kommunikációs hibák kezelésének módja Megjegyzés: végleges hiba alatt azt az esetet értjük, amikor a küldő fél a maximális újraküldésszám elérése után sem kapott választ. Általánosan feltételezhetjük, hogy amennyiben a hiba a válasz ágakon (3,5,6,8) jelentkezik, akkor valamely hálózati eszköz csomagszűrési beállításai miatt nem valósul meg a kommunikáció. Kérés ágak esetében (1,2,4,7) a kapott hibaüzenetek segíthetnek a hiba kiderítésében (hibás hálózati eszköz, nem létező hálózati kapcsolat, a szerver meghibásodása). A hiba pontos helyének és okának kiderítése és elhárításának módja túlmutat jelen dokumentum keretein, mivel az a hálózati infrastruktúra valamely elemében jelentkezik, az EFER hatókörén kívül. 1: A hiba az intézményi rendszeren kerül kijelzésre, mivel az EFER elérhetetlen. A hiba elhárításáig az ügyfél nem tudja folytatni az eljárást. 2: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 3: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 4: A hiba az FMSZ kapcsolatban van. Végleges hiba esetén az ügyfél más FMSZ-t alkalmazó fizetési megoldás választásával megpróbálhatja folytatni a folyamatot. 5: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárításáig az eljárás folytatása nem javasolt. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad, és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. A hiba elhárításának folyamata: Ellenőrizni kell EFER-ben, hogy a kérelem látható-e az EFER-ben és státusza Továbbítás alatt-e. Ha igen, akkor az EFER nem fogadta az FMSZ esetleges válaszát, így bizonytalan, hogy a függő fizetés a bank oldalán létrejött-e. Emiatt nem szabad más fizetési módot választani. Az EFER-FMSZ kapcsolatot helyre kell állítani. 22/80
Ha található kérelem Nyugtázásra vár státusszal, akkor a fizetést el kell végezni, a megérkező fizetési ígérvény pedig Fizetve státuszt állít be mind az EFER, mint az intézmény oldalán. Ilyen esetben is javasolt az EFER-FMSZ kapcsolat felülvizsgálata. 6: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárításáig az eljárás folytatása nem javasolt. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. A hiba elhárításának folyamata: Ellenőrizni kell EFER-ben, hogy a kérelem látható-e az EFER-ben és státusza Továbbítás alatt-e. Ha igen, akkor az EFER nem fogadta az FMSZ esetleges válaszát, így bizonytalan, hogy a függő fizetés a bank oldalán létrejött-e. Emiatt nem szabad más fizetési módot választani. Az EFER-FMSZ kapcsolatot fixálni. Ha található kérelem Nyugtázásra vár státusszal, akkor a fizetést el kell végezni, a megérkező fizetési ígérvény pedig Fizetve státuszt állít be mind az EFER, mint az intézmény oldalán. Ilyen esetben is javasolt az EFER-FMSZ kapcsolat felülvizsgálata. 7: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. 8: A hiba az intézményi rendszerben kerül kijelzésre, és riasztás készül az EFER-ben. A hiba elhárítása után, amennyiben az ügyfél a hibajelzés ellenére kifizeti a megkezdett tranzakciót, az FMSZ-től fizetési igérvény érkezik, amit az EFER befogad és az intézménynek automatikusan átad. Ennek hatására a folyamat a megszakadástól folytatódik. 2.3.3.4.2.2 EGYÉB ESETBEN Nem szükséges nyugtázás, a hívó addig ismétli a kérésüzenetet, amíg helyes választ nem kap. 2.3.3.4.3 Authentikáció Az EFER magát az intézményt autentikálja az által publikált szolgáltatások hívásakor. Az autentikáció módja kölcsönös SSL autentikáció minden átviteli protokoll esetén. Amikor az EFER hívja az intézmény szolgáltatásait, ugyanezen autentikációs módot kell alkalmazni. Az EFER nem szólítható meg ettől eltérő módon, vagyis olyan intézményből, aki nem rendelkezik a megfelelő, az EFER tanúsítvány kiállítója által aláírt tanúsítvánnyal. Ha a SOAP átviteli protokollja https, akkor az EFER az intézmény kliens tanúsítványából kiemeli a Distinguished Name (DN) és Organizational Unit (OU) mezőket, emiatt nem szükséges explicit módon üzenet szinten átadni számára minden kérésüzenetben. JMS protokoll esetén hálózatilag biztosított, hogy az intézmény nem hívhat meg olyan szolgáltatást, amelyre nem jogosult. Az EFER az intézmény felé nyújtott interfészen keresztül nem autentikál humán felhasználót. 2.3.3.4.4 Authorizáció Az EFER az intézményt szolgáltatásonként authorizálja az alábbi szabályok szerint: 23/80
Az intézmény csak a saját átvezetési számláját adhatja meg kedvezményezettként. 24/80
3 EFER ÉS AZ INTÉZMÉNYEK KÖZÖTTI KAPCSOLAT 3.1 FIZETÉSI KÉRELEM ÁTADÁSA EFER-NEK A folyamat rövid leírása: Az elektronikus fizetési megoldás választása esetén az Intézmény a fizetési kérelmet átadja az EFER számára a fizetési tranzakció lebonyolítása érdekében. Az EFER az intézménytől átveszi a fizetési kérelmet, ellenőrzi az adattartalom helyességét. Az átvétel sikerességéről/sikertelenségéről értesíti az Intézményt. Típus: szinkron Időkorlát: 45 másodperc Indító üzenet: IPP_EFER_FIZKER Válasz üzenet: IPP_EFER_FIZKERVALASZ Ismétlés: 90 másodperc 3.1.1 Folyamat leírása Az Ügyfél elektronikus fizetési megoldást választott az Intézmény oldalán. Az Intézmény a választott fizetési megoldás, és az FMSZ beállításainak megfelelően (lásd. IPP_FMSZLISTAKER) függvényében további adatokat kér be az Ügyféltől, házibankos és mobilbankos fizetés esetén a bankszámla számát. A fizetési kérelmet egyedi azonosítóval (pénzügyi ügyazonosító) látja el majd a fizetési kérelemnek megfelelő adatokkal kitöltött üzenetet küld az EFER felé. (IPP_EFER_FIZKER) A fej adatok tartalmazzák a fizetéshez szükséges adatokat mind az egyedi mind az összevont tételek esetén, a tétel adatok - az egyösszegben fizetett - az elszámoláshoz szükséges tételt vagy tételeket tartalmazzák, míg a láb adatok a tételadatok ellenőrzésére szolgálnak. Ha a Hozzájárulás mező értéke hamis vagy a mező nincs megadva, akkor a tételadatok nem lesznek az FMSz részére továbbítva. Az EFER az intézménytől átveszi a fizetési kérelmet, ellenőrzi az adattartalom helyességét és a választott fizetési megoldáshoz tartozó kiegészítő mezők kitöltöttségét. Ha hibátlan az üzenet, akkor házi- és mobilbankos fizetés esetén továbbítja az FMSZ-nek a fizetési adatokat VPOS esetén bankkártyás fizetési tranzakciót indít Sikeres adatátadás ill. tranzakció indítás esetén az EFER 0 hibakóddal ellátott válasz üzenetet küld az intézmény felé. (IPP_EFER_FIZKERVALASZ) Az Intézmény a megkapott válasz, a fizetési megoldás és az ügyintézői módnak megfelelően vagy azonnal folytatja a fizetési folyamatot az Ügyfélnek a megkapott URL-re történő átirányításával, vagy a választ letárolja és értesíti Ügyfelét a további teendőkről. Hiba esetén a kérelem elutasításra kerül, a válasz üzenet hibakódja utal a hiba okára lásd. Hibakódok, ebben az esetben az intézménynek új pénzügyi ügyazonosítóval kell megpróbálnia újra beadni a fizetési kérelmet. Hibának minősül a kötelező mezők hiányos kitöltése, a nem egyedi pénzügyi ügyazonosító és a hibás kumulált adatokat tartalmazó üzenet. 25/80
A kérelemben megadott intézményi átvezetési számlához tartozó intézményi számlának az EFER törzsadatai között szerepelnie kell, különben a kérelem visszautasításra kerül. Amennyiben az EFER nem tudja átvenni a fizetési kérelmet (pl hálózatkiesés miatt), az intézmény megpróbálhatja azt később újra elküldeni (a fizetési határidő lejárata előtt), tehát a kérelem megismételhető az eredeti formájában az eredeti pénzügyi ügyazonosítóval. Az intézményi oldallal szemben elvárás, hogy jelezze a kezelő felé, ha a meghatározott ismétlésszám elérése után sem sikerült választ kapnia az EFER-től. Ilyen esetben az ügyintéző az EFER rendszerben ellenőrizheti, hogy a fizetés megtörtént-e. Az ellenőrzés hiányában a fizetés állapotára semmiféle feltételezés nem tehető. Interneten történő ügyintézés esetén az intézményi oldalon jelezni kell az ügyfélnek, hogy az esetlegesen készült fizetési tranzakció az FMSZ megfelelő eszközével ne hagyja jóvá vagy írja alá. Az ismétlési szám a vonatkozó folyamat valósidejű jellege miatt van maximálva. Ellenőrzés Hibakód üzenet szintaktikailag megfelelő 1 számlaszám szintaktikailag megfelelő (pl. nem CDV hibás) 2,3,4 üzenet azonosító (pénzügyi ügyazonosító) egyedi 15 intézmény és alrendszer azonosító megfelelő 20,30,31 az intézménykód és a címzett/kedvezményezett számlaszám 32 nem tartozik össze vagy nem használható a megadott fizetési móddal, nem létező átvezetési számlaszám célszámla létezik, és EFER-hez tartozó 56 forrás (terhelendő) számlaszám nem létezik 50,51 tételek darabszáma és összegei helyesek 10,11 érvénytelen fizetési megoldás 22 fizetési határidő érvénytelen / nem konzisztens az üzenettel 40 fizetési megoldást az FMSZ támogatja 33 devizanem = HUF 23 Ismételt beküldés (sikeresnek tekintendő, ekvivalens a 0 hibakóddal) 97 FMSZ válaszra vár 98 Sikertelen üzenetátadás esetén az intézménynek maximum 3 alkalommal kell megkísérelnie az üzenet újraküldését. Az ismétlési szám a fizetési kérelem befogadási folyamat valósidejű jellege miatt van maximálva. 3.1.2 Adatkör leírás (IPP_EFER_FIZKER) Mező neve Tag neve Típus Kötelező FEJ intézményi azonosító intazon intazon I alrendszer azonosító alrszazon alrszazon I pénzügyi ügyazonosító penzazon penzazon I devizanem dev dev I fizetési határidő fizhatido idopont I fizetési megoldás fizmegold fizmegold I fizető bankszámlaszáma kotszlaszam fizetési szlaszam megoldás 26/80