Kontrolling Updater

1. Kontrolling Updater funkciója

FRISSÍTÉSEK, VERZIÓVÁLTÁSOK KEZELÉSE A KONTROLLING MODULBAN

2. A Kontrolling Updater feladatai

A Kontrolling programkörnyezet támogatására készült a Kontrolling Updater alkalmazás (amit a továbbiakban röviden „Updater"-ként említünk). Ez többek között lehetővé teszi a Kontrolling program karbantartását, naprakészen tartását, valamint folyamatainak kezelésében is nagy segítséget ad. Alapvetően azzal a céllal készült, hogy viszonylag egyszerűen le lehessen bonyolítani vele a Kontrolling verzióváltását a kapcsolódó OLAP adatbázis frissítésével együtt, idő közben azonban egyre több funkciót is ellát.
A következő műveletek hajthatók végre a segítségével:

• a Vectory által is használt SQL adatbázis megfelelő paraméterezése
• az SQL adatbázis Kontrollingos feldolgozása
• biztonsági mentés az SQL adatbázisról
• a Kontrollinghoz szükséges OLAP adatbázis létrehozása
• az OLAP adatbázis frissítése, telepítése
• az OLAP adatbázis verzióváltása
• az OLAP adatbázis biztonsági mentése
• az OLAP adatbázis transzformálása (OLAP mezők fizikai eltávolítása, vagy hozzáadása használat és újdonság szerint)
• a Kontrolling program telepítése, frissítése
• a Kontrolling program verzióváltása
• a Kontrolling program kapcsolati adatfájljának szerkesztése, tesztelése, beállítása
• a Kontrolling mail moduljának telepítése
• a Kontrolling mail moduljának verzióváltása
• a Kontrolling mail moduljának tesztelése
• a Kontrolling job létrehozása, vagy meglévő job kiegészítése kontrollingos feldolgozási lépésekkel
• diagnosztika
  A felsoroltakon túl még számos egyéb kiegészítő funkcióval is bír a program, mind például az ütemezett futtatás, vagy a műveletsoros használat.

3. Az Updater telepítése

Az Updater program telepítője a Vector Kft. terméktámogatási weboldalán bejelentkezve a Letöltések menüpont alatt érhető el, ahol KontrollingUpdater_inst.exe néven találjuk meg.

\\10.14.3.56\!y\KontrollingUpdater_inst.exe

A telepítő egy önkicsomagoló exe, amely az indítás helyén alapértelmezetten KontrollingUpdater almappába csomagolja ki a programot. Ez a kibontás után szabadon áthelyezhető.

4. Updater indítása, bejelentkezés

A felhasználói hitelesítésnél tehát a terméktámogatási hozzáférésünket kell megadni, és ha azok helyesek, akkor indul el maga az alkalmazás.

5. Devel mappa helye

Még az indítás során beállít egy ún “Devel” mappát a program, ide kerülnek majd OLAP adatbázis telepítésekor a létrehozott OLAP adatszerkezeti csomagok. Ez általában registry-ben az alábbi helyen van megadva:

DevelDir: CurrentUser\SOFTWARE\Kontrolling\DevelDir

Azonban ha nem elérhető a registry, akkor a KontrollingUpdater.exe indítási helyének mappáján belüli “DEVEL” almappát választja a program.

6. Verziók lekérdezése

A Kontrolling és más alkalmazások éppen elérhető verzióit kérdezi le a program következő lépésként, mert ez kulcsfontosságú a működésében.
(v paraméternek az SQL verzióját, ki paraméternek a saját adószámot, rnd paraméternek egy véletlen  számot és rnd2 paramétereknek a pillanatnyi időpont tick értékét adja meg)

https://apiv2.vector.hu/dl.php?v=....&p=vyw&f=kont&ki=....&rnd=....&rnd2=....

7. Frissítés ellenőrzése

Az Updater esetén különösen fontos, hogy naprakész legyen, ezért még a hitelesítést követően ennek vizsgálata következik. Miután tehát megadásra került a szükséges hozzáférés, és megtörtént a verzióinformációk lekérdezése, a program ellenőrzi, hogy a legfrissebb kiadása fut-e éppen. Amennyiben nem, akkor felkínálja saját maga frissítését. Ezt elfogadva újraindul egy rövidebb várakozást követően, ám ekkor már a lefrissült formában. (Megj.: Előfordulhat, hogy bizonyos védelmi szoftverek a program által végzett letöltés és felülírás miatt biztonsági rést látnak ennél a folyamatnál. Ha tehát ilyenkor nem indulna el automatán a program, akkor manuálisan ismét indítsuk el azt. Az is előfordulhat, hogy a vírusvédelemnek kivételként kell megadni az Updater teljes mappaszerkezetét, hogy saját felülírását el tudja végezni.)

8. Updater főablak

Az előzőek után betöltésre került a főablak. Itt szüksége lesz a későbbiekben egy Kontrolling.ini fájl tartalmára, ezért ezt megpróbálja a munkamappából kiolvasni az adott felhasználónál.

c:\Users\gipszj\AppData\Local\Kontrolling\Kontrolling.ini

(A Kontrolling.exe mellett nem keresi, mert több exe is lehet, és ezek helye sem egyértelmű, ezért mindig csak a munkamappát nézi automatán.)

Ezt követően az alábbi felületre jutunk. A megjelenő ablak színekkel, jól látható módon két nagyobb részre van tagolva. Ezek közül a felső sáv a kapcsolatok beállításáért, az alsó, kék színű panel pedig az egy kapcsolaton belüli műveletek kezeléséért felel.

Az ablak tehát egy splitterrel elválasztott két részből áll. A felső a kapcsolati rekordokat tartalmazza (amely egyben a Kontrolling.ini fájljának alapját is jelenti), az alsó kék panel pedig az egy-egy kapcsolathoz elérhető műveleteket kínálja fel. Ha sikeres volt a korábbi Kontrolling.ini kiolvasás, akkor a fenti táblázat már tartalmazni fogja a kapcsolati rekordokat is. Mivel a legtöbb esetben egyetlen kapcsolati rekordunk van csak, így a táblázat első sorának kapcsolatát sikeres kapcsolódás esetén egyből be is tölti a program (így azonnal lehet dolgozni a felületen).

Az ablak jobb alsó sarkában két gomb található: a Diagnosztika és a Hozzáértő mód.
A Diagnosztika szerepe leginkább az, hogy az adott szerver környezet Kontrolling számára érdekes adatait kérdezi le egy ablakban, ez könnyen rávilágíthat esetleges alapvető rendszerbeállítási hiányosságokra, valamint a kapcsolatok tesztelésében, illetve driverek telepítésében is hasznos segítséget tud adni.

9. Hozzáértő mód (DevelMode)

A Hozzáértő mód a részletestől abban különbözik, hogy további speciális funkciókat tartalmaz, amellyel a folyamatok számos részlete kezelhető, beállítható (pl. OLAP kapcsolati diagnosztikák, trafózás logok, stb). Ennek a módnak a használata teljes hozzáértést igényel (ahogyan neve is mutatja), mivel olyan eszközöket tartalmaz, amelyek nem szükségesek a Kontrolling alapvető frissítéséhez, verzióváltásához. Ennek a módnak a használata éppen ezért csak a Vector Kft. munkatársainak ajánlott.
Az Updater a gomb lenyomását csak akkor engedélyezi, ha Vector Kft munkatárs jelentkezett be (azaz a felhasználó munkahelyének adószáma a terméktámogatásnál egyezik a Vector Kft adószámával).
Hozzáértő mód esetén első sorban az alábbiak lesznek elérhetők:

• Job beállítása panel a kék műveleti felületen
• E-mail modul paneljén megjelenik egy telepítéshez használható gomb.
• Aktív lesz a műveletsorok panel
• Aktív lesz a trunk frissítés
• számos további többletfunkció lesz elérhető elsősorban a trafónál (pl. az OLAP telepítés összetevőinek, részfolyamatainak kikapcsolhatóságát szabályzó opciók)
• visszaválthatjuk a felületet normál módba

Az Updater normál módban a frissítéshez, verzióváltáshoz szükséges valamennyi opciót, beállítást megjeleníti.

10. Kapcsolatok, INI szerkesztése

A felső sáv táblázatában láthatók a kapcsolatok rekordjai. Mivel a Kontrolling program egyszerre több kapcsolatot és feltételt követel meg a működéséhez, így elengedhetetlen ezeket biztosítani neki már a frissítés megkezdése előtt is. Ez olyannyira szükséges, hogy az Updater addig nem enged műveleteket indítani, amíg az aktív kapcsolati rekord nem felel meg ennek teljesen. A kapcsolat érvényességét a “Tesztelés” gombbal tudjuk ellenőrizni. Ezt érdemes is megtenni, és csak a sikerese kapcsolat visszajelzése esetén nyomni az “OK” gombra, így garantálható, hogy megfelelő kapcsolatunk és ehhez a legbővebb műveletelérésünk lesz majd.
(Megj.: Lehetőségünk van ugyanakkor nem, vagy részben érvényes kapcsolat esetén is OK-ézni, ám ilyenkor csak a kapcsolat érvényessége szerint érjük majd el az egyes funkciókat is. Ha pl nincs OLAP kapcsolatunk, akkor sem frissíteni, sem biztonsági mentést készíteni nem tudunk majd a programban az OLAP adatbázisunkról.)
Azt, hogy megfelel-e, szintén egyszerű színezés szerint érzékelhetjük: ha zöld a táblázat sora, akkor használható a kapcsolat, ellenkező esetben ugyenez piros hátteret kap. Ilyen érvénytelen/nem teljes körű kapcsolat esetén nem, vagy korlátozottan érhetőek el a műveleti kezelőgombok is a lenti kék panelen. A táblázat feletti gombokkal tudunk kapcsolatot megadni, törölni, vagy éppen elmenteni INI fájlként. Mivel általában már van működő Kontrolling, amit frissítünk, így az már rendelkezik INI-vel is. Az Updater betöltéskor eleve ennek kapcsolatait sorolja fel a táblázatban. Ezt aztán el is menthetjük másként, vagy akár felül is írhatjuk a fájlt a táblázat feletti gombbal (Mentés INI fájlba).
(Megj.: Ha esetleg mégsem sorolná fel a kapcsolatokat a program, akkor az azért lehet, mert nem találja az kontrolling.ini fájlt. Ilyenkor a “Kapcsolatok betöltése INI-ből” elnevezésű gombbal kitallózhatjuk ezt neki.)

Kapcsolat szerkesztésekor új esetén a fenti Kapcsolat hozzáadása gombbal, meglévő módosításakor pedig a soron való egyszerű dupla kattintással tudjuk előhívni az erre kitalált felületet. A felületen az ábrán megadott módon kell kitölteni az OLAP és az SQL kapcsolat adatait.

Az ablak jobb felső sarkában lévő fogaskerekes gombocskával lehet elérni a speciális beállításokat ehhez a felülethez.

Erre alapvetően nincs szükség. Ha mégis kellene, akkor a kapcsolódási timeout időket, és a speciális funkciók megjelenítését, valamint az automata tesztelést szabályozhatjuk itt. Speciális funkcióként a rendszerparaméterek beállítófelületét, valamint az esetleges jelszótitkosítások kezelését tudjuk elérni.

11. Milyen vizsgálatok történnek kapcsolat betöltésénél?

Természetesen első körben az adatbázis elérések ellenőrzése történik. Ha van érvényes SQL kapcsolódásunk, akkor a progam egy SQL kapcsolatot állít be. Hasonlóan, ha van OLAP kapcsolatunk, akkor OLAP kapcsolatot is beállít. (Szerparált adatbázis esetén, csak érvényes SQL kapcsolat mellett kerülhet sor a szerparált adatbázis kapcsolat lekérdezésére, ellenőrzésére és beállítására is.)
Ezután az OLAP provider vizsgálata, és beállítása következik.
A a mail modul kezeléséhez szükséges feltétel, hogy legyen SQL elérésünk, OLAP elérésünk és létezzen az OLAP adatbázisunk.
A jogok vizsgálata következik, ahol a felhasználót vizsgálja a program, hogy része-e a rendszergazdák csoportnak. (Ez a “kont_rendszergazda_szemcskod” rendszerparaméter megadása esetén az itt megadott személycsoport tagságát, egyébként az 1-es kódú “Rendszergazdák” személycsoport tagságot jelenti a Vectoryban.) Csak rendszergazdai besorolású felhasználók használhatják a programot (kivéve hozzáértő mód).
A mail modulnak ez szintén feltétele, ahogy a moduljog megléte is, valamint a Kontrolling Mail telepítettsége, ezeket szintén ellenőrzi a program. Mivel mail modulnál az SQL szerveren kell a KontrollingMail segédprogramot is frissíteni, így az is feltétel, hogy magán az SQL szerveren fusson az Updater, hiszen csak így éri el a segédprogramot a frissítéshez. A segédprogram elérését a “k4_mail_path” rendszerparaméterből olvassa ki és az SQL szerveren értelmezi.
A trafózás (azaz OLAP adatbázis összeállítás és generálás, lásd később) előfeltételeinek vizsgálata következik, itt a éjszakai adatkarbantartást végző job sikeres lefutását, néhány fontos rendszerparaméter kitöltöttségét, illetve a verziómegfelelést ellenőrzi a program.

12. SQL kapcsolat beállítása

A kapcsolat elnevezése tetszőleges név lehet (általában az adatbázis nevét szokás ide írni). A bal oldalon megadható SQL adatok közül a szerver és az adatbázis névhez a Vectory programban is használt kapcsolódási szerver és adatbázis nevek, az alattuk megadható Windows-os, vagy felhasználónév-jelszavas hitelesítéshez pedig egy érvényes Vectory felhasználói hitelesítés kell (mindez tehát a Vectory bejelentkezéssel megegyezik).
(A titkosítás lehetősége jelenleg nem használt funkció. Azért inaktív, mert mostanra a beállításról függetlenül, mindenütt eleve aktív kell, hogy legyen biztonsági okokból.
A fenti „Sep.DB" pedig szintén teljesen egyedi, ún. szeparált adatbázisos felhasználása esetén kell, hogy be legyen csak pipálva. Ez utóbbinál egy teljesen külön adatbázisba kerül a Kontrolling, amit még telepítéskor kell megfelelően konfigurálni beállítani. Amikor ez aktív, akkor az SQL kapcsolatoknak van egy második füle is, ahol ez utóbbi adatbázis kapcsolati adatait szerkeszthetjük.)

13. Olap kapcsolat beállítása

Az OLAP esetén elég csak az OLAP szerver és adatbázis nevét ismerni (jellemzően egyeznek az SQL-be beírtakkal), az OLAP kocka pedig rendszerint az „XX" elnevezést használja. Ha minden szükséges adatot megadtunk, akkor A “Tesztelés” gombbal (vagy egyből, automatán (beállításunk szerint)) kiértékelésre is kerülnek a kapcsolatok. Először az SQL, majd, ha a kapcsolat sikeres, akkor az OLAP is kapcsolati tesztelésen megy keresztül. Mindezt kis ikonok formájában egyből láthatjuk is az alábbiak szerint:

14. Kapcsolatok beállítása, kiértékelése

Ha azt szeretnénk, hogy az automata kapcsolati kiértékelés működjön, akkor a fogaskerekes gomb paneljén bekapcsolhatjuk ezt. Ilyenkor bár aktív, de külön az SQL, és külön az OLAP esetén is ki-, bekapcsolható lesz a funkció az „Auto. teszt" pipával.
Mindaddig, amíg nincs SQL, vagy OLAP esetén érvényes kapcsolatunk, csak az elérhető kapcsolatnak megfelelő műveleteket tudjuk majd használni. Amennyiben a kapcsolatbeállítással probléma adódna, van néhány segítő funkció is a beállításhoz:

• Ha a kitöltött szervernév rovatban duplán kattintunk, akkor egy parancssoros ablak nyílik, ahol a szervernév ping tesztelése elindul.
• Ha már jó a szervernév, akkor az adatbázis névre dupla kattintással egy kiválasztó listás ablak nyílik fel, ahol felsorolásra kerülnek az éppen elérhető adatbázisok, és csak ki kell választani a megfelelőt (így garantáltan nem írjuk el azt).
• Ha valami miatt nem működik a kapcsolat, akkor az ablak alján lévő OK gomb ikonja sárga lesz:
  
• Ilyenkor a gomb lenyomására a program kiírja a tapasztalt problémákat, és lehetőségünk van, egy pár perces diagnosztikát is futtatni, ami még közelebb visz a megoldáshoz.
• Végül van még egy vizsgálati eszközünk: maga a diagnosztika gomb , amely a kapcsolathoz szükséges drivereket ellenőrzi, valamint a kapcsolatok minden paraméterének tetszőleges hangolásával vizsgálható a kapcsolódás. A szükséges driverek telepítésében is segít ez a felület.

Fontos, hogy az érvényes Kontrolling kapcsolathoz még nem elég, ha az SQL és OLAP szerverek irányában van kapcsolatunk. Alapvetően az alábbiak kellenek ahhoz, hogy az Updater teljeskörű módon tudjon dolgozni:
(Részletesebb információkért lásd korábbi vizsgálatok kapcsolat betöltésnél leírásunkat.)

1. Érvényes SQL kapcsolat
2. Érvényes Vectory felhasználói azonosítás
3. Vectory rendszergazdai besorolás (személycsoportok)
4. Érvényes OLAP kapcsolat (ez mindig a háttérben történik Windows hitelesítés szerint)
5. Legyen ismert a jelenlegi és beállítandó OLAP verziószám
   Ha van ugyan érvényes kapcsolatunk, de nem teljesülnek a 2-3 pontok, akkor az alábbi ábrán látható üzenetet és jelzést közli a program.

Ha viszont sikeres SQL kapcsolatot adtunk meg, akkor (amennyiben a speciális beállítások is aktívak) egyből el is érhetjük a Kontrollingban már megismert paraméter beállító felületet ezzel a gombbal:

Sikeres kapcsolatok esetén az érvényes verziók is láthatók lesznek a felületen.
Ha sikertelen a kapcsolat tesztelése, akkor a program ezt egy ennek megfelelő piros x ábrával jelzi, és ilyenkor nem működnek a speciális funkciók sem. Ha viszont működő kapcsolat áll fenn, akkor az ennek megfelelő zöld kapcsolat ábra megjelenése mellett elérhetőek lesznek az egyes funkciók indítógombjai is.

15. Kapcsolat betöltése

Ha a kapcsolatokat rendben megadtuk, és bezöldül az Updater táblázatának érvényes sora, akkor használhatók a műveletek is. A táblázatban persze több kapcsolatot is megadhatunk, és válthatjuk őket, hogy éppen melyikkel szeretnénk dolgozni. A váltásra az alábbi lehetőségeink vannak:

• a táblázat kívánt sorát kiválasztva nyomjuk le az F5-öt
• a táblázat kívánt sorát kiválasztva jobb klikkes helyi menüből válasszuk a „Kapcsolat betöltése" menüpontot
• a táblázat kívánt sorát kiválasztva a kék műveleti felületen nyomjuk le a „Kapcsolat betöltése" gombot
• jelöljük be gyors duplakattintással a táblázat ConnectActive oszlopában a megfelelő sort

Amennyiben minden kapcsolattal elkészültünk, akkor a fenti gombokkal lehetőségünk van elmenteni INI fájlként a megadott kapcsolatokat (ez egyébként a Kontrolling program telepítésekor külön is kezdeményezhető), vagy a Kontrollingból már megismert INI szerkesztő felületbe betölteni, tovább szerkeszteni azokat (lásd: „INI szerkesztése" gomb). Jó tudni, hogy az UPDATER biztonsági okokból sem az INI-ben, sem egyéb más módon nem tárolja el a jelszavakat. Ezért egy-egy ismételt használat alkalmával ez a rovat mindig kitöltetlen lesz, és mindig meg kell majd adni a jelszót, hogy legyen érvényes kapcsolatunk. Több adatbázisnál viszont, ha az egyik kapcsolat felhasználóneve is egyezik egy korábbival, akkor a futásidő alatt megpróbálja a már korábban beírt jelszót alapértelmezésként felkínálni egy ilyen hasonló rekord esetén is.

A táblázat bal oldalán látható „Kiválasztás" oszlop szerepe, hogy eltárolja a már sikeres kapcsolati rekordok státuszát, adatait. Konkrétan ez azt jelenti, hogy amennyiben be van pipálva a Kiválasztás oszlop (azaz az aktuális sor kiválasztottak között szerepel), akkor a program már tudja, hogy a sor már kiértékelésre került. Ilyenkor jóval gyorsabb működés, mivel a rekord adatai mellett annak kapcsolatainak érvényességét is egyből tudja a sor, ezért nem kell tesztelni azt. Persze, ha nem kiválasztott egy sor, akkor az mindig azt jelenti, hogy nincs még információnk arról, hogy érvényesek-e a sor adataiból előállítható kapcsolatok, vagy sem, ezért ebben az esetben mindig tesztelés történik a sor betöltéskor. Ilyenkor válik a sor egyúttal kiválasztott sorrá is. Manuálisan is indíthatjuk egy-egy sor kiválasztottságának szabályzását. Ha kiválasztott sor kiválasztásának megjelölését visszavonjuk, akkor ez azt jelenti majd a programnak, hogy bármi is volt korábban a kapcsolat érvényesség állapota, legközelebb mindenképpen újra ki kell azt értékelni tesztelésekkel. Ha pedig bepipáljuk a sor kiválasztottsági oszlopának pipáját, akkor egyúttal egy tesztelési folyamatot is elindítunk, így kiértékelésre kerül az adott sor, mivel így fogja tudni a későbbiekben tesztelés nélkül is a program a sor által adott kapcsolati rekord érvényességét megadni.
A kiválasztottság használata tehát azért jó, mert ha egy rekord már sikeres kapcsolatbeállítást tartalmaz, és azt elhagyjuk, majd később visszatérünk rá, akkor e státusz nélkül megint végig menne egy kapcsolati kiértékelésen. Így azonban „emlékszik" rá a táblázat, hogy legutóbb ez a sor érvényes volt, és kiértékelés helyett azonnal érvényes kapcsolattá minősíti a rekordot. Mindez a státusz persze csak a rekord adatainak változásáig érvényes. A kapcsolati adatok módosítását követően újra kiértékelésre kerül. A „Kapcsolatok vizsgálata" gomb ezt az első oszlopot használja ki, és valamennyi soron végig lépkedve megállapítja, hogy mely rekordok érvényesek. Az érvényes rekordok sorainál pipa került az 1. oszlopba. (Figyelem! Ez a folyamat sok rekordesetén időigényes lehet, akkor érdemes használni, ha tényleg valamennyi kapcsolat szerint dolgozni szeretnénk majd a programban.)

Az előző kiválasztottsági pipálás tehát minden sornál állítható, és nem összekeverendő a 2. oszlopban található “ConnectActive” mezővel. Ez utóbbi feladata, hogy egyértelművé tegye, melyik sor az aktív, vagyis éppen melyik sor adatait láthatjuk betöltve a táblázat alatt lévő kék panelen. A ConnectActive is pipálható, viszont itt mindig pontosan egy sort lehet megjelölni, megjelöléskor ugyanis minden más sor jelöletlen lesz. Így válik egyértelművé mindig, hogy melyik sort használjuk. Ezt a pipáltságon túl színezéssel is jelzi a program. Az aktív sor zöld lesz, ha érvényes kapcsolatai vannak és piros, ha vannak érvénytelen kapcsolatai, jogai is. ez utóbbi esetben a kék panel is csak a kapcsolatérvényességnek megfelelő korlátozással elérhető. A kék panelre egy sort betölteni több módon is lehet: dupla kattintással, a ConnectActive bepipálásával, a fókuszba hozott soron F5-öt nyomva, vagy a sorra kattintva jobb klikkes helyi menüből.

16. Diagnosztika

Diagnosztikát futtatni a Diagnosztika gomb segítségével lehet, mely hatására pedig az ábrán látható ablak jelenik meg. Itt láthatjuk a legfontosabb információkat az adott környezetről. Ez fontos lehet pl. akkor, amikor az OLAP-hoz szükséges tartományi felhasználói hitelesítéseket vizsgálunk. Lentebb pedig a kapcsolatokat tesztelhetjük, vagy a szükséges drivereket is telepíthetjük, valamint a Kontrolling számára javasolt teljesítménycentrikus energiagazdálkodást is könnyen beállíthatjuk. (Megj. A kapcsolatot driverenként teszteli a felület. Persze amennyiben érvénytelennek látja a driver szerinti kapcsolatot az ablak, akkor az a driver probléma mellett utalhat még hozzáférési, vagy akár adatbázis elérési okokra is.)

17. MŰVELETEK

Műveletek indításánál hasonló megjelenéssel találjuk meg a kék panelen, soronként az egyes funkciókat. Minden esetben az indítás/play gombbal tudjuk elindítani az adott műveletet, és ha már fut, meg is szakíthatjuk az ilyenkor aktív a piros x, elvetés gomb segítségével. A folyamatsáv tájékoztat a feldolgozás mértékéről, míg a mellette lévő nagyobb ábra a kimeneteléről. Ezek az állapotok az alaphelyzet, folyamat közben, sikertelen lefutás, sikeres lefutás lehetnek, melyket állapotjelző ikonok egy négyzet, loading jelzés, piros x, és pipa jeleznek.

Minden sáv elején találunk egy pipálható checkbox-ot is. Ezzel a pipával össze tudunk állítani egy műveletsort, ami azt jelenti, hogy az így megjelölt műveleteket együtt is elindíthatjuk. Ilyenkor automatán (sorban, egymás után, vagy párhuzamosan) történik a műveletek végrehajtása.

Ehhez pedig az erre kifejlesztett indítógombot kell használnunk, amit akár időzítve is elindíthatunk az alatta lévő időt.

beállítva. Ha ezt a funkciót használjuk, akkor a program felkészült rá, hogy viszonylag hosszabb idejű folyamatok fognak futni, akár az egész éjszaka folyamán. Ezért csak a folyamat elején kérdezősködik, és gyűjti be valamennyi szükséges információt a műveletek lefutásához. Ha elindult, akkor némán (naplózás és log fájl írása mellett) történik a feldolgozás. Ha egy lépésnél mégis elakad valamiért, akkor a teljes folyamat megáll, mivel ilyen indításnál feltételezi, hogy magára hagytuk (szemben a műveletenkénti indítással).
Ha az időzítőt használjuk (vagyis megadunk egy időt), akkor a „Mindent futtat" gomb hatására nem indul még el a feldolgozás. Ilyen esetben egy visszaszámlálás kezdődik és csak akkor kezdődik meg a tényleges feldolgozás, amint az visszaszámlált idő a nullát eléri.

FONTOS megjegyezni, hogy a frissítéseket általában csak jól átgondoltan, előre történő tájékozódást, tervezést követően érdemes használni, ugyanis nem véletlen, hogy többnyire éjszaka hajtják végre ezeket. A frissítés lefutása alatt a szerver erőforrásai nagyobb igénybevételnek vannak kitéve, ami rosszabb esetben akár a számlázás folyamatát is gátolhatja. Más részről előfordulhat, hogy a nap közben fokozottabban változó adatok miatt inkonzisztencia alakul ki a Kontrollinghoz generált adatok között. (Pl.: az adatfrissítés alatt zajló, új ügyfélnek történő számlakiállítás adataiból maga a számla már bekerül a Kontrolling adatai közé, de a kapcsolódó ügyfél még éppen nem. Ez természetesen hibákat eredményez majd az OLAP frissítése során, a feldolgozás megszakad és mindaddig elölről kell kezdeni a teljes frissítés folyamatot, amíg helyesen be nem sikerül frissítenünk az adatokat.)

18. Backup

Az Updater műveletek természetesen biztosítják a biztonsági mentés elvégzésének lehetőségét mind az SQL, mind az OLAP esetén. Mindkét művelet indításakor a szerveren definiált alapvető adatbázis mentések történnek meg. Erre általában nincs szükség, mivel ezek a mentések rendszerint éjszakánként is megtörténnek a beállított job-ok által, de igény szerint itt is végrehajthatók. Ezeket ugyan párhuzamosan is lehet futtatni, mégis célszerű sorban megtenni, mivel együtt még fokozottabban terhelik az erőforrásokat. A biztonsági mentések a szerveren alapértelmezetten meghatározott helyre kerülnek.

Biztonsági mentést csak arra jogosult felhasználó végezhet. Ezen kívül az SQL biztonsági mentés művelet elvégzéséhez természetesen elegendő, ha érvényes SQL kapcsolatunk van. Az OLAP biztonsági mentésének elvégzéséhez ugyanakkor a kapcsolatrekord teljes körű érvényessége szükséges (hiszen nem csak OLAP adatbázis műveletet hajt végre, hanem naplózza is azt az SQL adatbázison), valamint az OLAP adatbázis létezése is adott kell, hogy legyen (hogy legyen mit menteni)!

19. SQL feldolgozás

A Kontrolling frissítésének/verzióváltásának első lépése az SQL feldolgozás. Erről a „K4_Kont_job" nevű eljárás gondoskodik, amit ilyenkor mindig le kell futtatni. Itt is elérhető a „Rendszer paraméterek" gomb, melynek segítségével a Kontrollingban már megszokott paraméterező felülethez jutunk. Itt még az SQL feldolgozás előtt rá lehet nézni, be lehet állítani az esetleges Kontrolling paramétereket, ha az éppen szükséges. 

FONTOS, hogy soha ne futtassuk ezt a lépést, ha éppen zajlik az OLAP generálása, vagy fut az éjszakai job! Hacsak nincs valamilyen rendkívüli ok, amely indokolná a műveletet, azt javasoljuk, hogy ez a lépés a rendes éjszakai adatkarbantartás keretein belül történjen meg, és annak végeztével, másnap történjen meg az OLAP frissítése, verziócseréje!
Érdemes tudni, hogy szeparált adatbázisos esetnél az SQL feldolgozást (k4_kont_job) mindig a szeparált adatbázison futtatjuk, ugyanakkor a rendszerparaméterezést az éles adatbázison hajtjuk végre. Az éles adatbázis paraméterei az éjszakai job folyamán kerülnek át a szeparált adatbázisra.

Az SQL feldolgozás futtatásának feltétele a jogosult felhasználón túl az érvényes SQL kapcsolat. Ez utóbbinál szeparált adatbázisos esetnél - mivel ilyenkor a szeparált adatbázison fut maga a feldolgozás is - érvényes szeparált adatbázis kapcsolat is szükséges! A Rendszer paraméterek gomb indításához érvényes felhasználói jogok és érvényes SQL kapcsolat szükséges.

20. Kontrolling program frissítése

A Kontrolling program frissítését akár önállóan is elvégezhetjük, ilyenkor csak a program adott verzión való legfrissebb példányának beállítása történik meg. Természetesen verzióváltáskor is ugyanezt a felületet használjuk. A verzió kiválasztása automatán történik meg a rendelkezésre álló Vectory/SQL verzió alapján. A „Telepítés beállításai" gombbal lehet beállítani a részleteket, hatására egy táblázat nyílik, melyben megadhatjuk a telepítés helyét, az architektúrát, azt, hogy generáljon-e a kapcsolati táblázatból új INI fájlt, valamint, hogy frissüljön-e a parancsikon (lnk) végül. A beállításokat a registry-ben próbálja eltárolni a program, hogy legközelebb is emlékezzen azokra.

A felhős eseteket kivéve mindig a registry-ben az alábbi bejegyzésben kerülnek eltárolásra és visszatöltésre a telepítési információk egy XML szerkezetű stringként:

DevelDir: CurrentUser\SOFTWARE\Kontrolling\ExePath

Exe frissítésekor kerül beállításra a kont_version rendszerparaméter. Ez a paraméter több helyen is szerepet játszik (pl e-mail modul működése, automata menüfrissítés, stb.). Az Updater exe frissítésekor az új kontrolling.exe verziószámának rövid (4-jegyű) változata kerül a paraméterbe. Előfordulhat azonban, hogy nem csak egy adatbázisa van az ügyfélnek. Ilyen esetben jellemzően közös exe-t használnak a különböző adatbázisok, így csak egy központi helyen kell az exe-t lecserélni. Emiatt a jelenség miatt - nem felhős esetnél - ellenőrzi a program az INI-ben, hogy van-e más olyan ini rekord, ahol más adatbázis is ugyanehhez a szerverhez tartozik. Az összes ilyen esetnél is automatán frissíti a ‘kont_version’ paramétert a program.
Felhő esetén ugyanez a jelenség közel sem ilyen egyértelmű, mivel ott minden ügyfél adatbázisa azonos szerveren van. Éppen ezért, ha felhőben cserél exe-t a program, akkor mindig rákérdez, hogy frissítse-e minden ini rekord esetén is a “kont_version” paramétert. Itt ugyanis csak a felhasználó tudja, hogy az adott INI-ben egy cég különböző adatbázisai szerepelnek-e, vagy sem, így az ő felelőssége ezek felülírása is.
Amennyiben a paraméter felülírása megtörténik, akkor egyúttal a szalagmenüt is frssíti a program, mivel ennek is változhat az összetétele, és annak mindig az aktuális “kont_version” szerint kell betöltődnie.

Exe telepítésénél csak érvényes SQL adatbázis elérés és felhasználói jogosultság szükségesek. Minden más feltételt a folyamat futás közben ellenőriz.

21. OLAP műveletek

Kétféle OLAP műveletről beszélhetünk: az egyikkel az OLAP adatbázist újra legenerálhatjuk, míg a másikkal csak az OLAP adatbázis adatait frissítjük. Ez utóbbi szokott éjszakánként rendszeresen lefutni az adatkarbantartó job részeként is, ezt az OLAP műveletek közül az alsó sorban találjuk „Olap DB újraépítés" néven. Ha az SQL feldolgozást és ezt egymás után lefuttatjuk, akkor tulajdonképpen az éjszakai Kontrolling frissítést végezzük el.

FONTOS, hogy soha ne futtassuk ezt a lépést, ha éppen zajlik az SQL feldolgozás, vagy fut az éjszakai job!

A másik OLAP művelet az OLAP generálása, ami a felső sorban található egy gomb formájában, „Olap Transzformáció" néven. Ez az OLAP frissítéstől abban különbözik, hogy az adatfrissítés előtt magát az OLAP adatszerkezetet is újra alkotja a verzió és a korábbi beállítások alapján megadott séma szerint. Ezzel a művelettel végezhető el az Olap adatszerkezet verziófrissítése is. Működését később részletesen tárgyaluk még (lásd: Olap Transzformátor). Az archív adatbázis verziófrissítését biztosító Archiv db gomb az Updater kék paneljén található. Érvényes OLAP kapcsolat és létező OLAP adatbázis esetén használható. A frissítés minden esetben az éppen aktuális OLAP verziószámtól az éppen érvényes SQL (azaz Vectory) verziószámig frissíti fel az archív adatázist, amennyiben az létezik. Amennyiben archív adatbázist használunk, akkor annak frissítését közvetlenül a Vectory verziófrissítése után, de még a Kontrolling verziófrissítése előtt kell elvégezni. Az így archív adatbázis frissítést követően mindenképpen ki kell várni egy Kontrolling SQL adatfeldolgozást is az éjszakai job-ban, mivel csak ezután végezhető el a Kontrolling verzióváltása.

Az Olap DB Újraépítés indítógomb és az Archiv db gomb használatához teljes körű kapcsolatérvényesség kell, az OLAP adatbázis létezése is szükséges! Mindkét gombot megfelelő felhasználói jogosultsággal lehet használni. Archív adatbázis frissítésénél mind az SQL, mind az OLAP verziószámát le kell tudni kérdezni, azonosítani, hozzáférni kell az archív adatbázishoz és azon végrehajtani a frissítést. Az OLAP újraépítésnél pedig maga az OLAP kell, hogy hozzáférjen az SQL-hez a nevünkben, és végre is kell tudnunk hajtani az OLAP frissítés indítását! A Sérült Olap db helyreállítása gomb feltétel nélkül használható, ez ugyanis nem okoz semmilyen módosítást, mindössze egy OLAP kapcsolódást próbál létrehozni, ami bizonyos esetekben helyreállítja a sérült OLAP adatbázist. Még maga az OLAP kapcsolat sem szükséges ehhez, hiszen ez általában ilyenkor nincs. A helyreállítás pedig eleve csak akkor indítható, ha a felhasználó jogosult a kapcsolódásra így maga a folyamat egyben az ellenőrzés is.
Az OLAP transzformáció gomb használatához teljes körű kapcsolatérvényesség kell, mivel mind az éles, mind a szeparált SQL adatbázis, és az OLAP adatbázis is egyszerre szükségesek hozzá.

22. E-mail küldő modul

Amennyiben rendelkezünk e-mail küldő modullal, és azon a szerveren indítjuk az Updatert, ahol telepítve van, akkor aktív a következő művelet indítógombja is. Itt magát az e-mail küldő modul programját tudjuk befrissíteni. Mivel ez a program általában az SQL szerveren van elhelyezve, így ennek a pontnak a használatához szükséges, hogy magán az SQL szerveren futtassuk azt. A fenti gombok között csak hozzáértő módban látható az „E-mail modul telepítése" (ezt a Vector Kft-nek kell elvégeznie kezdetben), míg az „E-mail modul tesztelése" segítségével a modul működését tudjuk vizsgálni, elemezni, az „ E-mail modul paraméterek" gomb pedig a modulhoz kapcsolódó paraméterek szerkesztését teszi lehetővé.

23. OLAP Transzformátor

Az OLAP Transzformátor (amit a továbbiakban röviden trafó néven illetünk) a teljes OLAP adatbázis legenerálásáért felelős. Ezzel valósítjuk meg a kezdeti OLAP adatbázis telepítését, az OLAP verziócseréket, vagy éppen optimalizálhatjuk, átalakíthatjuk az OLAP szerkezetünket. Ez utóbbiból ered az elnevezése is.
Egy OLAP adatszerkezet éppen aktuális összeállításának számos befolyásoló tényezője van. Ezek közül a legfontosabbak:

• az aktuális Kontrolling paraméterezése (pl. mennyi cikkcsoportunk van, használunk-e egyedi fejlesztésű adatokat, stb.)
• az új OLAP adatszerkezet (új mezők esetleges bevezetése, régiek kivezetése stb.)
• az előző OLAP adatbázis (a Trafó próbálja átvenni a korábbi beállításokat)
• egyedi beállításaink (igény szerint be/kikapcsolt elemek, addonok)
• belső szerkezeti összefüggések (hierarchiák, függőségek biztosítása)
• gyári szabályok

Az Updater OLAP transzformáció gombját lenyomva megjelenik a trafó kezdőfelülete. Itt ismét a kapcsolati adatok tisztázásával kezdünk, aminek két oka is van. Egyrészt mivel önálló futást is támogat a program így nem feltétlenül adottak a kapcsolati információk. Az Updaterből indítva ugyanakkor ezek nyilván rendelkezésre állnak, ezért ilyenkor egyszerűen átadja és automatán ki is tölti a program a már használt kapcsolati információkat.
A kapcsolati információk tisztázásának másik oka a verziók ellenőrzése, ez ugyanis meghatározza a további működést.

A trafó betöltésének megkezdése előtt itt is van lehetőségünk az SQL feldolgozás elindítására (lásd: a szalagmenü K4_kont_job menüpontja), vagy az SQL paraméterezésre a kapcsolati adatoknál). FONTOS, hogy soha ne futtassuk a k4_kont_job lépést, ha éppen zajlik az OLAP generálása, vagy fut az éjszakai job! (Ez utóbbi amitt lényeges, mert a k4_kont_job eljárás teljesen újragenerálja az összes Kontrolling adatot SQL szinten, az OLAP feldolgozás pedig az újra generált adatokra építve generálja le saját adatait. Ha tehát az OLAP generálás futása közben módosítjuk az őt megalapozó adatokat, annak jobb esetben is inkonzisztencia, rosszabb esetben pedig OLAP generálási hiba, és emiatt esetleg sérült OLAP adatbázis lesz a következménye.)
Mindenképpen szükség van az éppen érvényes és a telepítendő OLAP adatbázis verziószámára. Az előzőt megpróbálja lekérdezni, az utóbbit pedig az érvényes SQL és OLAP verziók alapján kitalálni a program. Itt csak akkor van teendőnk, ha valamelyik nem sikerül, ilyenkor manuálisan tudjuk ezt megtenni (jellemzően nagyon régi, 5529 előtti Olap verziók esetén fordulhat elő).
Mindig a telepíthető verziók közül az adott Vectoryhoz elérhető legnagyobb verziószámút választja ki a rendszer telepítésre. Amennyiben nem váltunk verziót (azaz a jelenlegi, és az új verziók egyeznek), akkor is tudunk természetesen adatszerkezetet módosítani a trafó segítségével. Ez utóbbi az OLAP adatszerkezet összetételének módosítására, optimalizálására használható fel első sorban (ha pl szükség lenne egy eddig nem használt OLAP mezőre, vagy ha éppen nincs szükség néhány dimenzóra, mert soha nem hasnzáljuk fel azokat).

A Betöltés gomb hatására megkezdődik egy kb. fél-egy perces folyamat, ami alatt a trafó elemzi a jelenlegi OLAP adatbázist, a jelenlegi verzióhoz tartozó OLAP adatszerkezetet, és a telepítendő OLAP szerkezetet. E három elemzést, és még számos mást (pl. rendszerparaméter hatást, és függőség vizsgálatot, stb) figyelembe véve betölt egy kiinduló adatszerkezetet a program.

24. A trafó betöltésének lépései

Trafó betöltéskor az alábbi lépéseken megy végig a folyamat:

1. Kapcsolatteszt, verzióinformációk lekérdezése
2. Mapparendszer és adatszerkezeti fájlok biztosítása: Az Updater program saját mappáján belül egy WORK almappába kerül az új, nyers OLAP adatszerkezet. Ez tehát egy új verziónak megfelelő gyári, alapértelmezett adatszerkezet. Végig ezt írja, alakítja majd a program, és csak a kész változatról készül majd mentéskor egy másolat a Devel mappába. A WORK mappa tartalma nem maradandó, ezt a kezdeti betöltéskor mindig üríti a program. A letöltés eleinte egy TMP almappába történik, ugyanitt kerül kibontásra is a letöltött adatszerkezet telepítőfájlja, és csak ezt követően kerül át a WORK mappába, ahova egy verziószámnak megfelelő almappában lesz megtalálható az adatszerkezet. A WORK-ön belül adatszerkezeti mappában egy PREV almappa is keletkezik, ami az előzmény verzió adatszerkezetét tartalmazza majd mivel ezt is pontosan látnia kell a programnak a betöltéshez. Legvégül egy .kot_default almappa is készül a WORK-ön belüli adatszerkezeti almappában. Ez utóbbi azt a célt szolgálja, hogy ide kerül a kezdeti, érintetlen adatszerkezetek másolata (vagyis a WORK eddigi teljes tartalma), így egy esetleges újratöltésnél, alaphelyzethez való visszaállásnál ez már adott lesz, nem kell ismét letölteni, kibontani a telepítőfájlokat.
3. Betöltés csak az előző lépés sikeressége esetén történik. A betöltés előfeltétele egy trafo.xml nevű előelemzési fájl, amit az adatszerkezeti csomag tartalmaz. Ha bármi miatt ez mégsem állna rendelkezésre, akkor a trafó felajálnja, hogy elkészíti azt (ilyen esetben egy kb 20 perces folyamat során tudja legenerálni a fájlt). Ha létezik az előelemzési fájl, csak akkor folytatódhat a betöltés.
4. A kezdeti OLAP fa struktúra inicializálását követően előszöt néhány SQL beállítást végez a program. Ehhez SQL sriptek futtatására kerül sor, ami során első körben egy _olapszotarfeltolto.sql fájl tartalma kerül futtatásra. Ez az aktuális verzióhoz tartozó szabályokat generálja le, illetve a verziónak megfelelő szótárazást biztosítja. Előfordulhat eseti jelleggel, hogy van egy KontrollingUpdater.sql scriptünk is, ami szintén itt kerül ilyenkor futtatásra esetleges fontos beállításokkal a verzióhoz. A scriptek alapján néhány beállítás még történik végül lekérdezi a program az így előállt állapot szerinti szabályokat és szótárazásokat az ezt követő betöltéshez.
   Az sql scripteket követően megtörténik az aktuális OLAP adatbázis dimenzióinak, attribútumainak lekérdezése is egy-egy MDX lekérdezéssel. Ebből tudja majd a program, hogy mi szerepelt és mi nem korábban.
5. Maga az OLAP adatszerkezet betöltése az eddigiek felhasználásával történik meg. Elsősorban az előelemzési fájl adatai szerint megy a betöltés, de az adatszerkezet fájljainak olvasására is sor kerül közben (pl láthatósági és az előző verzióban való létezés ellenőrzésére). Közben az aktuális szótárazási rekordokat és a szabályokat is figyeli. Szabályok általában arra kellene, hogy szinkronban legyen az SQL és az OLAP adatgenerálása. Ezáltal ha egy addon paraméter aktív, akkor az SQL szátítsa ki az ehhez szükséges adatokat, az OLAP pedig töltse be azokat, ha viszont nem aktív az addon paraméter, akkor ne kerüljön sor az SQL ide vonatkozó felesleges számításaira sem és ne is létezzen az az OLAP mező, ami ezt használná. A betöltés során fontos szerepet kap még az előző adatbázis és az előző adatszerkezet állapota is. Az előzőből tudja, hogy létezett-e (aktív volt-e) eddig is az OLAP mező, az utóbbiból pedig, hogy új OLAP mezőről van-e szó. A betöltés alatt egyúttal a szótárazás is frissül. A fa struktúra kitöltésével megkapjuk a betöltés kiinduló fázisát, ami már minden adatot tartalmaz, de még messze nem tökéletes.
6. A kiinduló fázis már lehetővé teszi, hogy mélyebb összefüggéseket keressen a program. Így egy következő elemzés is történik, ami a rejtett mezőket redukálását végzi. Végig eddig is és itt is fontos a függőségi rendszer, amit az előelemzés ad. Az elv szerint ha egy rejtett mezőt függőség szerint nem használ fel semmilyen más aktív mező, vagy hierarchia, akkor ez a rejtett mező elhagyható. Ennek megfelelően kerülnek kihagyásra mezők.
7. Új mezők elemzése következik. Sajnos az eddigiek alapján tévesen bekapcsolásra kerülhettek dimenziók, ezeket rendbe kell tenni. Ha ugyanis egy korábban már kikapcsolt dimenzióba új mező került az új OLAP verzióban, akkor az új mező - mivel új - automatikusan aktív is lesz először. Ez viszont a függőségi szabályok miatt automatikusan feléleszti a kikapcsolt dimenziót is. Az ilyen esetekek ismeri fel ez az elemzés, és visszaállítja inaktív állapotúra az ilyen eseteket.
8. A következő elemzési kör a pipáltsági események miatt kell. Amikor ugyanis még épül a fa struktúra, hiába tudja már a rendszer menet közben is kitalálni, hogy milyen bekapcsoltsági állapotok vannak az egyes mezőknél és annak mlyen függőség hatásai vannak, mivel még nem is létezik a fa struktúrában számos olyan mező, amire ez hat (hiszen éppen épül a struktúra). Ezért most, mikor már felépült a teljes struktúra, lehet egy teljes körű elemzést végezni azon.
9. Az eddigiek már biztosítanak egy összefüggő érvényes OLAP adatszerkezetet, azonban az OLAP belső mechanizmusa miatt (függőségek, hierarchiák, stb.) felboríthatja néhol a szabályokat. Így ez a rész ellenőrzi és szükség esetén beállítja ismét azokat, hogy a szabályok garantáltan teljesüljenek. Ennek a folyamatnak garantáltan a betöltés végén kell lefutnia, hogy mikor ez biztosítja a szabályok teljesülését, azt már semmi ne boríthassa fel ezt követően. Emiatt ezt a részt záró rendelkezésekként emlegetjük.
10. Az OLAP adatszerkezet már betöltődött és jó is, ám egy gyakran visszatérő probléma szokott lenni a generálásnál a törölt áfakódok miatti inkonzisztencia, ami miatt megáll majd a későbbi OLAP generálás. Ezért a betöltés végén mind az éles, mind a szeparált adatbázisban (ha ez utóbbi van) biztosítja a program a törölt áfakódok rendezését.
11. A betöltési folyamat végül egy log írásával zárul. Az xml alapú log fájlnak itt még csak egy kezdő része kerül kiírásra: a teljes betöltéskori állapot.

Előfordulhat, hogy a betöltéskor providerrel kapcsolatos kérdés jelenik meg egy üzenetablakban. Ez az üzenet tipikusan akkor szokott megjelenni, ha az updatert futtató windows felhasználónak nincsen jogosultsága a megadott adatbázishoz. Ebben és a Visual Studiós fázisban pedig ennek a felhasználónak az accountját használja az Olap szerver az SQL szerverhez való kapcsolódáshoz, csak az éjjeli jobok során fogja a saját szerviz accountját használni.
Érdemes tehát az SQL Server Management Studioban felvenni ezt a felhasználót rendszer- és adatbázis szinten is. Ha így sem működik, másik lehetséges ok, hogy az updatert futtató gépen és/vagy az SQL szerveren nincs telepítve a megadott OLE DB Provider, de ez az esetek elenyésző részében fordul csak elő.

Az így betöltött adatszerkezet figyelembe veszi tehát előző beállításainkat ugyanúgy, mint a megújult adatszerkezetet, vagy a rendszerparaméter szerinti tiltásokat. A betöltéssel egyidőben az OLAP adatszótár is frissítésre kerül a leendő verzióra.
Az adatszerkezet fastruktúra-szerűen tartalmazza a dimenziókat, és a mértékcsoportokat, ezeken belül pedig valamennyi mezőt. A minden sor elején található pipával az jelezzük, hogy fizikálisan beépüljön-e az adott OLAP objektum az adatbázisba. Ha itt kikapcsolunk egy elemet, akkor az ténylegesen nem lesz része az OLAP adatbázisnak, azaz nem fog létezni ilyen elem, és nem kerül bele adat, nem végez rá számításokat az éjszakai feldolgozás. Nyilván ilyenkor az OLAP adatbázis által igényelt erőforrás is ennyivel kevesebb lesz. A Trafó tehát ilyen módon egyfajta optimalizálásra is használható, hiszen, ha kivesszük a nem használandó elemeket, akkor akár gyorsabb éjjelenkénti feldolgozáshoz, és kisebb adatbázis mérethez, ezáltal gyorsabb lekérdezésekhez is juthatunk általa.
Az elemek ki/bekapcsolásakor viszont érdemes szem előtt tartani, hogy számos elem működése összefügg egymással, mivel egymástól függhetnek.
Ezért, ha olyan elemet kapcsolunk ki, amitől más elemek is függenek, akkor természetesen azokat is automatán kikapcsolja a program, és erre figyelmeztet is. Így biztosítja az adatbázis működőképességét.
Hasonlóan, ha olyan elemet kapcsolunk be, amihez más kikapcsolt elemek is szükségesek, akkor ezeket is bekapcsolja egyúttal a trafó, és tájékoztat erről. Természetesen a függőségek nem kölcsönösek, tehát ha kikapcsolunk egy elemet, majd visszakapcsoljuk, a tőle függő kikapcsolt elemek nem kerülnek vissza automatikusan.
A sorokban zölddel háttérszínnel jelöljük az új elemek sorait, tehát azokat, amelyek azért nincsenek a jelenlegi OLAP adatbázisunkban, mert az új OLAP verzióban kerültek bevezetésre. Az ilyeneket általában csak akkor nem kapcsolja be eleve a program, ha azok egy már korábban is létező, kikapcsolt dimenzió elemei.

25. A trafó OLAP összeállítás kapcsolgatásának lépései

Ha egy már betöltött összeállítást szeretnénk még jobban személyre szabni az egyes elemek ki-, bekapcsolásával, akkor érdemes tudni, hogy az elem közvetlen kapcsolásán túl az alábbi automata folyamatok is megtörténnek ilyenkor:

• Ha aktiválunk egy elemet, akkor minden mást is aktiválni kell, ami függőség, vagy szabály szerint kell a működéséhez. Ilyenkor a trafó ezeket is automatán bekapcsolja, mivel e nélkül a mező nem lenne használható. (Figyelem! Ha ugyanezt a mezőt viszont kikapcsoljuk később, akkor a működéséhez bekapcsolt elemek nem feltétlenük kapcsolódnak majd ki, hiszen ezek működését nem akadályozza a mező kikapcsolása.).
• Bizonyos mezőket előfordul, hogy nem enged kikapcsolni a trafó (pl. Időszak - teljesítés, Cikkek). Ilyen eseteknél egyszerűen nem tudjuk kivenni a pipát a mezőtől. Az ilyen mezők gyerek node-jait sem tudjuk inaktívvá tenni.
• Ha kikapcsolunk egy mezőt, akkor előfordulhat, hogy számos más tőle függő mező is kikapcsolásra kerülne vele együtt. Ilyen esetben a program a mező kikapcsolása előtt figyelmeztet erre, és rákérdez a mező kikapcsolására a tőle függő elemeket felsorolva. (Fgyelem! Ha ugyanezt a mezőt később mégis bekapcsoljuk, akkor a vele együtt kikapcsolásra került többi mező nem kerül automatikusan visszakapcsolásra, mivel ezek aktivitása a mezőhöz már nem szükségszerű.)
• Szülő node ki-, bekapcsolása esetén annak valamennyi gyerek node-ja is automatán átveszi a szülő bekapcsoltságát.

A sorok sárga hátterű cellái szerkeszthetőek, és a Kontrollingban is elérhető szótározási szövegezések érhetők el itt is, és írhatók át. A fa-struktúra kereső sorral is rendelkezik, így könnyen megkereshetjük benne a kívánt mezőket.
A szótárbeállításokhoz tartozik még a felső szalagmenü egyik csoportja is, amelynek segítségével alaphelyzeti szótárfeliratozást, új idegen nyelvi szótárt vezethetünk be.

A már betöltött OLAP adatszerkezet esetén két menüpontunk is van, amelyekkel alaphelyzetbe hozható ismét az adatszerkezet. Az Újratöltéssel ismét teljes egészében letölti az adatszerkezeti csomagokat, majd újra tölti a fa-struktúrát, míg az Alaphelyzetbe állítással csak a letöltés nélküli újra töltést végzi el.

Természetesen lehetőségünk van úgy is hagyni az adatszerkezetet, ahogyan az kezdetben betöltődik. Ekkor egy alapértelmezett struktúrával fogjuk tudni legenerálni azt. Egy normál verziócserénél a legtöbb felhasználónak ennyi általában elegendő.

26. A trafó mentési folyamata

A trafó mentése - a betöltéshez hasonlóan - szintén több lépésből áll.

1. Előkészületek a mentéshez: Az SQL adatbázis kapcsolat ellenőrzése és a k4_olap tábla elérhetősége szükségesek a mentéshez, így ezeket ellenőrzi először a program.
   Egy biztonsági mentés is készül az egész projectről, mielőtt hozzányúlna a trafó. Ilyenkor a teljes mappatartalomról másolat készül. A k4_olap tábla mentéséhez adapterbeállítás történik és nullázódik a dimenzióhivatkozások számlálása (ez szabályozza majd a dimenzió xml-ek integrálását, mivel akkor kerül integrálásra egy dimenzió xml-je, ha legalább egy OLAP mező használja azt (ez főleg alias-szerű töbszörös felhasználásnál érdekes)).
2. Befrissíti a trafó a k4_olap táblát annak teljes ürítésével és az OLAP adatszerkezet szerinti előállításával. Ennek végén sor kerül a kont_version_olap rendszerparaméter frissítésére is, ahova az új OLAP adatszerkezet verziószáma kerül be. (Megj.: Persze fizikálisan ezen a ponton még valójában nem új az OLAP adatszerkezet, mivel azonban a trafó hatáskörén kívül esik az új OLAP generálása (többnyire Visual Studio programmal történik), így ez a pillanat áll a legközelebb a friss OLAP adatainak bejegyzéséhez. Tehát ténylegesen már a mentéskor bejegyzésre kerülnek az adatszerkezet adatai, és feltételezi a program ilyenkor, hogy a folytatásban ez meg is valósul.)
3. Ismét, másodjára is végigfut a trafó a fa struktúrán, ahol egyszerre több műveletet is végez. A legfontosabb, hogy minden elhagyott mezőhöz tartozó valamennyi xml bejegyzéseket törli az adatszerkezetből. Mivel a fa struktúra lehetőséget ad a szótárat átírni, így lefrissíti a szótárazást is a mentési folyamat. A mentéskor is sor került az xml log további írására, itt a mentéskori állapot kerül összeállításra. A folyamat végén a menet közben törölt/átírt számított measure képletek is visszaírásra kerülnek és törlődnek a nem használt dim fájlok. Mentésre kerülnek a többi adatszerkezeti xml fájl is az adatszerkezet alapján.
4. Az OLAP szótár frissítése is megtörténik az esetleges változtatásokkal.
5. Elkészült a WORK mappában fájl szinten az új OLAP adatszerkezet. Erről egy másolatot készít a program a DEVEL mappába is, ami megmarad majd. A Devel mappába az új OLAP adatszerkezet verziószáma és az adatbázis neve szerint meghatározott almappába kerül majd az adatszerkezet, így csak akkor írunk felül itt csomagot, ha ugyanarra az adatbázisra ugyanazt a verziót készítjük el vele. Így viszont garantáltan az adatbázist s felülírjuk majd ezzel, tehát a Devel mappában minden adatbázis minden verziójának utoljára használt adatszerkezete lesz majd megtalálható. A másolatban csak az érvényes adatszerkezeti fájlok kerülnek (így tehát a korábbi betöltést segítő PREV és .kot_default mappák törlődnek).
6. Az időszak függések feltérképezése következik. Az előállt OLAP adatszerkezet kapcsán a Kontrolling számos esetben időszaki kimutatásokat használhat. Ezekhez pontosan tudnia kell a programnak, hogy milyen időszaki függés feltételek vannak éppen, és hogy milyen időszaki dimenzió attribútumok jók ehhez. Ezt szedi össze a mentés alkalmával egy folyamat és menti el a k4_olap táblába a szükséges informácókat.
7. Az összeállított mentés xml log kiírása történik meg ezután, amit felhő esetén a mail modul automata frissítése követ, végül a trafó mentési folyamata naplózásra kerül.

Ha úgy gondoljuk, hogy már megfelelő az OLAP adatszerkezetet, akkor nekiláthatunk a generálásnak. Ennek első lépése a mentés. Amíg nem mentjük el a struktúrát nem tudjuk generálni sem azt, mivel a mentés készíti elő az egész folyamatot, és a még befejező elemzések mellett gyártja le az OLAP adatszerkezeti projectet.

Ha a mentés megtörtént, akkor 3 módon tudjuk elvégezni a generálást. Mind a három mód a Visual Studio segítségével történik, ezért ennek megléte mindenképpen szükséges feltétel hozzá (Egészen pontosan a régebbi verziók esetén elegendő az SQL Server Data Tools for Visual Studio, Visual Studio 2019 vagy újabb esetén pedig le kell még tölteni és telepíteni a SQL Server Data Tools extensiont. Azokon a szervereken, ahol előzesen mi telepítettük a kontrollingot, általában valamelyik elérhető.)
FONTOS, hogy soha ne futtassuk az OLAP generálását, ha fut az éjszakai job, vagy egy másik folyamat is éppen ugyanezt frissíti!

1. A legegyszerűbb az „Olap adatbázis létrehozása" menüpont, ami egyszerűen elindítja a generálást folyamatát, ami a háttérben fut, és a végén listázza az eredményt. Ez a megoldás a Visual Studio devenv.exe programját használja fel a háttérben, valamint az Analysis Services Microsoft.AnalysisServices.Deployment.exe hívását.
2. Ha a részletekre is kíváncsiak vagyunk, akkor célszerű a „Visual Studio" gombot használni. A gombot lenyomva a Visual Studio nylik meg, amibe a legyártott project betöltésre kerül, és itt is elindíthatjuk az OLAP adatbázis generálását a következő módon: Ha a betöltött project esetén a Solution Explorer ablakban kikeressük „VywOlap1.1" elemet, majd azon jobb klikket nyomunk, akkor a lenyíló menüből kiválaszthatjuk a „Process…" menüpontot. Ilyenkor egy előelemzést követően tudjuk elindítani a generálást. E módszernek az a legnagyobb előnye, hogy végig szem előtt tarthatjuk a folyamatot, ami egyébként több szálon is fut, és ha elakad bármiért, egyből lesznek részletes információink is az okokról.
   
3. A harmadik lehetőség pedig az ütemezés, ehhez a „Job létrehozása ütemezéshez" menüpontot használhatjuk fel. Ahogy a gomb neve is mutatja itt egy job jön létre, amit egyszeri lefutásra állíthatunk be, és akár önmegsemmisítéssel is elláthatjuk azt.

Amennyiben sikeresen használtuk a trafót és verziót váltottunk az OLAP adatbázison (vagy csak frissítettük azt), megváltozhattak ezáltal a kapcsolati adatok is (pl OLAP verziószám, utolsó adatfrissítés időpontja, OLAP kapcsolat, stb). Ilyen esetben a trafót bezárva és az Updaterre visszatérve, ha indokoltnak látjuk, érdemes az Updater aktuális kapcsolatát is frissíteni (pl. a kék panel bal felső sarkában lévő “Kapcsolat betöltése” gombbal), mivel ilyenkor újratölti az Updater a kapcsolatadatokat, de már a megváltozott állapot szerint. Így érvényesíthető az OLAP műveletek hatása (pl rájön az Updater, hogy most már megfelel az OLAP verziója az SQL-nek, így engedi a mail modult is frissíteni).

27. Kontrolling verziócsere

Az egyes alapfunkciók ismertetése után lássuk, hogyan javasoljuk az egyik legfontosabb folyamatot, a Kontrolling verziócseréjét elvégezni:

1. Első lépésként a Vectory program és az adatbázis(ok) verziócseréjét kell megtenni a vectory verziófrissítővel.
2. Amennyiben az új Vectory programverzióhoz kiadásra került ugyanilyen verziójú Kontrolling is, akkor a legfrissebb KontrollingUpdater alkalmazás a bejelentkezések után automatikusan felismeri és lehetővé teszi a legújabb verzió letöltését. A mappák esetleges kiválasztása után (lásd: Telepítés beállításai gomb) megtörténhet a Kontrolling kliens frissítése.
3. Általános ügyment esetén azt javasoljuk, hogy várják meg, míg az összes éjjeli adatkarbantartó job, köztük a kontrolling generálás sikeresen lefut, és csak másnap kora reggel kezdjék el az Olap adatbázis verziófrissítését , amely az Olap transzformáció használatával lehetséges (amíg az első éjjeli adatkarbantartó job futásával nincs meg a teljes, új verziójú SQL adatszerkezet, addig nem lehetséges az új Olap verzió generálása). Alapesetben félautomatikus a folyamat, azaz az alapértelmezett beállítások legtöbbször megfelelőek, a verzió újdonságok automatikusan bekerülnek (amit rendszerparaméterhez kötünk, azokat az éjjeli adatkarbantartás előtt szükséges paraméterezni). Nincs más dolgunk, mint betöltés után a szalagmenüben a „Mentés"-re kattintva elmenteni az új adatszerkezetet, majd az „Olap adatbázis létrehozása", esetleg „Visual Studio" ikonra kattintva telepíteni az új adatszerkezetet. Amennyiben több kontrollingos adatbázis is van a rendszerben, mindegyikre külön-külön, egymás után el kell végezni az Olap frissítését.
   Ha valamilyen okból nincs mód megvárni az éjjeli adatkarbantartás végét, és mindenképpen szükségünk van az új Olap adatszerkezetre, akkor az Updaterből manuálisan elindítható a „K4_Kont_job" nevű eljárás, ennek használatát azonban még tapasztalt rendszerüzemeltetőknek is csak megfelelő körültekintéssel, kizárólag saját felelősségére javasoljuk. Leginkább azért, mert napközben nagyon megterhelheti a rendszert, amely komoly lassulásokhoz vezethet, illetve ha túl közel van az éjjeli adatkarbantartáshoz, nem biztos, hogy az SQL futása és az új Olap adatszerkezet generálása belefér a rendelkezésre álló időkeretbe, és így ütközés lehetséges.
4. Végül az E-mail küldő modul frissítését (ha van) kell elvégezni. Mivel ez figyelembe veszi az OLAP adatbázis verzióját is, ezért érdemes csak a 3. lépésben leírt OLAP verzióváltás követően futtatni a mail modul frissítést.

28. Szeparált adatbázis

A Kontrolling általában a Vectory adatbázisát használja éles SQL adatbázisként. Néhány esetben azonban általában a nagy adatmennyiség miatt indokolt lehet külön adatbázist biztosítani számára. Ez utóbbit nevezzük szeparált adatbázisnak. Működését tekintve az éles Vectory adatbázisáról az éjszakai job adatkarbantartása során teljes másolat készül. Így minden éjjel felülíródik ez a szeparált adatbázis. A felülírás gyors folyamat, viszont ezt követően a feldolgozás már nem fogja érinteni a Vectory éles adatbázisát. Sok esetben ez külön szerverre is kerül, így az erőforrásokat sem a Vectory elől használja el a Kontrolling adatfrissítése.

Fontos tudni, hogy szeparált adatbázist használó Kontrollingok esetén is a felhasználói kapcsolatokat mindig az éles (tehát Vectory-val azonos) adatbázisra állítjuk be! Ennek egyik oka, hogy a szeparáció az éjszakai feldolgozás miatt szükséges, így a jellemzően nappali felhasználói munka nem befolyásolja az éles szerver terheltségét. Másrészt a szeparált adatok éjjelente felülíródnak, az éles adatbázisra történt mentés azonban automatán megmarad.

Szeparált adatbázis beállításakor a job kiegészül tehát egy plusz lépéssel, ami az éles adatbázis másolatát végzi éjjelente.
Azt, hogy a Kontrolling szeparált adatbázist használ-e még az alábbiakból lehet tudni:
A k4_eles és k4_olapdb rendszerparaméterek mindig azonos módon ki vannak töltve mind az éles, mind a szeparált adatbázison. Így a kitöltöttség a szeparáció tényét mutatják, míg a paraméterek értékei azonosítják magát az adatbázist. (Ezért van, hogy érvényes SQL kapcsolatra van szükség ahhoz, hogy a szeparált adatbázisos beállítást egyáltalán vizsgálhassuk.)
A KontrollingUpdater korábban még írta a kapcsolatbeállítások szerint ezt a két paramétert, de igény szerint (2025. február közepétől) már nem fogja írni. A paraméterek a továbbiakban csak manuálisan állíthatók és kell is őket manuálisan állítani, ha szeparációról van szó.

A k4_olapdb_name rendszerparaméter leginkább információs célokat szolgál. Ez mutatja meg az adott SQL adatbázishoz milyen OLAP adatbázis tartozik. Ezt viszont mindig automatán kitölti az Updater, amikor egy kapcsolatot betölt a felhasználó, hiszen ekkor derül ki, mely olap adatbázis kapcsolódik a Kontrollinghoz. (Telepítés esetén pl a leghamarabb itt derül ki: az OLAP adatbázis még nem is létezik, de a leendő neve már megvan, ezért letároljuk.) Később a Kontrolling folyamatai olvassák és fel is használják ezt az információt, ami így az Updatert használva egyből készen áll majd erre.

29. Archív adatbázis

Előfordulhat, hogy archív adatbázis is is készül a Kontrolling kapcsán. Ilyen esetben fizikálisan is egy külön adatbázisról van szó, amely - mivel archív - többnyire nem változik már. Ez persze csak részben igaz, mert a múlt adatai változatlanok, de ezekre is érvényes kell, hogy legyen a mindenkori csoportosítás, gyűjtőzés, stb. Ezért a Kontrolling is leginkább felhasználja az ilyen adatbázis adatait, és csak akkor és annyira dolgozza át őket, amennyire az akutiális helyzet megköveteli. Ha pl módosulnak a táblaszerkezetek, akkor ezt az archív adatokkal is követni kell.
Az updaterben helyet kapott emiatt egy Archív db feliratú gomb is az OLAP műveletek paneljén. A gomb csak érvényes kapcsolatok, jogok és az OLAP adatbázis létezése esetén elérhető. A gombot indítva érvényes SQL és OLAP kapcsolatok esetén ellenőrzi, hogy van-e archív adatbázis, és ha van azonosítja azt (mindezt a k4_tetel_archivum rendszerparaméter lekérdezésével teszi). Mivel szeparált adatbázisos esetnél a szeparált adatbázis szerverén (egyébként pedig az éles adatbázis szerverén) van az archív adatbázis is, így ennek megfelelően állítja be az adatbázis kapcsolatot a felület. Ezt tesztelve, csak sikeres kapcsolat esetén lehetséges az archív adatbázis frissítése.
Az OLAP és Vectory frissítések eseményeit listázza egy táblázatban a program. A frissítés az éppen érvényes OLAP verziótól kezdődik és az éppen érvényes SQL verzióig tart, azaz a két verzió között elérhető minden létező archív frissítést sorban futtat a program az OK gomb lenyomására.
Az archív frissítő scriptek itt keletkeznek:

SVN\mssql\trunk\_egyeb_scriptek\kont\verzio\

Innen pedig automatán ide kikerülnek:

\\vctr-aws-fs01\web\download\!scriptek\verziosql\

Az alábbi link alapján lehet elérni (a példában a 6021->6022 frissítést éppen): https://apiv2.vector.hu/dl?v=6016&p=vyw&f=verzio_k|6021|6022&ki=10574807203