Rendszerterv
verzió: 1.3
Verziókövetés Verzió: 1.0.
Készítette: Török Tamás
1.1
Török Tamás
1.2
Török Tamás
Török Tamás 1.3
Leírás: Dátum: Neptun -> NIIF LDAP szerverek közötti 2004. április 22. adatszinkronizációs megoldás Kiegészítések: A rendszer célja; 2004. április 26. A tényleges megvalósítás fejezetekben. Új fejezet: A szinkronizáció komponens működésének fázisai. Kiegészítés: Követelménylista 2004. április 28. részletezése; Új fejezet: a komponens kiválasztásának szempontjai; Kezdeti adatfeltöltés Végleges változat. A SzIE-n elvégzett 2004. június. 14. tesztek során történt módosításokkal kiegészítve.
-1-
Tartalomjegyzék 1. A rendszer célja.........................................................................................3 1.1 A megvalósítandó rendszer kiválasztásának szempontjai.............................3 1.1.1 Oracle triggerek használata..............................................................4 1.1.2 Külső szinkronizáló komponens az Oracle és az LDAP között..................4 1.2 A kiválasztott megoldás.........................................................................5 1.2.1 A megoldás peremfeltétele Oracle oldalon..........................................5 2. A megvalósítás feltételei............................. .................... ................... ..........7 3. A tényleges megvalósítás.............................................................................9 3.1 Oracle -> LDAP adatmegfeleltetés...........................................................9 3.2 Insert művelet....................................................................................12 3.3 Update művelet..................................................................................12 3.4 Delete művelet...................................................................................13 3.5 INITIALIZATION művelet.....................................................................13 3.6 Kezdeti adatfeltöltés....................... ............... ............... ............... ........14 4. A szinkronizációs komponens működésének fázisai.........................................15 4.1 Insert művelet....................................................................................15 4.2 Update művelet..................................................................................17 4.3 Delete művelet...................................................................................19 5. Előzetes tesztek, becslések........................................................................22 6. Telepítés tervezett menete.........................................................................23 7. Az alkalmazás működésének egyszerűsített folyamatábrája.............................24
-2-
1. A rendszer célja A cél egy olyan megoldás kialakítása, ami a Neptun rendszer által kezelt és karbantartott Oracle alapú felhasználói adatokat az NIIF által kezelt LDAP alapú címtár irányába (egy irányúan) szinkronizálja. A megoldás pilot jelleggel szemlélteti a koncepció működőképességét. A pilot jelleg jelen esetben koncepciót és teljes funkcionalitású megoldást jelent, azonban éppen a pilot jelleg miatt nem került kifinomításra minden részlet. A pilot megoldás kialakításánál természetesen szempont volt a megfelelő teljesítmény biztosítása. A megoldásnak nem célja az on-line, közvetlen szinkronizáció. Az NIIF-el történt egyeztetés alapján elfogadhatónak tartjuk a napi egyszeri Neptun-Oracle -> NIIFLDAP adatáttöltést. A SzIE-n elvégzett tesztek alapján a mérési eredmények azt mutatják, hogy a napi rendszeres működés során (viszonylag csekély számú – néhány száz rekord változása) a megoldás gyakorlatilag on-line működést tud biztosítani, hiszen a szinkronizáció időigénye igen kevés. A megoldás megvalósítása pilot jelleggel történt meg az NIIF által meghatározott helyszínen, a gödöllői Szent István Egyetemen (SzIE).
1.1 A megvalósítandó rendszer kiválasztásának szempontjai A rendszer céljának (a megvalósítandó feladat) ismeretében több megoldás, termék közül kellett kiválasztani azt az egyet, amely a pilot megoldásként ténylegesen implementálásra kerül. A kiválasztás során egyaránt megvizsgáltunk „dobozos” és saját fejlesztésű megoldásokat is a következő szempontok alapján: • • • • • •
A megoldás során (fel)használt komponensek költsége A bevezetés bonyolultsága A bevezetés ideje A bevezetés során milyen mértékben szükséges „hozzányúlni”, módosítani a meglévő komponensekben A megoldás platformfüggősége A megoldás bővíthetősége
-3-
A fenti szempontok figyelembevételével kizártuk a Sun Metadirecory és a (Sun portfóliójában szereplő, azonban pillanatnyilag önálló termékként megvásárolható) WaveSet LightHouse provisioning termékeit. Ezen termékek ugyan funkció tekintetében teljesítik a rendszerrel szemben támasztott követelményeket, azonban a termékek ára és platformfüggősége miatt az alkalmazásuktól eltekintettünk. Speciális feltétel a jelen szinkronizációs alkalmazással szemben bizonyos adatok transzformációja, adatok (adott esetben dinamikus, pl. mail attributum) származtatása, amelyre a metacímtár/provisioning termékek alapértelmezetetten sok esetben nem képesek. A saját fejlesztésű megoldások esetében két alternatívát vizsgáltunk meg:
1.1.1 Oracle triggerek használata Az Oracle trigger használata esetén az Oracle oldalon bekövetkező változások hatására lehetőség van a változások közvetlen LDAP publikálására. Ezen megoldásnak mindenképpen előnye, hogy gyakorlatilag on-line módon tud megtörténni a változások átvezetése az LDAP címtárba, azonban a közvetlen és viszonylag kevésbé kontrollálható közvetlen LDAP írás veszélyeket tartalmazhat. A megoldás során létrehozandó / módosítandó objektumok létrehozása kevésbé szabadon szabályozható, mint egy saját fejlesztésű „külső” komponens esetében. Ugyancsak kérdéseket vettet fel számunkra ezen megoldás debuggolásának lehetősége, a megoldás által generálható logok részletessége.
1.1.2 Külső szinkronizáló komponens az Oracle és az LDAP között Külső szinkronizációs komponens használata esetén az alkalmazás egy tetszőleges (definiált peremfeltételeknek megfelelő) számítógépen futhat, amely hálózaton (TCP/IP) keresztül kapcsolódik az Oracle és az LDAP szerverekhez. A komponens periódikusan (definiálható periodicitással) olvassa az Oracle adatbázist és a megfelelőképpen jelölt változásokat feldolgozva, értelmezve azokat publikálja az LDAP címtárba. A feldolgozás módja rugalmasan konfigurálható, az elvégzett műveletek, a működés módja általunk konfigurálható módon loggolható. A külső komponens megvalósítására több programozási platform is rendelkezésre áll, a különböző platformok használatával teljesen azonos funkcionalitás érhető el.
-4-
Az általunk preferált platformok a perl és a java. Mindkét programozási környezet platformfüggetlen, rendelkezésre áll Unix, Linux és Windows környezetben is. A konkrét megvalósítás során a perl mellett tettük le a voksot, hiszen megfelelő teljesítmény érhető úgy el vele, hogy a kód mindenki számára átlátható és értelzehető marad, ugyanakkor igen egyszerű a kód módosítása, amire a pilot fázisban szükség lehet. Ugyancsak a perl mellett szól az igen gyors fejlesztésu idő is.
1.2 A kiválasztott megoldás A kiválasztott megoldás a saját fejlesztésű külső szinkronizációs komponens. A pilot megoldás implementálását perl programozási nyelven valósítjuk meg. Abban az esetben, ha a megoldás az evaluációs fázist követően mint végleges megoldás kerül kiválasztásra, minden probléma nélkül portolható java platformra. A szinkronizációs alkalmazás jelen formájában egyirányú adatszinkronizálást tesz lehetővé Oracle -> LDAP irányban. A megoldás tervezésének kezdetén ezen irány volt a rendszerrel szemben támasztott követelmény. Természetesen nem tartjuk kizártnak az LDAP -> Oracle irányú szinkronizációt sem. Erre a „visszirányú” szinkronizációra a „dobozos” termékeken túl két alternatív módszert is alkalmasnak tartunk, amelyeket igény esetén képesek vagyunk hozzáfejleszteni a külső komponensként implementált megoldáshoz.
1.2.1 A megoldás peremfeltétele Oracle oldalon A megoldás kialakítása során azt a peremfeltételt vettük alapul, hogy a Neptun rendszer felhasználói adatbázisában (Oracle) minden olyan változás esetén, amely az NIIF LDAP rendszerét is érinti, egy átmeneti (LDAP_LOG) táblába kerülnek ideiglenesen aggregálásra a felhasználói adatok, adatváltozások. A szinkronizáló alkalmazás ezt az átmeneti táblát olvassa, ezen tábla rekordjai tartalmazzák számára a Neptun oldali változást (change log) és a rekordok feldolgozása után eltávolítja az átmeneti táblából a rekordokat.
-5-
Neptun Oracle DB Neptun tábla 1. Neptun tábla 2. Neptun tábla n.
NIIF LDAP DB
LDAP_LOG tábla ldp_kulcs: 12 ldp_muvelet: I ldp_egyen_kulcs: alpha123 ldp_nev: Alpha User ldp_kar: BME ldp_szak: 9 9 9 88 8 7 ldp_statusz: A ldp_szuletesi_hely: Budapest ldp_szuletesi_datum: 19 8 2.. ldp_anyja_neve: Beta User ldp_szem_ig_szam: AB-C 12.. ldp_allando_lakcim: Buda... ldp_levelezesi_cim: Buda... ldp_felvett_targyak: 11;12;13 ldp_modositas_datum: 2004-..
-6-
Neptun -> NIIF Sync tool.
dn: uid=alpha123,ou=people,.. objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: niifPerson objectClass: niifEduPerson uid: alpha cn: Alpha User cn;lang-hu: User Alpha sn: User givenname: Alpha niifEduPersonFaculty: BME niifEduPersonMajor: 9 9 99 8 88 8 7 niifPersonActivityStatus: active .............................
2. A megvalósítás feltételei A megvalósítandó alkalmazás egy perl program lesz, amit periodikusán futtatva (cron job-ként) a szükséges frekvenciával képesek leszünk elvégezni a szükséges szinkronizációt. A perl program elvileg bármely olyan számítógépen képes futni, amelyen a következő feltételeknek eleget tesz: Megfelelő perl futtatókörnyezet rendelkezésre áll (5.6.1 vagy magasabb verzió) TCP/IP kapcsolaton keresztül eléri az LDAP szervert (alapértelmezetten a 389-es porton át) és az Oracle szervert (alapértelmezetten a 1521-es porton át) a perl futtatókörnyezet mellett telepítve lesznek egyéb perl modulok (DBI, DBD::Oracle, NET::LDAP, Convert::ASN1, Text::Unaccent, ConfigReader::Simple) a DBD::Oracle perl modul használatához szükséges a futtató számítógépre az Orcale client telepítése. Az alkalmazás futtatása ütemezetten történik, amit unix környezetben cron jobként történő futtatással érünk el. Amennyiben a platform nem unix (v. linux), a futtatás periodicitásáról más módon kell gondoskodni. Abban az esetben, ha a komponens egy olyan számítógépen kerül telepítésre, amely tűzfalon keresztül izolálva van vagy az Orcale, vagy az LDAP szerverektől, akkor a tűzfalon a megfelelő portot ki kell nyitni. Az Oracle irányú kapcsolódásra alapértelmezetten a 1521-es (TCP) portot használjuk, ami a szinkronizációs komponens esetében teljesen szabadon konfigurálható. Abban az esetben, ha a szerver oldali Oracle Listener (akár biztonsági megfontolásból) más porton fut, akkor ezt rugalmasan tudjuk követni. LDAP oldalon feltételezzük a 389-es port használatát, így amennyiben a komponens és az LDAP szerver között tűzfal van, ezt a portot szükséges megnyitni. Az előkészítő megbeszéléseken az NIIF és Neptun szakembereivel az a megegyezés született, hogy Oracle szinten egy, a megoldás számára hozzáférhető (írható, olvasható) táblába kerülnek rögzítésre a Neptun adatbázisában jelen szinkronizáció számára releváns változások. Ezen táblában a rendezés elve a timeStamp mező lesz, ezért mindenképpen szükséges szavatolni, hogy adott Neptun azonosítóhoz minden egyes timeStamp esetén csak egy rekord tartozhasson. A tábla primary kulcsa az ldp_kulcs mező, ami Oracle oldalon sequencerként funkcionál.
-7-
Neptun Oracle DB
NIIF LDAP DB
po TC rt P/ : IP 15 21
IP P/ 389 C T t: r po
Perl 5.6.1 futtatókörnyezet Perl modulok Oracle Client
● ● ●
Neptun -> NIIF (Oracle to LDAP) sync app.
-8-
3. A tényleges megvalósítás 3.1 Oracle -> LDAP adatmegfeleltetés A megvalósítandó alkalmazás működésének alapja, hogy az Oracle táblába (LDAP_LOG) minden esetben a peremfeltételek megfelelő adatok kerülnek beírásra a Neptun rendszerből. A tábla adatszerkezete a következő mezőket tartalmazza: NIIF Oracle tábla Mezőkód
Típus
Formátum
Megjegyzés
ldp_modositas_ datum
Date
YYYY-DD-MM HH24:MI:SS, 2004-0421 12:00:00
Oracle bejegyzés időpecsétje
ldp_kulcs
varchar2(15)
ldp_muvelet
char(1)
pl.: I
Művelet kódja (I – insert, U – update, D – delete)
ldp_nev
varchar2(61)
Kiss János
Név (vezetéknév keresztnév). A vezetéknév és a keresztnév “space”-el szeparált
ldp_kar
varchar2(60)
BME
Egyetemi kar megnevezése. Megengedett több kar egyidejű bejegyzése is, ebben az esetben “;”-vel szeparálva
ldp_szak
varchar2(4000)
VILL
Szak megnevezése. Megengedett több kar egyidejű bejegyzése is, ebben az esetben “;”-vel szeparálva
ldp_statusz
char(1)
pl.: A
Státusz jelzése. pl. A – aktv, N - inaktív
Budapest
Születési hely
ldp_szuletesi_he varchar2(30) ly
Oracle Primary Key
ldp_szuletesi_da varchar2(30) tum
19821225
ldp_anyja_neve
varchar2(60)
Nagy Anna
Anyja neve
ldp_szem_ig_sz am
varchar2(15)
AB-C 123456
Személyi azonosító jel (pl. személyi igazolvány száma)
ldp_allando_lakc varchar2(100) im
pl.: 1027 Budapest, Kapás u. 1.
Állandó lakcím
ldp_levelezesi_c varchar2(100) im
pl.: 1027 Budapest, Kapás u. 1.
Levelezési cím
ldp_felvett_targ yak
Mat, fiz, 0000002, abc123
Felvett tárgyak kódja (több tárgy esetén “;”-vel szeparálva)
varchar2(4000)
Születési dátum
-9-
NIIF Oracle tábla ldp_egyen_kulcs varchar2(15)
pl. alma1234
Neptun ID
Az alkalmazás az LDAP_LOG táblában az aktuális dátumnál korábban keletkezett bejegyzéseket keresi ki, és ezeket a bejegyzéseket a bejegyzés időpontja alapján növekvő sorrendben dolgozza fel. Az Oracle és az LDAP adatok esetében közvetlen megfeleltetést alkalmazunk az alábbiak szerint: ORACLE -> LDAP adatmegfeleltetés ORACLE
LDAP
ldp_egyen_kulcs
->
uid; niifUniqueID
ldp_nev
->
cn; cn-lang; sn; givenname
ldp_kar
->
niifEduPersonFaculty
ldp_szak
->
niifEduPersonMajor
ldp_statusz
->
niifPersonActivityStatus
ldp_szuletesi_hely
->
niifPersonCityOfBirth
ldp_szuletesi_datum
->
niifPersonDateOfBirth
ldp_anyja_neve
->
niifPersonMothersName
ldp_szem_ig_szam
->
niifPersonIdentityNumber
ldp_allando_lakcim
->
niifPersonResidentalAddress
ldp_levelezesi_cim
->
homePostalAddress
ldp_felvett_targyak
->
niifEduPersonAttendedCourse
Az Oracle művelet kódja (ldp_muvelet) alapján 3 csoportba soroljuk az eseményeket. “I” - insert “U” - update “D” - delete A direkt adatmegfeleltetésen túl LDAP oldalon szükséges néhány attribútum származtatása. Ezen attribútumok legtöbbje a SzIE-n működő levelezőrendszer (SunONE Messaging Server) működéséhez szükséges és a származtatást statikus módon lehet megtenni, azonban a mail attribútum esetében a származtatás
- 10 -
dinamikus és feltételhez kötött. Az attribútum származtatás a következő táblázat tartalmazza:
származtatott LDAP attribútumok Származás forrása
LDAP attribútum
Oracle-ben tárolt ldp_nev
->
cn;lang-hu;unaccent
Oracle-ben tárolt ldp_nev
->
givenName;lang-hu;unaccent
Oracle-ben tárolt ldp_nev
->
sn;lang-hu;unaccent
rendszer default érték (mailbox)
->
mailDeliveryOption
rendszer default érték (a SzIE esetében atlas.szie.hu)
->
mailHost
rendszer default érték (active)
->
inetUserStatus
rendszer default érték (active)
->
mailUserStatus
rendszer default érték (a SzIE esetében 26214400)
->
mailQuota
rendszer default érték (-1)
->
mailMsgQuota
rendszer default érték (hu)
->
preferredLanguage
Oracle-ben tárolt ldp_szuletesi_datum utolsó hat karaktere (évek első két karaktere levágva)
->
userPassword
dinamikus származtatás az Oracle lpd_nev mezőből
->
mail
Az LDAP mail attribútum származtatása jelentősen eltér az összes többi attribútumétól. Ennek az az okta, hogy az LDAP oldalon a mail attribútumnak egyedinek kell lennie, ugyanakkor a névből képezzük, ami már viszonylag csekély hallgatói létszám esetében is jelenthetne átfedéseket. Az azonos mail címeket kerülendő a mail cím genarálása során létrehozzuk annak idealizált változatát (a konvenció szerint vezetéknév.keresztnév1.keresztnév2. ... stb. formában), majd megviszgáljuk, hogy az így előállított idealizált mail cím szerepel e már a címtárban. Amennyiben nem szerepel, akkor az adott LDAP objektum ezt a mail címet kapja, amennyiben már szerepelt, akkor az egyediség biztosításához a mail cím végére egy számlálót illesztünk és így próbáljuk meg egyedivé tenni. A vizsgálatot ismételten elvégezzük egészen addig, amíg a számláló növelésével valóban egyedi mail cím alakul ki. A mail címek létrehozása esetében megkötésekkel kell élni. Igen fontos feltétel, hogy mail címet csak abban az esetben lehet „létrehozni”, ha az még nem volt definiálva
- 11 -
egy objektum esetében, egyébként (UPDATE, INITIALIZATION műveletek esetében) a meglévő mail attribútumon nem szabad változtatni.
3.2 Insert művelet Oracle insert művelet esetén megvizsgáljuk, hogy az LDAP címtárban létezik e már a vonatkozó bejegyzés. Amennyiben létezik, akkor ez hibát jelent, ezért logba írjuk az eseményt, és nem hozzuk létre az LDAP bejegyzést. Amennyiben nem található a kérdéses LDAP objektum, úgy létrehozzuk azt. A létrehozás során külön attribútumokra (sn, givenname) szükséges bontani az egyetlen Oracle name attribútumot (NAME), ezért azt a konvenciót alkalmazzuk, hogy a “space”-val szeparált név első elemét tekintjük vezetéknévnek (sn), az eredeti érték maradékát pedig keresztnévnek (givenname). “;” szeparátort keresünk a szak (FAC), a kar (DEP) és a felvett tárgyak (SC) Oracle oldali értékében, és amennyiben ezen szeparátorral értelmezett több eleműnek tekinthetőek, akkor külön attribútumként vesszük fel azokat az LDAP-ban. A sikeres LDAP objektum létrehozás tényét log file-ban rögzítjük. Az Oracle rekord feldolgozása után a rekordot az adatbázisból töröljük.
3.3 Update művelet Oracle update művelet esetén ellenőrizzük, hogy a módosítani kívánt LDAP objektum létezik e. Amennyiben nem létezik, akkor a hiba tényét log file-ba írjuk. Amennyiben létezik az objektum, akkor az Oracle rekordban megadott új attribútumokkal egészítjük ki az LDAP objektumot. Amennyiben a módosítandó attribútum az LDAP schema alapján “single valued”, az attribútum értékének átírása történik, amennyiben az attribútum a schema szerint “multi valued”, akkor a korábbi attribútumok – érték párokat töröljük és az újonnan megjelenteket adjuk hozzá az objektumhoz. Az elvégzett módosításokról a log file-ba bejegyzés készül. Az update rekord feldolgozását követően a rekord az Oracle táblából törlésre kerül.
- 12 -
3.4 Delete művelet Delete művelet esetén szintén ellenőrizzük, hogy létezik e az adott objektum az LDAP-ban. Amennyiben nem létezik, akkor hibaágra fut a program és loggolja ennek tényét. Amennyiben létezik az objektum, akkor a konfigurációs file-ban megadott attribútum értékét szintén ezen file-ban megadott értékűre változtatjuk. Például: Amennyiben a konfigurációs file paraméterei: ldap_delete = niifPersonActivityStatus ldap_delete_val = deleted értékűek, abban az esetben az niifPersonActivityStatus attribútum értékét deleted értékűre változtatjuk. A módosítás eredményéről bejegyzés készül a log file-ba. A módosítást követően a vonatkozó Oracle rekord törlésre kerül.
3.5 INITIALIZATION művelet Az INITIALIZATION művelet egy speciális „UPDATE”. Abban az esetben használatos, ha egy már létező LDAP objektum esetében Oracle oldalról INSERT műveleti kódot „kap” a szinkronizáció alkalmazás. Az INITIALIZATION művelet esetében gyakorlatilag teljesen hasonló műveleteket végez a komponens, mint update esetében, azonban a kód ezen pontján lehetőség lenne bizonyos attribútumok módosítását másképpen kezelni. Megjegyezzük, hogy az eredeti koncepció alapján a már meglévő LDAP objektumra vonatkozó INSERT művelet hibaként lett volna értelmezve, azonban új igényként jelentkezett a teljes LDAP adatbázis újratöltésének (inicializáció) lehetősége, amit úgy oldunk meg, hogy Oracle oldalon a teljes hallgató adatbázis INSERT műveletként kerül ismételten bele az LDAP_LOG táblába.
- 13 -
3.6 Kezdeti adatfeltöltés Az LDAP címtár kezdeti adatfeltöltése az Oracle oldalon már meglévő hallgatói adatokkal olyan módon történik meg, hogy a Neptun szakemberei egyszeri alkalommal egy kezdeti konszolidációt végeznek a meglévő és adatot tartalmazó Oracle táblákra. Ez az egyszeri lekérdezés az LDAP_LOG táblába minden meglévő hallgatói adatot mint egy újonnan létrehozott rekordot hoz létre „Insert” műveletként. Ezen egyszeri lekérdezés lefuttatása után lesz a rendszer üzemszerű működésre kész, hiszen ezen időponthoz képest mindenféle változtatás már későbbi időpecséttel kerül be a táblába. Ezen egyszeri adatfeltöltésről a korábbiakban egy NIIF – Neptun – Sun megbeszélésen született megállapodás. Hivatkozva az újonnan bevezetett INITIALIZATION műveletre, a kezdeti adatfeltöltést „menet közben” bármikor el lehet végezni a teljes LDAP adatbázis inicializációjával.
- 14 -
4. A szinkronizációs komponens működésének fázisai Működés részletes ismertetését egy konkrét példa alapján szemléltetjük. A példa esetében azzal a feltételezéssel élünk, hogy egy konkrét személy adatai a Neptun rendszerben rögzítésre kerülnek és ezen adatok „konszolidált formában” az LDAP_LOG táblában megjelennek (Insert művelet). Ezt követően a felhasználó személyes adataiban változás következik (Update művelet), majd a felhasználó törlésre kerül a Neptun rendszerben. A működés ismertetését az Oracle rekord mezőinek illetve az LDAP objektum attribútumainak ábrázolásán szemléltetjük. A képzeletbeli személy adatai: Név: Anyja neve: Születési hely: Születési dátum: Személyi ig. száma: Állandó lakcím: Levelezési cím: Kar: Szak: Felvett tárgyak Neptun kód: Hallgatói státusz:
Kiss János Nagy Anna Budapest 1982 december 25. AB-C 123456 1027 Budapest, Kapás u.1. 1027 Budapest, Kapás u.1. BME Villamosmérnöki Matematika, Fizika, Villamosságtan kj123456 aktív
4.1 Insert művelet Az insert művelet esetén a Neptun Oracle LDAP_LOG táblájába az alábbi rekord keletkezik: Oracle mező neve
Oracle mező értéke
ldp_egyen_kulcs
kj123456
ldp_nev
Kiss János
ldp_kap
BME123
ldp_szak
Vill1234
- 15 -
Oracle mező neve
Oracle mező értéke
ldp_statusz
A
ldp_szuletesi_hely
Budapest
ldp_szuletesi_datum
19821225
ldp_anyja_neve
Nagy Anna
ldp_szem_ig_szam
AB-C 123456
ldp_allando_lakcim
1027 Budapest, Kapás u.1.
ldp_levelezesi_cim
1027 Budapest, Kapás u.1.
ldp_felvett_targyak
Mat1234;Fiz3210;Vill9999
ldp_muvelet
I
ldp_modositas_datum
2003-09-01 10:20:30
ldp_kulcs
12
A szinkronizáló komponens a periodikus futás során feldolgozza az LDAP_LOG tábla rekordjait (az ldp_modositas_datum illetve az ldp_kulcs mezo, mint sequencer mezok által meghatározott sorrendben). A fenti rekord feldolgozása során az ldp_muvelet mező értéke alapján egy új LDAP objektumot hoz létre az alábbiak szerint: (az egyszerűsítés kedvéért azzal a feltételezéssel élünk, hogy az LDAP bejegyzés az ou=people,o=bme,o=niif suffix alatt kerül tárolásra) dn: uid=kj123456,ou=people,o=bme,o=niif objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: niifPerson objectClass: niifEduPerson cn: Janos Kiss cn;lang-hu: Kiss János sn: Kiss givenName: Janos niifEduPersonFaculty: BME123 niifEduPersonMajor: Vill1234 niifPersonActivityStatus: active niifPersonCityOfBirth: Budapest niifPersonDateOfBirth: 19821225 niifPersonMothersName: Nagy Anna niifPersonResidentalAddress: 1027 Budapest, Kapas u.1. homePostalAddress: 1027 Budapest, Kapas u.1. niifEduPersonAttendedCourse: Mat1234 niifEduPersonAttendedCourse: Fiz3210 niifEduPersonAttendedCourse: Vill9999 uid: kj123456 niifUniqueId: kj123456
- 16 -
niifPersonIdentityNumber: AB-C 123456
Az LDAP objektum létrehozása után az LDAP_LOG tábla vonatkozó rekordja törlésre kerül. Az alkalmazás a szinkronizációs folyamat során a loggolja, hogy milyen rekordokat (jelent esetben Insert rekordot a kj123456 felhasználóra) talált az Oracle-ben, loggolja, hogy sikeresen létrehozta az uid=kj123456,ou=people,o=bme,o=niif objektumot az LDAP-ban, illetve loggolja a rekord törlését az Oracle táblából.
4.2 Update művelet Az update művelet ismertetése során azzal a feltételezéssel élünk, hogy a hallgató személyi és hallgatói adataiban is változás következett be. A személyi adatok közül a személyi igazolvány száma, míg a hallgatói adatok közül a felvett tárgyak listája változott meg. Ebben az esetben az LDAP_ORACLE táblába a következő rekord kerül:
- 17 -
Oracle mező neve ldp_egyen_kulcs
Oracle mező értéke kj123456
ldp_nev ldp_kap ldp_szak ldp_statusz ldp_szuletesi_hely ldp_szuletesi_datum ldp_anyja_neve ldp_szem_ig_szam
987654AB
ldp_allando_lakcim ldp_levelezesi_cim ldp_felvett_targyak
Mat1234;Szab4444;Prog3333
uvelet
U
ldp_modositas_datum
2004-02-02 11:22:33
ldp_kulcs
A szinkronizációs alkalmazás a periodikus futás során feldolgozza a rekordot és a művelet kódja alapján (Update) módosítja az uid=kj123456,ou=people,o=bme,o=niif LDAP objektumot az alábbiak szerint:
dn: uid=kj123456,ou=people,o=bme,o=niif objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: niifPerson objectClass: niifEduPerson cn: Janos Kiss cn;lang-hu: Kiss János sn: Kiss givenName: Janos niifEduPersonFaculty: BME123 niifEduPersonMajor: Vill1234 niifPersonActivityStatus: active niifPersonCityOfBirth: Budapest niifPersonDateOfBirth: 19821225 niifPersonMothersName: Nagy Anna niifPersonResidentalAddress: 1027 Budapest, Kapas u.1. homePostalAddress: 1027 Budapest, Kapas u.1. niifEduPersonAttendedCourse: Mat1234 niifEduPersonAttendedCourse: Szab4444
- 18 -
niifEduPersonAttendedCourse: Prog3333 uid: kj123456 niifUniqueId: kj123456 niifPersonIdentityNumber: 987654AB
Az LDAP objektum módosítása után az LDAP_LOG tábla vonatkozó rekordja törlésre kerül. Az alkalmazás a szinkronizációs folyamat során a loggolja, hogy milyen rekordokat (jelent esetben Update rekordot a kj123456 felhasználóra) talált az Oracle-ben, loggolja, hogy sikeresen létrehozta az uid=kj123456,ou=people,o=bme,o=niif objektumot az LDAP-ban, illetve loggolja a rekord törlését az Oracle táblából.
4.3 Delete művelet A Neptun oldali delete művelet esetén az NIIF-el történt megállapodás alapján a felhasználó nem kerül törlésre az LDAP oldalon, csupán egy státusz attribútum (amely attribútum megnevezése és értéke egy külső konfigurációs állományban módosítható) értéke módosul. Jelen esetben azzal a feltételezéssel élünk, hogy törlés esetén LDAP oldalon az NIIfPersonActivityStatus attribútum értékét „active”-ról „deleted”-re változtatjuk. Törlés művelet esetében az LDAP_ORACLE táblába a következő rekord kerül:
- 19 -
Oracle mező neve ldp_egyen_kulcs
Oracle mező értéke kj123456
ldp_nev ldp_kap ldp_szak ldp_statusz ldp_szuletesi_hely ldp_szuletesi_datum ldp_anyja_neve ldp_szem_ig_szam ldp_allando_lakcim ldp_levelezesi_cim ldp_felvett_targyak uvelet
D
ldp_modositas_datum
2004-03-13 12:45:02
ldp_kulcs
13
A szinkronizációs alkalmazás a periodikus futás során feldolgozza a rekordot és a művelet kódja alapján (Delete) módosítja az uid=kj123456,ou=people,o=bme,o=niif LDAP objektumot az alábbiak szerint: (Fontos megjegyezni, hogy abban az esetben, ha a művelet kódja Delete, az LDAP_LOG tábla összes egyéb mezőjének értéke figyelmen kívül lesz hagyva!) dn: uid=kj123456,ou=people,o=bme,o=niif objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: niifPerson objectClass: niifEduPerson cn: Janos Kiss cn;lang-hu: Kiss János sn: Kiss givenName: Janos niifEduPersonFaculty: BME123 niifEduPersonMajor: Vill1234 niifPersonActivityStatus: deleted niifPersonCityOfBirth: Budapest niifPersonDateOfBirth: 19821225 niifPersonMothersName: Nagy Anna niifPersonResidentalAddress: 1027 Budapest, Kapas u.1. homePostalAddress: 1027 Budapest, Kapas u.1.
- 20 -
niifEduPersonAttendedCourse: Mat1234 niifEduPersonAttendedCourse: Szab4444 niifEduPersonAttendedCourse: Prog3333 uid: kj123456 niifUniqueId: kj123456 niifPersonIdentityNumber: 987654AB
Az LDAP objektum módosítása után az LDAP_LOG tábla vonatkozó rekordja törlésre kerül. Az alkalmazás a szinkronizációs folyamat során a loggolja, hogy milyen rekordokat (jelent esetben Delete rekordot a kj123456 felhasználóra) talált az Oracle-ben, loggolja, hogy sikeresen létrehozta az uid=kj123456,ou=people,o=bme,o=niif objektumot az LDAP-ban, illetve loggolja a rekord törlését az Oracle táblából.
- 21 -
5. Előzetes tesztek, becslések A megoldás teljesítményének teszteléséhez tesz környezetet építettünk fel. A teszt környezet szándékosan viszonylag kis teljesítményű berendezésekből állt, továbbá célunk volt az is, hogy mindhárom komponens (Oracle, LDAP, Sync tool.) külön gépre kerüljön, hogy így garantáljuk a hálózati környezet teljesítménycsökkentő hatását. A tesztben szereplő összes komponens 100 Mbit sebességű kapcsolt hálózaton lett összekötve. A konfiguráció a következő komponenseket tartalmazta: Oracle 9.0.1i RDBMS, Sun Netra T1 (1*500Mhz,512MB RAM), Solaris 9 SunONE Directory Server 5.1, Sun Ultra 10 (1*330Mhz,384MB RAM), Solaris 9 Oracle -> LDAP sync tool, Sun Netra V120 (1*550 Mhz, 512MB RAM), Solaris 9 A mérések során teszt adatbázisokat hoztunk létre 1000 illetve 10000 bejegyzéssel (művelettel). A mérési eredményeket a következő táblázat mutatja: 100 rekord
500 rekord
1000 rekord
Insert
8 másodperc
33 másodperc
1 perc 5 másodperc
Update
15 másodperc
1 perc 7 másodperc
2 perc 45 másodperc
Delete
3 másodperc
19 másodperc
41 másodperc
Természetesen a mérési eredmény igen sok olyan környezeti paramétertől függ, amelyekben a tényleges működés teljesen különbözni fog, azonban jó közelítéssel megállapítható belőle, hogy az előzetesen elvárt teljesítményt a koncepció igazolja, másrészt a feldolgozandó adat mennyiségével jó közelítéssel lineárisan növekszik a végrehajtás időigénye. Úgy gondoljuk, a mérési adatok is alátámasztják azt a várakozásunkat, hogy a komponens használata egyaránt alkalmas a nagy mennyiségű (egyszeri v. igen ritka) adatfeltöltésre és a napi (vagy akár sűrűbb órás, fél órás) periodicitású adatszinkronizációra.
- 22 -
6. Telepítés tervezett menete A pilot rendszer telepítésére a tervek szerint a gödöllői Szent István Egyetemen kerül sor. A telepítés során mind Oracle, mind LDAP oldalon teszt rendszerekhez tudunk kapcsolódni, így a pilot működés az éles rendszereket nem befolyásolja. A telepítés során első lépésben a szükséges kiegészítő perl modulokat illetve Oracle Client-et installáljuk (a perl modulokat forrásból kívánjuk lefordítani azon a gépen, amelyen az alkalmazás futni fog), majd ezt követően kerül telepítésre és konfigurálásra a szinkronizáló alkalmazás. A működés tesztelésére kezdetben manuálisan indítunk próbafuttatásokat olyan bemeneti adatokkal, amelyek a lehetőségekhez képest minden működési állapotot lépesek szimulálni (insert, update, delete, illetve a műveletek esetében eltérő mezőfeltöltések). A manuális tesztek során vizsgálni kívánjuk a hibás bemenő adatokra történő reakciót is. Sikeres manuális tesztek során kerülhet sor a program futásának ütemezett beállítására. Az elvégzendő tesztekről teszt és mérési jegyzőkönyv készül, ami részét képezi a megvalósítási dokumentációnak.
- 23 -
7. Az alkalmazás működésének egyszerűsített folyamatábrája
- 24 -
- 25 -
