kiss tamás verziÓcsere microsoft dynamics nav...
TRANSCRIPT
Budapesti Mőszaki- és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar
Elektronikai Technológia Tanszék
Kiss Tamás
VERZIÓCSERE MICROSOFT DYNAMICS NAV
VÁLLALATIRÁNYÍTÁSI RENDSZERBEN
KONZULENSEK
Baranyay Máté Dr. Szikora Béla
BUDAPEST, 2007.
HALLGATÓI NYILATKOZAT
Alulírott Kiss Tamás szigorló hallgató kijelentem, hogy ezt a diplomatervet meg
nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat
(szakirodalom, eszközök, stb.) használtam fel. Minden olyan részt, melyet szó
szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem,
egyértelmően, a forrás megadásával megjelöltem.
Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a
Budapesti Mőszaki- és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi
intézmény saját céljaira felhasználhatja.
Kelt: Budapest, 2007. május 18.
.................................................................... Kiss Tamás
Tartalomjegyzék
1. Bevezetés.............................................................................................................. 1
2. A Microsoft Dynamics NAV ERP – rendszer ..................................................... 2
2.1. ERP - rendszerek.......................................................................................... 2
2.2. Navision bevezetı ........................................................................................ 3
2.2.1. Rendszer-architektúra ..........................................................................4
2.2.2. Adatbázis–szerkezet............................................................................. 5
2.2.3. Fejlesztıi környezet, egyéni fejlesztések ............................................. 7
3. Verziócsere Navisionben ..................................................................................... 9
3.1. Alapfogalmak............................................................................................. 11
3.1.1. Definíciók........................................................................................... 11
3.1.2. A verziócserék típusai ........................................................................ 12
3.2. Folyamatmenedzsment............................................................................... 13
3.3. Az Upgrade Toolkit.................................................................................... 16
3.4. A verziócsere folyamata............................................................................. 17
3.4.1. Futtatható állományok frissítése ........................................................ 19
3.4.2. Objektumok frissítése......................................................................... 21
3.4.3. Adatkonverzió (migráció) .................................................................. 24
3.4.4. Funkcionális tesztelés.........................................................................27
4. Funkcionális tervezés......................................................................................... 29
4.1. Az objektum-frissítés megtervezése .......................................................... 29
4.1.1. A NDT használata .............................................................................. 30
4.1.2. Módosított objektumok azonosítása................................................... 31
4.1.3. Objektum-analízis ..............................................................................32
4.1.4. Az objektum-egyesítés elıkészítése................................................... 32
4.2. A migráció megtervezése........................................................................... 33
5. Implementáció.................................................................................................... 35
5.1. Objektum-frissítés...................................................................................... 35
5.1.1. Táblák frissítése ................................................................................. 37
5.1.2. Őrlapok frissítése ............................................................................... 39
5.1.3. Jelentések frissítése ............................................................................ 41
5.1.4. Adatportok frissítése ..........................................................................43
5.1.5. Programmodulok frissítése................................................................. 45
5.1.6. Az új testre szabott verzió elıállítása................................................. 46
5.2. Migrációs rutinok elkészítése..................................................................... 48
5.2.1. Elsı fázisú migrációs rutin................................................................. 48
5.2.2. Második fázisú migrációs rutin.......................................................... 52
5.3. A verziócsere végrehajtása......................................................................... 54
5.3.1. Az új verzió elıállítása....................................................................... 54
5.3.2. A verziócsere tervezése és végrehajtása ............................................ 59
6. Tesztelés............................................................................................................. 61
6.1. Teszteredmények........................................................................................ 61
7. Összefoglalás...................................................................................................... 63
Irodalomjegyzék......................................................................................................... 65
Melléklet .................................................................................................................... 67
Ábrajegyzék ............................................................................................................... 69
Táblázatok jegyzéke................................................................................................... 70
Rövidítésjegyzék ........................................................................................................ 70
1.
1. Bevezetés
Célom a Microsoft Dynamics NAV integrált vállalatirányítási rendszerben a
verziócsere folyamatának megvalósítása, az eljárás során felmerülı problémák
vizsgálata, valamint ezekre alkalmas megoldások keresése. Ismertetem az új verzió
objektumainak létrehozásakor elıkerülı komplikációkat, az implementált
programmodulok mőködését, illetve a funkcionális tesztelés eredményeit. Végül
kitérek vizsgálataim eredményeire, és javaslatokat teszek továbbfejlesztési
lehetıségekre.
Diplomaterv – feladatomban egy könyvelıiroda rendszerének verziócseréjét
kívánom megvalósítani. Egy vállalatirányítási rendszerben egy ilyen folyamat
elvégzése komoly elıkészítést és tervezést igényel, hiszen az új rendszer funkcióinak
beépítésén túlmenıen, a régi változat törzs- és tranzakciós adatainak megfelelı
áttöltésérıl is gondoskodni kell.
A 2. fejezetben a Microsoft Navision vállalatirányítási rendszerrıl adok egy
rövid áttekintést, majd a 3. fejezetben a verziócsere általános lépéseit ismertetem. Az
általam megtervezett mőködést a 4. fejezetben mutatom be, míg a konkrét
implementáció az 5. fejezetben kerül bemutatásra. Külön részletezve mutatom be a
kritikusabb programrészeket. A vizsgálatokban alkalmazott tesztkörnyezetet és az
eredményeket a 6. fejezetben ismertetem. A 7. fejezetben összefoglalást adok
munkámról, illetve a vizsgálatokból levont következtetéseimet fejtem ki.
2.
2. A Microsoft Dynamics NAV ERP – rendszer
Az alábbiakban ismertetem az ERP rendszerek általános definícióját, majd
egy rövid áttekintést adok a Microsoft Dynamics NAV integrált vállalatirányítási
rendszerrıl.
2.1. ERP - rendszerek
Az ERP (Enterprise Resource Planning – Integrált vállalatirányítási
rendszer) rendszerek [4] megjelenése a ’90-es évek elején nagymértékben hozzájárult
a termeléssel foglalkozó vállalatok vezetési módszereinek gyökeres átalakításához.
„Az integrált vállalatirányítási rendszer (ERP) elırejelzi és összhangban
tartja a keresletet és a szállítást. Eszközök egész vállalatra kiterjedı készlete,
amellyel elırejelzés, tervezés és ütemezés valósítható meg. Segítségével
• a vevıket és a szállítókat egy teljes körő ellátási láncba kapcsolhatjuk össze,
• bevált eljárásokat alkalmazhatunk a döntéshozatal során, és
• összehangolhatjuk az értékesítést, a marketinget, a termelıegységeket, a
logisztikát, a beszerzést, a pénzügyet, a termékfejlesztést, valamint a humán
erıforrást.” [4]
A standard integrált vállalatirányítási rendszerek alatt [14] olyan kész
szoftvereket értünk, amelyeket valamilyen vállalatmodell feltételezésével készítettek
el, és amelyek e szerint a választott vállalatmodell szerint mőködnek. Ez a
feltételezett vállalatmodell meghatározza a rendszert alkalmazni tudó vállalatok
körét. Egy standard rendszer mőködését nem lehet alapjaiban véve megváltoztatni,
azonban a bevezetés során, testre kell szabni a standard funkciókat. Ez azt jelenti,
hogy az alkalmazó vállalat sajátosságainak, egyedi igényeinek megfelelıen be kell
állítani a vállalatra jellemzı mőködési paramétereket. Ezen túlmenıen, definiálni kell
az üzleti folyamatok által használt adatszerkezeteket, és fel kell vinni a törzsadatokat.
3.
2.2. Navision bevezetı
A Microsoft Dynamics NAV egy olyan integrált vállalatirányítási rendszer,
amely a kis– és középvállalatok igényei [1] alapján készült. Manapság a világ
50 országában alkalmazzák, több mint 30 000 vállalatnál.
A szoftvert kifejlesztı dán céget a Microsoft Corporation 2002. júliusában
vásárolta meg. Ezzel a programcsomag a Microsoft Business Solutions család
szerves részévé vált. 2006. áprilisa óta a programcsomag Microsoft Dynamics NAV
néven található meg a piacon. „Az új márka fogja megvalósítani a Microsoft
korábban ’Project Green’ néven ismert kutatási és fejlesztési koncepciójában
felvázolt stratégiát, amelynek középpontjában a felhasználói igények kielégítése és a
munkafolyamatok optimalizálása áll. A Microsoft az alkalmazáscsomag igazi áttörést
jelentı fejlesztéseit két termék–bejelentési hullám keretében fogja a piacra
bevezetni” [2]. A Microsoft Dynamics termékcsalád három, korábban önállóan
létezı szoftvert foglal magában, ezek a Microsoft CRM (ügyfélkapcsolat–kezelés), a
Microsoft Axapta (nagyvállalatok részére ajánlott integrált vállalatirányítási
rendszer), valamint a Microsoft Navision.
Integrált vállalatirányítási rendszerrıl lévén szó, a vállalat összes
adatfeldolgozását megvalósító, egységes információs rendszerrıl beszélünk, amely a
pénzügy, a termelésirányítás, a logisztika, az ügyfélkapcsolat–kezelés, a szerviz–
tevékenységek kezelése, az elektronikus kereskedelem, valamint az üzleti
adatelemzés területeit öleli fel.
Miután egy adott cég vezetése, menedzsmentje az üzleti forgalom, valamint a
vállalat mérete alapján indokoltnak találja egy vállalatirányítási rendszer bevezetését,
a Microsoft Dynamics NAV jó választásnak bizonyulhat, a következı elınyei miatt.
• A rendszert a KKV (jellemzıen 50-1000 alkalmazottal rendelkezı kis– és
középvállalatok) igényei szerint fejleszti a Microsoft. A rendszer nyitott
architektúrája lehetıvé teszi, hogy a hivatalos megoldáspartnerek a standard
rendszert a vállalat üzletmenetéhez igazítsák. A Navision–partnerek az üzleti
logika teljes forráskódjához hozzáférnek. A partner a vállalattal
együttmőködve, feltérképezi az üzleti folyamatokat, és megtervezi az ügyfél
igényeit legjobban kielégítı megoldást. A rendszer moduláris felépítésének
4.
köszönhetıen, folyamatosan bıvíthetı, a vállalat növekedésével
összhangban.
• A Microsoft együtt fejleszti a vállalatirányítási rendszereit a Microsoft Office
termékcsaláddal, valamint operációs rendszereivel annak érdekében, hogy
problémamentes legyen az együttmőködés az alkalmazások között. További
elınye ennek a megoldásnak, hogy az új felhasználók könnyebben el tudják
sajátítani az új szoftver használatát, a „szabványos” (Windowsban
megszokott) funkcióknak köszönhetıen.
2.2.1. Rendszer-architektúra
A Navision felépítését tekintve, kétrétegő alkalmazás: egy adatbázis–
kezelıbıl (DBMS - Database Management System), valamint egy grafikus
felhasználói interfészbıl (GUI - Graphical User Interface) épül fel. [5] A rendszer az
alkalmazási környezettıl függıen, telepíthetı egy felhasználós („Single user”,
Stand-alone mód), illetve több felhasználós („Multi user” mód) változatban is. Az
elsıként említett megvalósításnál mindkét réteg ugyanazon a számítógépen (a kliens
gépen) helyezkedik el, tehát nincs szükség külön szerverre. Ezt a kialakítást
fejlesztıi–tesztelıi környezet kialakításakor célszerő alkalmazni.
A több felhasználós változat mőködése a kliens–szerver architektúrán alapul.
Ekkor a szerveren elhelyezkedı adatbázist a kliensek hálózaton keresztül érhetik el.
A Navision által használt adatbázis kétféle kialakítású lehet. Használhatjuk a
Navision natív adatbázis-kezelıjét (ekkor a kliensek és a szerver közti
kommunikáció TCP/IP vagy NetBIOS protokollon keresztül megy végbe), vagy
választhatjuk a Microsoft SQL Servert is. Ez utóbbi esetben, a kliensek és a szerver
között ODBC (Open Database Connenctivity) kapcsolat épül fel.
A kliens felelıs a felhasználói interfész kezeléséért, valamint az üzleti logika
végrehajtásáért. Mőködése során, a kliens kiolvassa az adatbázisból és lefuttatja a
szükséges objektumokat.
A szerver szabályozza az egyszerre kiszolgálható felhasználók számát, és
felügyeli az összes bejelentkezett felhasználó olvasási-írási tranzakcióját. Ezen kívül,
gyorsítótárban tárolja az adatokat, továbbá az érvényben lévı zárolásoknak
megfelelıen, szabályozza az adatokhoz való hozzáférést.
5.
A Navision Alkalmazás Kiszolgáló (NAS - Navision Application Server)
lehetıséget biztosít a rendszer más alkalmazásokkal való összekapcsolására [3],
mivel az adatbázis-kezelı szempontjából kliensként látszik, míg a külsı
szolgáltatások felé szerver képet mutat. Ily módon össze tudjuk kapcsolni a Navision
ügyfélprogramot egy külsı szolgáltatással (például, Microsoft BizTalk Serverrel).
Az architektúra felépítését [17] a 2.2.1. ábra szemlélteti.
2.2.1. ábra A Navision felépítése
2.2.2. Adatbázis–szerkezet
A Navision adatbázis-szerkezete eltér a más rendszerekben alkalmazott
„hagyományos” adatbázis–fogalomtól. Tekintsük az adatbázis fizikai felépítését
illusztráló 2.2.2. ábrát. Látható, hogy az adatbázisban a vállalat adatfeldolgozásaival
kapcsolatos tranzakciós adatokon túlmenıen, az adatokat kezelı, módosító
alkalmazásobjektumok is megtalálhatóak. Az alkalmazásobjektumok hasonlóak a
hagyományos számviteli rendszerek fizikai fájljaihoz, mindegyiknek megvan a maga
sajátos célja.
2.2.2. ábra Az adatbázis fizikai szerkezete
Adatbázis
Közös vállalati adatok
Objektum definíciók (táblák, őrlapok, jelentések,
adatportok, programmodulok)
„B” vállalat
Tábla adat
„A” vállalat
Tábla adat
Disztribúció CRM e-Business
Integrált Fejlesztıi Környezet (C/SIDE)
Alkalmazás -objektumok
Adatbázis (Navision Szerver vagy MS SQL Szerver)
Grafikus Felhasználói Felület (GUI)
Pénzügy / számvitel
Termelés- irányítás
6.
Az „átlagos” felhasználók [6] nem foglalkoznak azzal, hogy fizikailag
pontosan hol tárolódnak az adatok, ezért a C/SIDE (Client/Server Integrated
Development Environment) adatbázis-rendszer egy absztrakt adatmodellt nyújt,
amely elfedi az adattárolás speciális részleteit. Ez az adatmodell könnyebben érthetı
logikai fogalmakat használ (úgy, mint objektumok, ezek tulajdonságai valamint a
köztük fennálló kapcsolatok).
Ezen megközelítés miatt meg kell különböztetnünk fizikai és logikai
adatbázist. Ha logikai adatbázisról beszélünk, akkor csak az adatstruktúrára
fókuszálunk, és nem foglalkozunk azzal a kérdéssel, hogy pontosan hogyan
valósították meg a struktúrákat és kapcsolatokat. A logikai adatbázis felépítése,
valamint a keresési útvonalak implementálásának kérdései a fizikai adatbázisok
fogalomkörébe tartoznak.
Az adatokhoz történı hozzáférést egy jól definiált logikai modell teszi
lehetıvé. Az adatbázis logikai struktúráját a 2.2.3. ábra szemlélteti.
2.2.3. ábra Az adatbázis logikai szerkezete
A fenti ábrán jól látható, hogy a C/SIDE adatbázisban a mezı jelenti a
legkisebb logikai szerkezetet. Egy mezı egységnyi mennyiségő, meghatározott
típusú információ – például egy név, vagy egy összeg – tárolására képes, ezért egy
mezı önmagában még semmire sem használható. Sokkal rugalmasabb és
rendezettebb „információ-hordozóhoz” jutunk, ha tetszıleges számú mezıbıl egy
rekordot képzünk, amely az összetartozó mezıket egységbe foglalja. Egy rekord
egyetlen adatbázis-bejegyzés tárolására szolgál. A rekordok táblákban
helyezkednek el, melyek úgy képzelhetık el, mint egy N×M–es mátrix, melyben az
N darab sor mindegyike egy-egy rekordot ír le, míg az M darab oszlop mindegyike
egy-egy mezıt határoz meg a rekordon belül. A táblákat vállalatokba rendezzük,
ezek alkotják a legnagyobb logikai struktúrát a C/SIDE adatbázisban. Egy vállalatra
Mezı Rekord Tábla Vállalat Adatbázis
7.
úgy tekinthetünk, mint egy „al–adatbázisra”, amely a nagymérető adatrészeket
elkülöníti és csoportosítja.
2.2.3. Fejlesztıi környezet, egyéni fejlesztések
A C/SIDE integrált grafikus fejlesztıi környezete objektum–bázisú. Ez
annyiban különbözik egy objektum–orientált nyelvtıl, hogy a fejlesztı nem tud
benne tetszılegesen új objektumtípusokat létrehozni, hanem csak a C/SIDE–ban
elıre definiált típusokat használhatja. Ez a megközelítés talán kissé furcsa, azonban
figyelembe kell venni, hogy a munka gyorsabbá és hatékonyabbá válhat azáltal, ha a
fejlesztı tisztában van azzal, hogy milyen eszközkészlet áll rendelkezésére.
Az adatbázisban elhelyezkedı alkalmazásobjektumokat az
Objektumtervezıben (Object Designer, ld. 2.2.4. ábra) tekinthetjük meg, továbbá új
objektumot is itt tudunk felvenni. A C/SIDE-ban a meglévı objektumok
módosításához, valamint új objektumok létrehozásához fejlesztıi licenc szükséges.
Valamennyi alkalmazásobjektum típusonként egyedi azonosító számmal (ID
number) rendelkezik. Az adatbázis objektumai kiexportálhatóak, és megfelelı
jogosultság birtokában, beépíthetık más rendszerek objektumai közé.
2.2.4. ábra Az Objektumtervezı
Az adatbázis-kezelı szerves részét képezi az eseményvezérelt, negyedik
generációs C/AL (Client Application Language) fejlesztıi környezet. Segítségével a
számviteli és ügyviteli funkciókon kívül (például jelentéskészítés, őrlapkészítés)
konkrét ügyféligényeket kielégítı megoldások és teljesen új funkcionális területek
8.
fejleszthetık ki. Miután eseményvezérelt nyelvrıl van szó, minden objektumtípushoz
típusfüggı triggerek tartoznak. A trigger a tárolt eljárások egy olyan speciális
formája, amely valamilyen azonosítható esemény bekövetkezésekor automatikusan
végrehajtódik. Gyakran a triggerek segítségével biztosítják a táblák közti hivatkozási
integritás megırzését.
A Navision fejlesztıi környezete meglehetısen kevés támogatást nyújt az
alkalmazás–fejlesztıknek. Nem mondható modern IDE (Integrated Development
Environment)–nek, hiszen a forráskód szerkesztése egy egyszerő, belsı
szövegszerkesztıben történik. Nem állnak rendelkezésre olyan, a fejlesztıi munkát
megkönnyítı „kényelmi szolgáltatások” (például syntax highlighting,
függvénydefiníció megjelenítése szerkesztés közben), amelyeket a manapság
használatos, ismertebb fejlesztıi környezetek nyújtanak.
A programozási nyelv szintaxisa, jellegzetességei a Pascal nyelvre
hasonlítanak a leginkább. Habár a nyelv nem tesz különbséget a kis– és nagybetők
között (non case-sensitive), léteznek bizonyos ajánlások, melyek betartásával
áttekinthetıbbé, érthetıbbé tehetjük a forrásainkat. Az ajánlás szerint a C/AL
utasítások, beépített függvények csupa nagybetőkkel írandók, míg a felhasználó által
definiált változó- és függvénynevekben egyaránt használható kis– és nagybető.
A változókat a használat elıtt deklarálni kell, meg kell határozni a típusukat.
A változók láthatósága lokális (például csak egy függvényen belül használható),
vagy globális lehet.
„Hétköznapi” értelemben vett programokat [9] a programmodul (CodeUnit)
objektumtípusban hozhatunk létre. Csak ennél az objektumtípusnál létezik az a
speciális trigger (OnRun) , mely a körülményektıl függetlenül, minden híváskor lefut.
A többi objektumtípus megfelelı triggerébe beágyazott kód, csak a feltételek
teljesülése esetén hajtódik végre.
9.
3. Verziócsere Navisionben
Egy verzióváltást követıen [8], az alkalmazást használó vállalat erıteljes, új
funkcionalitásra tehet szert, amely elısegítheti az üzleti növekedését. A tökéletesített
funkcionalitás, az új jellemzık és a továbbfejlesztett képességek elınyeit
kihasználva, a vállalatok csökkenthetik költségeiket, és az üzleti folyamataikat
naprakészen tarthatják.
Mindezen lehetıségek ellenére, az ügyfelek gyakran úgy vélik, hogy egy
verzióváltás egyáltalán nem indokolt, hiszen ez egy nagyon költséges és idıigényes
eljárás. Valójában, az ajánlások követésével, a verziócserét végrehajtó Navision–
partner az üzletmenet minimális mértékő megszakításával hajthatja végre a
folyamatot. Általánosságban elmondható, hogy minél tovább halogatja az ügyfél a
verziócserét, annál tovább fog tartani, és ebbıl következıen, egyre többe fog kerülni.
Ezzel szemben, a legújabb funkcionalitások folyamatos beépítésével, azonnal
megfigyelhetı a vállalat termelékenységének növekedése, így a cég
versenyképessége tovább növelhetı.
Számos elınnyel jár mind a Navision–partner, mind az ügyfél számára, ha
folyamatosan frissíti rendszerét.
A partnernek ekkor kevesebb verzióval kell egyszerre foglalkoznia, és a
fejlesztıknek csupán a legújabb verziókra kell koncentrálniuk. Ritkábban léphetnek
fel problémák, a különbözı verziók eltérı adottságai miatt. Nagyobb figyelmet
szentelhetnek a saját fejlesztéső add-onok tökéletesítésére, és verziócsere (upgrade)–
projektek végrehajtására. Egy verziócsere elınyei a partner szempontjából:
• növelhetı az ügyfél elégedettsége,
• növelhetı a partner versenyképessége,
• egyúttal megadja a hibajavítások telepítésének lehetıségét,
• lehetıséget teremt saját add-onok implementálására,
• csökkenti a supportra nehezedı terhelést.
Az ügyfélnek is elınyös, ha rendszerét folyamatosan frissíti, mivel azonnal
érezhetı az új funkcionalitás valamennyi elınye, továbbá így megkíméli magát a
késıbbi extra kiadásoktól.
10.
A verziócserével:
• az üzleti folyamatok naprakészen tarthatók, az ügyfél változó igényei szerint,
• lehetıvé válik, hogy a legújabb verzióba beépített standard funkcionalitással
helyettesítse a költséges testre szabott verziót,
• megoldódnak a lokalizációs problémák (hiszen ezek csak a legújabb
verziókban kerülnek implementálásra),
• lehetıvé válik a Microsoft termékek szélesebb körő integrációja.
Érdemes megjegyezni, hogy a verziócsere nem része a Navision - partner
által nyújtott supportnak, a megvalósításhoz külön szerzıdést kell kötni az ügyféllel.
Az észak-amerikai és az európai kis- és középvállalatok körében, egy
2006 novemberében elvégzett felmérés [15] során, arra a kérdésre kerestek választ,
hogy a vállalatok „Mely ERP - szállító szoftverébe kívánnak befektetni?”. A
felmérés eredményét a 2.2.5. ábra foglalja össze.
3%
8%
9%
18%
47%
0%
8%
8%
12%
27%
SSA GlobalTechnologies
The SageGroup
SAP
Oracle
Microsoft
Major upgrade*
Minor upgrade**
2.2.5. ábra Verziócserére vonatkozó befektetési hajlandóság felmérésének eredménye
(Forrás: Forrester Research)
A fenti ábrán látható, hogy a kis-és középvállalatok körében a Microsoft
vezeti a verziócserére vonatkozó befektetési hajlandóság listáját. Major-upgradet (*)
összesen 51 döntéshozó, míg Minor-upgradet (**) összesen 102 döntéshozó tervez a
11.
közeljövıben megvalósítani (a felmérés során 1 335 vállalatot kérdeztek meg, és a
kérdıívekben több választ is meg lehetett jelölni).
3.1. Alapfogalmak
Az alábbiakban megadom a verziócsere kapcsán felmerülı alapvetı
fogalmak, definíciók [7] magyarázatát.
3.1.1. Definíciók
• Végrehajtható állományok (Executables): az operációs rendszer felügyelete
alatt futó kliens- és szerver-alkalmazások, valamint a C/ODBC meghajtók
tartoznak ebbe a körbe. A fájlrendszerben „.exe” vagy „.dll” kiterjesztéssel
rendelkeznek.
• Alkalmazás (Application): a kliensen futó Végrehajtható állományok (a
C/SIDE-alkalmazások). Egy alkalmazás objektumokból épül fel.
• Funkcionális terület (Functional area): az Alkalmazás azon jelentısebb
részei, melyek elérhetıek a Fımenübıl (például a Fıkönyvi tétel vagy a
Raktárkészlet).
• Granula (Granule): az alapalkalmazást kiegészítı objektumok halmaza,
melyeket külön árusítanak (add–onként is nevezik).
• Feature: az alkalmazás részeit képzı funkciókészletek (például, az
alkalmazáson belül a „Fıkönyvi könyvelés” egy funkcionális terület, a
„Számlaséma” egy Granula, míg a „Dátum-összehasonlítás” a számlasémák
egy Feature-e).
• Hiba (Bug): a program egy olyan része, amely nem az elvárás szerint
mőködik.
• Képességbıvítés (Enhancement): egy meglévı feature továbbfejlesztése
(például könnyebb használhatóság, vagy gyorsabb mőködés megvalósítása).
12.
3.1.2. A verziócserék típusai
Az alábbiakban egy rövid leírást adok a különbözı típusú verziócserékrıl, az
egyszerően telepíthetıtıl haladva a bonyolultabbak felé.
• Javítás (Improvement): általában kisebb hibák javítását (bug fixes), esetleg
néhány új featuret vagy feature–képességbıvítést tartalmaz. Egy Javítás során
végrehajtható állományok cseréjére rendszerint nincs szükség. Ha a csomag
telepítése után adatkonverzióra is szükség lenne, a hiba által okozott
valamennyi adatsérülés egyszerő eljárások futtatásával kijavítható.
Egy Javítás megjelenésekor mérlegelnie kell a Partnernek, hogy a csomagot
szükséges–e azonnal telepítenie az ügyfélnél, vagy ezt elhalaszthatja a
következı, valóban lényeges Javítás telepítéséig.
• Szerviz csomag (Service Pack): magában foglalja az összes korábban kiadott
Javítást, de további hibajavításokat, esetleg kisebb feature–
képességbıvítéseket is tartalmazhat. Egy Szerviz csomag telepítése során,
esetenként a Végrehajtható állományokat is le kell cserélni. Ha a változások
maguk után vonják az adatkonverziót is, a csomaggal közreadott
programmodulok használhatók a hiba által okozott sérülések javítására.
Hacsak nem ítéli teljesen feleslegesnek a Navision partner - az adott ügyfél
szempontjából - a csomag telepítését, erısen ajánlott valamennyi Szerviz
csomag installálása.
• Minor Release: megtalálható benne az összes korábbi Javítás és Szerviz
csomag. Ezeken túlmenıen, újabb hibajavításokat, feature–
képességbıvítéseket, és új végrehajtható állományokat is tartalmazhat. Egy
Minor Releasezel gyakran jelenik meg egy vagy több, teljesen új feature is,
emiatt, kisebb mértékő adatkonverzióra is szükség lehet.
Egy Minor Release telepítéséhez külön Upgrade - Szerzıdést kell kötni az
ügyféllel.
• Major Release: az összes korábbi Javítást, Szerviz csomagot, Minor Releaset
is magában foglalja. További hibajavításokat, kisebb-nagyobb featureöket, új
végrehajtható állományokat tartalmazhat. Általában, egy Major Release az
alkalmazás funkcionalitásának nagymértékő módosítását jelenti, mely során
13.
az alkalmazás mőködésének módja gyökeresen megváltozik. Emiatt az
adatkonverziót mindig el kell végezni egy Major Release-típusú verziócsere
kapcsán. Ez a legkomplexebb típus, így alaposan meg kell tervezni ezt a
folyamatot.
A Névjegy ablakban (ld. 3.1.1. ábra) tekinthetjük meg az Alkalmazás és a
Végrehajtható állományok verziószámát. A zárójelben található szám a
Végrehajtható állományok verziójára utal, míg a másik szám az Alkalmazás verzióját
jelöli. A Névjegy ablakban olvasható verziószám több részbıl épül fel: az elsı
helyen az országkód áll, ezt követi a Major Release száma, majd közvetlenül
mögötte áll a Minor Release száma. A verziószám végén a Szerviz csomag és a
Javítás száma található. Általában a Szerviz csomag számát betővel jelölik, míg a
Javítás számát többnyire nem szokták megjeleníteni.
Az egyes objektumok pontos verziószámát az Objektumtervezıben lehet
megtekinteni.
3.1.1. ábra A Névjegy ablak
3.2. Folyamatmenedzsment
A verziócsere folyamatát körültekintıen meg kell tervezni. Az ajánlás [8] a
programfejlesztéssel megegyezı bonyolultságú feladatként említi ezt a
tevékenységet. A verzióváltást egyfajta implementációs projektként fogja fel, hiszen
ugyanazok a szerepek, valamint ugyanazok a fázisok tartoznak ide, mint egy
fejlesztıi projekthez. Az ajánlás szerint, a projekt–szervezetben a következı
14.
szerepeknek mindenképpen meg kell jelenniük, a folyamat sikerességének biztosítása
érdekében.
• Program menedzser (Program manager): feladata a projekt határain belül, az
elérendı célok összehangolása. Ez a szerep négy fı funkciót foglal magában:
projekt–menedzsmentet, megoldás architektúrát (solution architecture),
minıségbiztosítást, és adminisztratív szolgáltatásokat. Ezt a szerepet
tipikusan egy projektvezetı vagy egy ügyféloldali kapcsolattal is rendelkezı
üzleti tanácsadó tölti be, akinek feladata a termék leszállításának garantálása.
A szerepet betöltı tagnak, jelen kell lennie az ügyfélnél a projekt teljes
idıtartama alatt.
• A Termék menedzser (Product manager) feladata az ügyfél elégedettségének
biztosítása. Ez a szerep is négy funkcionális területet fed le: marketing, üzleti
érték, ügyfél képviselet, és terméktervezés. Egy verziócsere során, ezt a
szerepet gyakran egy üzletkötı tölti be, akinek elsıdleges feladata az ügyfél
elégedettségének biztosítása.
• Fejlesztı (Developer): feladata a termékspecifikáció megvalósítása. Ez a
szerep az alábbi területeket fedi le: techológiai tanácsadás, az architektúra és
a design implementálása, valamint alkalmazás–, és infrastruktúra–fejlesztés.
• Tesztelı (Tester): ennek a szerepnek a fı célja a termékre vonatkozó
minıségi követelmények meghatározását követıen, az elkészült termék
elfogadása. Ez a szerep az alábbi területeket fedi le: teszttervezés, teszt–
mérnökség, és teszt riportolás.
• Felhasználó oldali képviselı (User Experience): célja a felhasználói
hatékonyság növelése. A képviselık a tréningeken és a dokumentációk
elıállításában mőködnek közre. Ez a szerep a hozzáférhetıség,
internacionalizáció, technikai kommunikáció, tréning, használhatóság, és a
grafikus design területeit fedi le.
• Bevezetés menedzsment (Release Management): célja a bevezetés és a normál
mőködés problémamentességének biztosítása. Ennek a szerepnek négy fı
feladata van: infrastruktúra–, support–, mőködés–, és termékkiadás–
menedzselés. Egy verzióváltás során ezt a szerepet tipikusan a partner
szervezet tölti be.
15.
Nem feltétlenül kell minden szerepet más személynek betöltetnie, egy
résztvevı több szerepet is elláthat. Ugyanakkor, néhány kombináció nem ajánlatos,
például nem szerencsés, ha a fejlesztı egyben a tesztelı szerepét is betölti. Az ajánlás
megemlíti, hogy elınyre tehetünk szert akkor, ha ugyanazok a projekt-tagok vesznek
részt a verziócsere folyamatában, mint akik az implementációs projektben is részt
vettek.
A verziócsere fı fázisait és a fázisokat lezáró mérföldköveket a 3.2.1. ábra
mutatja be.
a) A Vizionálás (Envisioning) fázisában magas szintő követelmény-analízist
hajtunk végre, ez a fázis a projekt egyik legfontosabb része. Megfelelı
tervezéssel, az üzleti folyamatok megfelelı azonosításával, sokkal nagyobb
esélyünk van a projekt sikerességére. Nagyon fontos ennél a szakasznál a
verziócsere sikerkritériumainak pontos azonosítása, definiálása, valamint
ezen kritériumok elfogadtatása az ügyféllel. A Vizionálás fázisát fıként a
Termék- vagy Program-menedzser vezeti.
A fázist lezáró mérföldkı a Scope elfogadása, amely során az ügyféllel
történt egyeztetéseket követıen, rögzítésre kerülnek a projekt során
megvalósítandó feladatok.
b) A Tervezés (Planning) fázisban, a kockázatok azonosításával és tervezésével
elkerülhetjük a jövıbeli problémákat. Ebben a fázisban készül el a Fejlesztési
terv, a Tesztelési terv, valamint a Bevezetési terv. Ezt a fázist rendszerint a
Program Manager vezeti. Ezt a fázist akkor zárhatjuk le, ha az ügyfél aláírta
és elfogadta a projekt terveket.
c) A Fejlesztés (Development) során a régi verzió testre szabott objektumait
egybeolvasztjuk az új standard verzió objektumaival. A fázis kulcsszereplıje
a fejlesztı. Az elızı fázis feltáró analízisébıl kiindulva, a testre szabást
azokkal az objektumokkal kezdhetjük, amelyekre szükségünk lesz az új
verzióban. Ha nagymérető projektrıl van szó, az összes érintett terület
lefedéséhez szakterületi fejlesztık bevonására is szükség lehet.
A Fejlesztés fázisát a Scopeban megfogalmazott követelmények
teljesítésével, végrehajtásával zárjuk le.
16.
d) A Fejlesztéshez szorosan kapcsolódik a Stabilizálás (Stabilizing) fázisa,
melyben a létrehozott új objektumok tesztelésére, és az elıforduló hibák
javítására kerül sor. Ebben a fázisban kerülnek pontosan dokumentálásra a
végrehajtott változások, módosítások.
A fázist a Végleges változat elfogadásával zárhatjuk le.
e) Végül, a Bevezetés (Deployment) során átadásra kerül az új aktuális
implementáció. Ezt a fázist gyakran nevezik „rendszer-indításnak” is.
3.2.1. ábra Az upgrade projekt fázisai, mérföldkövei
3.3. Az Upgrade Toolkit
Az Upgrade Toolkit [10] olyan eszközök és eljárások halmazából áll, melyek
segítségével elvégezhetjük a verziócserét. A csomag általában több korábbi
verzióhoz tartalmaz olyan segédeszközöket, melyek segítséget nyújtanak a
verzióváltás megvalósításához. Attól függıen, hogy éppen melyik verzióról akarunk
áttérni az új változatra, a szükséges eszközök és eljárások különböznek egymástól.
Ha a Navision 4.0-ás verziójáról a Microsoft SQL-szervert használó
Navision-változatra szeretnénk áttérni, a szükséges konverziós eszközöket szintén
megtalálhatjuk ebben a csomagban. Egy korábbi Navision verzióról azonban nem
lehet egy lépésben áttérni az SQL-szerveres változatra, elıtte át kell migrálni az
Scope elfogadva
Projekt tervek elfogadva
Scope teljesítve
Bevezetés teljesítve
Végleges változat
elfogadva
17.
adatbázist natív Navision 4.0-ra, majd csak ezt követıen térhetünk át az
SQL-szervert használó változatra.
Az Upgrade Toolkit fıbb részei:
• Adat konverziós eszközök: a verziócsere során, az objektumok cseréjét
követıen, az adatbázisban tárolt adatokat is át kell alakítani. Ezt a migrációs
lépést a csomagban található, adat konverziós eszközök [12] hajtják végre, a
standard objektumokon. Amennyiben a régi változatban léteznek testre
szabott objektumot, akkor a migrációt megvalósító konverziós eszközöket
nekünk kell elkészíteni.
• Dokumentáció: a verziócsere javasolt végrehajtási menetét ismerteti.
• Feature - képességbıvítések dokumentációja (Feature Enhancements
Documents): ez a dokumentáció a Navision 4.0-ás verziójában megjelenı új
featureökrıl tartalmaz részletes áttekintést, a korábbi verziókkal
összehasonlítva. Ha a verziócsere során valamilyen ütközés lépne fel az új
standard objektum és a saját testre szabott verzió objektuma között, e
dokumentumok segítségével újra implementálhatjuk a Microsoft által
végrehajtott fejlesztéseket.
3.4. A verziócsere folyamata
Egy verziócsere során [13] a régi verziójú alkalmazásobjektumokat és / vagy
futtatható állományokat új verzióra cseréljük.
A 3.2. fejezetben is szóba került már, hogy a verziócsere folyamatát
körültekintıen meg kell tervezni. Ennek a tervezésnek már a rendszer bevezetésekor
[7] meg kell kezdıdnie. Sok esetben, egy verziócsere során azért lépnek fel
nehézségek, mert a testre szabott rendszer elkészítésekor nem dokumentálták
kellıképpen a módosításokat. A fejlesztési és dokumentációs ajánlások pontos
betartásával, nagyban megkönnyíthetı egy késıbbi verziócsere, mivel így
zökkenımentessé tehetjük az új rendszerre való áttérés folyamatát.
Ha esedékessé válik a verzióváltás, az ügyféllel együttmőködve, el kell
készíteni az ütemtervet. Ennek az az egyik oka, hogy bármilyen kicsiny módosítást is
tervezünk elvégezni, a mőködı rendszerrıl egy biztonsági mentést kell készíteni,
18.
majd a Navision-szervert le kell állítani. Ezért, a verziócserét végrehajtó partnernek
törekednie kell arra, hogy csak a feltétlenül szükséges mértékig korlátozza az ügyfél
napi ügymenetét, és amit csak lehetséges, a saját telephelyén végezze el. Az ügyféllel
meg kell állapodni arról, hogy mikor tudja nélkülözni a rendszer használatát (az
adatkonverziót érdemes hosszabb ünnepekre, vagy munkaszüneti napokra idızíteni).
Egy verzióváltást három nézıpontból kell megközelítenünk (ld. 3.4.1. ábra),
melyek a következık:
1. Futtatható állományok frissítése
2. Objektumok frissítése
3. Adatkonverzió (migráció)
3.4.1. ábra A verziócsere nézıpontjai
A fenti lépéseket egymás után kell végrehajtani. Az egyes lépésekkel
kapcsolatos tudnivalók a következı alfejezetekben kerülnek ismertetésre.
A fenti nézıpontoknak megfelelıen, a verziócsere folyamatának részeit a
3.4.2. ábra mutatja be. Az ábrán látható felsı háromszög a régi rendszert jelöli, míg
az alsó háromszög az elkészült, új rendszert reprezentálja. A verzióváltás a régi
rendszer adatbázisából kiindulva, két úton valósul meg.
Egyrészt, a régi rendszer testre szabott alkalmazásobjektumait egyesíteni
(merge) kell az új rendszer objektumaival, egy szöveg-összehasonlító alkalmazás
segítségével. Az összehasonlítást elvégezhetjük a NDT (Navision Developer’s
Toolkit) segítségével, de használhatunk bármilyen általános célú szövegszerkesztıt
is. A NDT olyan eszközöket nyújt [11], amelyekkel egyszerre több Navision
FFuutt ttaatthhaattóó ááll lloommáánnyyookk
OObbjjeekkttuummookk
AAddaattookk
19.
adatbázis struktúráját analizálhatjuk, továbbá támogatja az objektumok egyesítését is.
Az egyesítés eredményeként, elkészülnek az új rendszer alkalmazásobjektumai.
A régi rendszer törzs- és tranzakciós adatait a létrejövı új adatstruktúrába be
kell illeszteni. Megfelelı konverziós eszközökkel az adatokat át kell migrálni, hogy
az új rendszerben is konzisztens adatokat kapjunk. A konverziós eljárások standard
objektumokat érintı részét, az Upgrade Toolkitben találhatjuk meg. A testre szabott
objektumok migrációjához szükséges eljárásokat a partnernek kell elkészítenie.
3.4.2. ábra A verziócsere folyamata
3.4.1. Futtatható állományok frissítése
Amennyiben a verziócsere kapcsán futtatható állományok (az operációs
rendszer felügyelete alatt futó Navision alkalmazások) cseréjére is szükség van,
akkor ezt kell legelıször végrehajtani. A többi lépéstıl függetlenül, bármikorra
ütemezhetı ez a feladat, hiszen ez az eljárás általában nem tart sokáig.
A futtatható állományok cseréjét nagyon egyszerően el lehet végezni, mivel
rendszerint a régi állományokat csak felül kell írni az újakkal. Ugyanakkor, egy
vállalati környezetben, ahol adott esetben 50, vagy akár ennél is több kliens gépet
használnak, ez a lépés is jelentıs mennyiségő idıt emészthet fel. A szükséges
idımennyiség jelentısen lecsökkenthetı az SMS (Microsoft’s Systems Management
Server) alkalmazásával, amely képes egy központi forráshelyrıl az összes kliensen
végrehajtani a telepítést.
Régi futtatható állományok
Új futtatható állományok
Régi AB
Upgrade Toolkit
Adatok
Objektumok
Adatok új verzióra történı
konvertálása (migráció)
Szöveg -össze - hasonlító alk.
A régi testre szabott objektum- ok egyesítése az új objektumokkal
Új AB
20.
Mielıtt elkezdıdne a frissítés, meg kell gyızıdni arról, hogy a régi
felhasználói licenc használható–e az új verzióval. Ha esetleg nem, akkor
gondoskodni kell az új verzió használatához szükséges felhasználói licenc
beszerzésérıl. Ezt követıen, az Upgrade Toolkit dokumentációjában leírtak szerint,
meg kell határozni, hogy a Szerver-alkalmazás, a Kliens-alkalmazás (esetleg
mindkettı), vagy más futtatható állomány (például, C/ODBC) cseréjét kell elvégezni.
A. Navision szerver frissítésének lépései
• A szerver-alkalmazások frissítése elıtt, készítsünk a mőködı rendszer
adatbázisáról egy teljes körő biztonsági mentést, amely magában foglalja az
összes Vállalatot, a Közös vállalati adatokat, és az alkalmazásobjektumokat
is.
• Miután meggyızıdtünk arról, hogy minden felhasználó kilépett a
rendszerbıl, állítsuk le a Navision Szervert.
• Készítsünk egy biztonsági másolatot az egész rendszerrıl, amely magában
foglalja a Navision fájlokat (futtatható állományokat és adatbázist) is. Ebbıl a
másolatból, végszükség esetén visszaállíthatjuk a rendszer utolsó stabil
állapotát, ha valamilyen probléma merülne fel a frissítés során.
• Telepítsük fel az új szerver összetevıit (ez általában a régi állományok
újakkal való felülírását jelenti).
• Általános esetben, a szerveren egy Kliens-alkalmazás is található. Ha a
frissítés a kliens állományokra is kiterjed, most hajtsuk végre. Amennyiben az
új verzió használatához új licenc szükséges, másoljuk be a licenc állományt a
szerver-, és a kliens-alkalmazás könyvtárába is.
• Ha változott az adatbázis felépítése, törölnünk kell a régi adatbázist, és a
klienssel létre kell hozni egy új adatbázist. Ezt követıen, ebbe az új
adatbázisba állítsuk vissza a biztonsági mentést.
• Indítsuk el az új szervert, majd a kliens-alkalmazással hajtsunk végre néhány
egyszerőbb tesztet, hogy kiderüljön, sikerült-e helyesen visszaállítani az
adatbázisunkat.
21.
B. Navision kliens frissítésének lépései
• A kliensbıl való kilépést követıen, másoljuk be a szükséges állományokat a
kliens könyvtárába.
• Ha az új verzió használatához új licenc szükséges, másoljuk be a kliens
könyvtárba.
A fenti lépéseket a rendszerben található valamennyi kliensen végre kell
hajtani. Ha az ügyfél több klienst használ, igénybe vehetjük a felhasználók segítségét
is. A lépések egészen egyszerőek, de a rendszer minden egyes elemén végre kell
hajtani.
3.4.2. Objektumok frissítése
Az objektumok frissítése a legnehezebb feladat egy verziócsere során, akár
Javításról, akár Major Releaserıl van szó. Azért bonyolult ez a lépés, mert a
Navision értékesítési láncban résztvevı bármely szereplı megváltoztathatja az
objektumokat, a többi szereplı értesítése nélkül: a Navision fejlesztıközpont, az
értékesítést és támogatást összefogó szervezetek (Magyarországon a Microsoft
Business Solutions Hungary), a Navision partnerek, továbbá a fejlesztıi licenccel
rendelkezı ügyfelek is. Ez számos változatot eredményezhet ugyanabból az
alkalmazásobjektumból.
Egy verziócsere során a partnerek feladata, az általuk végrehajtott testre
szabások egyesítése az új verzióval, vagyis a módosítások átvezetése az új
rendszerbe. Számos eszköz segítheti ıket ebben a munkában, de ezek többsége
feltételezi, hogy a dokumentálásra vonatkozó szabályokat (ajánlásokat) betartották a
testre szabott verzió elkészítése során.
Minden egyes objektumból maximum három változat létezhet. Egyrészt, a
régi alap verzió (Old base version), amelyet a rendszer telepítı CD-jén is
megtalálhatunk. Alap verzió alatt a módosításokat nem tartalmazó, standard
alkalmazásobjektumot értjük. Különösen fontos annak dokumentálása egy testre
szabás során, hogy pontosan mely verzióból indultak ki a fejlesztés kezdetekor.
Másodszor, rendelkezésre áll az új alap verzió (New base version), végül
22.
hozzáférhetı az ügyfél rendszerében jelenlévı, módosításokat tartalmazó változat
(Old customized version).
Az objektumok frissítése során az a célunk, hogy elıállítsuk az új testre
szabott változatot (New customized version), amely tartalmazza mind a partner, mind
a Microsoft által végrehajtott módosításokat. Fentiekbıl nyilvánvalóan következik,
hogy egy konkrét objektumnál négy lehetıség adódik.
• Az elsı lehetıség szerint, a partner sem, és a Microsoft sem módosította az
adott objektumot. Tehát a frissítés során, az ügyfél rendszerében nem változik
meg az objektum.
• Második lehetıségként elıfordulhat, hogy a Navision partner testre szabta az
objektumot, de a Microsoft nem módosította az új változatban. Ebben az
esetben is, az objektum változatlan marad a verziócsere során.
• Harmadik lehetıségként elıfordulhat olyan eset, mikor az objektum
megváltozik az új standard verzióban, viszont a partner nem módosította a
régi verziójú objektumot. Ekkor az ügyfél rendszerébe ez az új objektum
kerül, felülírva a régi változatot.
• Végül, negyedik lehetıségként – amely minden probléma forrása –, elıállhat
olyan eset is, mikor a partner is, és a Microsoft is megváltoztatta az adott
objektumot, az eredeti változathoz képest.
Ha a negyedik lehetıség áll fenn, meg kell határozni, melyik szereplı (a
partner vagy a Microsoft) változtatta meg nagyobb mértékben a régi standard
objektumot. A frissítés során azt a változatot kell kiindulásként felhasználni, amely
nagyobb mértékben módosult. Ezután, a kevesebb változást tartalmazó verzió
módosításait újra kell implementálni az új változat elkészítéséhez.
Példaként tekintsük azt az esetet, mikor a partner szervezet a testre szabás
során nagyobb mértékben módosította az objektumot, mint az új változat
elkészítésekor a Microsoft. Ekkor, a régi testre szabott objektumból kiindulva, újra
kell implementálni az összes olyan módosítást, amit a Microsoft készített. Ebben
segítségünkre lehet a Változási napló (Change Log) [12], amit a Microsoft minden új
változat megjelenésekor közread. Ez a fájl részletesen dokumentálva tartalmazza az
összes, Microsoft által végrehajtott módosítást.
23.
A fenti változás–vizsgálatot valamennyi alkalmazásobjektumra el kell
végezni. Mivel ezek száma egy éles rendszerben adott esetben 3000-nél is több lehet,
az egyesével történı összehasonlítás nagyon sok idıt venne igénybe. Azonban,
alkalmas módszertan [13] választásával, ezt a számot jelentıs mértékben
redukálhatjuk.
Elsı lépésben (ld. 3.4.3. ábra), határozzuk meg az egyesítési mővelet
kiterjedését (scope). Ehhez, hasonlítsuk össze a régi testre szabott, valamint az új
standard verzió objektumainak verziószámát (Version Tag). Ezzel kiszőrhetık azok
az objektumok, melyek mindkét változatban megegyeznek, így ezekkel a
továbbiakban nem kell foglalkozni (ez megfelel a korábban említett elsı
lehetıségnek).
3.4.3. ábra Az objektum-frissítés elsı lépése
A második lépésben azonosítsuk be valamennyi módosított objektumot.
Hogy ezt megkaphassuk, a régi standard verzió objektumait hasonlítsuk össze a régi
testre szabott verzió objektumaival (ld. 3.4.4. ábra). Így figyelmen kívül hagyhatjuk
azokat az objektumokat, amelyeket nem módosítottak az ügyfél rendszerében (ekkor
a korábban említett második lehetıséggel állunk szemben).
Módosítatlan új verziójú objektumok
Módosított régi verziójú objektumok
Módosítatlan régi verziójú objektumok
Módosított új verziójú objektumok
24.
3.4.4. ábra Az objektum-frissítés második lépése
Végül, egyesítsük az elızı lépésben azonosított módosításokat az új
objektumok változásaival (ld. 3.4.5. ábra). Ezzel elıállnak az új testre szabott verzió
objektumai.
3.4.5. ábra Az objektum-frissítés harmadik lépése
3.4.3. Adatkonverzió (migráció)
A migráció [18] eltérı forrásból (rendszerbıl) származó, hasonló tartalmú
adatok új vagy létezı rendszerbe történı integrálását jelenti. A migrációval
megvalósul a régi rendszer adatainak új rendszerbe való átforgatása. A folyamattal
szemben egyrészt azt a követelményt támasztjuk, hogy a migráció
végeredményeként konzisztens adatok kerüljenek be az új adatbázisba, másrészt azt,
hogy az adatok a megfelelı adatstruktúrába kerüljenek migrálásra. A migráció
sikerkritériumának a migrált adatbázis sikeres tesztjét tekinthetjük.
Módosítatlan új verziójú objektumok
Módosított régi verziójú objektumok
Módosítatlan régi verziójú objektumok
Módosított új verziójú objektumok
Összehasonlítás
Módosított régi verziójú objektumok
Módosítatlan új verziójú objektumok
Módosítatlan régi verziójú objektumok
Módosított új verziójú objektumok
Egyesítés
25.
Tehát, az objektumok frissítését követıen, a verziócsere utolsó fázisaként,
adatkonverziót kell végrehajtani. Erre a lépésre általában minden Major Release, de
egyes Minor Release–típusú frissítéseknél is szükség van. A migráció csak a tábla
típusú objektumokat (pontosabban, a táblákban tárolt adatokat) érinti, a többi
alkalmazásobjektum az elızı alfejezetben ismertetett egyesítési mővelet
eredményeként jön létre.
A futtatandó adatkonverziós rutinok (általában programmodulok) az Upgrade
Toolkitben találhatók meg. Ezek a rutinok csak a standard változatok közötti
konverziót valósítják meg, így a testre szabott objektumokhoz szükséges rutinokat a
partnernek kell elkészítenie. Bizonyos speciális esetekben elıfordulhat, hogy
módosítani kell a standard rutinokat, azonban ajánlatosabb teljesen új eljárásokat
készíteni.
Az új verzió táblaobjektumainak szerkezete gyökeresen megváltozhat, a régi
verzióhoz képest. Például, képzeljük el azt az esetet, mikor a régi adatbázis két külön
táblájának rekordjait egyesíteni szeretnénk az új adatbázis egyetlen táblájában.
Elképzelhetı továbbá, hogy a verzióváltást követıen egy mezı típusa megváltozik,
de az sem kizárt, hogy megszőnik egy korábban létezı mezı.
A rendszerben azzal biztosítják az adatok sérthetetlenségét, hogy egy tábla
struktúráját addig nem lehet megváltoztatni, amíg a táblában vannak adatok. A
problémát úgy hidalhatjuk át, hogy a módosítandó tábla adatait, konverziós rutinok
futtatásával átalakítjuk az új szerkezetnek megfelelıen. Ha a mővelet nem oldható
meg egy lépésben, az adatokat át kell mozgatni egy ideiglenes táblába, melynek
szerkezete megegyezik az eredeti táblával (az ideiglenes táblák nem tartalmaznak
triggerkódokat). Ezt követıen felülírhatjuk a régi tábladefiníciót, mivel ilyenkor a
tábla már nem tartalmaz adatokat. Végül, az ideiglenes táblában tárolt adatok
visszamásolhatók, az új táblaszerkezet megfelelı mezıibe.
A migráció lépéseit [13] a 3.4.6. ábrán követhetjük nyomon.
26.
3.4.6. ábra A migráció általános lépései
1. Elıkészületek
Mielıtt elkezdenénk a táblákban található adatok konverzióját, bizonyos
kiegészítı lépéseket kell tenni. A végrehajtandó lépések az Upgrade Toolkit
dokumentációjában vannak rögzítve. Ezek egy része verziófüggı, mivel attól
függıen, hogy mely verzióból indulunk ki, eltérı feladatokat kell elvégezni.
Másrészt, a kiindulási verziótól függetlenül, elı kell állítani az új futtatható
állományok számára hozzáférhetı adatbázist, mely az adatok és objektumok
átmozgatását jelenti (ezt a lépést technikai frissítésnek [technical upgrade] nevezik).
Az elıkészítést követıen, a régi testre szabott adatbázis objektumai közé,
beimportáljuk a standard Elsı Fázisú Konverziós objektumokat (melyek az Upgrade
Toolkit részei), valamint az elkészített saját konverziós rutinokat is.
2. A konverziós rutinok futtatása
Az adatkonverziót a beimportált rutinok végrehajtásával érhetjük el. Elıször
a standard eljárásokat kell elindítani, majd ezt követıen a saját eljárásainkat.
Régi adatbázis
Új adatbázis
Upgrade eszközök
importálása
Upgrade Toolkit
Upgrade Toolkit
Adat- feldolgozás
Végsı adat-
feldolgozás
Új testre szabott objektumok importálása
Adatok és objektumok átmozgatása
27.
Bizonyos verzióknál elıfordulhat, hogy ezt követıen további lépéseket kell még
végrehajtani, ezekrıl pontos leírást az Upgrade Toolkit dokumentációja tartalmaz.
3. Új objektumok importálása
Ennél a lépésnél a korábban elkészített új testre szabott objektumokat
beimportáljuk az új adatbázisba. Az importálást követıen, az Objektumtervezıben le
kell fordítani valamennyi objektumot.
4. Az adatkonverzió befejezése
Miután rendelkezésre állnak az új verzióban használt objektumok, az
ideiglenes táblák adatai visszamásolhatók a végsı helyükre. A végsı
adatfeldolgozást a Második fázisú konverziós objektumok végzik el. Mielıtt
elindítanánk a konverziós eljárásokat, egyes verzióknál további, kiegészítı lépések
végrehajtása szükséges. Az elıkészítı lépéshez hasonlóan, most is elıbb a standard
konverziós rutinokat futtassuk, majd csak ezután a sajátjainkat.
Miután a konverziós eljárások rendben lefutottak, az adatbázisból
eltávolíthatók a felesleges objektumok (ezekre az Upgrade Toolkit dokumentációja
külön hivatkozik), az ideiglenes táblák, és a migrációs rutinok is.
Érdemes megemlíteni, hogy a migrációs eljárás hosszú ideig is eltarthat,
különösen akkor, ha az ügyfél adatbázisában tekintélyes mennyiségő adat található.
Ajánlatos a verziócserét szünidıre vagy hétvégére idızíteni, mikor az ügyfél
hosszabb ideig nem használja a rendszerét.
A verzióváltáshoz szükséges teljes idımennyiséget a partner saját
telephelyén elvégzett próba-verziócsere alkalmával lehet megbecsülni. Ekkor az
ügyfél egy korábbi adatbázisából kiindulva, a partner teljes egészében végrehajtja a
verziócsere valamennyi lépését, miközben pontos idınyilvántartást vezet.
3.4.4. Funkcionális tesztelés
Az adatkonverzió végrehajtását követıen, meg kell vizsgálni, hogy az új
rendszer az elvárások szerint mőködik-e. A partnernek meg kell bizonyosodnia arról,
hogy a definiált tesztkörnyezetben az alkalmazás megfelelıen funkcionál. A tesztelés
során külön ki kell térni annak ellenırzésére, hogy a frissített funkciók mőködésében
28.
nem léptek-e fel váratlan mellékhatások. Hiba esetén vissza kell térni a fejlesztıi
környezetbe, és javítani kell a helytelenül mőködı alkalmazásobjektumokat.
Az ügyfél telephelyén végrehajtandó éles tesztüzemben is fény derülhet
további hiányosságokra. A partner szervezet üzleti tanácsadók bevonásával
gördülékenyebbé teheti a rendszerindítást, akik a felmerülı problémák megoldásában
lehetnek az ügyfél segítségére.
29.
4. Funkcionális tervezés
Diplomaterv - feladatom egy könyvelıiroda rendszerében elvégzendı Major
Release–típusú verziócsere megtervezése, és ennek végrehajtása volt. A rendszert
alkalmazó cég tevékenységi körébıl adódóan, nem használja a Navision
termelésirányítással és raktározással kapcsolatos funkcióit, így ezek a modulok nem
tartoznak vizsgálataim körébe. A feladat elkészítése során a Navision saját, natív
adatbázis–kezelıjét használtam, egy felhasználós kiépítésben.
A vállalat jelenleg a Navision 3.70-es verzióját alkalmazza, ezt kívánja
felváltani a jelen pillanatban kapható legfrissebb, 4.00 SP3-as verzióval. A
verzióváltás legfıbb motivációs tényezıje az volt, hogy a Microsoft 2008. elején
végleg megszőnteti a 3.70-es változat támogatását. Habár e sorok írásakor már
elérhetı a Navision 5.00-ás verziója is, azonban ebbıl nem készítettek
magyarországi lokalizált változatot. Ennek az az oka, hogy a magyar piacot nem
tekintették akkora volumenőnek, amiért érdemes lenne a rendszer mőködését a
törvényi elıírásokhoz igazítani. Elıreláthatólag majd csak az 5.1-es verzióból készül
lokalizált változat, melynek megjelenése 2008. második felére várható.
4.1. Az objektum-frissítés megtervezése
Az objektum-frissítés során célunk az új testre szabott verzió objektumainak
elıállítása. Az elkészülı új objektumoknak tartalmazniuk kell mind a testre szabás
során hozzáadott, mind az új standard változatban megjelenı módosításokat.
Elsı lépésben azonosítani kell, mely objektumokban történt változás, a régi
standard verzióhoz képest. Ezt követıen meg kell vizsgálni, hogy a módosult
objektumoknak mely tulajdonsága, funkciója változott. Végül, a régi testre szabott és
az új standard verzióban végrehajtott módosítások alkalmas egyesítésével (merge)
elı kell állítani az új testre szabott objektumot.
30.
4.1.1. A NDT használata
A NDT fejlesztı-eszközt a Navision Partnerek a Navision Tools CD–n
kapják meg, de le is lehet tölteni a Microsoft oldaláról, a Partner–portálon keresztül.
Használatához fejlesztıi licenc szükséges.
A NDT olyan analízis– és fejlesztı–eszközök győjteményébıl épül fel,
amelyek egy Navision adatbázis struktúrájának vizsgálatában nyújtanak segítséget.
Az adatbázis struktúrájának vizsgálatakor [11] az objektumok, az objektumokban
elhelyezett programkódok, valamint az objektumtulajdonságok közötti kapcsolatokat
térképezzük fel. Ez a mővelet egy Navision adatbázis testre szabásakor,
fejlesztésekor nagyon sok idıbe telhet, különösen akkor, ha nem áll rendelkezésre
részletes dokumentáció.
Ezen túlmenıen, a NDT támogatást ad egy verziócsere során az új testre
szabott változat elkészítéséhez is.
A NDT egy Navision – adatbázisban tárolja a feldolgozandó objektumok
valamennyi leíró adatát. Elsı lépésben létre kell hozni egy olyan „munkaadatbázist”,
amelyben megtalálható az összes alkalmazásobjektum. Ennek megfelelıen, be kell
importálni ebbe a munkaadatbázisba a referencia-verziók (a régi standard, az új
standard, valamint a régi testre szabott verzió) valamennyi alkalmazásobjektumát. A
NDT lehetıségeit egy verzióváltás során a 4.1.1. ábra mutatja be.
4.1.1. ábra Verziócserét támogató funkciók a NDT-ben
Régi standard verzió
Új standard verzió
Régi testre szabott verzió
Verziók importálása
NDT munka-adatbázis
Új testre szabott verzió
Analizálás/ összehasonlítás
Egyesítési mővelet
Objektum exportálás
31.
A munkaadatbázis használatának nagy elınye, hogy egyetlen adatbázisban
tárolja három különbözı rendszer valamennyi objektumát. Így egyetlen helyrıl
elérhetı az összes szükséges objektum, nem kell a kliens-alkalmazással minden
alkalommal külön-külön megnyitni a referencia-verziókat.
4.1.2. Módosított objektumok azonosítása
A testre szabott adatbázisban elvégzett módosításokról nem állt
rendelkezésemre semmilyen dokumentáció. Továbbá, a rendszer bevezetését elvégzı
partner nem mindenhol tartotta be az objektumok verziókövetését segítı
konvenciókat (például, Version Tag mezı frissítése) [7].
Az egyesítési mővelet kiterjedésének meghatározásához össze kell
hasonlítani a régi (3.70-es) standard verzió valamennyi objektumát a testre szabott
objektumokkal. Ehhez egy grafikus felhasználói felülettel rendelkezı eszközt
használtam, amely alkalmas a két verzió közötti különbségek szemléletes
megjelenítésére. Erre a célra a NDT „Két verzió összehasonlítása” (Compare Two
Versions) funkcióját használtam (ld. 4.1.2. ábra).
4.1.2. ábra Verziók közti különbségek azonosítása
32.
A NDT ezen funkciója fastruktúrában jeleníti meg a referencia-verziók
objektumait. A képernyı függıleges és vízszintes görgetésekor mindkét oszlop
szinkronban van egymással, továbbá a verziók közti eltéréseket színezéssel jelöli, a
hierarchia valamennyi szintjén.
A funkció segítségével meghatároztam azon objektumok listáját, amelyek
megváltoztak a testre szabott változatban, valamint azonosítottam a testre szabás
során felvett, új objektumokat is.
Ezt követıen, a módosított objektumokkal összevetettem az új standard
verzió objektumait, ezeknél jelentıs eltérést (konfliktust) tapasztaltam. Ezeket az
ellentmondásokat kézzel kell majd feloldani, az egyesítési mővelet során.
4.1.3. Objektum-analízis
Az objektum-analízis során érdemes kilépni a C/SIDE környezetbıl [7], és az
objektumok felépítését egy külsı eszközzel megvizsgálni, hiszen a C/SIDE-ban ez a
mővelet meglehetısen hosszadalmas lenne. Az analízis megkezdése elıtt az
objektumokat ki kell exportálni szöveges formátumba.
A szöveges formátumú objektumokkal végzett munka során a következı
tényeket kell szem elıtt tartani.
• az összes objektumot kiexportálhatjuk szövegként;
• az objektumok szöveges reprezentációja teljes;
• ebben a formátumban könnyedén áttekinthetjük az objektum összes
tulajdonságát;
• a szöveges objektumot módosíthatjuk, majd ezt követıen beimportálhatjuk a
rendszerbe;
• az importálás közvetlenül, az import munkalap (import worksheet)
megkerülésével megy végbe (ekkor a már létezı objektumok figyelmeztetés
nélkül felülíródnak);
• a beimportált objektumokat le kell fordítani (compile).
4.1.4. Az objektum-egyesítés elıkészítése
A konfliktusban lévı objektumok azonosítását követıen, egyenként meg kell
vizsgálni, hogy miben térnek el egymástól az egyes verziók. Az eltérı
33.
objektum-tulajdonságok, kódrészletek alkalmas egyesítésével elérhetı, hogy az új
testre szabott objektum minden módosítást tartalmazzon.
Habár az objektum-egyesítést a NDT segítségével is el lehetne végezni,
ehhez az eljáráshoz egy általános célú szöveg-összehasonlító alkalmazást, az Araxis
Merget [20] használtam. Ennek oka az volt, hogy a NDT nem biztosít akkora
szabadságot a fejlesztınek, mint egy általános szövegszerkesztı. Emellett, a NDT
mőködése nem minden esetben garantált, gyakran lefagy [16] az alkalmazás. Hiba
esetén mindössze egy hibakóddal tájékoztatja a felhasználót, a hiba okáról nem ad
pontos tájékoztatást.
A konfliktusban lévı objektumokat ki kell exportálni szöveges formátumban,
hogy az objektum-egyesítés mőveletét el lehessen végezni az Araxis Mergedzsel. Az
azonosított konfliktusos objektumokat a NDT-bıl exportálhatjuk ki. Átláthatóbbá,
követhetıbbé tehetjük az egyesítést, ha minden objektum-típust külön állományban
tárolunk. Végeredményül, a három referencia-verzió konfliktusban lévı objektumait,
típusonként külön-külön szöveges állományokban tároljuk.
4.2. A migráció megtervezése
A migráció során a módosítandó táblák tartalmát ki kell menteni ideiglenes
táblákba. A testre szabott verzióban összesen 17 tábla szerkezetét módosították,
ezeket az 1. Táblázatban tekinthetjük meg.
1. Táblázat Konfliktusban lévı Tábla objektumok Objektum
típus Objektum- azonosító
Objektum név Verziószám
Tábla 4 Currency NAVW13.70,ICN Tábla 17 G/L Entry NAVW13.70,NAVHU3.70 Tábla 18 Customer NAVW13.70,NAVHU3.70,ICN Tábla 23 Vendor NAVW13.70,ICN Tábla 36 Sales Header NAVW13.70,NAVHU3.70,ICN Tábla 79 Company Information NAVW13.70,ICN Tábla 81 Gen. Journal Line NAVW13.70,NAVHU3.70,HP1 Tábla 98 General Ledger Setup NAVW13.70,NAVHU3.70,ICN Tábla 167 Job NAVW13.70 Tábla 270 Bank Account NAVW13.70,ICBANK1.00 Tábla 290 VAT Amount Line NAVW13.60 Tábla 312 Purchases & Payables Setup NAVW13.01,ICBANK1.00 Tábla 331 Adjust Exchange Rate Buffer NAVW13.70.02 Tábla 5061 Rlshp. Mgt. Comment Line NAVW13.60 Tábla 5091 Sales Cycle Stage NAVW13.60 Tábla 5606 FA Posting Group NAVW13.00 Tábla 2000000003 Member Of NAVW13.70
34.
A fenti objektumokhoz ideiglenes táblákat kell készíteni, amelyek szerkezete
megegyezik az eredeti tábláéval. Az ideiglenes táblákban nem lehetnek triggerkódok,
és a külsı táblákra vonatkozó hivatkozásokat (pl. a TableRelation mezık értékét)
is el kell távolítani. A fenti objektumokról másolatot készítettem, és a
mezı-definíciókon kívül minden kódot, hivatkozást eltávolítottam. Az elkészült
táblaobjektumokat – amelyek adat-konténerként viselkednek a verziócsere alatt –
beimportáltam a régi testre szabott verzióba, és lefordítottam ıket. Ezek alkotják
majd az Elsı fázisú konverziós objektumok egyik részét. Az ideiglenes táblák fıbb
adatait a 2. Táblázat tartalmazza.
2. Táblázat Létrehozott ideiglenes Táblák Objektum
típus Objektum- azonosító
Objektum név Verziószám
Tábla 55550 Temp_Currency ICN-UPG Tábla 55551 Temp_G/L Entry ICN-UPG Tábla 55552 Temp_Customer ICN-UPG Tábla 55553 Temp_Vendor ICN-UPG Tábla 55554 Temp_Sales Header ICN-UPG Tábla 55555 Temp_Company Information ICN-UPG Tábla 55556 Temp_Gen. Journal Line ICN-UPG Tábla 55557 Temp_General Ledger Setup ICN-UPG Tábla 55558 Temp_Job ICN-UPG Tábla 55559 Temp_Bank Account ICN-UPG Tábla 55560 Temp_VAT Amount Line ICN-UPG Tábla 55561 Temp_Purchases_P_Setup ICN-UPG Tábla 55562 Temp_Adjust_E_R_Buffer ICN-UPG
Tábla 55563 Temp_Rlshp. Mgt. Comment Line ICN-UPG
Tábla 55564 Temp_Sales Cycle Stage ICN-UPG Tábla 55565 Temp_FA Posting Group ICN-UPG Tábla 55566 Temp_Member Of ICN-UPG
35.
5. Implementáció
Ebben a fejezetben ismertetem az új verzió objektumainak elıállításának
menetét. Kitérek az egyes objektum-típusok sajátosságaira, melyeket figyelembe kell
venni az objektum-frissítés során. Ezt követıen bemutatom a konverziós rutinok
mőködését, valamint részletesen elmagyarázom a fontosabb programrészeket. Végül
kifejtem az új verzió elıállításának lépéseit.
5.1. Objektum-frissítés
Az Upgrade Toolkit dokumentációja ehhez a mővelethez a NDT használatát
javasolja, azonban a témával foglalkozó Internetes fórumokban a fejlesztık nem
ajánlják ennek használatát. Ennek az az oka, hogy a NDT automatikus egyesítési
funkciója nem minden esetben ad kielégítı eredményt, valamint nem ad kellı
szabadságot a fejlesztı kezébe. Habár szemléletesen megjeleníthetık benne a
referencia-verziók közötti különbségek, az új testre szabott változat elıállításához
másik program használata javasolt.
Fentiek miatt, az objektumok frissítésére az Araxis Merget használtam,
amely egy vizuális fájl-összehasonlító, fájl-egyesítı, és
könyvtárszerkezet-szinkronizáló alkalmazás. Ebben nem áll rendelkezésre
semmilyen varázsló, minden eltérést kézzel kell átvezetni az új változatba. Annak
ellenére, hogy ezzel a módszerrel kicsit tovább tart a mővelet a NDT-hez képest, a
fejlesztı jobban átlátja a programkódokat, és az objektumtulajdonságokat.
Az egyesítés mőveletét az objektumok szöveges reprezentációján lehet
elvégezni, a Háromirányú összehasonlítás (Three-way comparison) funkcióval. Az
összehasonlítás azzal a feltételezéssel mőködik, hogy egy ısváltozatból kiindulva,
két különbözı variánst készítettünk. A funkció tehát egyszerre három különbözı
forráskód elemzését teszi lehetıvé, megjelenítve a verziók közötti különbségeket (ld.
5.1.1. ábra).
Az objektum-frissítés elıkészítése során, referencia-verziónként elıállítottam
az objektumokat tartalmazó szöveges állományokat. A régi standard verzió
tekinthetı az ısváltozatnak, ebbıl kiindulva készült el a két variáns: a régi testre
szabott-, illetve az új standard verzió.
36.
5.1.1. ábra Objektum-frissítés Araxis Merge használatával
A Merge akkor használható hatékonyan, ha az ısváltozatot a középsı
panelbe töltjük be, míg a két variánst a jobb, és bal oldali panelbe. Ennél az
elrendezésnél egyértelmően láthatók az ısváltozat és az átdolgozott változatok
közötti különbségek.
A verziócsere objektum-frissítési lépésében egyesíteni kell az új standard
verzió, és a régi testre szabott verzió, régi standard verzióhoz viszonyított
módosításait. Az eltérések helyének pontos azonosításához, objektum-típusonként
ismerni kell a szöveges leírásban megjelenı, objektum-típusra jellemzı egyedi
építıköveket. Az egyesítéskor körültekintıen mérlegelni kell, hogy az egyes átvett
módosítások megfelelıen fognak-e mőködni a végsı változatban. Érdemes minden
elvégzett változtatást precízen dokumentálni, ugyanis egyrészt a migrációs rutinok
ezek ismeretében készíthetık el, másrészt így nyomon követhetı az elvégzett munka.
Miután elıállt az új testre szabott verzió objektumainak szöveges
reprezentációja, be kell importálni ıket a Navision adatbázisba. Az importálás során
szintaktikai ellenırzés történik, hiba esetén nem kerülnek be az objektumok az
adatbázisba. Ilyenkor vissza kell térni a szöveges állományhoz, és ki kell javítani a
hibát. Ez tehát egy olyan iteratív folyamat, mely során fokozatos finomítással áll elı
a végsı változat.
37.
A sikeres importálást követıen az objektumok bekerülnek az adatbázisba. Az
alkalmazásobjektumok ekkor még nem használhatók, ugyanis fordítással elı kell
állítani a futtatható változatukat. Míg az importálás során csupán objektumszinten
történik ellenırzés, addig a fordítóprogram az objektumok közötti kapcsolatokat,
külsı hivatkozásokat is ellenırzi. Ha a fordításkor valamilyen hiba lép fel, nem
készül az alkalmazásobjektumból futtatható változat, csak a hiba javítását követıen.
Amint sikerül az új változat összes objektumát hiba nélkül lefordítani,
funkcionális teszteléssel meg kell vizsgálni, hogy a rendszer az elvárásoknak
megfelelıen mőködik-e. Külön ki kell térni annak ellenırzésére, hogy a verziócsere
során nem rontottuk-e el valamelyik korábban jól mőködı funkciót, tehát hogy a
módosítás nem okozott-e váratlan mellékhatásokat. Ha a mőködésben valamilyen
hibát, hiányosságot tapasztalunk, javítani kell az objektumot. Ilyenkor már nem
szükséges visszatérni a szöveges reprezentációhoz, közvetlenül a Navision
fejlesztıkörnyezetében is elvégezhetjük a módosításokat.
5.1.1. Táblák frissítése
A tábla típusú objektumok szolgálnak a törzsadatok és a tranzakciós adatok
tárolására. Kulcsfontosságú szerepet töltenek be, mivel a Navision helyes mőködését
alapvetıen meghatározza a tábla objektumok megfelelı szerkezete, valamint a
köztük fennálló kapcsolatok helyes kialakítása. A többi alkalmazásobjektum
mőködése közvetetten bár, de a táblák felépítésétıl függ, hiszen ezek vagy a táblák
adatait jelenítik meg, vagy a bennük tárolt adatokkal végeznek különféle
mőveleteket. Ebbıl következıen, a táblák frissítése kritikus mővelet, így nagyon
körültekintıen kell eljárni az új testre szabott verzió elıállításakor.
Az alábbiakban egy tábla típusú objektum általános felépítését láthatjuk,
szöveges formátumban.
38.
OBJECT Table 90000 Table_Template { OBJECT-PROPERTIES { Date=07.05.18; Time=12:00:00; Modified=Yes; Version List=Template; } PROPERTIES { } FIELDS { } KEYS { } CODE { BEGIN END. } }
Jól látható, hogy a leíró jellegő objektum-tulajdonságokon túlmenıen (ezek a
tulajdonságok az összes alkalmazásobjektumnál megjelennek: objektum létrehozási
ideje, módosítást jelzı bit, és verziólista), a táblák négy alkotórészbıl épülnek fel.
A Tulajdonságok (Properties) blokkban helyezkednek el a rekordokhoz
kapcsolódó mőveletek triggerkódjai (pl. OnRename), valamint a beviteli őrlapokra
vonatkozó hivatkozások (LookupFormID paraméter) is itt kerülnek definiálásra. A
Mezık (Fields) csoportban a táblát felépítı mezık definíciói, és a mezıkhöz tartozó
triggerkódok állnak. A Kulcsok (Keys) szakaszban a tábla elsıdleges-, és másodlagos
kulcsainak felsorolása található. Végül, a Kód (Code) részben a tábla által használt
globális változók definíciói, és a tábla felhasznált eljárásai foglalnak helyet.
Konkrét példaként tekintsük a 8-as objektum-azonosítóval rendelkezı Nyelv
(Language) tábla-objektumot (ld. Melléklet).
A testre szabott változatban módosított tábla objektumok listája az 1.
Táblázatban (ld. 33. oldal) tekinthetı meg, a frissítés ezekre az objektumokra terjedt
ki.
Az új testre szabott verzió elıállításának minden apró lépését dokumentáltam
a Változás-naplóban, ezen kívül a programkódokban is jelöltem az általam
módosított részleteket. Azonban az elvégzett elemi lépések felsorolása helyett, a
továbbiakban összefoglalóan ismertetem a táblák frissítésekor szerzett
tapasztalataimat.
39.
A testre szabott változat nem tért el jelentısen a régi standard verziótól, így
nem lépett fel olyan konfliktus, amelyet ne lehetett volna egyszerően feloldani.
Ezalatt azt értem, hogy nem állt elı olyan helyzet, amikor egy objektum-tulajdonság
ugyanott változott volna az új standard és a testre szabott verzióban is. A változások
összefésülésével elı lehetett állítani az új testre szabott verziót.
A tábla konzisztenciáját ellenırzı triggerkódokban figyelembe kell venni,
hogy az új változatban a mezık jelentısen megváltozhatnak. Ha a régi változatban
valamelyik trigger egy olyan mezı értékét ellenırzi, amely mezı az új változatban
már nem szerepel, akkor el kell távolítani ezt a kódrészletet, különben szintaktikai
hibát kapunk. Tehát a triggereknél mindig ellenırizni kell, hogy milyen utasításokat
tartalmaznak.
A mezık definícióit tartalmazó részben kell a legkörültekintıbben eljárni. Az
új változat mezıinek egyesítésekor figyelembe kell venni azt a korlátozást, hogy még
a fejlesztıi licenc sem ad lehetıséget arra, hogy a rendszer-táblákba (50 000-nél
kisebb objektum-azonosítóval rendelkezı tábla objektum), 50 000-nél kisebb
azonosítójú mezıt vegyünk fel. Ezért az új testre szabott objektum mezıinek
összeállításakor az új standard verzióból kell kiindulni, majd ezekhez hozzáadni a
testre szabott változatba felvett (50 000 feletti) mezıket. Probléma akkor
jelentkezhet, ha az új változat egy rendszer-táblájában megszőnik egy olyan mezı,
amely a régi változatban még szerepelt, hiszen a korlátozás miatt az új testre szabott
objektum sem tartalmazhatja ezt a megszőnı mezıt. Az ilyen helyzetekre különösen
figyelni kell majd a konverziós eljárások elkészítésekor is. Ilyenkor a probléma úgy
hidalható át, hogy az új változatból kikerülı mezık adatait egy másik táblában
helyezzük el.
A táblába újabb másodlagos kulcsok, változók, és eljárások felvételére nem
vonatkozik ilyen jellegő korlátozás. Azonban, az eljárásoknál is figyelni kell arra,
hogy a programkódban ne maradjon olyan utasítás, amely egy megszőnt mezı
adataival dolgozik.
5.1.2. Őrlapok frissítése
Egy őrlap (Form) [19] hozzáférést biztosít a táblák adataihoz. A
végfelhasználó az őrlapokon keresztül tekintheti meg a tárolt adatokat, továbbá ezek
segítségével vihet be új adatokat az adatbázisba.
40.
Tekintsük egy őrlap típusú objektum általános felépítésének, szöveges
reprezentációját.
OBJECT Form 90000 Form_Template { OBJECT-PROPERTIES { Date=07.05.18; Time=12:00:00; Modified=Yes; Version List=Template; } PROPERTIES { } CONTROLS { } CODE { BEGIN END. } }
Az őrlapok felépítése három fı szakaszra osztható. A Tulajdonságok
(Properties) blokkban a beviteli őrlap mőködésével, megjelenésével kapcsolatos
adatokon (hosszúság, szélesség pixelben kifejezve) kívül, az őrlapokra alkalmazható
triggerek helyezkednek el. A Vezérlık (Controls) elnevezéső rész az őrlapon
megjelenítendı vezérlık (például: szövegdoboz, nyomógomb, beviteli mezı)
definíciójából, elhelyezési paramétereibıl épül fel. A Kód (Code) szakaszban az
őrlap által használt globális változók definíciói és eljárások foglalnak helyet.
Az őrlapok frissítése a 3. Táblázatban felsorolt objektumokra terjedt ki.
A testre szabott változatban az őrlapoknál történt a legtöbb módosítás. Ennek
az a magyarázata, hogy a végfelhasználó elsısorban az őrlapokon keresztül éri el a
rendszer funkcióit. Ebbıl következıen, ezeket az objektumokat kell a leginkább az
ügyfél igényeihez igazítani a testre szabás során. A standard őrlapok kinézetét úgy
kell megváltoztatni, hogy a rajta elhelyezett vezérlık minél jobban hozzájáruljanak a
hatékony munkavégzéshez. Ez az elvárás az alkalmazó vállalat szempontjából
lényeges vezérlık átcsoportosításával, kihelyezésével biztosítható.
Az objektum szöveges változatával végzett munka során nehézséget jelent,
hogy ezen a szinten a vezérlık pontos elhelyezkedését nem lehet átlátni. A beviteli
mezık, nyomógombok, jelölınégyzetek, stb. őrlapon belüli elhelyezése X és Y
41.
irányú koordináták megadásával történik. Emiatt olyan probléma léphet fel, hogy az
őrlapon esetleg egyes vezérlık átfedésben jelennek meg.
Ezt a komplikációt úgy oldottam meg, hogy az új objektum elıállításakor
felvettem az összes lehetséges vezérlıt, majd a tesztelés során valamennyi módosított
objektumot megvizsgáltam, hogy nem tartalmaznak-e véletlenül átfedı vezérlıket.
Azoknál az objektumoknál, ahol ilyen jellegő hibát tapasztaltam, a vezérlık alkalmas
áthelyezésével hárítottam el a problémát.
3. Táblázat Konfliktusban lévı őrlap objektumok Objektum
típus Objektum- azonosító
Objektum név Verziószám
Őrlap 1 Company Information NAVW13.70 Őrlap 16 Chart of Accounts NAVW13.70,NAVHU3.70 Őrlap 20 General Ledger Entries NAVW13.60 Őrlap 21 Customer Card NAVW13.70,NAVHU3.70 Őrlap 22 Customer List NAVW13.70 Őrlap 25 Customer Ledger Entries NAVW13.70 Őrlap 27 Vendor List NAVW13.70 Őrlap 43 Sales Invoice NAVW13.70,NAVHU3.70 Őrlap 44 Sales Credit Memo NAVW13.70,NAVHU3.70 Őrlap 47 Invoice Subform NAVW13.70,NAVHU3.70 Őrlap 51 Purchase Invoice NAVW13.70,NAVHU3.70 Őrlap 52 Purchase Credit Memo NAVW13.70,NAVHU3.70 Őrlap 55 Purch. Invoice Subform NAVW13.70 Őrlap 62 Applied Vendor Entries NAVW13.60 Őrlap 98 Purch. Cr. Memo Subform NAVW13.70 Őrlap 118 General Ledger Setup NAVW13.70 Őrlap 144 Posted Sales Credit Memos NAVW13.00 Őrlap 146 Posted Purchase Invoices NAVW13.00 Őrlap 207 Resource Journal NAVW13.70 Őrlap 232 Apply Customer Entries NAVW13.70,NAVHU3.70 Őrlap 233 Apply Vendor Entries NAVW13.70 Őrlap 253 Sales Journal NAVW13.70 Őrlap 254 Purchase Journal NAVW13.70 Őrlap 255 Cash Receipt Journal NAVW13.00 Őrlap 256 Payment Journal NAVW13.00 Őrlap 315 VAT Entries NAVW13.70 Őrlap 370 Bank Account Card NAVW13.70,ICBANK1.00 Őrlap 371 Bank Account List NAVW13.70,ICBANK1.00 Őrlap 372 Bank Account Ledger Entries NAVW13.00 Őrlap 495 Currency Card NAVW13.70 Őrlap 5050 Contact Card NAVW13.70 Őrlap 5601 Fixed Asset List NAVW13.70 Őrlap 5628 Fixed Asset G/L Journal NAVW13.00 Őrlap 5629 Fixed Asset Journal NAVW13.00
Őrlap 5666 FA Depreciation Books Subform NAVW13.70
5.1.3. Jelentések frissítése
Egy jelentés (Report) [19] összesített információk megjelenítésére,
kinyomtatására használható.
42.
A jelentés típusú objektumok általános esetben, az alábbiakban látható
építıelemekbıl állnak.
OBJECT Report 90000 Report_Template { OBJECT-PROPERTIES { Date=07.05.18; Time=12:00:00; Modified=Yes; Version List=Template; } PROPERTIES { } DATAITEMS { } REQUESTFORM { PROPERTIES { } CONTROLS { } } CODE { BEGIN END. } }
Az egyes építıelemekbe a következıkben meghatározott elemek kerülnek. A
Tulajdonságok (Properties) szakaszban a jelentés megjelenésével kapcsolatos
paraméterek, és a jelentésekre jellemzı speciális triggerek kódjai találhatók. Az
Adatelemek (Dataitems) blokkban az elkészült jelentésben megjeleníteni kívánt
adatelemek felsorolása történik. Az egyes adatelemekhez, az adat eredetét leíró
paraméteren (DataItemTable ) kívül, meg kell adni az adott szakaszban (Section)
(például, fejléc, törzsrész, lábléc) megjelenítendı vezérlık elhelyezését leíró
paramétereket is. Az Igénylı őrlap (Requestform) a jelentés futása elıtt jelenik meg,
amelyen a mőködési paraméterek adhatók meg. Ebben a blokkban kell megadni az
igénylı őrlap megjelenésével kapcsolatos paramétereket (Tulajdonságok), és az
őrlapon megjelenı, mőködést befolyásoló vezérlık definícióit is (a Vezérlık
(Controls) alcsoportban). Végül, a Kód (Code) szekcióban a jelentés által használt
globális változók és eljárások definíciói helyezkednek el.
A testre szabott verzióban módosított jelentések a 4. Táblázatban tekinthetık
meg, ezeket kellett frissíteni.
43.
A jelentések képei szintén ügyfelenként eltérıek lehetnek. A bizonylatok,
ügyviteli dokumentumok, számlák kialakítását az ügyfél egyedi igényeihez kell
igazítani a rendszer bevezetésekor. Ezeket a módosításokat át kell vezetni az új
verzióba is.
Az új testre szabott verzió jelentéseinek elkészítésekor még cizelláltabb a
helyzet, mint az őrlapok frissítésekor. Az objektum szöveges leírásában gyakorlatilag
lehetetlen átlátni a koordináták alapján, hogy pontosan melyik adatelem, hova kerül
majd kiíratásra.
4. Táblázat Konfliktusban lévı Jelentés objektumok Objektum
típus Objektum- azonosító
Objektum név Verziószám
Jelentés 2 General Journal - Test NAVW13.70 Jelentés 6 Trial Balance NAVW13.00,ICN Jelentés 16 G/L Consolidation Eliminations NAVW13.10 Jelentés 104 Customer - Detail Trial Bal. NAVW13.70 Jelentés 117 Reminder NAVW13.70 Jelentés 206 Sales - Invoice NAVW13.70,NAVHU3.70,ICN Jelentés 207 Credit Memo NAVW13.70,NAVHU3.70,ICN Jelentés 406 Purchase - Invoice NAVW13.70 Jelentés 595 Adjust Exchange Rates NAVW13.70.02,NAVDE3.70.02 Jelentés 14500 VAT Analitics NAVHU3.70 Jelentés 14502 Vevı nyitott tételek NAVHU3.70, ICN Jelentés 14503 Szállítói nyitott tételek NAVHU3.70, ICN
Ezért, a jelentések elkészítésekor azt az utat követtem, hogy a jelentésben
elsısorban az új változat kódrészleteit, triggereit vettem át, míg a jelentés kinézete a
régi változatra hasonlít. Azért választottam ezt a megoldást, mert az új változat
bevezetése elıtt az ügyféllel mindenképpen egyeztetni kell, hogy az új változat
jelentései milyen mértékben változhatnak.
A jelentéseknek létezik egy olyan változata, amelyek nem jelenítenek meg
adatokat, csak számításokat végeznek a táblák adatai között (Processing only
reports). Ezek frissítése a programmodulokhoz hasonló módon történik.
5.1.4. Adatportok frissítése
Egy adatport (Dataport) [19] segítségével más programokból importálhatunk
be adatokat a megfelelı helyükre, vagy más alkalmazások számára exportálhatunk ki
adatokat, elıírt formátumban.
Egy adatport típusú objektum általános felépítése a következıképpen néz ki.
44.
OBJECT Dataport 90000 Dataport_Template { OBJECT-PROPERTIES { Date=07.05.18; Time=12:00:00; Modified=Yes; Version List=Template; } PROPERTIES { } DATAITEMS { } REQUESTFORM { PROPERTIES { } CONTROLS { } } CODE { BEGIN END. } }
Látható, hogy egy adatport felépítése megegyezik a jelentés szerkezetével. A
Tulajdonságok szakaszban a mőködéssel kapcsolatos paraméterek állíthatók be, míg
az Adatelemek blokkban építhetı fel az adatport által használt adatmodell. Az
adatport mőködési paramétereit a felhasználótól is be lehet kérni, a futás elıtt. Az
Igénylı őrlapon megjelenı vezérlık és tulajdonságok definiálása az Igénylı őrlap
csoportban lehetséges. Végül, a Kód részben találhatók az objektum globális
változói, és itt helyezkednek el a használt eljárások, függvények kódjai is.
A testre szabott verzióban nem módosították a standard adatport
objektumokat, azonban, az 5. Táblázatban felsorolt hozzáadott objektumokat ki
kellett javítani, hogy a 4.00-ás verzióban is használhatóak maradjanak.
5. Táblázat Módosított Adatport objektumok Objektum
típus Objektum- azonosító
Objektum név Verziószám
Adatport 50035 ÁFA_csoportok Adatport 50037 Szallitok
A fenti táblázatban látható adatportok módosítására azért volt szükség, mert
az importálást követıen, nem lehetett lefordítani ezeket az objektumokat, ugyanis
szintaktikai hibát lépett fel. A problémát mindkét objektumnál az okozta, hogy az
„Áfakönyvelési mátrix beállítása” (VAT Posting Setup) táblában az egyik mezı neve
45.
megváltozott a 4.00-ás verzióban. Mivel ilyenkor nem létezı mezıre próbál
hivatkozni az adatport, ezért nem lehetett elıállítani az objektum futtatható
változatát. Az adatmodellben a régi mezınév átírása után már le lehetett fordítani az
alkalmazásobjektumot.
5.1.5. Programmodulok frissítése
Egy programmodul (Codeunit) [19] C/AL függvényekbıl épül fel, melyeket
más alkalmazásobjektumokból is meg lehet hívni. A különbözı objektumokban
elhelyezett függvények programmodulba történı kiszervezésével lehetıvé válik a
kódok újrafelhasználása, továbbá csökkenthetı az eredeti objektum mérete is.
Az alábbiakban egy programmodul típusú objektum általános, szöveges
felépítését láthatjuk.
OBJECT Codeunit 90000 Codeunit_Template { OBJECT-PROPERTIES { Date=07.05.18; Time=12:00:00; Modified=Yes; Version List=Template; } PROPERTIES { OnRun=BEGIN END; } CODE { BEGIN END. } }
A programmodul szerkezete két részre bontható. A Tulajdonságok
(Properties) szakaszban helyezkedik el a programmodul által megvalósított
fıprogram (OnRun trigger), valamint itt kell felsorolni azon táblákat, amelyekhez a
programmodul hozzáférhet (írhatja, olvashatja, stb.). A Kód (Code) blokkban a
programmodul által használt (illetve a többi alkalmazásobjektumnak felkínált)
eljárások és függvények találhatók.
A 6. Táblázat tartalmazza a frissített programmodulok adatait.
46.
A programmodulok frissítése során fellépı konfliktusok egyszerőbben
megoldhatók a többi alkalmazásobjektumhoz viszonyítva. Az objektumok
összehasonlításakor egyértelmően láthatók az ütközést okozó eltérések. A
programkód vizsgálatával dönthetı el, hogy melyik változat kerüljön be az új testre
szabott verzióba.
6. Táblázat Konfliktusban lévı Programmodul objektumok Objektum
típus Objektum- azonosító
Objektum név Verziószám
Programmodul 1 ApplicationManagement NAVW13.70,NAVHU3.70,ICN Programmodul 13 Gen. Jnl.-Post Batch NAVW13.70 Programmodul 80 Sales-Post NAVW13.70,NAVHU3.70,ICN Programmodul 6620 Copy Document Mgt. NAVW13.70,NAVHU3.70,ICN
A programmodulok frissítése során fellépı konfliktusok egyszerőbben
megoldhatók a többi alkalmazásobjektumhoz viszonyítva. Az objektumok
összehasonlításakor egyértelmően láthatók az ütközést okozó eltérések. A
programkód vizsgálatával dönthetı el, hogy melyik változat kerüljön be az új testre
szabott verzióba.
Az 1-es programmodulban a „NASHandler” eljárásban végeztek el
módosítást, míg a többi programmodulban olyan változtatásokat hajtottak végre,
amelyeket az új standard változatban is megvalósítottak.
5.1.6. Az új testre szabott verzió elıállítása
Miután feloldásra került valamennyi konfliktus, össze kell állítani az új testre
szabott verzió objektumait. Az új testre szabott verzió három összetevıbıl épül fel:
• az elızıekben elkészített testre szabott objektumokból;
• a régi testre szabott változathoz hozzáadott objektumokból;
• valamint az új standard verzió összes olyan objektumából, amelyekkel nem
foglalkoztunk az objektum-frissítés során.
Ezzel biztosítható, hogy az elıálló 4.00-ás verzióban használhatóak lesznek
az új standard verzió elınyei mellett a régi testre szabott változatban megvalósított
extra funkciók is.
Nyissuk meg a Navision 4.00 SP3-as standard adatbázisát, majd „fob”
formátumban exportáljuk ki az Objektumtervezıbıl az összes objektumot (tegyük
47.
fel, hogy a new_version_objects.fob fájlba mentettünk). Ezt követıen, készítsünk egy
üres adatbázist, amelybe elıször importáljuk be a new_version_objects.fob –ban lévı
objektumokat. A következı lépésben, töltsük be az újonnan elkészített objektumok
szöveges változatát, valamint a régi testre szabott verzióhoz hozzáadott
objektumokat. Ha az új objektumok importálása során, valamelyik szöveges
állományban szintaktikai hibát talál a Navision, figyelmeztetést küld. Ekkor a fájlban
ki kell javítani a hibát, mivel csak szintaktikailag helyes objektumokat lehet
beimportálni. Végül, ellenırizni kell az objektumok közötti hivatkozások épségét,
amely az objektumok fordításával érhetı el. Jelöljük ki az összes objektumot, és
fordítsuk le ıket. A fordítóprogram ekkor megpróbálja az objektumok futtatható
változatát elıállítani. Hiba esetén figyelmeztetést küld, amelyet javítani kell. A
javítás elvégezhetı már a C/SIDE környezetben is, nem kell visszatérni a hibás
objektum szöveges állományban tárolt változatához.
Megjegyzem, hogy a fordítóprogram a 7. Táblázatban felsorolt standard
objektumokat nem tudta újrafordítani, ugyanis ezek az alkalmazásobjektumok
számomra nem hozzáférhetı, külsı típuskönyvtárakra hivatkoznak. Ez a tény
azonban nem korlátozza a használatukat, mivel rendelkezésre áll belılük a futtatható
változatuk (hiszen ezeket nem módosítottuk).
7. Táblázat Nem fordítható standard objektumok Objektum típus Objektum-azonosító Objektum név
Tábla 5062 Attachment Jelentés 5192 Patch Exchange References
Programmodul 5064 E-Mail – Logging Programmodul 5500 Production Schedule Management Programmodul 6810 EP Request Handler Programmodul 6815 EP Support Functions Programmodul 6817 EP Format Functions Programmodul 6870 EP Trust Handler Programmodul 6872 EP Crypto Mgt. Programmodul 99008528 BizTalk Appln. Srv. Startup
Miután sikeresen kijavítottuk az összes szemantikai hibát, rendelkezésre áll
az új testre szabott verzió valamennyi objektuma. Az Objektumtervezıbıl
exportáljuk ki az objektumokat „fob” formátumban (tegyük fel, hogy az objects.fob
fájlba mentettünk). Ezt a végsı állományt kell majd elvinni az ügyfél telephelyére,
amikor a verziócserére sor kerül.
48.
5.2. Migrációs rutinok elkészítése
Miután elkészültek az új verzió objektumai, gondoskodni kell arról, hogy a
verziócsere végrehajtása során, a régi adatbázisban szereplı adatok a megváltozott
táblaszerkezetnek megfelelıen kerüljenek át az új adatbázisba. Ezt úgy lehet elérni,
hogy azokból a táblákból, amelyek felépítése, szerkezete jelentısen megváltozik az
új verzióban, az adatokat átmozgatjuk egy ideiglenes táblába. Miután beimportáltuk
az új verziójú táblát, az adatok visszakerülhetnek a végsı helyükre.
Az adatok átmozgatását konverziós (migrációs) rutinokkal lehet végrehajtani.
Az alábbi alfejezetekben ismertetem a rutinok mőködését, és bemutatom a fontosabb
kódrészleteket.
5.2.1. Elsı fázisú migrációs rutin
Az elsı fázisú migrációs rutinokat az objektumok frissítése elıtt, a régi testre
szabott verzióba kell beimportálni, és lefuttatni. A migráció elıkészítés során (ld
33. oldal) elkészített ideiglenes táblákba az adatok mozgatását programmodul
futtatásával valósítottam meg. A programmodul mőködését az alábbiakban
ismertetem.
Elsı lépésben a programmodul leellenırizni, hogy az ideiglenes táblák
elérhetıek-e. Ha bármelyik is hiányzik, a felhasználó hibaüzenetet kap, és a program
leáll. Ezt követıen, a konzisztencia megırzése érdekében, annak ellenırzésére kerül
sor, hogy a táblákban található-e adat. A programmodul az összes ideiglenes táblát
leellenırzi, és ha bármelyikben talál adatot, figyelmezteti a felhasználót. Ilyenkor
egy kérdés jelenik meg, mely felkínálja az adatok törlésének lehetıségét. Normál
mőködési körülmények között, ezt a lehetıséget nem szabad választani, kizárólag
akkor, ha az ideiglenes táblába kézzel írtunk be rekordokat. Az ellenırzéssel egyrészt
elkerülhetı, hogy véletlenül kitöröljük az ideiglenes táblában tárolt adatokat, az új
verziójú objektumok beimportálása elıtt, másrészt megelızhetı az is, hogy a
második fázis során inkonzisztens adatokat töltsünk vissza az új adatbázisba.
Fentiekbıl következik, hogy az elsı fázisú konverziós rutint csak egyszer szabad
lefuttatni, különben az ideiglenes táblák adatai menthetetlenül elvesznek.
Ha a program az ellenırzési lépések során nem talált semmilyen hibát, akkor
átmásolja az eredeti tábla adatait az ideiglenes táblába, majd az adatokat törli az
eredeti helyükrıl. Erre azért van szükség, mert egy tábla struktúráját csak akkor lehet
49.
megváltoztatni, ha nincsen benne adat. A másolási mővelet alatt egy folyamatablak
jelenik meg, amely alapján nyomon követhetı, hogy éppen melyik tábla adatainak
mentése történik. Az ablak megjelenése egyúttal információt nyújt a felhasználónak,
hogy a program még nem fejezte be a futását.
A programmodul mőködését szemléltetı állapottérképet az 5.2.1. ábra
szemlélteti.
5.2.1. ábra Migrációs programmodul állapottérképe
A programmodul az OnRun triggerében meghívja a CheckTables függvényt.
Ha a hívott függvény Igaz értékkel tér vissza, végrehajtódik az Upgrade eljárás,
ellenkezı esetben egy hibaüzenet jelenik meg a képernyın. A programmodul
fıprogramja tehát egyetlen összetett utasításból áll:
OnRun() IF (CheckTables()) THEN Upgrade() ELSE MESSAGE('Hiba lépett fel, az adatok mentése siker telen!');
A CheckTables függvény az összes ideiglenes táblára meghívja a
CheckTempTable nevő függvényt, amely a fentebb részletezett ellenırzési mőveletet
valósítja meg. Az ellenırizendı ideiglenes táblákat az objektum-azonosítójukkal
választhatjuk ki, amelyet a CheckTempTable függvény bemenı paramétereként kell
50.
megadni. A CheckTables függvény Igaz értékkel tér vissza, ha az összes tábla
ellenırzése sikeresen végrehajtódott. Azonban, ha bármelyiknél hiba lépett fel, a
függvény Hamis értéket ad eredményül. Hasonlóan a fıprogramhoz, ez a függvény is
csak egy összetett utasítást tartalmaz:
Procedure CheckTables() : Boolean IF CheckTempTable(55550) AND CheckTempTable(55551) AND CheckTempTable(55552) AND … CheckTempTable(55565) AND CheckTempTable(55566) THEN EXIT(TRUE) ELSE EXIT(FALSE);
A CheckTempTable függvény elıször leellenırzi, hogy az ObjID paraméter
által címzett tábla létezik-e az adatbázisban. Ezt úgy valósítottam meg, hogy a
függvénybe felvettem egy Obj nevő, lokális rekordváltozót, amely az Object táblára
mutat. Ez egy olyan rendszertábla, amelyben az összes alkalmazásobjektum leíró
adata megtalálható. A GET függvény megpróbálja kiválasztani az objektumok
listájából azt a táblát, amelynek objektum-azonosítója megegyezik az ObjID
paraméterben kapott számmal. Ha nem sikerül a kiválasztási mővelet, hibaüzenettel
tér vissza a függvény.
Amennyiben megtalálható az adatbázisban a tábla-objektum, annak
ellenırzésére kerül sor, hogy található-e adat az adott táblában. Ezt úgy oldottam
meg, hogy miután felvettem az obj1 rekord-referencia típusú változót, az OPEN
függvénnyel megnyitottam az ObjID változó által címzett táblát. Ezután a FIND
függvénnyel megpróbálunk ráállni a megnyitott tábla utolsó rekordjára. Ha sikerül a
mővelet, akkor a táblában van adat, ellenkezı esetben Igaz értékkel tér vissza a
CheckTempTable . Ha található adat a táblában, egy kérdés jelenik meg a képernyın,
amelyre Igennel válaszolva, törölhetı a tábla összes rekordja.
51.
Procedure CheckTempTable(ObjID : Integer) : Boolean IF NOT Obj.GET(Obj.Type::Table,'',ObjID) THEN BEGIN MESSAGE('A(z) %1 azonosítójú táblaobjektum nem lé tezik!',ObjID); EXIT(FALSE); END; obj1.OPEN(ObjID); IF obj1.FIND('-') THEN BEGIN MESSAGE('Figyelem! A(z) %1 tábla (%2) adatokat tartalmaz!',Obj.Name,Obj.ID); IF NOT CONFIRM('Törölhet ıek az adatok ebb ıl a táblából?') THEN EXIT(FALSE) ELSE BEGIN obj1.DELETEALL; EXIT(TRUE); END; END ELSE EXIT(TRUE);
Miután sikeresen lezajlottak az ellenırzési mőveletek, a fıprogramból
meghívásra kerül az Upgrade eljárás. Ez az eljárás egymás után meghívja a táblák
adatait átmozgató eljárásokat:
Procedure Upgrade() UpgCurrency(); UpgGLEntry(); UpgCustomer(); … UpgFAPostingGroup(); UpgMemberOf();
Az adatok áttöltése az ideiglenes táblába ugyanazzal a módszerrel történik, az
összes objektumnál. Az alábbiakban a Pénznem (Currency) tábla adatait kimásoló
eljárást ismertetem, a többi eljárás ezzel teljesen analóg módon mőködik.
Procedure UpgCurrency() WITH Currency DO BEGIN IF FIND('-') THEN BEGIN ProgressWindow.OPEN('Currency tábla adatainak m entése #1#######'); REPEAT Tcurr.Code :=Currency.Code; Tcurr."Last Date Modified" :=Currency."Last D ate Modified"; Tcurr."Last Date Adjusted" :=Currency."Last D ate Adjusted"; Tcurr."Unrealized Gains Acc." :=Currency."Unr ealized Gains Acc."; … Tcurr."Default Bank Account" :=Currency."Defa ult Bank Account"; Tcurr.INSERT; ProgressWindow.UPDATE(1,Currency.Code); UNTIL NEXT = 0; DELETEALL; ProgressWindow.CLOSE; END; END;
Az adatok áttöltése az ideiglenes táblába mezınként történik. A Currency
rekordváltozó az eredeti táblára mutat, míg a Tcurr rekordváltozó az ideiglenes
52.
táblára. A FIND függvény végigmegy a Pénznem tábla összes rekordján, és soronként
letárolja az adatokat az ideiglenes táblába, majd törli az eredeti tábla adatait. Mivel
az ideiglenes táblák nem tartalmaznak triggereket, így a beszúráskor elegendı csak
az Tcurr.INSERT utasítást kiadni.
A megjelenı folyamatablakban folyamatosan frissül a Pénznem tábla
elsıdleges kulcsa, így nyomon követhetı, hogy éppen melyik rekord másolása zajlik
a háttérben. A globális elérhetıségő, Dialog típusú ProgressWindow változó
definiálása után az OPEN metódussal nyitható meg a folyamatablak. Miután
megtörtént az új rekord beszúrása az ideiglenes táblába, az UPDATE függvény frissíti a
folyamatablakban megjelenı kód mezıt. Végül, miután átmozgatásra került az
eredeti tábla összes rekordja, be kell zárni a folyamatablakot, a
ProgressWindow.CLOSE utasítással.
5.2.2. Második fázisú migrációs rutin
A második fázisú migrációs rutinokat az új testre szabott verzióba kell
beimportálni, és lefuttatni. A programmodul futása során visszamásolja az ideiglenes
tábla adatait az eredeti táblába, az új szerkezetnek megfelelıen. Az olyan mezıknél,
amelyek már nem szerepelnek az új verziójú objektumban (tehát kikerültek az új
standard verzióból), a bennük tárolt adatok nem másolódnak át az új adatbázisba.
Ugyanakkor, az újonnan megjelenı mezıket, típusuktól függıen, kezdıértékkel kell
ellátni, a végsı táblába másolás elıtt.
Az áttöltést végzı programmodul teljesen analóg módon mőködik, mint az
elızı alfejezetben ismertetett elsı fázisú programmodul, azonban ellenkezı irányú
adatcserét valósít meg. Ezért, a programmodul mőködését csak vázlatosan
ismertetem.
Az adatok visszatöltését jelen esetben is ellenırzés elızi meg. Elıször meg
kell vizsgálni, hogy a táblaobjektumok megtalálhatók-e az adatbázisban. Ha az új
verziójú táblák rendelkezésre állnak, az adatkonzisztencia megırzése érdekében,
meg kell bizonyosodni arról, hogy nincs semmilyen adat a táblákban. Ez a
programmodul is figyelmezteti a felhasználót, ha talál adatot az ellenırzött táblában,
és megerısítést követıen lehetıséget biztosít az adatok törlésére. Normál
körülmények között, ez a figyelmeztetés nem jelenik meg, csak akkor, ha az elsı
sikeres futás után ismét le akarjuk futtatni a programmodult, vagy ha az új táblákba
53.
már vettünk fel új adatokat. Miután az ellenırzés sikeresen befejezıdött, át lehet
mozgatni az ideiglenes táblák adatait a megfelelı helyükre. Fontos megjegyezni,
hogy a rekordok beszúrásakor nem szabad meghívni a tábla OnInsert triggerét, mert
könnyen elıfordulhat, hogy olyan kód hajtódik végre, amely egy másik táblába még
egyszer beszúr egy rekordot.
A másolás alatt egy folyamatablak látható a képernyın, amely azt jelzi, hogy
a mővelet még nem fejezıdött be.
A második fázisú migrációs rutin futtatását követıen, gondoskodni kell arról,
hogy az ideiglenes táblák és a konverziós eljárásokat megvalósító programmodulok
eltávolításra kerüljenek az adatbázisból. A felesleges alkalmazásobjektumok
automatikus törlését egy programmodullal oldottam meg, amelyet a sikeres
migrációs eljárás végén kell elindítani.
OnRun() IF CONFIRM('Biztosan törölhetem a konverziós rutino kat?') THEN BEGIN WITH Object DO BEGIN SETRANGE(Type,Type::Table); SETFILTER(ID,'55550..55566'); IF NOT ISEMPTY THEN DELETEALL; SETRANGE(Type,Type::Codeunit); SETFILTER(ID,'55556..55557'); IF NOT ISEMPTY THEN DELETEALL; END; MESSAGE(Text000); END;
Induláskor megerısítést kér a program, hogy valóban törölhetık-e az
objektumok. Ha a felhasználó Igennel válaszol erre a kérdésre, az objektumok közül
elıször az ideiglenes táblákat törli, majd a programmodulokat. A táblák törlése elıtt
megvizsgálja az alkalmazásobjektum, hogy valóban üresek-e a törlendı táblák.
Sikeres futás esetén tájékoztatást küld a felhasználónak, a feladat hibátlan
végrehajtásáról.
54.
5.3. A verziócsere végrehajtása
Az alábbiakban részletesen ismertetem a 4.00-ás adatbázis elıállításának
menetét. Lépésrıl lépésre leírom a végrehajtandó feladatokat, ezután rámutatok
azokra a körülményekre, amelyeket érdemes figyelembe venni a megvalósítás
folyamán.
5.3.1. Az új verzió elıállítása
A verzióváltás elsı lépésében az új verziójú futtatható állományokat kell
feltelepíteni a rendszerre. Mielıtt hozzákezdenénk a mővelethez, készítsünk egy
biztonsági másolatot a teljes adatbázisról. Ezt követıen, távolítsuk el az alkalmazás
3.70-es változatát, és a telepítı CD-rıl installáljuk fel a Navision 4.00 SP3-as
változatát.
Az új verzió elıállításának további menetét az 5.3.1. ábra [10] szerint
követhetjük nyomon. Az ábrán kiemelten jelölt elsı lépés mőveleteit a régi verziójú
adatbázisban, míg a második lépés feladatait az új adatbázisban kell végrehajtani. Az
egymást követı lépések során több kisebb feladatot kell elvégezni.
Indítsuk el a Navision 4.00-ás verzióját, majd nyissuk meg vele a régi
adatbázist. Ilyenkor egy figyelmeztetı üzenet jelenik meg, amely arról tájékoztat,
hogy az adatbázist át kell konvertálni. Ezt a lépést mőszaki frissítésnek (technical
upgrade) nevezzük, mivel olyan átalakítások mennek végbe az adatbázisban,
amelyek lehetıvé teszik a régi adatbázis megnyitását, az új futtatható állományokkal.
Fontos kiemelni, hogy ezzel a lépéssel csak a futtatható állományok verziója frissül,
az üzleti logika továbbra is a 3.70-es változat szerint mőködik. A konverzió
irreverzibilis, elvégzése után nem lehet megnyitni az adatbázist a 3.70-es
alkalmazással.
55.
5.3.1. ábra A migráció folyamatábrája
Az „Adat elıkészítés” (1.1. lépés) mőveletéhez az alábbi feladatok
tartoznak:
• adatbázis kibıvítése;
• elsı fázisú konverziós rutinok betöltése;
• és az adatkonverziót elıkészítı adat-módosítások végrehajtása.
Elıször tehát az adatbázis méretét kell bıvíteni. Az új adatbázis méretét az
5.1 képlettel határozhatjuk meg.
1. lépés – 3.70-es verziójú objektumok
1.1. lépés
Adat elıkészítés
1.2. lépés
Adat- konverzió
2. lépés – 4.00-ás verziójú objektumok
2.1. lépés
Adat elıkészítés
2.2. lépés
Adat- konverzió
A telepítés befejezése
Migrációs workflow
A táblák kivételével a 3.70-es objektumok
törlése
A testre szabott 4.00-ás
objektumok importálása
Közös vállalati adatok
frissítése
A nem használt táblák és a konverziós
rutinok törlése
56.
( ) ( )dataold
objnew
objold
DBnew SSSS ×++= 2 (5.1)
A fenti képletben DBnewS az új adatbázis méretét, obj
oldS a régi adatbázis objektumainak
méretét, objnewS az új adatbázis objektumainak méretét, végül data
oldS a régi adatbázisban
tárolt adatok méretét jelenti.
A kapott adatbázisban az objektumok által foglalt tárterület 62,2 MB, míg az adatok
méretére 39,3 MB adódott. Az új adatbázis objektumai 72,9 MB-ot foglalnak. A
konkrét értékeket a fenti képletbe behelyettesítve, az új adatbázis javasolt mérete
213,7 MB-ra adódik. Végeredményül, az adatbázis méretét 80 MB-al bıvítettem.
Miután kibıvítettük az adatbázist, be kell importálni az Objektumtervezıbe a
standard és a saját készítéső elsı fázisú konverziós objektumokat. A standard
eljárások az Upgrade Toolkit részét képezik. Az eljárások a Data Conversion Tools
könyvtárban találhatók meg, ezen belül verziónként külön alkönyvtárakban vannak
elhelyezve. Jelen helyzetben az Upgrade370400.1.fob állományt kell betölteni.
Ezután importáljuk be az elızıekben elkészített, saját elsı fázisú konverziós
objektumainkat (Phase_One_Objects.fob).
Mielıtt lefuttatnánk az eljárásokat, meg kell vizsgálni a Pénznem táblában
tárolt adatokat. Meg kell gyızıdni arról, hogy egyik sorban sem szerepel az „Összeg
kerekítési pontosság” és az „Egységösszeg kerekít.pontosság” nevő mezıkben zérus
érték.
Az elıkészítı feladatok végrehajtását követıen térhetünk rá az
„Adatkonverzió” mőveletére (1.2. lépés). Az Objektumtervezıben válasszuk ki az
Upgrade - Old Version nevő őrlapot (104 001-es objektum-azonosító), és indítsuk el.
Az őrlapon kattintsunk az Adatmozgatás (Transfer Data) nyomógombra (ld. 5.3.2.
ábra).
5.3.2. ábra Standard konverziós rutin futtatása
57.
A nyomógombra kattintáskor elindul egy programmodul, amely megvalósítja
a standard objektumokon a konverziót. Ha valamilyen hiba folytán a mővelet nem
hajtódna végre sikeresen, hibaüzenet jelenik meg a képernyın.
Miután hiba nélkül lefutott a standard programmodul, indítsuk el az ICN-
Upgrade Step 1. nevő programmodult (55 555-ös objektum-azonosító). Bármilyen
rendellenesség esetén a programmodul hibaüzenettel tájékoztatja a felhasználót.
Az elsı fázisú migrációs rutinok hibamentes futtatását követıen, térjünk
vissza az Upgrade - Old Version őrlapra, és kattintsunk az Objektumok törlése
(Delete Objects) nyomógombra. Ezt követıen, a táblák kivételével valamennyi
alkalmazásobjektum törlésre kerül, hiszen csak így biztosítható, hogy a következı
lépések során nem ütközünk konfliktusba.
A következı lépésben importáljuk be az elkészített új testre szabott verzió
objektumait tartalmazó objects.fob állományt (ld. 5.1.6. fejezet). Az importálás
elindulását követıen, egy figyelmeztetés jelenik meg, amely arról tájékoztat
bennünket, hogy néhány objektumnál ütközést lépett fel. A megjelenı Import
Munkalapon (Import worksheet) kattintsunk az Összes cseréje (Replace All)
nyomógombra, és indítsuk el a betöltést. Amint véget ért a folyamat, az
Objektumtervezıben jelöljük ki valamennyi alkalmazásobjektumot, és fordítsuk le
ıket.
Ezzel elıállítottuk a 4.00 SP3-as Navision adatbázist, amelyben már az új
testre szabott alkalmazásobjektumok vannak.
A 2.1.-es „Adat elıkészítés” mőveletnél az alábbi feladatokra kell kitérni:
• második fázisú konverziós rutinok betöltése;
• az adatkonverziót elıkészítı adat-módosítások végrehajtása.
Importáljuk be az Upgrade Toolkit részét képzı, második fázisú standard
konverziós rutinokat (Upgrade370400.2.fob), valamint a saját testre szabott
verzióhoz készített eljárásokat is (Phase_Two_Objects.fob).
Ezt követıen, az Eszközök � Nyelv menün keresztül válasszuk ki a régi
adatbázisban alkalmazott nyelvet. Ha kiválasztottuk a kezelınyelvet, az
Objektumtervezıbıl indítsuk el a Team - Meeting Organizers őrlapot (104 090-es
objektum-azonosító). A Csapatkód (Team Code) mezı értékéhez válasszuk ki annak
58.
az értékesítınek a kódját (Salesperson Code), aki az értekezletek megszervezéséért
lesz felelıs. Miután beállítottuk, indítsuk el az „Emberi erıforrás - mértékegys.”
(Human Res. Units of Measure) nevő őrlapot (5236-os objektum-azonosító).
Válasszuk ki az alapértelmezett mértékegységet, és bizonyosodjunk meg arról, hogy
ehhez a mértékegységhez a „Mértékegység szerinti menny.” mezıben 1-es érték
tartozik. Jelen esetben csak egyetlen mértékegység-kód található az őrlapon (ÓRA).
Ehhez, alapértelmezés szerint az 1-es értéket rendelte az elsı fázisú konverziós
programmodul.
Ha lennének esetleg további mértékegységek, a „Mértékegység szerinti menny.”
mezıbe írjuk be a mértékegységhez tartozó egységértéket. Például, ha a
mértékegységek között szerepelne a NAP is, akkor a „Mértékegység szerinti
menny.” mezıbe 8-as értéket kellene felvenni.
A második fázis elıkészítése után elvégezhetjük az „Adatkonverziót” (2.2.
lépés). Az Objektumtervezıbıl indítsuk el az Upgrade - New Version őrlapot
(104 002-es objektum-azonosító), majd kattintsunk az Adatmozgatás (Transfer Data)
nyomógombra. A mővelet sikeres végrehajtását abból láthatjuk, hogy a nyomógomb
inaktívvá válik. Ekkor indítsuk el a ICN-Upgrade Step 2. (55 556-os
objektum-azonosító) programmodult. Ha a mőködés közben hiba lépne fel, a
felhasználó hibaüzenet formájában tájékoztatást kap. Miután eltőnt az utolsó
folyamatablak is a képernyırıl, a programmodul befejezte mőködését.
Az adatok sikeres áttöltését követıen, a „Telepítés befejezı mőveletében”
már csak néhány apró beállításra van szükség. Indítsuk el a Company-Initialize
programmodult (2-es objektum-azonosító), ezzel frissítésre kerülnek a rendszer
használatához szükséges paraméterek. Az új menürendszer megjelenítéséhez
nyomjuk le az ALT+F1 billentyőkombinációt. Végül indítsuk el a Beállítások
ellenırzılistája őrlapot (531-es objektum-azonosító), amely automatikusan frissíti a
4.00-ás adatstruktúra ellenırzılistáját.
A fenti lépéssel befejezıdött a vállalat-specifikus adatok frissítése is.
Ha az új adatbázisban több vállalat adatai is szerepelnek, a közös vállalati
adatokat is frissíteni kell. Be kell tölteni az objektumokhoz történı hozzáférést
szabályozó Szerepeket (Roles) és Engedélyeket (Permissions) tartalmazó
állományokat.
59.
Legvégül, a feleslegessé váló táblákat és konverzió rutinokat ki kell törölni
az adatbázisból. Az Upgrade - New Version őrlapon kattintsunk a Törlés (Delete)
nyomógombra, és válasszuk a Felesleges táblák törlése (Unused Old Tables) opciót.
Miután a verziócserét sikeresen végrehajtottuk, a továbbiakban már nem lesz
szükségünk a konverziós rutinokra, így ezeket is el kell távolítani a rendszerbıl. Az
elıbb említett őrlapon, a Törlés nyomógomb alatt válasszuk az Upgrade Toolkit
opciót. Ennek eredményeként törlésre kerül majdnem az összes standard konverziós
objektum, a Status Log tábla (104 002-es objektum-azonosító) kivételével. Ezt a
táblát manuálisan lehet törölni.
A saját konverziós rutinok eltávolításához futtassuk le az ICN-Upgrade
Delete Objects programmodult (55 557-es objektum-azonosító).
A 3.70-es és az elkészült 4.00-ás rendszer mőködését az 5.3.3. ábra
szemlélteti.
5.3.3. ábra A régi és az új rendszer mőködés közben
5.3.2. A verziócsere tervezése és végrehajtása
A verziócsere folyamata alapos tervezés nélkül [13] nem valósítható meg.
Nagyon fontos, hogy a partner az ügyféllel szorosan együttmőködve, elkészítse a
verziócsere részletes ütemtervét. Ebben a verzióváltás lépésenkénti ütemezésén
60.
kívül, ki kell térni az adat-ellenırzıpontok (Data Checkpoints) definiálására, a
felelısségi körök kiosztására, valamint azt is el kell dönteni, mikor kerülhet sor a régi
rendszer leállítására. Adat-ellenırzıpontok definiálásával validálhatjuk a
kulcsfontosságú funkciók mőködését. Az ellenırzés úgy valósítható meg, hogy a
legfontosabb jelentésekben (például, Korosított követelések, Korosított
kötelezettségek, Készletértékelés), az összesítı mezık értékeit összehasonlítjuk a
verziócsere elıtt és után.
A rendszer mőködési körülményeitıl függıen, el kell dönteni, hogy milyen
kialakítású tesztkörnyezetben deríthetık fel leginkább a hiányosságok. Mérlegelni
kell, hogy a tesztet egy- vagy több-felhasználós környezetben célszerő elvégezni.
Továbbá ki kell térni arra is, hogy az egyenként végrehajtott vagy a párhuzamosan
több gépen végzett tesztelés a célravezetıbb.
A futtatható állományok telepítésekor figyelembe kell venni azt a lehetıséget
is, hogy az új rendszer esetleg erısebb hardvert, vagy frissebb operációs rendszert
igényel. Szem elıtt kell tartani azt is, hogy az ügyfélnek minél rövidebb idıre kelljen
megszakítania az átállás miatt az ügymenetét. A folyamat végrehajtásához szükséges
idı megbecsülhetı, ha az éles rendszer verziócseréje elıtt a partner a saját
telephelyén próba-verziócserét hajt végre. Ily módon felderíthetık az elıre nem látott
nehézségek, problémák is.
61.
6. Tesztelés
Az elkészült rendszer fejlesztıi tesztelését az Expressz módszertanban [21]
foglaltak szerint végeztem el. Ez a kézikönyv a leggyakrabban használt modulok
bevezetését segíti elı, a mőködést konkrét példákon keresztül bemutatva. A tesztelést
a kézikönyvben bemutatott folyamatok, beállítások és példák szerint valósítottam
meg, a Pénzügy, Befektetett eszközök, Eladás, és Beszerzés modulokban.
Mivel a fejlesztıi teszt sikeres elvégzése önmagában még nem garantálja az
új rendszer tökéletes mőködését, pénzügyi szakemberek közremőködésével is
megvizsgáltam az új változat mőködıképességét. Az éles használat során ugyanis
elıállhatnak olyan körülmények, amelyekre a fejlesztıi teszt közben nem derült fény.
6.1. Teszteredmények
Az Express módszertan példáin végighaladva, nem tapasztaltam hibás
mőködést. A megjelenített őrlapokon, jelentésekben nem találkoztam átfedésben lévı
vezérlıkkel. A teszteléskor az egyszerőbb összeadások helyességét is ellenıriztem.
A fejlesztıi teszt elvégzését követıen, pénzügyi szakemberek
közremőködésével teszteltem az új rendszer használhatóságát. A vizsgálat nem volt
teljes körő, csupán a legfontosabb funkciókra terjedt ki.
A rendszer helyes mőködésével szemben azt a kritériumot támasztottam,
hogy a definiált adat-ellenırzıpontokban az összesítı értékek egyezzenek meg a régi
és új változatban.
A teszteléshez olyan adat-ellenırzıpontokat választottam, amelyek mindkét
verzióban egyszerően ellenırizhetıek. Röviden bemutatom a használt jelentéseket.
• A Fıkönyvi kimutatásban a fıkönyvi számlák adott idıszakra vonatkozó
összesített forgalmi adatai jeleníthetıek meg. Különbözı számlasémák
felhasználásával megtekinthetı az Eredménykimutatás, a Cash Flow
kimutatás, és a Mérleg is.
• Fıkönyvi kivonat/elızı év jelentés az elızı év számadataival való
összehasonlításban mutatja be a fıkönyvi kivonatot. A könyvelési idıszak
vagy üzleti év zárásakor használható.
62.
• Záró fıkönyvi kivonat jelentés a tárgyév és az elızı év számadatait normál
fıkönyvi kivonatként mutatja be. Az eredménykimutatás-számlák esetében az
egyenlegek zárótételek nélkül szerepelnek. Az eredménykimutatás-számlák
zárását a program az üzleti év végén könyveli. A jelentés – többek között –
egy üzleti év lezárásával kapcsolatban használható.
• A Vevı- és Szállító - kivonat jelentés a kiválasztott vevık vagy szállítók
részletes egyenlegét jeleníti meg. Ezzel a jelentéssel igazolható, hogy egy
vevı (vagy szállító) könyvelési csoport egyenlege egy adott napon
megegyezik-e a megfelelı fıkönyvi számlán szereplıvel. Könyvelési idıszak
vagy üzleti év zárásakor használható.
• A Korosított vevıkövetelések jelentéssel a vevıkövetelések avulását
követhetjük nyomon. A program az avulást az esedékesség, a könyvelési
dátum vagy a bizonylatdátum alapján számítja ki. A teszteléskor a korosítás
alapjának a fizetési határidıt írtam elı, két éves idıszakra vonatkozólag.
• A Korosított kötelezettségek jelentéssel a kötelezettségek avulása követhetı.
Ennél a jelentésnél ugyanazok a beállítási lehetıségek jelennek meg, mint a
vevıkötelezettségeknél.
A fenti jelentések összesítı értékei megegyeztek az új és a régi verzióban.
63.
7. Összefoglalás
Elıször a verzióváltás elvégzéséhez felhasználható eszközök lehetıségeit
vizsgáltam, majd a NDT és az Araxis Merge használatával ismerkedtem meg. A
Navision alkalmazásobjektumainak felépítését, mőködését és fejlesztését is
tanulmányoztam. Áttekintettem a rendelkezésre álló szakirodalomban a folyamat
szervezési és megvalósítási lépéseit.
A diplomaterv – feladatomban megterveztem a Microsoft Business
Solutions - Navision vállalatirányítási rendszer verziócseréjének folyamatát, valós
vállalati környezetben. A régi testre szabott változat módosított
alkalmazásobjektumainak azonosítását követıen, elkészítettem az új testre szabott
verzió objektumait, ez volt a legidıigényesebb részfeladat. Az elıállított új verziójú
alkalmazásobjektumok mennyiségi eloszlását a 6.1.1. ábra foglalja össze.
Ezt követıen létrehoztam azokat a migrációs eljárásokat, amelyek a régi
rendszer adatbázisában lévı törzs- és tranzakciós adatokat áttöltik az új struktúrába.
Végül a Navision 3.70-es adatbázisából kiindulva, elıállítottam az új, 4.00 SP3-as
verziót.
Az új verzió testre szabott objektumai
16
35
12
4
Táblák
Beviteli őrlapok
Jelentések
Programmodulok
6.1.1. ábra Frissített objektumok típusonkénti megoszlása
Az új rendszer mőködését fejlesztıi teszt végrehajtásával és a legfontosabb
funkciók valós körülmények közötti vizsgálatával ellenıriztem.
64.
Jövıbeli fejlesztési elképzelésnek tartom az adatbázis Microsoft SQL
Szerverre történı átültetését. Érdemes az áttérés elıtt az elérhetı legfrissebb
változatra frissíteni a rendszert, és a natív adatbázist használó változat mőködését
alaposan letesztelni.
Továbblépési ötletnek tartom olyan általánosan használható őrlapok
kialakítását, amelyek a teljes konverziós mőveleten, lépésrıl lépésre végigvezetik a
fejlesztıt. A végrehajtandó feladatok automatikus elvégzésével csökkenthetı a
hibalehetıségek, tévedések száma. Ily módon lehetıség lenne a fejlesztıt pontosan
tájékoztatni a további lépésekrıl, valamint az eddig elvégzett feladatok
eredményérıl. A standard és a saját készítéső migrációs eljárások egységbe
foglalásával lehetıvé válna pontos idıadminisztráció vezetése is.
65.
Irodalomjegyzék
[1] Microsoft Corporation, Microsoft Dynamics NAV Termékinformációk,
http://www.microsoft.com/hun/Dynamics/nav.mspx, 2007.04.26., 23:27
[2] Microsoft Corporation, Microsoft Dynamics lett a Business Solutions
üzletág termékcsaládjának új neve,
http://www.microsoft.com/hun/news/050907_hir01.mspx, 2007.04.27., 0:19
[3] Hetyei József (szerk.), ERP rendszerek Magyarországon a 21. században,
ComputerBooks, Budapest, 2004.
[4] Thomas F. Wallace, Michael H. Kremzar, ERP - Vállalatirányítási
rendszerek, HVG Kiadói Rt., Budapest, 2006.
[5] Navision Academy, Navision Attain Architecture, Vedbaek (Denmark),
2002. (DocID: AT–310–SST–004–v01.00–W1W1)
[6] Navision Academy, Navision Attain Objects, Vedbaek (Denmark), 2002.
(DocID: AT–310–SST–005–v01.00–W1W1)
[7] Navision Academy, Navision Attain Solution Development, Vedbaek
(Denmark), 2002. (DocID: AT–310–ILT–006–v01.00–W1W1)
[8] Microsoft Dynamics NAV, Best Practices for Upgrading (White Paper),
March, 2006., http://www.mibuso.com/dlinfo.asp?FileID=598,
2007.04.27., 23:39
[9] Navision Academy, C/AL Programming, Vedbaek (Denmark), 2002.
(DocID: AT–310–SST–003–v01.00–W1W1)
[10] Microsoft Business Solutions ApS, Upgrade Toolkit, Denmark, 2005.
[11] Microsoft Business Solutions ApS, Microsoft Business Solutions-Navision
Developer’s Toolkit, Denmark, 2005.
(DocID: NA-400-DVG-002-v03.00-W1W1)
66.
[12] Microsoft Business Solutions ApS, Upgrade Toolkit Localization and
Customization Guide, Denmark, 2007.
(Document ID: NA-400-DVG-012-v01.00-W1W1)
[13] John Ponzio, Upgrading Microsoft Navision, MBS Webcast,
http://www.mibuso.com/dlinfo.asp?FileID=420, 2007.02.26., 16:10
[14] Dr. Szikora Béla, Vállalatirányítási rendszerek (elıadásjegyzet),
BME-ETT, Budapest, 2004.
[15] Forrester Research, ERP Software Upgrades In SMBs And Enterprises,
http://www.forrester.com/Role/Research/Workbook/0,9126,41803,00.html,
2007.04.12., 19:00
[16] mibuso.com Forum, Dev toolkit problem with compare and merge,
http://www.mibuso.com/forum/viewtopic.php?t=10185, 2007.05.04., 16:33
[17] Axis Consulting 2000 Kft., Microsoft® Business Solutions–Navision®,
http://mik.vein.hu/notes/26/Axis_MBS_Navision_Veszprem.ppt,
2007.04.05., 13:47
[18] Clarity Consulting, Adat migráció / Adattisztítás,
http://www.clarity.hu/szolgaltat/bodyframe.php?szcsid=3&szid=40&leng=1
, 2007.05.10. 2:00
[19] Microsoft Business Solutions ApS, Application Designer’s Guide,
Denmark, 2004. (DocID: NA-400-DVG-001-v01.00-W1W1)
[20] Araxis Merge, http://www.araxis.com/merge/, 2007.02.22. 16:38
[21] Microsoft Navision, Expressz bevezetési módszertan – Felhasználói
kézikönyv
67.
Melléklet
OBJECT Table 8 Language { OBJECT-PROPERTIES { Date=01.12.17; Time=12:00:00; Version List=NAVW13.10; } PROPERTIES { OnInsert=BEGIN IF WebSite.FIND('-') THEN SynchMgt.InsertLanguage(Rec); END; OnModify=BEGIN IF WebSite.FIND('-') THEN SynchMgt.ModifyLanguage(Rec,xRec); END; OnDelete=BEGIN IF WebSite.FIND('-') THEN SynchMgt.DeleteLanguage(Rec); END; OnRename=BEGIN IF WebSite.FIND('-') THEN SynchMgt.RenameLanguage(Rec,xRec); END; CaptionML=[ENU=Language; HUN=Nyelv]; LookupFormID=Form9; } FIELDS { { 1 ; ;Code ;Code10 ; CaptionML=[ENU=Code; HUN=Kód]; NotBlank=Yes } { 2 ; ;Name ;Text50 ; CaptionML=[ENU=Name; HUN=Név] } { 6 ; ;Windows Language ID ;Integer ; TableRelation="Windows Language";
68.
OnValidate=BEGIN CALCFIELDS("Windows Language Name"); END; CaptionML=[ENU=Windows Language ID; HUN=Windows nyelvazonosító]; BlankZero=Yes } { 7 ; ;Windows Language Name;Text50 ; FieldClass=FlowField; CalcFormula=Lookup("Windows Language".Name WHERE (L anguage ID=FIELD(Windows Language ID))); CaptionML=[ENU=Windows Language Name; HUN=Windows nyelvmegnevezés]; Editable=No } } KEYS { { ;Code } } CODE { VAR WebSite@1001 : Record 6217; SynchMgt@1000 : Codeunit 6205; PROCEDURE GetUserLanguage@1() : Code[10]; BEGIN CLEAR(Rec); SETRANGE("Windows Language ID",GLOBALLANGUAGE ); IF FIND ('-') THEN; SETRANGE("Windows Language ID"); EXIT(Code); END; PROCEDURE GetLanguageID@2(LanguageCode@1000 : C ode[10]) : Integer; BEGIN CLEAR(Rec); IF LanguageCode <> '' THEN IF GET(LanguageCode) THEN EXIT("Windows Language ID"); "Windows Language ID" := GLOBALLANGUAGE; EXIT("Windows Language ID"); END; BEGIN END. } }
69.
Ábrajegyzék
2.2.1. ábra A Navision felépítése ................................................................................. 5
2.2.2. ábra Az adatbázis fizikai szerkezete .................................................................. 5
2.2.3. ábra Az adatbázis logikai szerkezete.................................................................. 6
2.2.4. ábra Az Objektumtervezı .................................................................................. 7
2.2.5. ábra Verziócserére vonatkozó befektetési hajlandóság felmérésének
eredménye .................................................................................................................. 10
3.1.1. ábra A Névjegy ablak....................................................................................... 13
3.2.1. ábra Az upgrade projekt fázisai, mérföldkövei ................................................ 16
3.4.1. ábra A verziócsere nézıpontjai ........................................................................ 18
3.4.2. ábra A verziócsere folyamata........................................................................... 19
3.4.3. ábra Az objektum-frissítés elsı lépése............................................................. 23
3.4.4. ábra Az objektum-frissítés második lépése......................................................24
3.4.5. ábra Az objektum-frissítés harmadik lépése .................................................... 24
3.4.6. ábra A migráció általános lépései .................................................................... 26
4.1.1. ábra Verziócserét támogató funkciók a NDT-ben ........................................... 30
4.1.2. ábra Verziók közti különbségek azonosítása ................................................... 31
5.1.1. ábra Objektum-frissítés Araxis Merge használatával ...................................... 36
5.2.1. ábra Migrációs programmodul állapottérképe ................................................. 49
5.3.1. ábra A migráció folyamatábrája....................................................................... 55
5.3.2. ábra Standard konverziós rutin futtatása.......................................................... 56
5.3.3. ábra A régi és az új rendszer mőködés közben ................................................ 59
6.1.1. ábra Frissített objektumok típusonkénti megoszlása........................................ 63
70.
Táblázatok jegyzéke
1. Táblázat Konfliktusban lévı Tábla objektumok.................................................... 33
2. Táblázat Létrehozott ideiglenes Táblák ................................................................. 34
3. Táblázat Konfliktusban lévı őrlap objektumok..................................................... 41
4. Táblázat Konfliktusban lévı Jelentés objektumok ................................................ 43
5. Táblázat Módosított Adatport objektumok ............................................................44
6. Táblázat Konfliktusban lévı Programmodul objektumok ..................................... 46
7. Táblázat Nem fordítható standard objektumok...................................................... 47
Rövidítésjegyzék
C/AL Client Application Language C/SIDE Client/Server Integrated Development Environment DBMS Database Management System ERP Enterprise Resource Planning GUI Graphical User Interface IDE Integrated Development Environment NAS Navision Application Server NDT Navision Developer’s Toolkit ODBC Open Database Connenctivity SMS Microsoft’s Systems Management Server