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
3.
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
Verziócsere Navisionben ..................................................................................... 9 3.1.
4.
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
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. 5.
Alapfogalmak............................................................................................. 11
A migráció megtervezése........................................................................... 33
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. 5.2.
Elsı fázisú migrációs rutin................................................................. 48
5.2.2.
Második fázisú migrációs rutin.......................................................... 52
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
Tesztelés............................................................................................................. 61 6.1.
7.
Migrációs rutinok elkészítése..................................................................... 48
5.2.1.
5.3.
6.
Az új testre szabott verzió elıállítása................................................. 46
Teszteredmények........................................................................................ 61
Ö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. 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.
1.
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.
2.
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
3.
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.
4.
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.
Grafikus Felhasználói Felület (GUI) Alkalmazásobjektumok
Pénzügy / számvitel
Disztribúció
Termelésirányítás
CRM
e-Business
Integrált Fejlesztıi Környezet (C/SIDE) Adatbázis (Navision Szerver vagy MS SQL Szerver) 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. Közös vállalati adatok
Adatbázis
„A” vállalat Tábla adat
Objektum definíciók (táblák, őrlapok, jelentések, adatportok, programmodulok)
„B” vállalat Tábla adat
2.2.2. ábra Az adatbázis fizikai szerkezete
5.
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.
Adatbázis
Vállalat
Tábla
Rekord
Mezı
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 6.
ú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
7.
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.
8.
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.
9.
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.
27%
Microsoft
47% 12%
Oracle SAP The Sage Group
18% 8% 9% 8% 8%
Major upgrade* Minor upgrade**
SSA Global 0% Technologies 3% 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
10.
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).
11.
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
12.
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ı 13.
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.
14.
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 A
Fejlesztés
szakterületi fázisát
fejlesztık a
Scopeban
teljesítésével, végrehajtásával zárjuk le.
15.
bevonására
is
megfogalmazott
szükség
lehet.
követelmények
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. Bevezetés teljesítve
Végleges változat elfogadva
Scope elfogadva
Scope teljesítve
Projekt tervek elfogadva
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
16.
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,
17.
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ó)
Adatok Objektumok Futtatható állományok 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 18.
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.
Régi futtatható állományok
Szöveg-összehasonlító alk. A régi testre szabott objektumok egyesítése az új objektumokkal
Régi AB
Adatok Objektumok Upgrade
Toolkit Adatok új verzióra történı konvertálása (migráció)
Új AB
Új futtatható állományok
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.
19.
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.
20.
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
21.
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.
22.
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).
Módosítatlan régi verziójú objektumok
Módosított régi verziójú objektumok
Módosítatlan új verziójú objektumok
Módosított új verziójú objektumok
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).
23.
Módosítatlan régi verziójú objektumok
Összehasonlítás
Módosítatlan új verziójú objektumok
Módosított régi verziójú objektumok
Módosított új verziójú objektumok
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.
Módosítatlan régi verziójú objektumok
Módosított régi verziójú objektumok Egyesítés
Módosítatlan új verziójú objektumok
Módosított új verziójú objektumok
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. 24.
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.
25.
Upgrade Toolkit
Upgrade eszközök importálása
Régi adatbázis
Adatok és objektumok átmozgatása
Adatfeldolgozás
Új adatbázis
Új testre szabott objektumok importálása
Upgrade
Toolkit Végsı adatfeldolgozás
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.
26.
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
27.
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.
28.
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.
29.
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.
Régi standard verzió
Új standard verzió
Régi testre szabott verzió
Verziók importálása
NDT munkaadatbázis
Analizálás/ összehasonlítás
Egyesítési mővelet
Objektum exportálás
Új testre szabott verzió
4.1.1. ábra Verziócserét támogató funkciók a NDT-ben
30.
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. A
Módosított objektumok azonosítása
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
31.
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ı
32.
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.
Objektum típus Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla
1. Táblázat Konfliktusban lévı Tábla objektumok ObjektumObjektum név Verziószám azonosító 4 17 18 23 36 79 81 98 167 270 290 312 331 5061 5091 5606 2000000003
Currency G/L Entry Customer Vendor Sales Header Company Information Gen. Journal Line General Ledger Setup Job Bank Account VAT Amount Line Purchases & Payables Setup Adjust Exchange Rate Buffer Rlshp. Mgt. Comment Line Sales Cycle Stage FA Posting Group Member Of
33.
NAVW13.70,ICN NAVW13.70,NAVHU3.70 NAVW13.70,NAVHU3.70,ICN NAVW13.70,ICN NAVW13.70,NAVHU3.70,ICN NAVW13.70,ICN NAVW13.70,NAVHU3.70,HP1 NAVW13.70,NAVHU3.70,ICN NAVW13.70 NAVW13.70,ICBANK1.00 NAVW13.60 NAVW13.01,ICBANK1.00 NAVW13.70.02 NAVW13.60 NAVW13.60 NAVW13.00 NAVW13.70
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.
Objektum típus
2. Táblázat Létrehozott ideiglenes Táblák ObjektumObjektum név azonosító
Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla Tábla
55550 55551 55552 55553 55554 55555 55556 55557 55558 55559 55560 55561 55562
Tábla
55563
Tábla Tábla Tábla
55564 55565 55566
Temp_Currency Temp_G/L Entry Temp_Customer Temp_Vendor Temp_Sales Header Temp_Company Information Temp_Gen. Journal Line Temp_General Ledger Setup Temp_Job Temp_Bank Account Temp_VAT Amount Line Temp_Purchases_P_Setup Temp_Adjust_E_R_Buffer Temp_Rlshp. Mgt. Comment Line Temp_Sales Cycle Stage Temp_FA Posting Group Temp_Member Of
34.
ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG ICN-UPG
Verziószám
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
könyvtárszerkezet-szinkronizáló
fájl-összehasonlító, alkalmazás.
Ebben
fájl-egyesítı, nem
áll
és
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ó. 35.
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.
36.
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.
37.
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
tapasztalataimat.
38.
a
táblák
frissítésekor
szerzett
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.
39.
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
40.
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.
Objektum típus
3. Táblázat Konfliktusban lévı őrlap objektumok ObjektumObjektum név Verziószám azonosító
Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap Őrlap
1 16 20 21 22 25 27 43 44 47 51 52 55 62 98 118 144 146 207 232 233 253 254 255 256 315 370 371 372 495 5050 5601 5628 5629
Őrlap
5666
5.1.3.
Company Information Chart of Accounts General Ledger Entries Customer Card Customer List Customer Ledger Entries Vendor List Sales Invoice Sales Credit Memo Invoice Subform Purchase Invoice Purchase Credit Memo Purch. Invoice Subform Applied Vendor Entries Purch. Cr. Memo Subform General Ledger Setup Posted Sales Credit Memos Posted Purchase Invoices Resource Journal Apply Customer Entries Apply Vendor Entries Sales Journal Purchase Journal Cash Receipt Journal Payment Journal VAT Entries Bank Account Card Bank Account List Bank Account Ledger Entries Currency Card Contact Card Fixed Asset List Fixed Asset G/L Journal Fixed Asset Journal FA Depreciation Books Subform
NAVW13.70 NAVW13.70,NAVHU3.70 NAVW13.60 NAVW13.70,NAVHU3.70 NAVW13.70 NAVW13.70 NAVW13.70 NAVW13.70,NAVHU3.70 NAVW13.70,NAVHU3.70 NAVW13.70,NAVHU3.70 NAVW13.70,NAVHU3.70 NAVW13.70,NAVHU3.70 NAVW13.70 NAVW13.60 NAVW13.70 NAVW13.70 NAVW13.00 NAVW13.00 NAVW13.70 NAVW13.70,NAVHU3.70 NAVW13.70 NAVW13.70 NAVW13.70 NAVW13.00 NAVW13.00 NAVW13.70 NAVW13.70,ICBANK1.00 NAVW13.70,ICBANK1.00 NAVW13.00 NAVW13.70 NAVW13.70 NAVW13.70 NAVW13.00 NAVW13.00 NAVW13.70
Jelentések frissítése
Egy jelentés (Report) [19] összesített információk megjelenítésére, kinyomtatására használható.
41.
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.
42.
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.
Objektum típus Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés Jelentés
4. Táblázat Konfliktusban lévı Jelentés objektumok ObjektumObjektum név Verziószám azonosító 2 6 16 104 117 206 207 406 595 14500 14502 14503
General Journal - Test Trial Balance G/L Consolidation Eliminations Customer - Detail Trial Bal. Reminder Sales - Invoice Credit Memo Purchase - Invoice Adjust Exchange Rates VAT Analitics Vevı nyitott tételek Szállítói nyitott tételek
NAVW13.70 NAVW13.00,ICN NAVW13.10 NAVW13.70 NAVW13.70 NAVW13.70,NAVHU3.70,ICN NAVW13.70,NAVHU3.70,ICN NAVW13.70 NAVW13.70.02,NAVDE3.70.02 NAVHU3.70 NAVHU3.70, ICN 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.
43.
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.
Objektum típus Adatport Adatport
5. Táblázat Módosított Adatport objektumok ObjektumObjektum név azonosító 50035 50037
Verziószám
ÁFA_csoportok 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 44.
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.
45.
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.
Objektum típus
6. Táblázat Konfliktusban lévı Programmodul objektumok ObjektumObjektum név Verziószám azonosító
Programmodul Programmodul Programmodul Programmodul
1 13 80 6620
ApplicationManagement Gen. Jnl.-Post Batch Sales-Post Copy Document Mgt.
NAVW13.70,NAVHU3.70,ICN NAVW13.70 NAVW13.70,NAVHU3.70,ICN 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
46.
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).
Objektum típus Tábla Jelentés Programmodul Programmodul Programmodul Programmodul Programmodul Programmodul Programmodul Programmodul
7. Táblázat Nem fordítható standard objektumok Objektum-azonosító Objektum név 5062 5192 5064 5500 6810 6815 6817 6870 6872 99008528
Attachment Patch Exchange References E-Mail – Logging Production Schedule Management EP Request Handler EP Support Functions EP Format Functions EP Trust Handler EP Crypto Mgt. 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.
47.
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 48.
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 sikertelen!');
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
49.
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.
50.
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 mentése #1#######'); REPEAT Tcurr.Code :=Currency.Code; Tcurr."Last Date Modified" :=Currency."Last Date Modified"; Tcurr."Last Date Adjusted" :=Currency."Last Date Adjusted"; Tcurr."Unrealized Gains Acc." :=Currency."Unrealized Gains Acc."; … Tcurr."Default Bank Account" :=Currency."Default 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 51.
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
ProgressWindow.CLOSE
5.2.2.
rekordja,
be
kell
zárni
a
folyamatablakot,
a
utasítással.
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
52.
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 rutinokat?') 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.
53.
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.
54.
1. lépés – 3.70-es verziójú objektumok 1.1. lépés
1.2. lépés
Adat elıkészítés
Adatkonverzió
A táblák kivételével a 3.70es objektumok törlése
A testre szabott 4.00-ás objektumok importálása
2. lépés – 4.00-ás verziójú objektumok 2.1. lépés
2.2. lépés
Adat elıkészítés
Adatkonverzió
A telepítés befejezése
A nem használt táblák és a konverziós rutinok törlése
Közös vállalati adatok frissítése
Migrációs workflow 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.
55.
(
) (
DB obj obj data S new = S old + S new + 2 × S old
)
(5.1)
DB obj A fenti képletben S new az új adatbázis méretét, S old a régi adatbázis objektumainak obj data méretét, S new az új adatbázis objektumainak méretét, végül S old 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
56.
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 ICNUpgrade 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 57.
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
állományokat.
58.
(Permissions)
tartalmazó
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
59.
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.
60.
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ó.
61.
•
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.
62.
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
4 16 12
Táblák Beviteli őrlapok Jelentések Programmodulok
35
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.
63.
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.
64.
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,
(DocID: NA-400-DVG-002-v03.00-W1W1)
65.
Denmark,
2005.
[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
66.
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
{ 2
;
;Name
;Text50
{ 6
;
;Windows Language ID ;Integer
;CaptionML=[ENU=Code; HUN=Kód]; NotBlank=Yes } ;CaptionML=[ENU=Name; HUN=Név] } ;TableRelation="Windows Language";
67.
{ 7
;
;Windows Language Name;Text50
} KEYS { { ;Code } CODE { VAR WebSite@1001 : Record 6217; SynchMgt@1000 : Codeunit 6205;
OnValidate=BEGIN CALCFIELDS("Windows Language Name"); END; CaptionML=[ENU=Windows Language ID; HUN=Windows nyelvazonosító]; BlankZero=Yes } ;FieldClass=FlowField; CalcFormula=Lookup("Windows Language".Name WHERE (Language ID=FIELD(Windows Language ID))); CaptionML=[ENU=Windows Language Name; HUN=Windows nyelvmegnevezés]; Editable=No }
}
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 : Code[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. } }
68.
Á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
69.
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 C/SIDE DBMS ERP GUI IDE NAS NDT ODBC SMS
Client Application Language Client/Server Integrated Development Environment Database Management System Enterprise Resource Planning Graphical User Interface Integrated Development Environment Navision Application Server Navision Developer’s Toolkit Open Database Connenctivity Microsoft’s Systems Management Server
70.
