Rendszerterv. verzió: 1.3

Átírás

1 Rendszerterv verzió: 1.3 Verziókövetés Verzió: Készítette: Leírás: Dátum: 1.0. Török Tamás Neptun -> NIIF LDAP szerverek közötti április 22. adatszinkronizációs megoldás 1.1 Török Tamás Kiegészítések: A rendszer célja; április 26. A tényleges megvalósítás fejezetekben. Új fejezet: A szinkronizáció komponens működésének fázisai. 1.2 Török Tamás Kiegészítés: Követelménylista április 28. részletezése; Új fejezet: a komponens kiválasztásának szempontjai; Kezdeti adatfeltöltés 1.3 Török Tamás Végleges változat. A SzIE-n elvégzett tesztek során történt módosításokkal kiegészítve június

2 Tartalomjegyzék 1. A rendszer célja A megvalósítandó rendszer kiválasztásának szempontjai Oracle triggerek használata Külső szinkronizáló komponens az Oracle és az LDAP között A kiválasztott megoldás A megoldás peremfeltétele Oracle oldalon A megvalósítás feltételei A tényleges megvalósítás Oracle -> LDAP adatmegfeleltetés Insert művelet Update művelet Delete művelet INITIALIZATION művelet Kezdeti adatfeltöltés A szinkronizációs komponens működésének fázisai Insert művelet Update művelet Delete művelet Előzetes tesztek, becslések Telepítés tervezett menete Az alkalmazás működésének egyszerűsített folyamatábrája

3 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 -> NIIF- LDAP 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 -

4 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: 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 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

5 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 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

6 Neptun Oracle DB NIIF LDAP DB Neptun tábla 1. Neptun tábla 2. Neptun tábla n. LDAP_LOG tábla ldp_kulcs: 12 ldp_muvelet: I ldp_egyen_kulcs: alpha123 ldp_nev: Alpha User ldp_kar: BME ldp_szak: ldp_statusz: A ldp_szuletesi_hely: Budapest ldp_szuletesi_datum: 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: 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: niifpersonactivitystatus: active

7 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

8 Neptun Oracle DB NIIF LDAP DB TCP/IP port: 1521 TCP/IP port: 389 Perl futtatókörnyezet Perl modulok Oracle Client Neptun -> NIIF (Oracle to LDAP) sync app

9 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, :00:00 Oracle bejegyzés időpecsétje ldp_kulcs varchar2(15) Oracle Primary Key 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 ldp_szuletesi_he ly ldp_szuletesi_da tum varchar2(30) Budapest Születési hely varchar2(30) Születési dátum ldp_anyja_neve varchar2(60) Nagy Anna Anyja neve ldp_szem_ig_sz am ldp_allando_lakc im ldp_levelezesi_c im ldp_felvett_targ yak varchar2(15) AB-C Személyi azonosító jel (pl. személyi igazolvány száma) varchar2(100) varchar2(100) pl.: 1027 Budapest, Kapás u. 1. pl.: 1027 Budapest, Kapás u. 1. varchar2(4000) Mat, fiz, , abc123 Állandó lakcím Levelezési cím Felvett tárgyak kódja (több tárgy esetén ; -vel szeparálva) - 9 -

10 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

11 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 ) -> 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) dinamikus származtatás az Oracle lpd_nev mezőből -> userpassword -> 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

12 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

13 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

14 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

15 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: Kiss János Anyja neve: Nagy Anna Születési hely: Budapest Születési dátum: 1982 december 25. Személyi ig. száma: AB-C Állandó lakcím: 1027 Budapest, Kapás u.1. Levelezési cím: 1027 Budapest, Kapás u.1. Kar: BME Szak: Villamosmérnöki Felvett tárgyak Matematika, Fizika, Villamosságtan Neptun kód: kj Hallgatói státusz: 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 ldp_egyen_kulcs ldp_nev ldp_kap ldp_szak kj Kiss János BME123 Vill1234 Oracle mező értéke

16 Oracle mező neve Oracle mező értéke ldp_statusz A ldp_szuletesi_hely Budapest ldp_szuletesi_datum ldp_anyja_neve Nagy Anna ldp_szem_ig_szam AB-C 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 :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: niifpersonmothersname: Nagy Anna niifpersonresidentaladdress: 1027 Budapest, Kapas u.1. homepostaladdress: 1027 Budapest, Kapas u.1. niifedupersonattendedcourse: Mat1234 niifedupersonattendedcourse: Fiz3210 niifedupersonattendedcourse: Vill9999 uid: kj niifuniqueid: kj

17 niifpersonidentitynumber: AB-C 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 kj 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:

18 Oracle mező neve Oracle mező értéke ldp_egyen_kulcs kj ldp_nev ldp_kap ldp_szak ldp_statusz ldp_szuletesi_hely ldp_szuletesi_datum ldp_anyja_neve ldp_szem_ig_szam AB ldp_allando_lakcim ldp_levelezesi_cim ldp_felvett_targyak Mat1234;Szab4444;Prog3333 uvelet U ldp_modositas_datum :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: niifpersonmothersname: Nagy Anna niifpersonresidentaladdress: 1027 Budapest, Kapas u.1. homepostaladdress: 1027 Budapest, Kapas u.1. niifedupersonattendedcourse: Mat1234 niifedupersonattendedcourse: Szab

19 niifedupersonattendedcourse: Prog3333 uid: kj niifuniqueid: kj niifpersonidentitynumber: AB 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 kj 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:

20 Oracle mező neve Oracle mező értéke ldp_egyen_kulcs kj 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 :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: niifpersonmothersname: Nagy Anna niifpersonresidentaladdress: 1027 Budapest, Kapas u.1. homepostaladdress: 1027 Budapest, Kapas u

21 niifedupersonattendedcourse: Mat1234 niifedupersonattendedcourse: Szab4444 niifedupersonattendedcourse: Prog3333 uid: kj niifuniqueid: kj niifpersonidentitynumber: AB 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 kj 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

22 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 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

23 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

24 7. Az alkalmazás működésének egyszerűsített folyamatábrája

25 - 25 -