AZ XSD LEÍRÁSOK FELÉPÍTÉSE

Felsıoktatási Információs Rendszer Az XSD leírások felépítése

Országos Felsıoktatási Információs Központ Verzió: 1.1; Kiadás dátuma: 2007. május 25.

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

AZ XSD LEÍRÁSOK FELÉPÍTÉSE A KÖNYVTÁRSZERKEZET A www.felvi.hu portál „Hivatali ügyek” csatornájából letölthetı tömörített állományokban megtalálhatóak mind a bejelentések (intézmények → FIR), mind az intézményi bejelentésekre adott FIR válaszok (FIR → intézmények), mind pedig a FIR-bıl érkezı adatterítések definíciós állományai (FIR → intézmények). A kitömörített könyvtárstruktúra felépítése a következı: –

–

FIR_XSD/AdatSzolgaltatas: az intézményi bejelentések definíciós állományai; a bejelentéseket az AlairtAdatSzolgaltatas.xsd file alapján fogjuk ellenırizni. A bejelentési kérelmek tényleges formátumát az alkönyvtárokban lévı üzenettípus.xsd állományok határozzák meg (az üzenettípusokról bıvebben az interface specifikáció „A bejelentés formája” címő fejezetében lehet olvasni). FIR_XSD/AdatSzolgaltatasValasz: az intézményi bejelentésekre a FIR-ben

készült

válaszok

definíciós

állományai; a küldött válaszok AlairtAdatSzolgaltatasValasz.xsd minta alapján fognak készülni

az

–

FIR_XSD/AdatSzolgaltatas: az intézményi bejelentések definíciós állományai; a küldött válaszok az AlairtAdatTerites.xsd minta alapján fognak készülni

–

FIR_XSD/Alairas: az XML-ek digitális hitelesítésének formai elıírásait tartalmazó

állományok

AZ ALÁÍRT XML Az kommunikáció hitelesítése és a hitelesség ellenırzése rendszerünk elengedhetetlen alapeleme; a digitális kommunikációban ennek megvalósításához pedig igyekeztünk szabványos formátumot használni. A digitális hitelesítéshez szükséges XSD definíciókat mindegyik könyvtárban az Alairt*.xsd állományok tartalmazzák. A kulcselemek jelentésérıl, valamint az aláírás kialakításáról és a megkötésekrıl szóló részletes tájékoztató elkészítése folyamatban van.

AZ ADATSZOLGÁLTATÁS FORMAI KÖVETELMÉNYEI ÜZENETAZONOSÍTÓK Az xml üzenetek egyrészt tranzakciós azonosítóval (/Kontener/KontenerFej/TranId), másrészt üzenetazonosítóval (/Kontener/Kontenertorzs/Uzenet/UzenetFej/UzenetId), harmadrészt rekordazonosítóval (/Kontener/Kontenertorzs/Uzenet/UzenetTorzs/HallgatoKontener/Hallgato RekordId attribútum) rendelkeznek. Ezek közül az üzenetazonosító és a rekordazonosító a saját szintjén futó számozással generálódik (ez annyit jelent, hogy pl. különbözı konténerekben szerepelhetnek megegyezı üzenetazonosítók), a tranzakciós azonosítók viszont globálisan egyediek. A központi rendszer minden küldıtıl minden tranzakciót csak egyszer fogad el, elkerülendı a zavaró üzenet visszajátszásokat. Amennyiben egy kérésre nem érkezik egy megadott idın belül válasz, a küldı rendszernek kell lekérdeznie, hogy mi lett a kérésével. Az azonosító felépítése AxxxxyÉÉHHNNegyediazonosító, ahol:

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–1–



___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–

–

'A' - kötött szám karakter (értéke 4), ez csak azért szükséges az elejére, hogy az 'xxxx' intézményi azonosító mindenféleképpen 0-kkal prefixelt legyen (tehát pl. az 5ös intézmény esetében 0005 kerüljön a kódba) 'xxxx' - az intézmény 4 jegyő azonosító kódja

–

'y' – intézményen belüli küldı rendszer azonosító kódja (egyetlen ilyen alkalmazás esetén a kód 1) – ezt a kódot az OFIK osztja

–

Az ’y’ azonosító bevezetése fıként azokban az intézményekben fontos, ahol a bejelentés több rendszerbıl fog történni. Az ’y’ azonosítószám használatával elkerülhetı, hogy a különbözı intézményi rendszerek megegyezı konténer tranzakciós azonosítót készítsenek (könnyen elıfordulhatna, hogy az utolsó 7 számjegyet naponta újrainduló futó számozással készíti mindkét rendszer, így várható, hogy az azonosítók többszörösen szerepelnének).

– – –

'ÉÉHHNN' - az azonosító létrehozásának dátuma egyediazonosító – az XML küldıje által generált fixen 7 jegyő számsorozat, amely képzésénél a küldı garantálja, hogy a teljes azonosító egyedi lesz pl: 4000510705281234567

A FIR-bıl az intézményi rendszerekbe érkezı üzenetazonosítók is ilyen felépítésőek, ebben az esetben az intézmény 4 jegyő azonosító kódja ’0000’. ALKALMAZOTT KONVENCIÓK A XML minták és séma definíciós fájlok készítése során – a teljesség igénye nélkül – az alábbi konvenciókat alkalmaztuk: –

A Hallgató (/Kontener/Kontenertorzs/Uzenet/Uzenettorzs/Hallgatokontener) és Oktató konténerben (/Kontener/Kontenertorzs/Uzenet/Uzenettorzs/Oktatokontener) levı tételek elejére egy Azonosító blokkot (…/Azonosito) helyeztünk, ebben az oktatási azonosító és természetes azonosító adatok szerepelnek, ebbıl – a jogviszony létrehozás esetét leszámítva – az oktazon kötelezı.

–

Általánosan igaz, hogy a nem kötelezı mezık kitöltetlenségét NULL értékkel kell jelölni (tehát az adat nem hagyható el), nem kötelezı adatblokkok pedig elhagyhatók. Ez alól eltérés a személyadat módosítások esetén a hallgató és oktató blokknál, illetve az azonosító adatok körénél van, itt ugyanis nem követeltük meg, hogy bennük minden adat szerepeljen (szükség esetén NULL értékkel), a nem relevánsak elhagyhatók.

–

Nem kötelezı adatblokkok esetén lehetıség van az adott blokk törlésére és mentésére. Elıbbi esetben (az XML blokk „muvelet” attribútumának értéke TOROL), ha a megadott adatok szerinti blokk szerepel az adatbázisban (és a megfelelı egyéb, folyamatfüggı feltételek teljesülnek), akkor az törlésre kerül, míg utóbbinál (az XML blokk „muvelet” attribútumának értéke MENT) ha nem szerepelt, akkor mentésre, ha igen és egyértelmően azonosítható, akkor módosításra kerül.

–

a bejelentendı és módosítandó adatok esetében ún. azonosító és kiegészítı (módosító) adatblokkok kerültek bevezetésre. Az azonosító blokkban találhatóak az adott adatkörre jellemzı azonosító adatok – pl. az oktatók esetében a nyelvtudás bejelentésének azonosító adatai: NylID (nyelv azonosító), Fok (a nyelvvizsga típusa), és Tipus (a nyelvvizsga típusa). Az adatok kiegészítı adatait a megszokott (HJVK vagy HSZE kérelmek használatával) módon lehet elvégezni; az azonosító

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–2–



___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

adatok módosítása a különbözı adattípusoknál más és más, ezt szemlélteti a következı összefoglalás: o

személy adatok: a régi adatok az Azonosító, az újakat a Szemelyes blokkba kell írni

o

jogviszony adatok:

o

o

a típus és érintett szervezet nem módosítható, ha ezek lettek hibásan rögzítve, akkor a jogviszonyt sztornózni kell egy HSTR vagy OSTR üzenettel és a helyes adatokkal egy új HJVL vagy OJVL bejelentést kell készíteni

a kezdıdátum egy HJVD vagy OJVD kérelemmel módosítható

képzés adatok:

a képzés azonosítója nem módosítható, ha ez hibás, akkor sztornózni kell a képzést egy HSTR üzenettel és a helyes adatokkal egy új HJVL bejelentést kell készíteni

képzés kezdıdátuma a HJVD kérelemmel módosítható

munkakör adatok:

típus nem módosítható, ha ez hibás, akkor sztornózni kell a munkakört egy OSTR üzenettel és a helyes adatokkal egy új OJVL bejelentést kell készíteni

kezdıdátum egy OJVD kérelemmel módosítható

o

képzési idıszak, szakirány: ezek esetén a hibás adatok javítására csak sztornózás és új bejelentés használatával van lehetıség

o

egyéb személyes adatok (pl. címek, értesítési adatok, …) esetén a hibás érték felülírható a „ment” mővelet alkalmazásával

A SZÓTÁR TÁBLA HASZNÁLATA Az XSD leírásokban több helyen említésre kerül a SZÓTÁR tábla odavonatkozó típusa. Az ilyen helyeken a mezı értékkészletét a SZÓTÁR táblából deríthetjük ki: az adott „tipus”-ú rekordok „rnev” értékeit veheti fel a mezı; a jelentése pedig az adott „rnev”-hez tartozó „hnev” szöveg lesz. MIRE FIGYELJÜNK AZ XML-EK KÉSZÍTÉSEKOR? Az XSD leírások tervezésekor figyelembe kellett venni, hogy a definíciók követhetıek maradjanak. Ennek érdekében több helyen inkább azt a megoldást választottuk, hogy a beérkezı adatok ellenırzését nem az XSD-ben próbáljuk megvalósítani, hanem a kérelmeket feldolgozó folyamatok ellenırzési mechanizmusába integráljuk. Ezek alapján az XSD definíciókat kiegészítendı a következı megkötéseket tesszük az adatok formájára vonatkozóan (amennyiben az adatok nem ilyen formán kerülnek bejelentésre, a kérelmek várhatóan elutasításra kerülnek): –

azoknál a mezıknél, ahol a mezı értéke felvehet NULL értéket, az XSD elkészítésekor használtuk az xs:nil opcionális attribútumot. Amennyiben egy ilyen mezınél NULL értéket kell elküldeni, a rá vonatkozó XML tag attribútumlistájában szerepelnie kell egy xs:nil=”true” vagy egy xs:nil=”1” elemnek; ebben az esetben az XML tag-ben nem lehet értéket megadni.

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–3–



___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–

minden dátummezıben ÉÉÉÉ-HH-NN formátumot kell használni. Amennyiben idıpont mezırıl van szó: ÉÉÉÉ-HH-NN ÓÓ:PP:MM.

–

amennyiben egy születési dátum pontatlan (pl. egy afrikai országból érkezı hallgató esetén), a bejelentett születési dátumot ennek ellenére a fent említett formában kell megadni. Az ÉÉÉÉ adat általában jı közelítéssel megadható, a nem ismert HH vagy NN adat helyére pedig 01 értéket kell megadni. A születési dátum pontatlanságát az ennek megfelelı mezıben a SZÓTÁRBAN található értékek használatával lehet jelölni.

–

amennyiben egy „C” típusú nyelvvizsga külön „A” és „B” nyelvvizsgából tevıdik össze, a bejelentéskor az „A” és a „B” típusú nyelvvizsgát kell megadni.

–

a vonatkozó jogszabályok alapján a kollégiumi tagsági jogviszony létrejötte a kollégiumi felvétellel jön létre, befejezıdése pedig többek között a felvételrıl szóló döntésben meghatározott határidı lejárta lehet. Várható, hogy legtöbb esetben emiatt szőnik meg a kollégiumi tagsági jogviszony, ezért az ilyen típusú jogviszonyok bejelentésekor ki kell tölteni a jogviszonyra vonatkozó VegDat mezıt is (ez alapján a jogviszony automatikus lezárásra kerül).

AZ ADATSZOLGÁLTATÁSRA A FIR-BİL ÉRKEZİ VÁLASZOK A FIR rendszer többféle választ fog visszaküldeni a bejelentı rendszerek számára: –

a konténer beérkezésekor egy nyugtát, amely tartalmazni fogja a beküldött konténer azonosítóját, az átvett konténer kivonatát (hash) és a beérkezési státuszt (pl. olvasható, hiteles bejelentés; sérült hitelesítés; sérült adattartalom; …)

–

a konténerben található kérelmek feldolgozásakor minden egyes kérelemre a feldolgozás végén válaszüzenet készül (pl. a kérelem elfogadva; a kérelem elutasítva formai vagy adattartalmi vagy jogi okból)

–

egy válaszüzenet konténer több egyedi bejelentésre vonatkozó választ is tartalmazhat majd. Fontos, hogy egy ilyen konténer várhatóan nem fogja egy teljes bejövı kérelemkonténer összes egyedi bejelentésének feldolgozási eredményeit tartalmazni (elıfordulhat ugyanis, hogy egy konténeren belüli kérelmek kezelési ideje lényegesen eltér – például egyes esetekben emberi feldolgozásra is szükség lehet –, a hosszabb lefutású kérelmek miatt viszont nem várakoztatjuk azokat, amelyekre gyorsabban tudunk válaszolni).

–

minden egyes választípushoz egy egyedi kódot rendelünk, amely utal a jellegre (1. karakter; 3 → hallgatói; 4 → oktatói, 5 → általános), folyamatra (2. karakter), konkrét hibára (3-4. karakter)

–

a válaszkódok azonosítására használhatóak a SZÓTÁR tábla EREDMENYKOD (tartalmazza a pár szavas részletezést), EREDMENYKODRL (rövid leírás) és EREDMENYKODHL (hosszú leírás) típusai

A FIR-BİL TÖRTÉNİ ADATTERÍTÉS Az adatterítés célja, hogy a FIR-ben tárolt adatok automatizált módon juthassanak el az intézmények adatbázisaiba. Az adatterítés érintheti a következı területeket: –

törzstáblákat (többek között tartalmazza az intézmények és a képzések adatait, valamint a rendszer üzemeléséhez kapcsolódó táblákat – szótár, település-, ország-, nyelvjegyzék)

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–4–



___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–

személyes adatokat (amennyiben a FIR-ben egy személy adata megváltozik és az közhitelesen ellenırizhetı, az összes olyan intézménybe, amellyel a személynek jogviszonya van terítésre kerül a módosult adat)

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

–5–

AZ XSD LEÍRÁSOK FELÉPÍTÉSE

Recommend Documents