Fejlesztői kérdések








Az NTAK-hoz való kapcsolódáshoz minimálisan egy autentikációs és egy aláíró tanúsítványra van szükség.











Az SSL kapcsolat felépítése során mindkét félnek meg kell bíznia egymásban. A szerver úgy bízik meg a kliensben, hogy az alkalmazás felmutatja az autentikációs tanúsítványát. A fenti hibák arra utalnak, hogy bár a szerver is felmutatja a saját tanúsítványát nekünk, az alkalmazásunk azt nem fogadja el. Teszt környezetben úgy nevezett self-signed tanúsítványt használ a rendszer, így a PMS szoftverek alapból nem tekintik megbízhatónak ezt a tanúsítványt.
Éles környezetben nem self-signed, hanem hitelesített tanúsítvánnyal rendelkezik a szerver. Ennek ellenére néhány programnyelv alapból egyetlen tanúsítványban sem bízik meg.
A hibát úgy lehet kiküszöbölni, hogy a Trust Store-ban elhelyezzük a központi NTAK szerver tanúsítványát (a teljes tanúsítványláncot), ezáltal a szerver megbízhatóvá válik.











.NET alapú alkalmazások esetén ez a legegyszerűbben a Windows tanúsítvány-kezelő alkalmazásával érhető el, amelyet a Start/Futtatás/certlm.msc beírásával tudunk elindítani. Itt a Trusted Root Certification Authorities mappában szerepelnie kell az NTAK-os tanúsítványnak. A tanúsítvány (chaint) a legegyszerűbben úgy szerezhető be, ha egy böngészőben betöltjük az NTAK tesztkörnyezet végpontjának web címét (https://pms.tst.sagem.hu/ntak), és onnan kimentjük a tanúsítványt.











A megbízhatónak tekintett szerver tanúsítványokat egy pem formátumú állományban kell elhelyezni. Erre az állományra a php.ini fájlban kell hivatkozni az alábbi módon:


curl.cainfo=”/etc/php7.0/cacert.pem”


openssl.cafile=”/etc/php7.0/cacert.pem”











Az autentikációs és aláíró tanúsítványok megszerzéséhez tanúsítványkérelmet (CSR) kell eljuttatni az NTAK számára. A tanúsítvány-kérelmet az NTAK által üzemeltetett tanúsítvány-kiszolgáló (CA) hitelesíti. A tanúsítvány-kérelmekből a hitelesítés által tanúsítvány képződik.











Tanúsítvány-kérelem számtalan módon előállítható. A PMS dokumentációkban három különböző lehetőséget mutattunk be:












Nem, a két tanúsítvány fajtát nem azonos módon kell igényelni, ezért fontos, hogy a dokumentációban leírt lépéseket pontosan kövesse az igénylő.











Alkalmazásfüggő, hogy a privát kulcsunkkal együtt, egy fájlban (pfx / p12) tároljuk, vagy külön fájlokban.











A tanúsítványt PFX / P12 formátumban (azaz a hozzátartozó privát kulccsal összepárosítva) be kell importálni a böngészőnk saját / privát tanúsítványokat tartalmazó listájába, majd ez után megpróbálni megnyitni az egyik NTAK által biztosított WSDL állományt tartalmazó URL-t. Amennyiben a böngésző meg tudja nyitni a WSDL állományt, úgy a böngészőnk sikeresen azonosított minket az szerveren, tehát az autentikációs tanúsítványunk megfelelő. Többek között az alábbi URL-ek használhatók a tanúsítványok tesztelésére:












A Failed check hibaüzenet arra utal, hogy az XML állomány nem megfelelően lett aláírva, vagy az aláírás elhelyezése és az üzenet beküldése között az üzenet tartalma megváltozott. Akár egy karakternyi változás is problémát okoz.











A hibaüzenetet akkor kapjuk, ha nem írjuk alá a SOAP üzenet body és timestamp részeit, hanem csak vagy az egyiket, csak vagy a másik részét.











Az eseményvezérelt adatküldéseket az státusz tényleges változásának dátumával kell beküldeni, akkor is, ha valamiért a rendszerben ez később került rögzítésre. Ennek oka az, hogy ellenkező esetben inkonzisztenciák lépnének fel a rendszerben a napi zárásokból és az eseményvezérelt adatokból származó információk között.











Ideális esetben természetesen azonnal, teljes adattartalommal kell sor kerüljön az eseményvezérelt adatok beküldésére. A rendszer technikai szempontból jó működéséhez arra van szükség, hogy az üzenetek teljes adattartalommal kerüljenek beküldésre, így kérjük minden szükséges adat rögzítésekor kerüljenek továbbításra az üzenetek. Az, hogy ez mennyivel térhet el a tényleges érkezéstől például, a rendszeren kívüli, adott esetben jogi kérdés, kérjük kövessék nyomon a vonatkozó jogszabályokat.











A validáció célja az, hogy a technikai kapcsolódást követően az MTÜ szakértői csapata meggyőződhessen arról, hogy a beküldésre kerülő adatok üzleti tartalom szempontjából is megfelelőek. A javasolt folyamat lépései:



  1. A fejlesztők a sikeres csatlakozást és üzenetküldéseket követően jelzik az NTAK Ügyfélszolgálaton keresztül ezt, kérve a validációs esettanulmányt.

  2. Átküldésre kerül egy üzleti esettanulmány és a leírása, szükség esetén sor kerül a tisztázó kérdések megválaszolására.

  3. A fejlesztők elkészítsék el a tesztkörnyezeteken a beküldendő napokat az esettanulmánynak megfelelően.

  4. Az 1. napi napi záráshoz a fejlesztők elküldik a rendszer felé az UtemezesRequest-et, amire megkapják a beküldendő napok listáját, melyekre beküldésre kerülhetnek az eseményvezérelt és napi zárás üzenetek.

  5. Legkésőbb a beküldés végeztével a fejlesztő csapat a fenti csatornán jelzi a tesztek beküldésének elvégzését és tájékoztatja a feldolgozó szakértőket a beküldéskor használt T01 nap pontos dátumáról.

  6. A feldolgozó csapat elvégzi a beküldött üzenetek validációját.

  7. Sikeres validáció esetén a szoftverfejlesztők, az MTÜ felelőse és az ellenőrző csapat felelőse aláírja a tesztelés lezárásáról készülő jegyzőkönyvet, mellyel a szoftver alkalmas lesz az éles rendszerre való adatküldésre.











Az elvárt megoldástól való eltérések tételes összegyűjtésre kerülnek, ezeket küldi vissza az ellenőrző csapat. Ezek kapcsán a szoftverek fejlesztőinek feladata ezeket kategorizálni az alábbiak szerint:



  • Adminisztratív hibák: Nem a szoftver rossz működéséből, hanem pl. input adatok téves felviteléből, felületen módosítandó paraméterek rossz beállításából fakadó eltérések. Kérjük azt is jelezni, hogy hogyan biztosítható, hogy éles üzemben helyesen kerülnek majd beküldésre az NTAK rendszerbe.

  • Technikai hibák: Szoftver pontatlan működéséből fakadó, programozásból fakadó hibák.

  • Egyéb: Nem adminisztratív és nem technikai hiba okozza az eltérést. Eltérés okát ebben az esetben kérjük feltüntetni szíveskedjenek.



A kiértékeléshez az adminisztratív hibának jelöltek áttekintése érdekében ezek adminisztratív jellegét bemutató képernyőképeket is küldeni kell.



A validációt végző csapat kérheti bizonyos üzenetek vagy napok újraküldését, amennyiben úgy látják, hogy ezzel állapítható meg bizonyos hibák kijavításának elvégzése.











Az NTAK rendszer integrációs tesztkörnyezetén és éles környezetén az adatküldési végpont elérése a következő:













Az aktuálisan használt WSDL fájlok az NTAK információs oldalról letölthetőek, a PMS interfész leírás dokumentum mellékleteként a v1, v6 és v7 végpontra vonatkozóan is, a következő linken: https://info.ntak.hu/fejlesztoi-dokumentacio/