A TMS rendszer adminisztrátorának számos feladatot kell elvégezni. Azért, hogy ezeket a feladatokat minél magasabb szinten tudja megoldani, alapos ismeretekkel kell rendelkeznie a TMS rendszer felépítéséről, belső folyamatairól, működéséről.
Ebben a segédletben gyakorlatorientáltan közelítjük meg az adminisztrátor feladatait, és ilyen szempontból vizsgáljuk azokat az elemeket amikkel az adminisztrátor kapcsolatba kerül. Bemutatjuk ezeket az elemeket (programkomponenseket) és azok használatán keresztül megmutatjuk a rendszer működését. Célunk, hogy az adminisztrátor az itt leírt ismeretek birtokában önállóan is képes legyen a TMS rendszer telepítésére, használatára, esetleg felmerülő problémák megoldására, valamint a változó igényeknek megfelelően a rendszer konfigurálására.
Az ismeretek megszerzéséhez célszerűnek tartjuk az itt leírt tematika szerinti tanulást úgy, hogy minden részfeladat a gyakorlatban is kipróbálásra kerüljön. Az ismeretek egyszerű elsajátításához lehetőleg sok helyen alkalmazunk képeket, példákat, hogy a leírtak minél egyértelműbben értelmezhetőek legyenek.
Célunk, hogy olyan tagolást alkalmazzunk, ami segíti a leírtak kézikönyvszerű használatát is a már megszerzett ismeretek pontosítására, elmélyítésére.
A leírás tartalmaz olyan ismereteket is amelyek ismerete nem feltétlenül szükséges a rendszer használatához, de hasznos tudnivaló azok számára akik a rendszer működését számítástechnikai oldalról is szeretnék megismerni. Ezen információk megértése esetleg alaposabb informatikai és operációs rendszer ismereteket igényel.
A telepítés elvégzéséhez az operációs rendszerben megfelelő, célszerűen adminisztrátori jogosultsággal kell rendelkeznünk. Később a TMS rendszer futtatásához, konfigurálásához többnyire már nem szükséges kiemelt jogosultság, kivéve pár alap funkciót.
A TMS esetében az adatbázis-kezelő rendszer és a felügyeleti rendszer két, egymástól függetlenül telepíthető rendszert alkot, akár külön gépen is ahol az adatbázis kezelő rendszer lehet Windows, de akár Linux operációs rendszeren is. (A működéshez csak a rendszer elemei közti TCP/IP alapú hálózati kapcsolatot kell biztosítani.) Sőt a felügyeleti rendszer is más-más módon kerülhet telepítésre attól függően milyen feladatokat akarunk az adott munkahelyen elvégezni.
Az adatbázis-kezelő rendszer (PostgreSQL) Linux rendszerre való telepítésével jelen leírás nem foglalkozik, ennek jelentős és részletes szakirodalma található az interneten.
A Windows környezetben való telepítés minél egyszerűbbé tétele érdekében a TMS telepítőprogramja segít. Ezzel elvégezhető az adatbázis-kezelő rendszer egyszerű (alapértelmezett paraméterekkel való), informatikai ismereteket nem igénylő telepítése és a TMS felügyeleti rendszer igényeknek megfelelő kialakításban történő telepítése is.
A telepítőprogram a Windows rendszerekben általánosan használt felépítést követi, így végigvezeti a felhasználót a telepítés folyamatán. A telepítő indítása után a nyelvválasztás, valamint a bevezető után a következő felülete jelenik meg:
Három választási lehetőségünk van. Itt eldönthetjük, hogy a TMS telepítése mellet milyen további komponensek kerüljenek telepítésre az adott számítógépen:
A PostgreSQL kliensre kizárólag az adatbázis mentése és visszatöltése során van szükség.
A továbbiakban megjelenő adatbeviteli lapok annak függvényében változhatnak, hogy milyen a három lehetőségből mit választottunk. Ennek megfelelően jelen leírásban minden adatbeviteli lap bemutatásra kerül, de konkrét telepítési folyamat esetén lehet hogy nem minden lap jelenik meg.
Következő lapon az adatbázis kezelő komponenseinek, valamint a TMS adatbázisának adatállományainak telepítési útvonalát adhatjuk meg:
Ezt követően az adatbázis eléréséhez szükséges alapadatokat kell megadnunk:
Figyelem: Az itt megadott adatokat, elsősorban a TMS adatbázis neve és adminisztrátori név/jelszó megjegyzése nagyon fontos! Ezek megléte szükséges hogy a felügyeleti rendszer adataihoz hozzá lehessen férni. Ezek (elsősorban a név/jelszó) „elvesztése” speciális esetben azzal járhat, hogy semmi módon nem tudunk a rendszerünkben tárolt adatokhoz hozzáférni.
Ha a megadott adataink helyesek a következő lap figyelmeztet, hogy továbblépés esetén az adatbázis-kezelő rendszer telepítése megtörténik:
Az adatbázis kezelő telepítésének folyamatát követhetjük a továbbiakban.
Az adatbázis telepítésének sikeres befejezéséről információt kapunk egy figyelmeztető ablakban, amit nyugtázni kell.
Figyelem: Ha az a célunk, hogy erre a gépre kizárólag az adatbázis-kezelő kerüljön telepítésre, akkor ezen a ponton lehetőségünk van megszakítani a telepítés folytatását és így a TMS rendszer már nem kerül telepítésre.
A sikeres adatbázis telepítésről informáló ablak nyugtázása után megjelenő lapon adhatjuk meg a TMS telepítési útvonalát:
Majd megadhatjuk TMS ikonjait tartalmazó mappa nevét a „Start menüben”:
Kapunk egy összefoglaló információs lapot a TMS telepítési paramétereiről, majd indíthatjuk a TMS rendszer telepítését. A telepítés folyamatát nyomon követhetjük.
A telepítés befejezéséről információt kapunk és kiválaszthatjuk, hogy a telepítés befejezése után azonnal indítani akarjuk-e a TMS regisztrációját elvégző modult:
A telepítés utolsó lépésként a telepítő bezárását követően automatikusa elindul (ha csak le nem tiltottuk) a TMS regisztrációt biztosító program modul.
A TMS regisztráció (és minden más licence kezeléshez kapcsolódó művelet) természetesen később is elérhető a start menüből nyíló, telepítés során megadott TMS rendszer indító ikonjait tartalmazó mappából a „TMS licence kezelés” nevű ikonra való kattintással. A program indításához Windows adminisztrátori jogosultság szükséges. Csak olyan adminisztrátori fiók adataival lehet belépni amelyhez minden jog, tehát a felhasználó kezelési jog is megadásra került!
A TMS rendszer alapértelmezett bejelentkezési adatai a telepítést követően (az alapértelmezett bejelentkezési adatok módosíthatók a TMS használata során a 2.4.1.2 pontban tárgyaltak szerint):
név: root
jelszó: irf
A bejelentkezést követően a regisztrációs felület jelenik meg ahol a „TMS Licence Kezelő” fülön lehet a TMS regisztrálását elvégezni:
A regisztrációhoz ki kell tölteni az kiemelten jelzett alapadatokat és meg lehet adni az e-mail címet vagy címeket is. A regisztráció elvégzéséhez internet kapcsolatra van szükség. Ha ez csak proxy kiszolgálón keresztül érhető el, akkor a proxy elérés adatait is meg kell adni.
Regisztrációt a „Regisztráció” gombbal lehet elvégezni, de a későbbiek folyamán is módosíthatók az itt rögzített adatok. (Sikeres regisztrációt követően a „Regisztráció” gombfelirat átalakul „Regisztráció frissítése” felirattá.)
Figyelem: Ezen az oldalon a TMS rendszerünk regisztrációját végezzük el és nem egy adott számítógépét. A TMS rendszer regisztrálását egyszer kell elvégezni és ez nem visszavonható.
A licence kezelő alkalmazás alsó státuszsorában az internet kapcsolat állapotát, valamint a Windows gépünk neve és egyedi azonosítója szerepel.
A „TMS kliens kezelés” fülön összefoglalót találunk az általunk használt TMS rendszer licence információiról, valamint itt van lehetőségünk engedélyezni/tiltani Windows számítógépeink számára a TMS rendszer komponenseinek futtatását:
A TMS komponenseit korlátozás nélkül több számítógépre is feltelepíthetjük, viszont a feltelepített klienseken a TMS rendszer egyes moduljait csak az arra kijelölt számítógépeken használhatjuk. A vásárolt TMS licence határozza meg az egy időben használható aktív licencelt kliensek számát. A vásárolt kliens licence számnál nagyobb számú kliens is regisztrálhatunk a rendszerünkbe, de licence köteles TMS modulokat csak a vásárolt számú kliens gépen engedélyezhetünk, és így futtathatunk.
A TMS klienskezelés lapon van módunk TMS kliensek regisztrálására, törlésére, vagy aktív állapotának ki vagy bekapcsolására. Új kliens regisztrálásához a regisztrálandó kliensen kell futtatni a TMS licence kezelő modult, majd a plusz gombbal tudjuk az adott klienst regisztrálni és aktívvá tenni. Kliens törlése a rendszerből a kliensbejegyzés kijelölése után a mínusz gombbal végezhető el. (Figyelem ez nem távolítja el a TMS komponenseit az adott gépről, csak blokkolja azok használhatóságát.) Törlés helyett lehetőségünk van a kijelölt kliens aktív állapotának tiltására/engedélyezésére is, valamint engedélyezhetjük vagy tilthatjuk az adott kliensen futtatható TMS főmodulokat.
Természetesen egy időben csak a vásárolt licence által meghatározott maximális számú aktív, vagyis licence köteles főmodul futtatására képes TMS kliensünk lehet.
A klienseket tartalmazó listában minden bejegyzés tartalmazza a kliens számítógép Windowsban megadott nevét és a bejegyzés előtti szimbólum tájékoztat arról, hogy az adott gépen az operátori modul futott-e a lista készítésének időpontjában. A második oszlopban a kliens TMS adminisztrátori moduljában megadott név látható, valamint jelzés arról, hogy a licence kezelőt futtató gép melyik bejegyzéshez tartozik.(A TMS adminisztrátori modulban lehetséges, de nem kötelező a kliens megnevezése. Bővebben lásd: 2.4.12 pont) A következő oszlopban látható az adott számítógép egyedi azonosítója (ID). Ha a programot futtató gépet reprezentáló sort jelöljük ki, akkor az ID értéke megegyezik a státuszsorban látható ID értékével. A bejegyzés végén a kliens státusza látható ami tiltott (piros), engedélyezett (zöld), valamint csak nem licencelt TMS modulok futtatására engedélyezett (sárga) jelzés lehet. Ha a jelzés fölé visszük az egeret akkor részletes információt kaphatunk az adott kliensen engedélyezett modulokról.
A telepítő program, ha erre a gépre telepítettük az adatbázist is, akkor a telepítés során elvégzi a TMS rendszer alap paramétereinek beállítását. Viszont ha az adatbázis telepítése nem erre a gépre kerül, akkor TMS rendszer telepítését követően szükséges az alap paraméterek beállítása.
A beállítás elvégző modult a start menüből nyíló, telepítés során megadott TMS rendszer indító ikonjait tartalmazó mappából a „TMS Paraméterek” nevű ikonra való kattintással tudjuk indítani:
Az első szekcióban a felügyeleti rendszerben tárolt adatok eléréséhez szükséges paramétereket adhatjuk meg. Ha azonos gépen van a felügyeleti program és az adatbázis-kezelő rendszer akkor ez „localhost” vagy „127.0.0.1”. Ha távoli gépen van az adatbázis, akkor annak az IP címét kell megadnunk. Ha az adatbázis nem az alapértelmezett TCP porton érhető el, akkor a szerver IP (vagy DNS név) után, kettősponttal elválasztva kell a port számát megadni.
Az adatbázisnév és felhasználónév, jelszó a telepítés során megadott adatok. Ha a jelszót szeretnénk változtatni, akkor azt jelezni kell és a régi jelszó mellet az új jelszót is kétszer be kell írnunk.
A második szekció a TMS alkönyvtárstruktúráját mutatja. Lényeges kiemelni, hogy itt az „Adatok útvonala” címszóval jelölt alkönyvtár csak a futáshoz szükséges segédadatokat tartalmazza: pl. hang állományok stb. A forgalmi, vagy ügyféladatokat nem!
Ha erre a gépre nem telepítettünk sem adatbázist, sem PostgreSQL kliens modult, akkor a „PostgreSQL kliens útvonala” mező üresen maradhat. Ennek hiányát jelezheti a rendszer, de ettől a TMS működőképes marad, csak adatmentés és visszatöltés nem végezhető ezen a gépen. (Bővebben a 2.6 pontban foglalkozunk az adatmentéssel)
Az adatok magadása után tesztelhetjük a beállításokat: a szerverrel való kapcsolatot, valamint az alkönyvtárak meglétét. A tesztelés eredményéről visszajelzést kapunk, valamint sikeres adatbázis-kapcsolat esetén a státuszsorban megjelenik az adatbázis szerverünk verziószáma.
Ha mindent rendben találunk akkor az adatok rögzíthetőek is és a következő TMS modul induláskor már ezeket fogja figyelembe venni.
A PostgreSQL egy nagy teljesítményű SQL adatbázis-kezelő rendszer, ami rendkívül kiterjedt funkcionalitással rendelkezik és hatékony használatát nagyon sok paraméter beállításával tudjuk hangolni a helyi igények szerint. Nem lehet egy mindenki számára optimális beállítási sablont megadni, mert ezt befolyásolják a futtató számítógép paraméterei, a számítógépen használt egyéb programok, a kezelt adatbázis(ok) mérete, használat típusa stb. A PostgreSQL rendszer kiterjedt szakirodalommal rendelkezik az Interneten, vagy könyvekben egyaránt. Ezek szerepét ez a leírás nem tudja átvenni, de a konfigurálásra vonatkozó legfontosabbakra az alábbiakban kitérünk.
A telepített rendszer paramétereit, futási jellemzőit három szövegállomány (pg_hba.conf; pg_ident.conf; postgresql.conf) tartalmával tudjuk befolyásolni. Ezek a telepített rendszer adatkönyvtárában találhatók. (Adatkönyvtár útvonalát a telepítés során mi adtuk meg)
Ha szerkesztésre megnyitunk egy állományt és módosítottuk azt, akkor a módosult paraméter függvényében többnyire a PostgreSQL szolgáltatás leállításával és újra indításával tudjuk azt érvényre juttatni.
Nézzünk egy példát a leggyakoribb konfigurációs feladat elvégzésének áttekintésével: A PostgreSQL TCP/IP protokollon hálózaton keresztül szolgálja ki a hozzá forduló klienseket, így a TMS rendszer moduljait is. A rendszer biztonsága érdekében az adatbázis-kezelő a telepítést követően kapcsolatfelépítési kérést kizárólag csak az adatbázist is kezelő számítógépen futó rendszerektől fogad el. Ha azt szeretnénk, hogy a hálózat másik gépe is képes legyen kommunikálni a PostgreSQL szerverrel, akkor a szerver számára meg kell adni, hogy honnan, milyen IP címről, vagy IP tartományból fogadhat el kapcsolódási kérést. Ezt a „pg_hba.conf” állomány szerkesztésével tudjuk definiálni. Szerkesztésre nyissuk meg a „pg_hba.conf” állományt. A „#” jellel kezdődő sorok a megjegyzéseket tartalmazzák, a PostgreSQL ezeket figyelmen kívül hagyja. A tényleges definíció az állomány végén található például ebben a formában:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
#host all all ::1/128 md5
Egy Ipv4 kapcsolatra vonatkozó érvényes definíció sor van, ez a sor mutatja, hogy IP kapcsolódás bármely adatbázishoz, bármely a PostgreSQL-ben definiált felhasználónak a 127.0.0.1 címről lehetséges.
Ha azt szeretnénk, hogy a kapcsolódási kérelmet a 192.168.1.0 „C” osztályú címtartományból vagyis 192.168.1.1-192.168.1.254 címek mindegyikéről elfogadja akkor a pg_hba.conf állományt a következőképpen kell módosítani:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.1.0/24 md5
# IPv6 local connections:
#host all all ::1/128 md5
A változások érvényre jutásához a PostgreSQL szolgáltatást a gépen le kell állítani, majd újra elindítani!
Figyelem: a távoli elérés biztosításához szükséges lehet a Windows tűzfal megfelelő beállítása is! A PostgreSQL (ha telepítés során nem módosítottuk) az 5432-es TCP porton elérhetőnek kell lenni a kliens gépekről.
Telepítést követően a rendszer egy alap beállítási készlettel dolgozik. Ezzel az adatbázis-kezelő rendszer a gépek nagyon széles körén hiba nélkül működőképes, de az esetek egy részében közel sem az optimális teljesítmény nyújtásával teszi ezt. A telepítést követően vegye fel a kapcsolatot a rendszer forgalmazójával, hogy a terméktámogatás keretében a jobb teljesítményparaméterek eléréséhez milyen beállítások módosítása szükséges a telepített rendszeren.
A telepítés során minden, a program futásához és kezeléséhez szükséges komponens felmásolódik a számítógépre, és az alapértékek beállításra kerülnek.
A TMS sikeres telepítése esetén a start menüben a telepítéskor megadott mappában találhatók a TMS komponenseinek indító ikonjai:
A TMS rendszer két leggyakrabban használt (adminisztrációs, és operátori modul) ikonja az asztalra is kihelyezésre kerül.
A későbbiekben az egyes moduloknál csak a modulok nevére hivatkozunk, azok indításához az ikonok helyére már nem.
A TMS rendszer frissítéséhez egyszerűen a már frissített TMS verziót tartalmazó telepítőanyagot el kell indítani és telepítendő komponensek választásánál a harmadik pontot kell választani, vagyis kizárólag a TMS komponenseinek telepítését.
A telepítő ebben az esetben a „Tovább” gomb megnyomását követően nem kéri további adatok megadását, hisz az a korábbi telepítés alapján már ismert, így a következő megjelenő lapon azonnal indítható a TMS komponenseinek frissítése.
Amennyiben egy számítógépről szükségessé válik a telepített rendszer eltávolítása, azt az adott Windows operációs rendszerben megszokott módon végezhetjük el.
A rendszer eltávolítása során azok az adatok, amik a telepítés elvégzése után generálódtak, nem fognak törlésre kerülni.
A PostgreSQL adatbázis-kezelőt szükség esetén a TMS-hez hasonló módon külön kell eltávolítani.
A sikeresen telepített rendszer csak az alapbeállításokat tartalmazza. Először szükséges ezen beállítások esetleges módosítása, valamint az ügyfelek, és hozzájuk kapcsolódó adatok definiálása.
Ezeket a feladatokat, mint szinte minden a rendszer adminisztrálásához kapcsolódó feladatot, a „TMS Adminisztrátor” programmal lehet elvégezni. Ebben a fejezetben ennek a programnak a használatával ismerkedünk meg.
Ha a TMS Adminisztrátor program felépítését megjelenése alapján vizsgáljuk, akkor a megjelenő ablak öt fő részre osztható: A menüsáv, és a kezelői gombsor itt is a Windows rendszerekben megszokott módon található. Az alkalmazás ablakának fennmaradó területe két részre van osztva. (Az osztás aránya egér segítségével változtatható.) A baloldali panelen egy úgynevezett objektumböngésző található, míg a jobboldali panelen a kiválasztott objektum adatait kezelhetjük. Az ablak alján egy státuszsort láthatunk, ahol áttekintő információkat láthatunk a rendszerben lévő főbb objektumok számáról: Felhasználók, ügyfélcsoportok, ügyfelek (definiált és rendszer ügyfelek külön-külön), valamint a kódtáblák számáról.
A kezelői gombsor, ebben az alkalmazásban is csakúgy mint az TMS rendszer egyéb alkalmazásaiban is, az egér „vonszolásával” átalakítható lebegő ablakká, vagy akár el is tüntethető.
Ez a lehetőség is segíti a program felületének igényeink szerinti beállítását. Ezen kívül a „Nézet-Eszközök” és „Nézet-Kereső” menüpont segítségével is a kezelői gombsor el is tüntethető, vagy újra megjeleníthető.
Az eszközök menüponton belül elérhető funkciók két csoportba sorolhatók. Egyrészt innen indítható az adatbázis tömörítése (2.2 pontban tárgyaljuk részletesen), valamint innen is lehet kezdeményezni egyes objektumok törlését (2.4.4.6), és innen lehet a rendszerhez kapcsolódó külső bővítőmodulok elérése, használata is.
Ha rendelkezünk több nyelvi modullal is akkor a „Nyelv” menüpont felhasználásával kiválaszthatjuk a program megjelenítésének alapértelmezett nyelvét. Ezt a funkciót a program futása közben bármikor használhatjuk, de a változtatási igényünk csak a program következő indításakor jut érvényre.
A munkát általában az adatbázis megnyitásával tudjuk elkezdeni: „File → Adatbázis nyitása” A nyitásnál felhasználói nevet-jelszót kér tőlünk a rendszer. A TMS Adminisztrátor programban adatbázisnyitást csak megfelelő jogosultsággal rendelkező felhasználó tud végrehajtani. Az adatbázis megnyitásával válik lehetővé az objektumböngésző használata is. Az objektumböngészőben megjelenő objektumok típusa a bejelentkezett felhasználó jogaitól függően változhat.
A TMS rendszer alapértelmezett bejelentkezési adatai:
név: root
jelszó: irf
Ez a funkciók csak az adatbázis nyitása után érhető el, de kizárólag a rendszer telepítése során létrehozott felhasználó számára.
Mivel a PostgreSQL adatbázis-kezelő ezt az adattömörítő funkciót a háttérben, felhasználói beavatkozás (és egyéb folyamatok zavarása) nélkül is elvégzi, így menüből való indítása általában nem szükséges. Ha valamilyen adatbázissal kapcsolatos kérdés vagy probléma felmerül, első lépésként ajánlott felvenni a kapcsolatot a rendszer forgalmazójával a terméktámogatás keretén belül.
Megjegyzés: Ezen automatikusan futó háttérfolyamat szabályozására a „postgres.conf” állományban van lehetőség.
Ha a bejelentkezés során megfelelően adtuk meg az adatokat és rendelkezünk megfelelő jogosultsággal akkor használhatóvá válik az objektumböngésző. A rendszerben lévő, hozzáférhető objektumok fa struktúrában a jobb oldali panelen jelennek meg.
Nézzük milyen objektumokon, és milyen módon tudunk műveleteket végrehajtani.
A képen az objektumböngésző struktúra minden főbb eleme látható, ami installálás után a rendszerben létezik. Ha valamely objektumon műveleteket akarunk végrehajtani akkor először azt az objektumot kell kiválasztani, majd az objektumhoz tartozó információkat a jobb oldali panelen szerkeszthetjük.
A bal oldali struktúra valamely objektumán jobb egérgombbal kattintunk, akkor egy lebegő menü jelenik meg, amivel bizonyos, csak az adott objektumra vonatkozó műveleteket tudunk végrehajtani.
Ha már nem kívánunk több adatmódosítást végrehajtani a rendszer objektumain, akkor a „File – Adatbázis zárása” menüponttal lehet a nyitott adatbázist zárni.
Ha az objektumböngészőben egy objektumot kiválasztunk akkor a jobb oldali panelen az adott objektumhoz tartozó paraméterek jelennek meg egy vagy több lapon. Az objektumhoz tartozó paramétereken módosításokat hajthatunk végre. A módosítás érvényesítéséhez többnyire három gomb szolgálhat:
Az elvégzett adatmódosítás a rögzítést követően azonnal hatályossá válik. Ha adott adatbeviteli területről úgy akarunk elnavigálni, hogy nem történt meg a módosítások rögzítése, akkor erről figyelmeztetést kapunk. A figyelmeztetés kezelésével eldönthetjük, hogy maradunk és folytatjuk az adatmódosítást (például a módosítások rögzítésével), vagy hagyjuk elveszni a módosításokat és elnavigálunk az adott lapról.
A későbbiek folyamán már külön-külön nem minden esetben emelem ki, hogy a változtatások érvényesítéséhez az adatrögzítő gombokat használni kell.
Bizonyos objektumok „gyermek” objektumokkal rendelkeznek. Például az „Ügyfél” objektum gyermekei a konkrét definiált ügyfelek. Ilyen típusú objektumoknál egy új gyermekobjektum létrehozását a szülő objektumra való kattintással tudjuk elindítani. Itt kell az új gyermekobjektum alapadatait megadni, majd a „Bővít” gombbal hozhatjuk létre a gyermekobjektumot, ami meg is jelenik az objektum böngészőben. A gyermekobjektum adatainak részletes beállítása már a létrejött új objektum kijelölésével végezhető el.
A TMS rendszer terminológiájában a felhasználó azokat a személyeket jelenti akik a felügyeleti rendszert kezelik. Az hogy a rendszeren belül mely programmodulokat és azon belül mely funkciókat használhatnak, azt egy jogosultsági rendszer dönti el. Felhasználók kezelése alatt gyakorlatilag az alapadatok megadásán túl ezen jogosultsági rendszer megfelelő beállítását értjük.
A felhasználók száma nincs korlátozva a rendszerben, de felhasználót nem lehet törölni a rendszerből. Ha szükséges, akkor az „Aktív” jellemzőjének törlésével tudjuk kitiltani az TMS rendszer használatából.
Új felhasználót definiálását a „Felhasználók” objektumra való kattintással lehet elkezdeni. Ekkor az alábbi beviteli panel jelenik meg a jobb oldalon, aminek segítségével adhatjuk meg a definiálandó felhasználó alap adatait:
Felhasználó neveként a teljes nevet kell megadni. Belépőnév a bejelentkező nevet jelenti, ez lehet akár egy kód is. Ezt a nevet kell használni a rendszerbe történő bejelentkezéskor. A jelszó beírásakor csak fedő karakterek jelennek meg. Ezen a panelen kell bejelölni, hogy a felhasználó aktív-e, vagyis azonnal használhatja-e a rendszert a definiálás után. Továbbá itt kell megadni, hogy a felhasználó alapértelmezetten milyen jogosultsági szinttel rendelkezzen.
A felhasználói tevékenységek két fő kategóriába kerültek összegyűjtésre. Ezek a kategóriák határozzák meg az adott felhasználó jogosultságait a TMS rendszerben. Ezek a kategóriák a következő alapértelmezett jogokat jelentik:
Felhasználó: Kizárólag operátori tevékenység ellátása lehetséges. A TMS Adminisztrátor programba nem lehet belépni ilyen típusú azonosítóval.
Rendszergazda: Az operátori tevékenységen túl a TMS Adminisztrátor programmal az ügyfelekre vagy a rendszerre vonatkozó adatok, beállítások kezelhetők, lekérdezhetők a számára. Új felhasználót alapértelmezésben nem hozhat létre, és meglévő adatait és jogosultságait nem módosíthatja, de megnézheti a rendszerben lévő felhasználók beállításait, kivéve természetesen a jelszót.
Ezek az alapértelmezett beállítások, de ezen jogosultsági rendszer természetesen módosítható, személyre szabható.
Ha mindent helyesen kitöltöttünk, akkor az adatok tárolásához a „Bővít” gomb lenyomása szükséges.
Felhasználó adatainak módosításához az objektumböngészőben a módosítani kívánt felhasználót jelképező objektum bejegyzést kell kijelölni. Ekkor a következő panel jelenik meg a jobb oldalon:
A bemutatott képen a „Superuser” adatait láthatjuk, úgy ahogy az az installálás során létrejött. Ez egy kiemelt felhasználó, így ennek a felhasználónak a jogosultságait nem tudjuk szűkíteni, de természetesen nevét, bejelentkezőnevét és jelszavát módosíthatjuk. Viszont minden más felhasználónak a jogosultságait részletesen szabályozhatjuk, persze ha van hozzá megfelelő jogosultságunk!
Látható, hogy a „Felhasználói” és „Rendszergazdai” jogkőr (amit a 2.4.1.1 pontban már tárgyaltuk) részletekbe menően tovább finomítható. Persze ezen pontokban összefoglalt jogosultságok kihatnak egymásra. Leglényegesebb, hogy akinek a „Felhasználókezelési” jogot megadjuk, annak ezzel minden jogot megadunk, hisz képes lesz önmagának, vagy bárki másnak beállítani a jogosultsági rendszerét, továbbá ezen kiemelt jog szükséges a licence adatok kezeléséhez is. Másik lényeges dolog, hogy ha valakinek nem adjuk meg a belépési jogot az adminisztrátori, vagy operátori modulba, akkor neki természetesen hiába adjuk meg a modulon belüli tevékenységek jogait, azzal nem lesz képes élni, hisz be sem tud lépni a modulba az adott tevékenység elvégzéséhez.
Lehetőségünk van az egyes felhasználók jogainak további szűkítésére. Létrehozhatunk ügyfél és eseménycsoport sablonokat. Ezen a sablonokban definiálhatunk „rejtett” vagyis nem látható ügyfeleket és eseményeket. Ha ilyen sablont (ügyfél vagy eseménycsoport sablont) hozzárendelünk egy felhasználóhoz akkor az operátori modul, ugyan feldolgozza ezektől a számára „rejtett” ügyfelektől bejövő eseményeket is, de azokat nem jeleníti meg a korlátozott jogú felhasználó számára. Ezzel biztosítható, hogy egyes felhasználók csak bizonyos ügyfeleket és/vagy eseményeket láthatnak a TMS rendszerben.
Természetesen itt is, mint általában a változtatásokat a „Használ” gomb lenyomásával tudjuk letárolni és érvényre juttatni, ha rendelkezünk megfelelő jogosultsággal a művelet végrehajtásához.
Az ügyfelek egyes jellemzői munkarend függőek lehetnek. Ezeknél a jellemzőknél zavart okozhat egy – egy ünnepnap. Ünnepnap miatti munkarendváltozások miatt pl. egy naptár szerint hétköznapi napon is lehet vasárnapi vagy éppen szombati munkarend. Ezeket a rendhagyó munkarendű napokat tudjuk definiálni az „Ünnepnapok” objektum adatainak módosításával a következő panel segítségével:
Ezen a panelen egy adott dátumhoz hozzárendelhetünk egy adott napi munkarendet. Ezt az összerendelést ügyfelenként kell érvényesíteni. Az ügyfelek kiválasztását segítik a „Mind”, illetve az „Egysem” nyomógombok.
A panel alsó felén az eddig tárolt, vagyis már rögzített összerendelések láthatóak.
A TMS rendszer terminológiájában az Ügyfél azt az objektumot jelöli ahonnan a riasztóközpont jelzései érkeznek. Az ügyfél adatai közé tartozik minden ehhez a védett objektumhoz köthető jellemző.
Van az alaprendszerben két kitüntetett ügyfél: az egyik maga a felügyeleti rendszer, ennek neve SYSTEM, kódja: 0. A másik ügyfél a Vevőegység, ennek neve: VEVŐ(vagy RECEIVER), kódja: -1. Ezekhez az ügyfelekhez is tartoznak események amelyek a hozzájuk rendelt eseménycsoportban vannak definiálva. Megfelelő jogosultsággal módosítható ezeknek az ügyfeleknek is az adatait. Ezeket a módosításokat azonban csak nagyon megfontoltan szabad végrehajtani, mert hibás beállítással a rendszer működését is veszélyeztetni lehet. A rendszer részét képező ügyfelek abban is eltérnek az utólag definiáltaktól, hogy ezek az ügyfelek nem törölhetők.
A SYSTEM ügyfél eseményei alapvetően az időhöz kapcsolódnak, és különböző segédfunkciók indítására használhatjuk fel ezeket. A VEVŐ eseményei ténylegesen a vevőegység(ek) működéséhez kapcsolódó események feldolgozására szolgál.
Az ügyféladatok kezelése, hasonlóan a felhasználók adataihoz, szétválasztható az új ügyfél definiálására, és a már meglévő definiált ügyfél adatainak módosítására. Lényeges viszont, hogy itt új ügyfél definiálásakor csak pár alapadat kerül megadásra, és a többi ügyféljellemzőt, később csak mint létező ügyfél adatainak módosításaként tudunk megadni.
Az ügyfelekhez sokféle, logikailag is elkülönülő adat tartozik. A jobb áttekinthetőség, és később a részletek hatékonyabb visszakereshetősége miatt az adatcsoportok definiálását külön-külön fejezetekként tárgyaljuk.
Az ügyfeleket az objektumböngészőben csoportokba szervezhetjük. Ezeket az ügyfélcsoportokat (vagyis ügyfeleket, vagy akár újabb ügyfélcsoportokat tartalmazó objektumokat) az ügyfelekkel azonos lapon tudjuk definiálni.
Ügyfél vagy ügyfélcsoport létrehozásához ki kell választani az „Ügyfél” objektumot az objektumböngészőben. Ekkor a jobb oldali panelen megjelennek azok a beviteli mezők, melyek megfelelő kitöltésével létrehozhatjuk az új ügyfelet vagy ügyfélcsoportot. Az ügyfélcsoportok kezeléséről később részletesen tárgyalunk, ebben a pontban csak röviden összefoglaljuk hogyan definiálhatunk új ügyfélcsoportot
Mint látható csak a legszükségesebb jellemzőket kell beállítani:
Az adatok megfelelő megadása után rögzíthető az új ügyfél.
Ezzel tulajdonképpen az ügyfél már élő tagja a rendszernek. Ha a „Bővít” gomb lenyomása után esemény érkezik az ügyfélnek beállított ügyfélkóddal a rendszerhez, akkor az már feldolgozásra és kijelzésre kerül. Mint később látni fogjuk a sablonok használatával ilyenkor már a kezelendő események érkezésekor az operátornak már az elvégzendő feladatra figyelmeztető jelzés is meg fog jelenni.
Az ügyféladatok módosításához először meg kell keresni és ki kell jelölnünk a kezelendő ügyfelet az objektum böngészőben, hogy részletes adatai megjelenjenek a jobb oldali területen.
Ügyfél megkeresése:
Az ügyfél megkeresését több módon is megtehetjük:
Ha az utóbbi megoldást kívánjuk alkalmazni és megnyomjuk a keresést indító nyomógombot akkor a megnyíló dialógusdoboz lehetőséget ad, hogy egy vagy több karaktersorozat alapján megkeressünk egy ügyfelet.
Először meg kell adni egy vagy több keresett karaktersorozatot. (Ezt ki is választhatjuk az utoljára beírtak közül.) Ha szükségesnek látjuk, szűkíthetjük is annak az adathalmaznak a körét amelyekben a program keresi a megadott szöveget. Ezt az egyes adatcsoportok előtti „pipa” ki- vagy vissza tételével tudjuk megtenni. Azzal is javíthatjuk a keresés hatékonyságát, ha beállítjuk, hogy a kis- és nagybetűk egyezését is figyelje, vagy csak az aktív ügyfelek közt keressen. (Az hogy hogyan tehetünk egy ügyfelet aktívvá, vagy nem aktívvá azt rövidesen részletesen tárgyaljuk a 2.4.3.2.1 pontban) A keresés indítása után az ügyfelek adatai átvizsgálásra kerülnek. Ha valahol egyezés található akkor az adott ügyfél neve és kódja kiírásra kerül. Ha egy ügyfél adataiban a megadott szöveg többször is szerepel, akkor az adott ügyfél többször is felsorolásra kerül. Ha a felsorolt ügyfelek közül kijelölünk egyet, akkor láthatjuk, hogy az adott listaelem milyen adategyezés miatt került felsorolásra. „Mutat” gomb megnyomásával a kijelölt ügyfél alapadatai megjelenítésre kerülnek.
Ez a dialógusablak speciális tulajdonságokkal rendelkezik. Egyrészt átméretezhető, így igényeink és a képernyőnk mérete szerint módosíthatjuk méretét és ezzel a keresés eredményének megjelenítését is. Másik lényeges tulajdonság, hogy a dialógusablak zárása nélkül is tudunk műveleteket végezni a program főablakán és így pl. egy-egy ügyfél adatainak megtekintésével tudjuk ellenőrizni, hogy kell-e folytatni a keresést vagy megvan a keresett ügyfél és bezárható a dialógusablak.
Keresést indíthatunk úgy is ha az objektumböngésző adott objektumán jobb egérgombbal kattintunk, és megjelenő lebegőmenüből válasszuk a „Keresés innen...” funkciót, ha a kijelölt objektumon megvalósítható a keresés. Ilyenkor a keresés csak az adott objektumon és annak gyermekobjektumain kerül végrehajtásra. Például ezzel szűkíthetjük a keresést egy ügyfélcsoportra.
Ügyfél adatainak szerkesztése:
Mivel egy ügyfélhez nagyon sok adat tartozik (tartozhat, mert nem kötelező mindent használni, csak azt amire igény van), és ezek az adatok nem ábrázolhatók egy panelen így a jobb oldalon most több táblát láthatunk. Minden logikailag összefüggő adatcsoport külön-külön táblán látható és módosítható. Így a módosítani kívánt ügyfél kiválasztása után a jobb oldali panelen megjelennek az ügyfél adatait tartalmazó táblák. A táblák közül a panel felső részén található fülek segítségével választhatunk:
Mint látható több főcsoportba lettek szervezve az ügyfélre vonatkozó adatok. (Egyes táblákon további alcsoportok vannak) Ezeken a táblákon az adatbevitel bizonyos egységes szabályszerűségek szerint történik, ezek a szabályok itt kerülnek összefoglalásra, így táblánként csak a beviteli mezők jelentése, azok rendszerben elfoglalt helye kerül csak meghatározásra.
A kiválasztott táblától, és az azon végrehajtott módosításoktól függően, a végrehajtott változtatások a táblák bizonyos szekciójában lévő, korábban már megismert „Bővít”, „Használ” gombokkal tudjuk rögzíteni vagy a „Törlés” gombbal tudjuk törölni az éppen kijelölt adatsort, vagy sorokat. Az adatmegjelenítő rácsban közvetlenül nem tudunk adatokat módosítani! Itt az adatokat összefoglalva láthatjuk és egy-egy adatsorra kattintva lehet az adatsor adatait kijelölni, majd azon a beviteli mezőkben műveleteket végezni, vagy éppen törölni a kijelölt adatsort. Az adatmegjelenítő rácsok fejlécére kattintva többnyire lehetséges a megjelenített sorok sorrendjének módosítása az adott oszlop szerint növekvő vagy csökkenő sorrendbe. A sorba rendezés irányát a fejlécre való ismételt kattintással tudjuk megfordítani.
Nézzük részletesen, hogy milyen adattáblákon milyen adatok kezelhetők.
Az ügyfél alapadatokat a következő beviteli mezők segítségével lehet definiálni:
A beviteli mezőkkel a következő adatokat adhatjuk meg, vagy módosíthatjuk:
Ezen a lapon kerül megjelenítésre (de nem módosítható!) az ügyfél definiálásának, létrehozásának dátuma és a létrehozó felhasználó neve, valamint az ügyfélhez rendelt kódtábla (CID) is.
A kódtábla neve melletti gombbal közvetlenül átválthatunk az adott kódtábla kezelését végző panelra.
A keretezett mezőben az adott ügyfél státuszállapotát láthatjuk, és módosíthatjuk is ha szükséges, de a módosításokat alapvetően a rendszer végzi el. Minden ügyfélhez három előre definiált státusztípus tartozik, és minden státusztípus három állapotot vehet fel:
Az ügyfél objektumának ismeretlen – zárt – nyitott állapotát jelzi.
Az ügyfél objektumának ismeretlen – riasztott – nyugalmi állapotát jelzi.
Az ügyfél objektumának ismeretlen – műszakilag hibás – műszakilag rendbennlévő állapotát jelzi
A státuszállapotokat jelző ábrák melletti gombokkal módosíthatjuk az adott státusz állapotát. A „Frissítés” gombbal az adatbázisból újraolvashatjuk az aktuális állapotokat. A jelzett státuszállapot nem frissül automatikusan. Alapértelmezetten az alapadatok megjelenítésének időpillanatának státusz állapotát mutatja.
Minden ügyfélhez négy különböző címet rendelhetünk. Ezeknek a címeknek a rögzítését a „Cím” lapon tudjuk megtenni:
Mint látható a négy különböző címadat négy különálló táblán definiálható. A négy tábla adatai szinte azonosak, de minimális különbség van a táblák közt:
Az „Objektum címe” lap (amely tulajdonképpen alapnak tekinthető, hisz erre szinte biztosan szükség van) kivételével a többi lapon található egy kék nyíl nyomógomb amellyel az első („Objektum címe”) lapon megadott adatokat az aktuális lapra másolhatjuk, és csak az esetlegesen szükséges módosításokat kell megadnunk.
Az eseménycsoport adatainak definiálása során, az egyes eseményeknél a zóna száma és típusa definiálható (ha szükséges, mert egyes kódtípusoknál, mint amilyen a CID is a Zóna számát a központ az eseménykódtól függetlenül közli és így csak a zóna típusának megadására van szükség). Ezen a lapon viszont meg lehet adni az adott ügyfélnél az adott zóna jellemzőit. Ez elsősorban azt jelenti, hogy egy konkrét számú, és típusú zónának ennél az ügyfélnél mi a megnevezése, de ezen túl itt adható meg az is, hogy a zónához milyen eszközök rendelhetők. Ezek a Zónához rendelhető eszközök érzékelők, vagy egyéb kategóriába tartozó eszközök lehetnek. (Az eszközök definiálásával később fogunk részletesen foglalkozni a 2.4.7 pontban)
Lényeges, hogy az TMS terminológiájában minden az eseményekhez tartozó kiegészítő információtípust zónának tekintünk. A zónák típusa ennek megfelelően, a riasztóközpont és a vevőegység közti protokoll függvényében nagyon sokfajta lehet. Általában két típust minden riasztóközpont ismer: a felhasználót és ténylegesen a szó hagyományos értelmében használt zónát.
A rendszerben definiálásra került egy „Egyéb” zónatípus is szabad felhasználásra.
A definiálást, mint látható is egy adatmegjelenítő rács segítségével tudjuk elvégezni. A definiáláshoz meg kell adni. A felső szekcióban a zónák adatait (neve, típusa, száma és kategória) tudjuk definiálni, míg az alsó szekcióban a kijelölt zónához tartozó eszközöket és jellemzőit lehet megadni. A két szekció méretét a köztük lévő dupla vonallal (átméretező sávval) tudjuk módosítani.
A rendszer használata során az eseményekhez, ha az zónafüggő esemény akkor az itt meghatározott zónanevek fognak kapcsolódni.
Zónákat kategorizálhatjuk is. Ha zónákat eltérő kategóriába soroljuk, akkor kategóriánként külön-külön tudunk (és valószínűleg kell is!) munkafolyamat sablonokat definiálni az egyes zónákról érkező riasztásoknak. Egy-egy munkafolyamat sablon csak egy kategóriába sorolt zónára tud riasztási, és így tevékenység szabályt megadni.
Telepítést követően két kategóriát tartalmaz a TMS: „Általános” és „Kültéri”, és az előre definiált sablonok a kizárólag az „Általános” zóna kategóriára vonatkoznak.
Kategóriákat mi is szerkeszthetjük a kategória választó mező előtti fogaskerék gomb megnyomásával:
Minden zóna kategóriának egyedi névvel kell rendelkezni. Ennek figyelembevételével:
A módosítások után az „OK” gombbal zárhatjuk a szerkesztő ablakot.
Egyes eseményekhez hozzáköthetünk munkafolyamatokat (több módon is), amiket a TMS rendszer felhasználójának (az operátornak) kell végrehajtani, az esemény bekövetkezte esetén. Tipikusan ilyen munkafolyamat a járőr indítása, vagy az érintettek értesítése. Így ezekhez a munkafolyamatokhoz hozzárendelhetünk személyeket, akikkel kapcsolatban kell különböző tevékenységeket elvégezni a rendszer operátorának.
A most tárgyalt adatlapon ezeknek a személyeknek az adatait rögzíthetjük, akiket később az egyes munkafolyamatokhoz tudunk majd rendelni.
Az adatrögzítés a már ismert adatmegjelenítő rács használatával tudjuk elvégezni, amin az értesítendő személy nevét és elérhetőségének adatait tudjuk megadni, valamint egy lemondási jelszót ami csak ehhez a személyhez tartozik.
Itt tudunk az ügyfélhez rendelni egy (vagy akár több) „Munkatársat” is, így akár egy-egy eseménynél az ügyfélhez rendelt munkatársak is szerepelhet az értesítendők közt. Lényeges, hogy míg értesítendő esetén minden adatot módosíthatunk (név, cím stb.) addig „Munkatársat” kategóriában egy listából választhatunk és csak a megjegyzést fűzhetünk a bejegyzéshez és a szerződésre vonatkozó dátumokat tudjuk módosítani.
„Munkatárs” néven szereplő bejegyzéseket több kategóriába sorolhatjuk és ezeket a kategóriákat és bejegyzéseket külön szerkeszthetjük, amit részletesen ismertetni is fogunk a későbbiek folyamán. Lényeges hogy a munkatársak olyan személyeket (esetleg cégeket) jelölnek amelyek több ügyfélhez is rendelhetők (pl.: telepítő, vagy járőr).
Azt hogy új értesítendőt vagy új munkatárs kapcsolatot akarunk definiálni azt az adat beviteli terület felső részén lévő gombokkal tudjuk szabályozni.
Értesítendő adatainak rögzítését, vagy módosítását a következő adatbeviteli képen tehetjük meg.
Munkatársak adatainak kezelése ettől eltér. Itt egy legördülő listából választhatunk az előre definiált adatok közül és csak az ügyfélspecifikus adatokat tudjuk módosítani.
Minden személyhez/bejegyzéshez rendelhetünk prioritást, így fontossági sorrendet állíthatunk fel az értesítendők közt. Ez a prioritási érték alapértelmezésben „50” és ezt szabadon módosíthatjuk 0 és 100 közt. Az értesítendőket a munkafolyamatok kezelését segítő ablakban mindig a prioritási értékek szerint sorrendben történik. A magasabb prioritással definiált személyek lesznek a lista elején.
Az értesítendők számát nem korlátozza a rendszer!
Eseményekhez munkafolyamatokat rendelhetünk. Ezt több módon is megtehetjük, valamint magának a munkafolyamatnak is több típusa lehet.
Nézzük először a lehetőségeinket és utána pontosan megvizsgáljuk, hogyan tudjuk ezeket alkalmazni a TMS rendszerben. Először is tisztázzuk, hogy a munkafolyamat jelen esetben azt jelenti, hogy beérkezik egy adott esemény egy adott ügyféltől, ahhoz rendelhető feladat, vagy feladatok, amiket el kell végezni. Milyen feladatok is lehetnek ezek? Két típusát különböztetjük meg a feladatoknak: vannak olyan feladatok amiket a rendszernek önállóan kell elvégezni, minden külső beavatkozás nélkül (ilyen lehet pl. egy személy SMS, vagy e-mail értesítése az eseményről) – ezeket „Automatikus funkcióknak” nevezzük. Valamint vannak olyan feladatok amiket az operátornak kell elvégezni (ilyen a járőr indítása, kapcsolat felvétele a megadott személlyel stb.) - ezeket a „Felhasználói beavatkozás” néven kezeljük. Ezek a feladatok akár ügyfelenként és eseményenként mások-mások lehetnek. További igény lehet, hogy egyes ügyfelektől, egyes eseményeknél a megadott munkafolyamatot csak akkor kell elvégezni, ha az az esemény meghatározott zónára vonatkozik. Más zónák esetén nem, vagy mást kell elvégezni.
Az eddigiekből is látszik, hogy a munkafolyamatok definiálása főleg nagyszámú ügyfél esetén rendkívül összetett feladat (lenne) ami rengeteg időt, fáradságot követelhet meg a rendszer adminisztrátorától. Szerencsére van egy jellemzője ezeknek a feladatoknak, ami nagy segítséget jelent a számunkra: Általában az ügyfelek nagy részénél a kezelést, beavatkozást igénylő események és az ezekhez tartozó feladatok azonosak, esetleg csak az értesítendő személyek változnak. Sokkal kisebb azon ügyfelek száma akiknél valami speciális, személyre szabott beállítás szükséges. Ezt kihasználva egyből sokkal egyszerűbbé válik a feladatunk: Létre lehet hozni egy, vagy több úgynevezett munkafolyamat sablont (telepítés után a rendszer már tartalmaz pár általános beállítást) és a „szokásos” feladatokat (operátori vagy automatikus feladatok) ezekben kell definiálni. Itt ezekben a sablonokban adhatjuk meg hogy az egyes események esetén milyen feladatokat kell az operátornak (vagy a rendszernek automatikusan) elvégezni. Az ügyfeleknél már csak a meglévő sablont vagy esetleg sablonokat kell az adott ügyfélhez rendelni önállóan, vagy egy-egy értesítendőhöz társítva. Ezenkívül ha valamiben el szeretnénk térni a sablonban megadottaktól, akkor azokat ez egyedi eseteket, kivételeket kell csak definiálni az ügyfélnél. Ezek a kivételek bővíthetik a sablonban megadott feladatokat, vagy akár felül is bírálhatják azokat. A sablonokat a definiálásuk során jelölhetjük „alapértelmezettnek” ilyenkor ha egy ügyfelet létrehozunk, akkor ahhoz rögtön hozzárendelődik ez a sablon csak még értesítendők nélkül. Sablonokat ködtáblánként tudunk létrehozni és természetesen ügyfél-sablon összerendelés csak azonos kódtábla esetén lehetséges. Most hogy megismerkedtünk a munkafolyamat sablonok fogalmával, tartalmával a jelen részben csak a felhasználásukkal foglalkozunk. Munkafolyamat sablonok definiálását egy későbbi pontban fogjuk részletezni a 2.4.10.3.1 pontban.
A fentiekből is kitűnik, hogy az ügyfélnél a munkafolyamat beállításokat négy részre bonthatjuk:
Nézzük részletesen hogy ezeket a feladatokat hogyan tudjuk elvégezni!
2.4.3.2.5.1 Munkafolyamat sablonok ügyfélhez rendelése
Mint látható a beviteli panel három részre osztható: A felső szekcióban választhatunk, hogy az előző pontban felsorolt négy tevékenység közül melyikkel szeretnénk foglalkozni (jelen esetben az elsővel). A maradék terület alsó része mind a négy lapon azonos. Itt láthatjuk a már meglévő definíciókat. Az adatmegjelenítő rács melletti gombbal tudjuk szűkíteni a rácsban felsorolt információkat. Ha szűkítjük a felsorolást (benyomott, aktív nyomógomb) akkor csak az adott lapon kezelhető sorok jelennek meg, egyébként az összes. A felső adatbeviteli terület szolgál az adott laphoz tartozó információk megadására.
Jelen esetben a munkafolyamat sablonok és értesítendők listájából a kijelölő pipákkal tudjuk az összerendeléseket megtenni, majd rögzíteni azokat a szokásos módon. Mint az alsó listából látszik is, nem feltétlen szükséges minden munkafolyamat sablonhoz értesítendőt rendelni, de ha szükséges egyhez akár több is rendelhető.
2.4.3.2.5.2 Munkafolyamatok egyedi definiálása
A sablonokban megadottakon kívül definiálhatunk speciálisan ennél az ügyfélnél elvégzendő feladatokat az operátor számára. Az alábbi adatbeviteli panel segítségével tudjuk ezt megtenni:
A fenti képen az „AC hiány” eseményre definiáltunk egyedi szabályt. Ha erre az eseményre lenne már elvégzendő feladat valamely sablonban akkor az nem hajtódik végre, mert itt felülbíráltuk azt. Az alsó adatmegjelenítő rácsban látható, hogy a sorok előtti ikon jelzi, hogy milyen típusú az adott munkafolyamat definíció.
Nézzük a definiálást hogyan tudjuk elvégezni. A beviteli panel adatainak kitöltése részletezve:
Ha két eseményt jelöltünk meg Pl. „Esemény 1” és „Esemény 2” valamint két értesítendőt Pl. „Értesítendő 1” és „Értesítendő 2”, akkor az „Bővít” gomb lenyomásával négy új munkafolyamatsor jelenik meg az adatmegjelenítő rácson.
Az adatmegjelenítő rácson láthatjuk az adott ügyfélhez rendelt munkafolyamatok minden adatát. Minden munkafolyamatot egy-egy sor ír le. Ha egy sort jelölünk ki akkor annak adataival kerül feltöltésre a felső beviteli mezőket tartalmazó terület. A kijelölt sort (munkafolyamatot) törölhetjük, vagy módosíthatjuk az adatait, és igény szerint új sorként rögzíthetjük, vagy a módosítást elmenthetjük.
Ha több sort is kijelölünk (pl. egérkattintás a sorokon a „Shift” vagy „Ctrl” billentyűk lenyomása mellet) akkor egyszerre tudunk a kijelölt sorokon műveleteket végezni. Ilyenkor viszont az adatmódosításra csak szűkebb lehetőségünk van:
Ezekre a megkötésekre azért van szükség, mert egyébként nem lehetne egyértelműen eldönteni, hogy a több soron végzett műveletek melyik soron milyen változást generáljon.
Ezen a lapon van egy további munkafolyamathoz kapcsolódó lehetőségünk. Definiálhatunk előre egy adott időpillanatban bekövetkező eseményt ehhez az ügyfélhez. Tulajdonképpen ez úgy működik, mintha a naptárban előre beállítanánk egy eseményt figyelmeztetéssel. A kódtáblában szabadon létrehozhatunk új eseményt és ehhez az eseményhez előre adott időpontban munkafolyamatot rendelhetünk. (Az eseményt a TMS rendszer fogja generálni.)
Vegyünk egy gyakorlati példát: Ügyfél kérésére adott időpontban el kell valamilyen tevékenységet végezni, például szabadsága alatt a védett objektum helyszíni ellenőrzését. Ennek elvégzéséhez definiálunk egy eseményt (kódtábla kezelésnél pontosan tárgyaljuk ennek módját), majd ehhez az eseményhez definiálunk egy (vagy akár több) munkafolyamatot ahol a tevékenység leírásában megadjuk ez elvégzendő feladatot, és ezeket a munkafolyamat bejegyzéseket adott időponthoz rendeljük. Így az elvégzendő feladatról az operátor riasztást fog kapni, így annak elvégzése nem maradhat el, valamint a munkafolyamat kezelése során az elvégzett tevékenység dokumentálásra is kerül.
A munkafolyamat adott időponthoz rendeléséhez a már definiált munkafolyamatot ki kel jelölni majd az időzítő panelen a riasztás időpontját be kell állítani és az óra szimbólummal azt a kijelölt munkafolyamat bejegyzéshez kell rendelni:
Időzített munkafolyamat a munkafolyamat listában is jelölésre kerül:
Természetesen az időzítés az időzítő panelen az óra gombra való kattintással meg is szüntethető.
2.4.3.2.5.3 Automatikus munkafolyamatok definiálása
Definiálhatunk olyan munkafolyamatot is (a munkafolyamat sablonban is) ami nem az operátornak ír elő feladatot, hanem magának a TMS rendszernek. Ezt nagyon hasonló módon tehetjük meg az előzőleg részletezett munkafolyamat definícióhoz, csak itt a feladat leírása helyett egy külső programot és annak paramétereit adhatjuk meg, valamint értelemszerűen ehhez a tevékenységhez nem rendelhetünk hangjelzést, hisz ez az operátor számára nem jelent feladatot:
A külső programok listájának kezelésével később a 2.4.11.1 pontban fogunk foglalkozni.
Automatikusan végrehajtódó funkciót is tudunk időzíteni.
2.4.3.2.5.4 Kivételek definiálása
Felmerülhet igényként, hogy a beállított munkafolyamatot csak akkor kell elvégezni, ha az esemény bizonyos zónáról, vagy zónákról érkezik, de más esetben nem. Nézzük meg hogy ügyfél munkafolyamatoknál a kivételek lapon ezt hogyan tehetünk meg!
Megjegyzés: többekben felmerülhet a kérdés, hogy miért bonyolítja a TMS túl ezt a dolgot, hiszen észrevehetjük, hogy ezt a feladatot megoldhatjuk a zónáknál tárgyalt zóna kategóriák alkalmazásával is? Ott az egyes zónákat más-más kategóriába sorolhatjuk és ezekhez a kategóriákhoz önálló munkafolyamat sablonokat rendelhetünk – vagy éppen ha azt akarjuk, hogy ne generáljon riasztást ahhoz a zónakategóriához rendelt zóna akkor ahhoz a kategóriához nem készítünk munkafolyamat sablont.
Nos ez nem a túlbonyolítás, hanem az egyszerűsítés miatt került így kialakításra: Ha egy-két ügyfélnél merül fel igény adott esemény zónánkénti eltérő kezelésére, akkor ez egyszerűbben megvalósítható az adott egy-két ügyfél munkafolyamat definíciójánál és nem kell külön zónákat kategorizálni, külön munkafolyamat sablonokat készíteni, stb. Ha viszont akár több tíz ügyfélnél kell például a kültéri zónák által generált eseményeket eltérő módon kezelni, akkor már egyszerűbb a kategorizálás és sablonok alkalmazása mint több tízszer ügyfelenként a kivételek definiálását elvégezni.
Kivételt csak az előzőleg operátori, vagy automatikus munkafolyamat lapon definiált feladatokhoz rendelhetünk, munkafolyamat sablonokhoz nem. Ha kiválasztunk egy definíciót, akkor a lap felső szekciójában láthatjuk annak adatait (esemény és elvégzendő munkafolyamat neve) és alatta az adott eseményhez tartozó, előzőleg már definiált (2.4.3.2.3 pontban bemutatott módon) zónaadatokat. Alapértelmezésben a munkafolyamat minden zónára vonatkozik, de itt szűkíthetjük ezt és egyes zónákra kitilthatjuk a feladat végrehajtását. Az alábbi képen egy nem feltétlenül életszerű példa látható ahol a betöréshez rendelt munkafolyamatot letiltottuk ha a betörésjelzés a „Bejárat” nevű zónáról érkezik. Ilyenkor az alsó adatmegjelenítő rácson az „Esemény” oszlopban látható jelzés mutatja, hogy ez a feladat nem minden zónára vonatkozik.
Ezzel a módszerrel az is megoldható, hogy ugyanazon esemény bekövetkezte esetén bizonyos zónákra más feladat kerül végrehajtásra, mint más zónákról jövő értesítés esetén. Például az előző pontokban megismert módszerrel már be tudjuk állítani akár azt is, hogy ha a betörésjelzés a „Bejárat” zónából jön, akkor az más feladatleírással vagy/és más hanggal induljon el a munkafolyamat riasztás. Ehhez csak még egy munkafolyamatot kell definiálni a betörés jelzésre már az új jellemzőkkel, majd azt ki kell tiltani a Bejáraton kívül a többi zónáról.
A feni pontokban összefoglaltuk milyen lehetőségeink vannak az ügyfelekhez rendelt munkafolyamatok definiálásakor és ez ijesztően összetettnek tűnhet, de nézzük hogyan mit is kell tennünk az esetek 99%-ában egy ügyfél létrehozásakor:
Egyszer(!) a telepítés után létre kell hozni a szükség szerinti munkafolyamat sablonokat, vagy meg kell módosítani a rendszerhez adottakat, ha azok abban a formában nem megfelelőek. Alapértelmezettnek kell kijelölni azt amit minden ügyfél esetén alkalmazni szeretnénk.
Ezután ha létrehozunk egy ügyfelet a kódja, neve, és kódtáblája megadásával, már a munkafolyamat definíció is kész van! A rendszer már működőképes, de ezt még finomíthatjuk az értesítendők megadásával (ami nem megkerülhető, ha csak nem ügyfélcsoportot alkalmazunk, hisz ez ügyfélspecifikus információ). Ezután elvégezhető a munkafolyamat sablonok – értesítendők összerendelése, ami pár egérkattintással megtehető. Valamint a zónák neveinek megadásával segíthetjük az operátor munkáját.
Az ügyfelek riasztóközpontjaiban generálódó események egy része általában előre megadható időpontokban generálódik. Tipikusan ilyen események a nyitás és a zárás: Amennyiben ügyfelünk az üzlethelyiségét védi, akkor annak nyitása, zárása a nyitva tartásnak tipikusan azonos időpontokban fog bekövetkezni. Lehetőségünk van eseményenként, napi bontásban előre megadni, hogy az adott eseménynek mikor kell bekövetkezni. Ha a megadott időtartományon belül nem érkezett meg, vagy azon kívül érkezik az esemény, akkor azzal automatikusan egy másik eseményt generálhatunk amihez munkafolyamatot köthetünk, így például az operátort utasíthatjuk, hogy ellenőrizze a szokásostól való eltérés okát.
Minden eseményhez (vagy nyitás/zárás státuszváltozáshoz) naponta akár több időablakot rendelhetünk, amikor annak be kell, és azon az időablakot kívül nem szabad bekövetkeznie. Ebből következik, hogy a definiáláskor eseményenként vagy státuszváltásonként, naponta meg kell adni az engedélyezett időpont elejét, és végét.
A definiálást a következő panel segítségével tudjuk elvégezni:
Tudunk bármilyen eseményt figyelni, de van két kitüntetett „esemény”. Ezek tulajdonképpen nem önálló események hanem a zárási státusz változása. Vagyis ez aktivizálódik, ha bármely esemény a zárási státuszt beállítja (vagyis élesítették a központot a védett objektumban), vagy törlődik ez a státusz ha pl. felhasználói nyitás történt a központban.
A fenti képen látható konfiguráció szerint a felhasználói nyitást figyeljük (zárási státusz törlése). A figyelés minden nap történik, vagyis minden napot kijelöltünk a pipával és minden napra 00:00-00:00 időintervallumtól eltérő értéket állítottunk be. Látható, hogy hétfő – szombat időintervallumban 07 és 08 óra közt kell megtörténni a nyitásnak. Vasárnap láthatjuk, hogy az időintervallum eleje és vége megegyezik (és 00:00-00:00 -tól eltérő) ami azt jelzi, hogy nincs olyan időszak amikor be kell következni a nyitásnak, tehát ha az bármikor jön az helytelen időben jön, és ennek megfelelően ha egyáltalán nem jön, az nem okoz nyitás elmaradt jelzést.
Időablak nem nyúlhat át éjfélen, tehát az időablak elejének és végének azonos napon kell lennie.
Látható, hogy definiálni kell, hogy mit tegyen a rendszer, milyen eseményt generáljon, ha nem érkezett meg a beállított esemény az adott időintervallumban, illetve melyik eseményt generálja ha a beállított időablakon kívül érkezik meg az esemény.
Feltűnhet, hogy a 00:00-00:00 beállításnak kitüntetett szerepe van. Ez a korábbi verziókkal való kompatibilitás miatt kellett megtartani, ahol ez a bejegyzés jelezte, hogy azon a napon nincs időablak figyelés. Azért hogy ez minél kevesebb zavart okozzon a jelen beállításnál is pár dolgot automatizálni kellett: ha egy napon beállítjuk, hogy itt időablak figyelést szeretnénk végezni, vagyis bekattintjuk a nap előtti pipát, akkor az időintervallum automatikusan 12:00-12:00 -ra ugrik. Innen könnyebb is a feltehetően napközbeni időpont beállítása. Ha letiltjuk a nap figyelését az időintervallum visszaáll 00-00 időszakra. Ha kézzel állítjuk be a 00-00 időszakot, a nap figyelése letiltódik, ha előtte be is volt állítva.
A következő táblán az ügyfelekhez képeket rendelhetünk:
A beviteli panel három részre osztható:
A felső szekcióban a képek manipulálására szolgáló segédeszközöket találjuk:
A középső rész a kép megjelenítésére szolgál. Amennyiben a kép mérete miatt nem lehet egyszerre megjeleníteni, akkor a görgetősávokkal mozgathatjuk a képet a megjelenítést végző ablakban. A kiválasztott kép megjelenítésekor, ha arra a „0-s zónát” vagyis a védett objektum helyét elhelyeztük (például térkép esetén) akkor az, ha megoldható, középen fog megjelenni. Természetesen ha pl. a megjelenített térkép szélén van az ügyfél telephelye, akkor az középre nem kerül, de mindenképpen a látható felületen lesz. Így könnyebb azonosítani egy térképen a védett objektum helyét.
Az panel alsó részében választhatunk az ügyfél zónái, és egy speciális bejegyzés közt, ami a már említett módon a védett objektum helyének kijelölésére használhatunk. Ha a kép felületére kattintunk akkor a kiválasztott zónát „elhelyezhetjük” a képen. A zónát a zóna száma (0 - a védett objektum helye), és egy kis nyíl jelöli:
Ha ismét ugyanarra a helyre kattintunk, akkor a szimbólumunkat „levehetjük” a képről. Ha az egérkurzort (nyilat) a szimbólum közelébe mozgatjuk, akkor az alsó szekcióban kiíródik a zóna neve.
Az ügyfelekhez megjegyzéseket rendelhetünk. Ezeknek a megjegyzéseknek a kezelését végezhetjük a következő táblán.
Az tábla felső részében az adatok kezelésére, valamint a megjelenítés befolyásolására szolgáló gombsort találjuk. A megjegyzések megjelenítését stílusát (nagy ikon, kis ikon, részletek stb.) a Windows rendszerekben megszokott módon módosíthatjuk, így ezt részletesen nem elemezzük. Ha a részletes listázást választjuk (ez az alapértelmezett, és a fenti képen is ez látható), akkor a felsorolt bejegyzések sorrendjét a bejegyzések fejlécére kattintva tudjuk módosítani.
Ha kiválasztunk egy megjegyzést akkor annak szöveges része az alsó szekcióban jelenik meg. Ha a megjegyzéshez tartozik csatolt állomány, akkor azt (vagy azokat) gombsor jelképezi a csatolt állomány nevével. A gombra kattintva megjeleníthető/letölthető az állomány.
Az adtok kezelését a bal felső szekcióban látható három gomb segítségével végezhetjük el.
Új megjegyzés létrehozása: Az első gomb megnyomásával az ablak felülete átalakul, és így lehetőségünk van egy új megjegyzés szerkesztésére.
Új megjegyzés rögzítéséhez először nevet kell adnunk a megjegyzésünknek. A listában majd ezen a néven fog szerepelni. Érvényességi időhatárt nem kötelező kijelölni, de megtehetjük. Ez az időpont csak tájékoztató jellegű, ha túlléptük is, a megjegyzés ugyanúgy kezelhető, mint előtte.
Szabályozhatjuk, hogy a megjegyzéshez milyen módon férhetnek hozzá a felhasználók. Beállításunktól függően a korlátozott jogosultsággal rendelkező operátorok a megjegyzést nem is látják, csak olvashatják, vagy akár korlátozás nélkül kezelhetik is. Jelen esetben mindenki „Felhasználó” kategóriába tartozik, ha nincs joga az ügyfelek és így az ügyfelek adatainak kezeléséhez és az elemzések kezeléséhez ahol szintén a megjegyzésekhez szükséges teljes hozzáférési jog. Ha korlátozott joggal rendelkezünk, akkor csak olyan megjegyzést hozhatunk létre amit minden felhasználó tud kezelni.
Továbbá itt jelölhetjük, hogy megjegyzést vagy hibajegyet szeretnénk rögzíteni. A hibajegy kezelése megegyezik a megjegyzésével, csak mivel típusa más, így könnyen különválogathatjuk azokat elemzések alkalmával.
Az tábla legnagyobb részét kitevő területre írhatjuk magát a megjegyzést. Ennek mérete nincs korlátozva.
Amennyiben rendelkezünk megfelelő jogosultsággal, a második gombbal módosíthatjuk a kiválasztott megjegyzést. A megjegyzés szerkesztése egy eltéréssel megegyezik az új megjegyzés létrehozásával, csak jelen esetben már adatokkal feltöltve jelenik meg az adatszerkesztést biztosító képernyőkép:
A korábban megadott adatok módosításán túl lehetőségünk van a már meglévő megjegyzésünkhöz állományok csatolására (gemkapocs gomb), vagy egy meglévő csatolt állomány törlésére (a csatolt állományt jelképező gomb előtti mínusz jelre való kattintással), vagy az állomány letöltésére/ megjelenítésére a gomb nevet tartalmazó részére való kattintással.
Amennyiben rendelkezünk megfelelő jogosultsággal, a harmadik megjegyzéskezelő gombbal törölhetjük a kiválasztott megjegyzést. A szándékunk megerősítésére még egy kérdést tesz fel a program.
A védett objektumokból beállítástól függően különböző időközönként tesztesemények érkeznek. Ezeknek az eseményeknek az elmaradása lényeges, beavatkozást igénylő információ. Ezen események, pontosabban az események elmaradásának nyomon követését állíthatjuk be ezen a lapon.
Először is lehetőségünk van a tesztesemények figyelését engedélyezni, vagy letiltani. Ha engedélyeztük a tesztesemények figyelését, akkor beállíthatjuk, hogy maximum milyen időközönként kell teszteseménynek érkezni, valamint hogy a teszteseményt az ügyféltől érkező bármilyen esemény (életjel) pótolhatja-e, vagy csak a teszt típusú eseményt tekintjük elfogadhatónak. Ha a feltételnek megfelelő esemény nem érkezik a megadott időszak alatt, akkor a teszt elmaradását a kiválasztott esemény fogja jelezni. Célszerűen ehhez az eseményhez a már megismert módon munkafolyamatot rendelhetünk.
Lehetőségünk van a tesztfigyelés átmeneti felfüggesztésére. Ez jól alkalmazható például új ügyfél definiálásakor. Ebben az esetben a definiált, de még nem bekapcsolt ügyfél nem generál elmaradt teszt jelzést, de ha az ügyféltől megérkezik az első olyan esemény ami a beállított feltételek szerint teszt eseménynek tekinthet a rendszer, automatikusan törli a tesztfigyelés felfüggesztését.
Egyes esetekben az ügyfelek eseményei, vagy eseményeinek egy része a megvalósított adatátviteli út sajátosságai miatt többszörösen is megérkezhetnek a felügyeleti központba. Ez néha zavaró lehet, hisz eseményhez rendelt automatikus SMS vagy e-mail értesítés esetén többszöri SMS/E-mail küldést eredményez. Ennek a zavaró tényezőnek a megakadályozására lehetőségünk van úgynevezett „Eseményismétlés tiltási sablonok” létrehozására (lásd: 2.4.10.1). Itt megadhatjuk, hogy adott események ha a (másodpercen) beállított időintervallumon belül ismételten megérkeznek a felügyeleti központba, akkor ugyan regisztrálva legyenek, de tiltott vagyis kezelést nem igénylő eseményként jelennek meg.
Ezen a lapon ezeket a sablonokat aktivizálhatjuk, vagy tilthatjuk a kezelt ügyfélnél:
Mint látható csak ki kell jelölni egy-egy pipa elhelyezésével a használni kívánt sablont, majd a változásokat aktivizálni a szokásos módon.
Nem csak a zónákhoz hanem az ügyfélhez, pontosabban a védett objektumhoz is lehetőségünk van eszközöket rendelni.
Az eszközöket egy listából választhatjuk ki (aminek szerkesztését a 2.4.7 pontban részletezzük), majd megjegyzést és egy dátumot fűzhetünk még az ügygélhez rendelt eszközhöz.
A 2.4.3.2.6 pontban láthattuk, hogy van módunk ellenőrizni, hogy egy adott esemény egy definiált időablakban megérkezik-e, vagy sem, illetve figyelni, hogy az időablakon kívül érkezik-e meg. Ez tipikusan a kötött munkarend szerint dolgozó védett objektumok, például üzletek ellenőrzésére alkalmas, ha annak nyitás-zárás periódusát akarjuk ellenőrizni. Viszont van pár korlátja ennek a figyelési módnak. Ilyen, hogy ha ugyan például a zárás megtörténik a megadott időablakon belül, de utána valami miatt még egyszer nyitni kell (amiről jelzés jön az operátornak egy jól beállított rendszernél, hisz tiltott időben érkezett a nyitási esemény, de nyugtáz is az illetékes kapcsolattartó hisz indokolt a nyitás), és ha ezután nem történik meg a zárás, arról már nem kap figyelmeztetést az operátor, hisz időablakon belül volt már egy zárás. Ezen kívül további problémát jelenthet, hogy olyan objektumban ahol a zárás néha éjfél előtt néha utána történik, ott a már a megismert módon nem tudjuk a zárás ellenőrzését elvégezni. A fenti problémák megoldására alkalmazható a „Státusz ellenőrzés”.
Itt a nyitott, vagy zárt állapotát, státuszát vizsgálhatjuk az objektumnak adott időpontban. Naponta több ellenőrzési időpontot is beállíthatunk egy-egy státusz ellenőrzésére akár 5 perces lépésekben. Ha zárt, vagy nyitott állapot ellenőrzésénél nem a megfelelő státuszban van az ügyfél objektuma, arról eseményt generál a rendszer. Ehhez a generált eseményhez köthető munkafolyamat, így az ügyfél igénye szerint reagálhat a felügyelet a problémára.
A fenti képen látható, hogy a zárt és nyitott állapotot ellenőriztetjük a rendszerrel naponta egyszer. (Nyitott állapot ellenőrzése vasárnap nem történik meg)
Lehetőségünk van egyedi ügyfélre jellemző kulcs – érték párok definiálására. Mivel elképzelhető, hogy több ügyfél esetén is azonos kulcs, sőt esetleg érték megadására lehet szükség így a használni kívánt kulcsokat mi bármelyik ügyfélnél létrehozhatjuk és ezek a kulcsok ettől kezdve minden ügyfélnél rendelkezésre állnak. A kulcsokhoz megadott értékeket a rendszer automatikusan gyűjti és adott kulcs esetén ezek közül választhatunk, vagy új értéket adhatunk meg. Egy ügyfélhez azonos kulccsal több érték is definiálható.
A kulcs érték párokat a következő lapon definiálhatjuk:
A képen láthatjuk a már definiált kulcs – érték párokat. A kulcs választása után választhatunk az eddig használt értékek közül, vagy újat adhatunk meg. Új kulcs – érték pár rögzítésekor a művelet dátuma is letárolásra kerül.
Új kulcs definiálását a fogaskerék gombbal tudjuk kezdeményezni és a következő ablakban elvégezni:
Minden kulcsnak egyedinek kell lennie. Ennek figyelembevételével:
A 2.4.3.1 pontban már beszéltünk az ügyfélcsoportok legalapvetőbb jellemzőiről, sőt a létrehozásukról is szó volt, ami gyakorlatilag megegyezik az új ügyfél definiálásával, kivéve hogy nem kell ügyfélkódot és kódtáblát megadnunk. Most az ügyfélcsoportok legfontosabb jellemzőit és megjelenítésüket nézzük át:
A képen egy ügyfélcsoportot láthatunk aminek neve „Teszt”. Már itt az objektumböngészőben is látható, hogy nem tartozik hozzá ügyfélkód, viszont jelen esetben tartozik hozzá egy úgynevezett gyermekobjektum „Teszt ügyfél” néven aminek adatait korábbiakban már láthattuk. Egy csoportobjektum alá természetesen több ügyfél is rendezhető, sőt maguk a csoportobjektumok is korlátozás nélkül egymás alá szervezhetők. Ezzel gyakorlatilag a számítógépek fájlrendszeréhez hasonló hierarchikus struktúrába szervezhetjük ügyfeleinket könyvtár → ügyfélcsoport; fájl → ügyfél megfeleltetéssel.
Azt már láthattuk, hogy hogyan kell ügyfelet létrehozni úgy, hogy az egy ügyfélcsoport tagja legyen, de most nézzük meg miért is tegyünk ilyet, mi a hasznunk belőle. Ügyfélcsoport használata esetén egyes adatokat elég egyszer megadni és az érvényessé válhat minden csoporttag (vagyis gyermekobjektum) számára. Nézzük milyen adatok kezelésére van mód, és ezt hogyan tehetjük meg.
Ha kiválasztunk az objektumböngészőben egy ügyfélcsoportot, akkor a jobb oldali panelen (hasonlóan az ügyfeleknél már megismerttel) több lapon végezhetjük az adatok rögzítését, csak éppen jelen estben sokkal kevesebb lap közül választhatunk:
Látható, hogy ezeket az adatbeviteli lapokat már megismertük, itt is ugyanazzal a módszerrel kezelhetjük ezeket egészen minimális változásokkal.
Nézzük az alapadatokat:
2.4.3.2.1 pontban megismert laphoz képest itt az a legszembetűnőbb, hogy mindössze az ügyfélcsoport nevét tudjuk módosítani, valamit a „Riport szükséges” jelzést. Viszont megjelent egy eddig nem látott lakat gomb is a lapon. Ezzel a gombbal mintegy zárolhatjuk az itt beállított jellemzőt, és ezzel minden az ügyfélcsoporthoz rendelt gyermek objektumra kötelezővé tehetjük azt, vagyis felülbírálhatjuk az ott beállított értéket. Lényeges hogy az ilyen „zárolt” adatok nem írják felül az ügyfélhez beállított saját adatokat, csak felülbírálja azt. Ha a szülő ügyfélcsoport objektumban zárolunk egy (vagy több) értéket, azt a gyermek objektumokban (ami ügyfél, vagy másik csoport objektum lehet) már nem tudjuk módosítani, és ezt egy lakat szimbólum ott jelzi is. A zárolás megszüntetésekor a gyermekobjektumokban az adott objektumban korábban beállított értékek jelennek meg. Ez oly módon is igaz, hogy ha egy ügyfelet bemozgatunk egy csoportba és az így átveszi a csoport jellemzőit, majd később kiemeljük a csoportból, akkor az ügyfél visszatér eredeti beállításaihoz, azokat nem veszíti el, ha azok a csoportban nem is juthattak érvényre a csoport zárolásai miatt. Ez az szabályzott tulajdonság „öröklés” akkor is működik ha több ügyfélcsoportot ágyazunk egymásba.
Miután megismertük a jellemzők zárolását, azok kötelezővé tételét a gyermekobjektumokra, nézzük meg milyen adatokkal tehetjük ezt meg és milyen más módszerrel adhatunk még át adatokat a csoport tagjainak!
Címadatoknál címcsoportonként szabályozhatjuk az öröklést, vagyis például lehet minden ügyfélobjektumnak saját címe, de a riport, számlázási vagy levelezési címadatokat csak egyszer kell megadnunk, ha minden a csoportban szereplő ügyfél számára ezek azonosak.
Értesítendőknél viszont ez a módszer már nem lenne hatékony, hisz lehetnek olyan személyek akik minden a csoportban szereplő objektum értesítendői között kellene, hogy szerepeljenek, de vannak olyanok is akik csak egy-egy ügyfélobjektumnál. Erre az a megoldás, hogy minden a csoportobjektumban rögzített értesítendő személy megjelenik minden csoporttag értesítendő listájában de ott ezek az adatok nem módosíthatóak, viszont lehetnek saját értesítendőik is.
Erre példaként nézzünk egy definíciót ahol egy értesítendőt („Közös teszt értesítendő” néven) az ügyfélcsoportban definiálunk. Ilyenkor a gyermek ügyfélnél az értesítendők így jelennek meg:
Ugyanez a vezérelv a megjegyzések kezelésénél is. Az ügyfélcsoportban létrehozott megjegyzések minden gyermekobjektumban megjelennek:
Természetesen a közös, ügyfélcsoportban létrehozott megjegyzésekhez is csatolhatunk állományokat.
Ügyféljellemzők kezelése is az előzőekben ismertetett formában történik, vagyis a gyermekdokumentumoknál megjelenik, de nem szerkeszthető a szülő ügyfélcsoportban (vagy ügyfélcsoportokban) létrehozott ügyféljellemző kulcs – érték pár.
Mint láthattuk, ha egy ügyfelet el akarunk távolítani a rendszerből akkor azt nem kell feltétlenül törölni, elég ha „Aktív” jellemzőjét töröljük, vagy „Felfüggesztve” állapotba állítjuk (lásd: 2.4.3.2.1). Ha ennek ellenére mégis törölni szeretnénk az ügyfél minden adatát a rendszerből akkor azt az ügyfél objektumának kiválasztása után az „Eszközök” → „Törlés <ügyfélnév>” menüponttal, vagy az ügyfél nevén jobb egérgombbal való kattintás után a lebegőmenüből a „Tölés <ügyfélnév>” menüpont kiválasztásával tudjuk megtenni. Ezután figyelmeztetést kapunk arról, hogy a törléssel eltávolítunk a rendszerből minden az ügyfélhez kapcsolódó adatot is. Ha ezek után is a törlés mellet döntünk, akkor az ügyfél adatai végérvényesen törlődnek a rendszerből.
Ügyfélcsoport is hasonló módon törölhető de ezt csak akkor végezhetjük el, ha a csoportnak nincs egyetlen tagja sem!
A gyakorlatban felmerülhet igényként, hogy egy ügyfélről másolatot készítsünk. Egy adott ügyfél duplázását az objektumböngészőben az ügyfél nevén való jobb egérgombbal való kattintással indíthatjuk. A megjelenő lebegő menüből az „Ügyfél duplázása...” menüpontot kell kiválasztani. A megjelenő dialógusablakban adhatjuk meg az új (duplikált) ügyfél egyedi adatait:
Mint látható az új ügyfél négy jellemzőjét kell megadni: ügyfélkódját, nevét, kódtábláját (ami alapértelmezésben ugyanaz mint az eredeti ügyfélé volt), valamint a szülő objektumét, vagyis szülő ügyfélcsoport nevét, ha egy csoporthoz akarom rendelni az új ügyfelet.
Az adatok megadása után az „OK”gombra kattintva létrejön a megadott adatok alapján az új ügyfél. Az eredeti ügyfél adataiban nem történik változás!
Lehetőségünk van az objektumböngészőben az ügyfél objektumán való jobb egérkattintással megjelenő menüből közvetlenül módosítani az ügyfélhez rendelt kódtáblát. Ehhez az előző pontban megismert dialógusablak jelenik meg és ott a feladatnak megfelelő adatok módosítása után elvégezhetjük a kívánt feladatot.
Figyelem: A kódtábla módosítását követően minden olyan ügyfélhez rendelt szabály törlésre kerül amiben kódtáblában lévő eseményre való hivatkozás van.
Láthattuk, hogy új ügyfél megadásakor rögtön kiválaszthattuk a szülő objektumot, de később is szükség lehet rá, hogy csoportba rendezzük ügyfeleinket, vagy éppen felbontsunk egy csoportot és egyes ügyfeleket kivegyünk onnan.
Egy adott ügyfél mozgatását az objektumböngészőben az ügyfél nevén való jobb egérgombbal való kattintással indíthatjuk. A megjelenő lebegő menüből az „Mozgatás...” menüpontot kell kiválasztani. A megjelenő dialógusablakban adhatjuk meg hogy mely csoport tagja legyen a továbbiakban a kiválasztott ügyfél:
Az eseménycsoportokban lévő események neve egy listából választható. Ennek a listának a szerkesztését egy központi objektum alatt tudjuk kezelni:
Az események neveinek központi kezelésével elérhetjük, hogy az események megnevezése (azonos funkciók esetén) közös lehet több kódtáblán is. Az eseménynév lista bármely elemén végzett módosítás automatikusan minden kódtáblában érvényre jut ahol a módosított név szerepel. Az eseménynév szótár ad lehetőséget az eseménynevek nyelvének módosítása is.
Az adatok kezelését a következő módon tudjuk elvégezni:
A lista bővítése vagy egy név módosítása a már megismert módon elvégezhető. Egy elem törlése, csak abban az esetben hajtódik végre, ha nincs hivatkozás rá egy kódtáblában sem. A hivatkozások megléte az esemény neve előtt szereplő „villám” jel jelöli ahogy az a képen is látható.
A nevek három oszlopban kerülnek letárolásra. Megjelenítésre esemény érkezésekor csak kizárólag az első oszlopban látható megnevezések kerülnek, valamint közvetlenül módosítani is csak ezt tudjuk. A maradék két oszlopot akkor tudjuk jól hasznosítani, ha módosítani szeretnénk az elnevezéseket, például át szeretnénk írni a megnevezéseket más nyelvre. Így megőrizhetjük az eredeti nyelvű szöveget is. Valamely oszlop adatait egyszerre átmásolhatjuk egy másik oszlopba. Ehhez ki kell választani, hogy melyik oszlop adatait szeretnénk másolni melyik oszlopba. A másolás a „Másolás” gombbal lehet elvégezni. A célként megjelölt oszlopban eredetileg tárolt adatok felülíródnak.
Előfordulhat, hogy két hasonló elnevezés is van a táblázatunkban és szeretnénk ha csak egyik maradna. Gondot az jelent hogy mindkét eseménymegnevezés számos kódtáblában jelölhet eseményt, vagy eseményeket. Ezen munka egyszerűsítésére szolgál az eseménymegnevezések összevonását segítő funkció. Itt ki kell jelölni, hogy melyik eseménynevet akarjuk általánossá tenni, vagyis mi legyen az összevonás alapja (például „Felhasználói nyitás”), valamint ki kell választani, hogy melyik eseménynevet akarjuk átnevezni az összevonás alapjának megjelölt névre (például „Felhasználó nyit” kiválasztása az „Összevon” mezőben). Ezután az „Összevonás” gomb lenyomásával a program végignézi az összes kódtáblát és minden eseményt amit eddig a példa szerint „Felhasználó nyit” eseményként jelent meg, átnevez „Felhasználói nyitás” eseménynévre. Ezzel megszüntettük, hogy egyes ügyfelektől „Felhasználó nyit”, más ügyfelektől „Felhasználói nyitás” néven érkezett ugyanazzal a jelentéssel bíró esemény. Ezután az „Felhasználó nyit” megnevezés a már megismert módon törölhető lesz, mert nem hivatkozik rá egy esemény sem.
Azért, hogy a TMS rendszer értelmezni tudja az ügyfelektől érkező kódokat, definiálni kell a kód → esemény összerendeléseket. Ezek az összerendelések általában az ügyfél riasztójának, vagy a riasztó kommunikációs protokolljának függvényében változnak. Mivel több ügyféllel való kommunikációhoz is azonos kód → esemény összerendeléseket használhatunk, célszerű ezeket az összerendeléseket csoportba szervezni. Ezeket az adathalmazokat nevezzük kódtáblának vagy eseménycsoportnak. A kódtábla tartalmaz minden az elemi kommunikációs kódokhoz tartozó olyan információt, ami a vevőegységtől érkező kódok helyes értelmezéséhez szükséges.
A TMS rendszer tartalmaz legalább két olyan speciális kódtáblát, ami magának a TMS komponenseinek a helyes működéséhez szükségesek. Ezek a csoportok a 2.4.3 bekezdésben már tárgyalt, a rendszer működéséhez szükséges ügyfelekhez vannak rendelve. Ezekben a kitüntetett eseménycsoportokban a módosítások lehetősége korlátozott.
Az eseménycsoportok létrehozása, módosítása az objektumböngésző használatával, a már megismert módon történik: A „Kódtábla” objektum segítségével új csoportot hozhatunk létre. Már létező eseménycsoportot az eseménycsoport objektumának kiválasztásával tudunk módosítani.
Új eseménycsoportot az „Kódtábla” objektum kiválasztása után tudunk létrehozni:
Ekkor a jobb oldali panelen az új eseménycsoporthoz minimálisan szükséges adatok kitöltésére szolgáló beviteli mezőket látjuk:
Új eseménycsoport definiálásához kötelezően mindössze a létrehozandó kódtábla nevét kell kitöltenünk, de rövid leírást is rendelhetünk az eseménycsoporthoz Ezen túl lehetőségünk van egy már meglévő eseménycsoport adatainak átvételére. Ekkor egy választott csoport adatait „örököltethetjük”. Ezzel a megoldással egyszerűen lehet létrehozni olyan eseménycsoportot ami csak kis mértékben különbözik egy már meglévőtől.
Ha örököltetni akarunk, akkor kijelöltnek kell lennie az „Öröklés engedélyezése” választómezőnek, és ki kell választanunk, hogy melyik, már létező kódtábla adatait akarjuk átvenni. Ha kódtáblát egy már meglévőből örököltetünk (vagyis duplikálunk), akkor a kódtábla minden adata megjelenik az új ködtáblában, sőt a kódtáblára való hivatkozások (például munkafolyamat sablonok) is duplikálásra kerülnek.
Az beviteli mezők megfelelő kitöltése után a „Bővít” gombbal tudjuk az új eseménycsoportot létrehozni.
Egy kódtábla adatainak módosításához az objektumböngészőben ki kell jelölni a módosítani kívánt objektumot. A módosítani kívánt kódtábla kiválasztása után a jobb oldali panelen megjelennek a kódtábla adatait tartalmazó lapok:
Az első táblán a kódtábla alapadatait tudjuk módosítani, míg a második lapon az kódtáblában definiált eseményadatokat.
Az alapadatok lapon az eseménycsoport nevének módosítása, valamint az eseménycsoporthoz rendelt rövid magyarázószöveg módosítására van lehetőségünk, továbbá ezen a lapon láthatjuk, hogy az adott eseménycsoport adatai mely ügyfelekhez vannak rendelve.
Az adatok a már megismert adatmegjelenítő rács segítségével elemezhetőek. A kiválasztott adatsor elemeinek módosítása vagy bővítése a következő panelen végezhető el:
Az adatbeviteli mezők a következők:
Események adatai:
Zóna adatai:
Automatikus program start
Státuszadatok:
Ha új, pl. 4/2-es kódokat tartalmazó kódtáblát definiálunk akkor az események felvitelénél lehetőség van egy további egyszerűsítésre. Mivel a zónafüggő események általában egymást követő kóddal vannak jelölve a panelen megoldható, hogy a kód és a zónaszám automatikusan növekedjen. Ha az „Aut. köv.” választómezőt kipipáljuk, akkor adatsor tárolásakor, vagyis az „Bővít” gomb lenyomásakor a program automatikusan növeli az eseménykódot, valamint a zónaszámot. Így az azonos nevű, zónánként külön eseménykóddal érkező események (például „Felhasználói zárás”) definiálása rendkívül leegyszerűsödik.
Az eseménycsoport objektumának kiválasztása után a törlést az „Eszközök → Törlés < eseménycsoport név>” menüpontok, vagy a jobb egérgombbal való kattintás után a „Törlés <eseménycsoport név>” kiválasztásával tudjuk megtenni. Ezután még egy megerősítést vár tőlünk a rendszer. Ha itt is igennel válaszoltunk, és az eseménycsoport nincs egyik ügyfélhez sem rendelve akkor a törlés végrehajtódik.
Olyan eseménycsoportot ami ügyfélhez van rendelve nem lehet törölni!
Mint azt már a 2.4.3.2.3 pontban a zónák definíciójánál és a 2.4.3.2.11 pontban az ügyfélhez rendelt eszközöknél láthattuk, létezik egy eszköz lista amiből választhatunk. Ennek a listának a szerkesztését a „Központok és tartozékok (eszközök)” objektum kiválasztásával tudjuk elvégezni:
A jobb oldalon megjelenő beviteli mezők és adatmegjelenítő rács felhasználásával a már megszokott módon tudjuk szerkeszteni, bővíteni, vagy törölni az eszközöket tartalmazó listánkat:
A lista elemeit több kategóriába sorolhatjuk. A telepítést követően Központ, Érzékelő modul, Kezelő modul, Kommunikátor és Egyéb eszközök kategóriákat tartalmaz a rendszer. A későbbiekben igény szerint ezeket a kategóriákat bővíthetjük új elemekkel, illetve a telepítéskor meglévő kategóriák is módosíthatók, de csak korlátozottan. A kategóriák kezelését a fogaskerék gombbal tudjuk elindítani. A megjelenő ablakban végezhető műveleteket a 2.4.3.2.13 pontban már megismertük, csak itt az eszközkategóriák szerkesztését tudjuk elvégezni.
Az eszköz típusán kívül még az eszköz megnevezését kell megadnunk. A listában a megszokott módon kis villámjel jelöli azokat az eszközöket amelyek legalább egy ügyfélhez hozzá vannak rendelve, ezek nem törölhetők.
Telepítést követően a TMS rendszer csak minta eszközadatokat tartalmaz.
Mint láthattuk a 2.4.3.2.4 pontban az ügyfelekhez közös, több ügyfélhez is csatolható munkatársakat (céget, személyt, szervezett, járőrt, stb.) is rendelhetünk az értesítendők között. A munkatársak adatait ehhez előre rögzíteni kell. Ezt tehetjük meg a következő objektum kiválasztásával.
A munkatársak adatait a jobb oldalon megjelenő panelen szerkeszthetjük a már megszokott módon.
A munkatársak adatai alatti szekcióban láthatjuk azon ügyfelek listáját akikhez a telepítő hozzárendelésre került
A munkatársainkat több kategóriába sorolhatjuk. A telepítést követően Szerelő, Járőr és Egyéb kategóriákat tartalmaz a rendszer. A későbbiekben igény szerint ezeket a kategóriákat bővíthetjük új elemekkel, illetve a telepítéskor meglévő kategóriák is módosíthatók, de csak korlátozottan. A kategóriák kezelését a fogaskerék gombbal tudjuk elindítani. A megjelenő ablakban végezhető műveleteket a 2.4.3.2.13 pontban már megismertük, csak itt a munkatársak kategóriáinak szerkesztését tudjuk elvégezni.
Ha egy eseményhez operátori feladatokat rendelünk, akkor az operátornak az elvégzett munkáját dokumentálni kell. Ilyenkor kiválaszthatja azt is, hogy az adott esemény milyen kategóriába (riasztási kategóriába) tartozik. Itt adhatjuk meg, hogy például téves riasztás történt, teszt, éles riasztás stb. Ezeket a kategóriákat szabadon definiálhatjuk a következő módon. Az objektumböngészőben válasszuk ki a „Riasztási kategóriák” objektumot:
A jobb oldalon megjelenő panelen tudjuk a kiválasztható kategóriákat bővíteni, vagy meglévő kategória szövegét módosítani:
Ügyféladatok definíciója során már szó volt a sablonokról, azok felhasználásáról a 2.4.3.2.5.1 pontban. Mint láthattuk a munkafolyamatok definíciója azon alapszik, hogy az ügyfélhez egy vagy több munkafolyamat sablont rendelünk (esetleg értesítendőhöz is kötve) és a továbbiakban csak speciálisan az ügyfélre vonatkozó, a szokásostól eltérő definíciókat kell elvégeznünk.
A 2.4.3.2.10 pontban pedig azt tárgyaltuk, hogy az automatikus eseménytiltás másként nem is valósítható meg, csak ha szükséges tiltási feltételeket sablonban, vagy sablonokban definiáljuk és azok használatát engedélyezzük az adott ügyfélnél.
Talán ez a két legáltalánosabban használt sablon típus, de sablonokat más helyeken is használhatunk nem csak ezeken. A következő pontokban megismerjük nem csak az említett, hanem minden a rendszer által támogatott sablon definiálásának pontos menetét.
A sablonok kezelése (definiálása, módosítása törlése) függetlenül a sablon típusától egységes módon történik.
Új sablon létrehozásához ki kell választani az objektum böngészőből a létrehozni kívánt sablont reprezentáló objektumot:
A kiválasztás után az objektum adatait tartalmazó lapon láthatóak a sablonra vonatkozó legfontosabb általános információk. Minden esetben meg kell adni a sablon nevét és megadhatunk hozzá egy rövid leírást, valamint egyéb sablonspecifikus adatokat.
Ha minden általunk szükséges adatot megadtunk, akkor a „Bővít” gombra kattintva létrejön a megadott paraméterekkel a sablon, de még természetesen szabálydefiníciók nélkül.
A már legenerált sablont ha kijelöljük az objektumböngészőben, akkor a jobb oldalon két lapon jelennek meg a sablonra vonatkozó adatok. Az első lapon a sablonra vonatkozó alapadatokat módosíthatjuk, a második lapon a sablon definícióinak tartalmi részét. A lapok közt a megszokott módon választhatunk a felső szekcióban lévő „fülek” segítségével.
Az alapadatok mindig tartalmazzák a sablon nevét és egy rövid leírásra adnak lehetőséget, és több esetben beállítható, hogy a sablon alapértelmezett legyen-e. Ha alapértelmezett egy sablon akkor egy új ügyfél létrehozásakor a sablon azonnal hozzárendelődik az új ügyfélhez, nem kell nekünk ezt kézzel megtenni. Természetesen ezt az összerendelést később módosíthatjuk.
Egyes sablonoknál felsorolásra kerülhet a már hozzá rendelt objektumok listája, sőt egyes esetekben az összerendelést itt is módosíthatjuk.
Sablon törlése a már más objektumoknál is megismert módon lehetséges: Az objektumböngészőben a törölni kívánt sablont kijelöljük, majd vagy az „Eszközök” menüben a „Törlés <sablonnév>” menüponttal indítjuk a törlést, vagy jobb egérgombbal kattintunk a sablon nevén és a megjelenő lebegő menüben a törlés menüpont segítségével törölhetjük a sablont és adatait.
Törölni csak olyan sablont tudunk amire nincs hivatkozás másik objektumból.
Egyes esetekben az ügyfelek eseményei, vagy eseményeinek egy része a megvalósított adatátviteli út sajátosságai miatt többszörösen is megérkezhetnek a felügyeleti központba ami néha zavaró lehet. Ennek a zavaró tényezőnek a megakadályozására lehetőségünk van úgynevezett „Eseményismétlés tiltási sablonok” létrehozására. Itt megadhatjuk, hogy mely események ha a beállított időintervallumon (másodpercen) belül ismételten megérkeznek a felügyeleti központba, akkor ugyan legyenek regisztrálva, de átmenetileg tiltott eseményként és ne keljen kezelni őket.
A sablon általános adatain (sablon neve és rövid leírás) túl ki kell választani, hogy a sablon melyik kódtábla adataira vonatkozik. Ezt a sablon létrehozásakor kell megadni és később már nem módosítható. Továbbá megadhatjuk, hogy a sablon alapértelmezett legyen-e.
A sablon tartalmi részének módosítását a sablonhoz rendelt második lapon („Sablon adatok”) végezhetjük el. Itt adhatjuk meg, hogy mely események ismétlését kívánjuk tiltani:
Az esemény nevén kívül másodpercben meg kell adni azt az időszakot is, amin belül a tiltás fennáll. Ha ezen időszakon belül ugyanaz az esemény, ugyanazon paraméterekkel, vagyis ugyanattól az ügyféltől, ugyanaz az eseménykód, ugyanavval a zóna és csoport (Group) jellemzőkkel érkezik, akkor az első eseményt követően a többi ugyan rögzítésre kerül, de átmenetileg tiltott eseményként kezeli a TMS.
A tiltási időszakot 1 másodperc és 3599 másodperc (gyakorlatilag egy óra) időintervallumban lehet beállítani.
A sablonban akár minden eseményre is definiálhatok eseménytiltást.
Munkafolyamat sablonokkal nagyban egyszerűsödik az ügyfelek kezelendő eseményeinek definiálása. A használatot a 2.4.3.2.5 pontban már tárgyaltuk, most a sablon kezelését ismerhetjük meg.
A sablon általános adatain (sablon neve és rövid leírás) túl ki kell választani, hogy a sablon melyik kódtábla adataira vonatkozik. Ezt a sablon létrehozásakor kell megadni és később már nem módosítható. Továbbá megadhatjuk, hogy a sablon alapértelmezett legyen-e. Minden zónakategóriához önálló munkafolyamat sablon rendelhető. A sablon létrehozásakor már definiálni kell a sablon érvényességét kijelölő zónakategóriát, de a későbbiekben ez módosítható, sőt a zónakategóriák szerkesztésére is van módunk egy már létező sablon alapadatait tartalmazó lapon. Zónakategóriákkal és azok szerkesztésével bővebben a 2.4.3.2.3 pontban a zónák adatainak definiálásánál, kezelésénél már foglalkoztunk.
Létező sablon alapadatainak módosítására szolgáló lapon lehetőségünk van egy gombnyomásra a sablon hozzárendelésére minden a sablon kódtábláját használó ügyfélhez, vagy minden sablon hozzárendelés megszüntetésére is!
További lehetőség, hogy a sablon alapadatainál a sablonban definiált szabályokra késleltetést tudunk megadni. Ez azt jelenti, hogy ha a sablonban definiált szabály szerint munkafolyamatot kellene indítani a TMS-nek, ezt a munkafolyamat indítást késleltethetjük egy előre definiált idővel. (A késleltetés idejét percben adhatjuk meg.) ContactID kódtábla esetén, ha a késleltetés ideje alatt a riasztást generáló esemény a riasztási eseményt nyugtázó párja megérkezik, akkor az esemény a késleltetés letelte után sem fog riasztást generálni.
Nézzünk erre egy gyakorlati példát: Készítsünk egy sablont az áramszünetek késleltetett kezelésére. A sablonban az „AC hiány” eseményre (kódja 1301) definiáljunk munkafolyamatot az operátor számára (felhasználói beavatkozást), majd állítsuk be erre a sablonra a késleltetést 30 percre. Ha ezt a sablont ügyfelekhez rendeljük és azoknál az ügyfeleknél másik (késleltetés nélküli) sablonban nincs erre az eseményre szabály, vagy az ügyfélnél nincs definiálva munkafolyamat az „AC hiány” eseményre, akkor az érintett ügyfeleknél az „AC hiány” esemény riasztást vagyis munkafolyamatot csak 30 perccel a bekövetkezte után fog generálni, de csak akkor ha közben nem érkezett az adott ügyféltől „AC hiány visszaállás” (kódja 3301) esemény. Ezzel a beállítással segíthetjük az operátor munkáját, hisz nem kell reagálnia rövid idejű áramszünetekre azoknál az ügyfeleknél, akiknél erre nincs szükség.
Már létező munkafolyamat sablon alapadatait a következő lapon tudjuk kezelni:
A sablon tartalmi részének módosítását a szokásos módon a második lapon végezhetjük el. A munkafolyamat sablon adatokat két részre lehet osztani, és az ezekhez tartozó definíciókat is külön kell elvégezni. Egyrészt ide tartoznak a felhasználói beavatkozások definíciói, másrészt az automatikus események definíciói. Ezek a fogalmak már ismerősek lehetnek az ügyfél-definícióban megismert munkafolyamat definícióból (2.4.3.2.5.2 és 2.4.3.2.5.3 pontok), de míg ott a sablonhoz képesti kivételeket adhattuk meg, itt magát a definíció törzsét végezhetjük el.
A munkafolyamat általános leírása már 2.4.3.2.5 pontban megtörtént, így az itt nem kerül még egyszer megismétlésre, itt csak konkrétan a sablonok adatainak definiálásával foglalkozunk. Mint látható lesz ez is sok ismerős elemet tartalmaz.
2.4.9.3.1.1 Felhasználói beavatkozások egyedi definiálása
Itt adhatjuk meg hogy a rendszer üzemeltetőének mit kell elvégezni ha egy bizonyos esemény érkezik. Lényeges, hogy mivel most egy általános definíciót (sablont) készítünk, ami több ügyfélre is alkalmazható lesz, így itt értesítendőket nem adhatunk meg, de ezen kívül minden szabály rögzítésre kerülhet. Az alábbi adatbeviteli panel segítségével tudjuk ezt megtenni:
Nézzük a definiálást hogyan tudjuk elvégezni. A beviteli panel adatainak kitöltése részletezve:
Ha két eseményt jelöltünk meg Pl. „Esemény 1” és „Esemény 2”, akkor az „Bővít” gomb lenyomásával két új munkafolyamatsor jelenik meg az adatmegjelenítő rácson.
Az adatmegjelenítő rácson láthatjuk az adott ügyfélhez rendelt munkafolyamatok minden adatát. Minden munkafolyamatot egy-egy sor ír le. Ha egy sort jelölünk ki akkor annak adataival kerül feltöltésre a felső beviteli mezőket tartalmazó terület. A kijelölt sort (munkafolyamatot) törölhetjük, vagy módosíthatjuk az adatait, és igény szerint új sorként rögzíthetjük, vagy a módosítást elmenthetjük.
Ha több sort is kijelölünk (pl. egérkattintás a sorokon a „Shift” vagy „Ctrl” billentyűk lenyomása mellet) akkor egyszerre tudunk a kijelölt sorokon műveleteket végezni. Ilyenkor viszont az adatmódosításra csak szűkebb lehetőségünk van:
Ezekre a megkötésekre azért van szükség, mert egyébként nem lehetne egyértelműen eldönteni, hogy a több soron végzett műveletek melyik soron milyen változást generáljon.
2.4.9.3.1.2 Automatikus munkafolyamatok definiálása
Definiálhatunk olyan munkafolyamatot is (a munkafolyamat sablonban is) ami nem az operátornak ír elő feladatot, hanem magának a TMS rendszernek. Ezt nagyon hasonló módon tehetjük meg az előzőleg részletezett munkafolyamat definícióhoz, csak itt a feladat leírása helyett egy külső programot és annak paramétereit adhatjuk meg, valamint értelemszerűen ehhez a tevékenységhez nem rendelhetünk hangjelzést, hisz ez az operátor számára nem jelent feladatot:
Mint látható a definíciók szinte teljesen megegyeznek az ügyfél definiálásánál megismertekkel.
Felügyeletek egyik problémája, hogy bizonyos esetekben olyan üzenetek, sok esetben kezelendő üzenetek, árasztják el az operátort ami a pillanatnyi munka szempontjából közömbös. Ha ezek elvonják az operátor figyelmét, akkor a tényleg lényeges események kezelése elsikkadhat. Ennek megoldására az operátornak és adminisztrátornak több lehetőséget is biztosít a rendszer. Ezek egyike a munkafolyamat sablonoknál használható késleltetés alkalmazása. További lehetőség, hogy az adminisztrátor eseménycsoport sablont hoz létre kézi tiltáshoz. Egy ilyen sablon összefoglalhatja az események egy kívánt csoportját, amelyeknek az átmeneti tiltását az operátor menüből tud be vagy kikapcsolni. Jól használható ez például vihar esetén tömegesen érkező „AC hiba” és „AC hiba visszaállás” események tiltására.
A definiált sablont az operátori modulban az „Ügyfél -> Eseménycsoport tiltása” menüpontban tudja az operátor aktivizálni és minden ügyfélre érvényes lesz, függetlenül az ügyfél egyéb beállításaitól, munkafolyamat sablon kapcsolataitól, azok paramétereitől.
A sablon általános adatain (sablon neve és rövid leírás) túl meg kell adni a sablon tiltási időszakát percben. A sablon aktiválását követően ezen idő alatt a sablon szabályai érvényre jutnak. A sablont az operátor bármikor ki tudja kapcsolni a bekapcsoláshoz hasonló módon, de a beállított tiltási idő leteltével automatikusan inaktívvá válik, így nem lehet bekapcsolva felejteni.
Az alapadatokon túl a sablon adattartalma gyakorlatilag az események felsorolása. Kódtáblától függetlenül bővíthetjük a lista tartalmát:
A listaelemek mindegyikében egyszerre több elemet is kijelölhetünk és egyszerre végezhetünk műveleteket rajtuk.
A sablon felhasználásával kijelölhetünk ügyfeleket akiket „rejtetté” teszünk azon felhasználók (operátorok) számára akikhez ezt a sablont hozzárendeljük a 2.4.1.2 pontban megismertek szerint.
A sablon alapadatainak kezelése a már megismert módon történik. Az ügyféllistákat (látható és rejtett) pedig a következő beviteli panelen szerkeszthetjük:
Egyszerre egy vagy több ügyfelet kijelölhetünk és ezeket mozgathatjuk a két panel között, valamint lehetőségünk van minden kilistázott elem átemelésére is.
Az előző pontban megismertek analógiájára lehetőségünk van események elrejtésére is. A sablon felhasználásával kijelölhetünk eseményeket amiket „rejtetté” teszünk azon felhasználók számára az operátori modulban akikhez ezt a sablont hozzárendeljük a 2.4.1.2 pontban megismertek szerint.
A sablon alapadatainak kezelése a már megismert módon történik. Az eseménylistákat (látható és rejtett) pedig a következő beviteli panelen szerkeszthetjük:
Itt is egyszerre egy vagy több eseményt kijelölhetünk és ezeket mozgathatjuk a két panel között, valamint lehetőségünk van minden kilistázott elem átemelésére is.
A rendszer működése során külső modulok használatára is támaszkodik. Ezek alapvető működését tudjuk befolyásolni az objektumböngésző ezen pontján.
Mint látható két alapvető modultípus kezelése lehetséges ezen a ponton.
Az ügyfelek, a sablonok és az eseménycsoportok definíciójánál is találkoztunk már azzal, hogy valamely feltétel teljesülése esetén külső programot tudunk indítani. Ezeken a helyeken a külső alkalmazásokat minden esetben egy listából választhattuk ki. A lista előállításához az „Külső programok” objektumot kell kiválasztanunk.
Az objektum kiválasztásakor a jobb oldali panelen lévő, már ismert, adatmegjelenítő rács alkalmazásával tudunk futtatható programokat felvenni a listára.
definiáláshoz meg kell adnunk a futtatható program nevét, kézi beírással vagy az adatböngésző gomb és a megjelenő „megnyitás” dialógusablak segítségével. Megadhatunk a programnak paramétereket is. A programnak a TMS alapadatainak beállításakor megadott „Program útvonala” paraméterben szereplő könyvtárban kell lennie.
A rendszer több típusú vevőkészülékkel, vagy külső rendszerrel is képes kommunikációt folytatni, akár egy időben is. Ha a „Vevő illesztő egységek” objektumot válaszuk ki, akkor a jobb oldalon megjelenik a rendszer által tartalmazott vevők kezelésére alkalmas modulok listája.
Ezen a lapon van lehetőségünk új vevő illesztő egységet regisztrálására is.
A listában „kipipálva” vagy a „pipát” elvéve a megfelelő külső egységet kezelő modult aktiválhatjuk, vagy tilthatjuk. Az itt elvégzett változtatás csak az operátori modul következő indításakor jut érvényre.
(A DEMO események generálására szolgáló speciális interfész modul, használatával teszteléshez nem szükséges külső vevőegység)
Ha az operátor számára munkafolyamatot rendeltünk egy eseményhez, akkor ahhoz figyelmeztető hangot is köthetünk. Ezeknek a hangállományoknak a kezelését tudjuk a „Hangok” objektumhoz tartozó lapon elvégezni:
Az adatok kezelésére szolgáló panelen láthatjuk a már a rendszerbe definiált hangok állományait. A „Bővít” gombbal bővíteni tudjuk ezt a listát, a „Töröl” gombbal törölhetjük a kijelölt állományt, és van módunk adott hangállomány lejátszására is ha rendelkezünk hangkártyával.
A hangállományok az adatok számára kijelölt alkönyvtárban kerülnek tárolásra. Ha bővítjük a listát, akkor a kiválasztott állomány is ide kerül másolásra. Törlés esetén fizikailag is törlődik az állomány.
A rendszerben használt hangok listájának kezelésén túl ezen a panelen tudunk további speciális feltételekhez (ismeretlen ügyféltől érkező esemény vagy/és ismeretlen esemény regisztrálása, valamint a riasztott ügyfelek listájának bővülése) is hangot rendelni.
Megjegyzés: A speciális feltételekhez definiált hang definíciója csak azon a gépen jut érvényre ahol beállították
A felhasználók kezelésénél a 2.4.1.2 pontban már láthattuk, hogy egyes személyek jogosultságait korlátozhatjuk ügyfelek, vagy események általunk definiált csoportjára. Az alább ismertetett módon láthatjuk, hogy az operátori moduloknak is korlátozhatjuk a jogait és így bizonyos ügyfelek eseményei nem kerülnek megjelenítésre az adott operátori munkahelyen, függetlenül a bejelentkezett operátor jogosultságaitól. De ezen túl további lehetőségeink is vannak: Az operátori munkahelyeket jogosultsági sorba állíthatjuk és így ha „A” munkahely kiesik, akkor az ott addig kezelt ügyfél események kezelése automatikusan a definíció szerinti következő („B”) munkahelyen folytatható, az események ott jelennek meg, így az operátori munkahelyek egymás tartalékai lehetnek.
Ez a jogosultsági beállítás kizárólag az operátori modul ügyfelek eseményeihez való hozzáférésre vonatkozik, így az operátor az ügyféladatokhoz az operátori munkahely jogosultságától függetlenül (kizárólag saját személyes jogosultságának megfelelően) hozzáfér.
A felsorolt műveletek elvégzéséhez valamilyen módon az operátori modulokat, pontosabban az operátori modult futtató számítógépet azonosítani kell. Erre a TMS kliens egyedi azonosítója (ID) szolgál (lásd: 1.1.1.2 pont).
A definíciót két lépésben, két lapon végezhetjük el. Ezekhez a már megismert módon, jobb oldali definíciós területen látható két lap szolgál:
Az első lapon („Terminálok listája”) TMS kliens azonosítót (1.2.2 pontban tárgyaltuk) és így a kliens gépet „nevesíthetjük”, vagyis megadhatunk egy nevet a könnyebb azonosíthatóság érdekében. A definiálást a megszokott módon tudjuk elvégezni: Új bejegyzést hozhatunk létre és meglévő bejegyzést módosíthatunk, vagy törölhetünk. A használt hardver kulcsok definiálása, nevesítése (vagy akár ennek elhagyása) nem befolyásolja semmi módon a rendszer használhatóságát, de ha elvégezzük, akkor a TMS rendszerben pillanatnyilag bejelentkezett operátori modulokról is információt kaphatunk. A felsorolásban a hardverkulcs előtti villám szimbólum jelzi, hogy a kulcs legalább egy ügyfél biztonsági sablonhoz hozzárendelésre került. A megnevezés előtti szimbólum pedig megmutatja, hogy az adott hardverkulcsot használó operátori modul pillanatnyilag üzemel-e. Itt is a hibátlan működést a villám szimbólum jelképezi.
A második lapon tudunk a már definiált munkahelyekhez ügyfél biztonsági csoportokat rendelni:
A kiválasztott biztonsági csoport és egy-egy operátori munkahely közti összerendelést tudjuk engedélyezni, vagy tiltani az „Engedélyez” vagy „Tilt” gombokkal.
Egy Biztonsági csoporthoz több operátori munkahelyet is engedélyezhetünk. Ilyenkor is az események csak egy operátori modulon fognak megjelenni, mégpedig a sorban első üzemelő modulon. A modulok (operátori munkahelyek) sorrendjét a jobb oldali fel-le nyilakkal tudjuk szabályozni.
FIGYELEM: Ha akár egy összerendelést is megadunk, akkor a rendszer az operátori modulok számára csak az itt definiált jogosultságok szerint engedélyezi az események megjelenítését. Vagyis az összerendelés nélküli operátori munkahelyeken nem jelenik meg egy esemény sem! Ennek megfelelően ha valahol az összes ügyfél eseményét meg szeretnénk jeleníteni, akkor létre kell hozni egy olyan biztonsági csoportot ahol nincs rejtett ügyfél és az adott kulcshoz/operátori munkahelyhez ezt a csoportot kell hozzárendelni.
Figyelem: A definíciót minden esetben nagy figyelemmel kell elvégezni, mert helytelen beállítás esetén egyes ügyfelek eseményei, riasztásai egy operátori modulban sem fognak megjelenni, habár a rendszer átveszi azokat a vevő egységektől!
A rendszerben tárolt adatok összevont elemzésére nem csak riportok formájában lehet szükségünk. Az adatok két kitüntetett halmazát önállóan is kezelhetjük, elemezhetjük, hogy segítse a napi munkánkat, illetve átfogó képet kapjunk rendszerünkben tárolt adatokról. Ezeket az elemzéseket, esetleg beavatkozásokat az objektumböngésző „Elemzések” szekciójában tudjuk elvégezni:
Mint láthattuk (2.4.3.2.8 pont) minden ügyfélhez rendelhetünk megjegyzéseket, hibajegyeket, akár nagy számban is. Szükséges, hogy a napi munka során az egyes ügyfelekhez rendelt hibajegyeket, vagy eseményeket összesítve is látni, kezelni lehessen. Így szervezhető a napi munka a hibák javítására, vagy például így törölhetők egyszerűen azok a bejegyzések amelyek már nem aktuálisak.
A megjegyzések összevont kezelését a következő panelen lehet elvégezni:
Mint látható a megjegyzések kezelését hasonló módon tehetjük meg, mint ahogy azt már az ügyfélnél történő megjegyzések tárgyalásánál megismertük. Viszont van pár nagyon lényeges eltérés:
Természetesen a megjelenített sorokat a fejléc szövegére kattintással bármi szerint sorba rendezhetjük növekvő, vagy csökkenő sorrendbe.
Szükséges lehet, hogy átfogó képünk legyen arról, hogy az elmúlt napokban az egyes ügyfelektől érkeztek-e és milyen típusú események. Ezen elemzést tudjuk elvégezni ezen a ponton:
Megadhatjuk a visszamenőleg vizsgált napok számát, majd a frissítés gomb megnyomásával kérhetjük az összesítés elvégzését. Ez az összesítés az ügyfelek, valamint a vizsgált napok számának függvényében akár több perc is lehet! A megjelenő táblázatban minden ügyfél adatai külön-külön egy sorban kerülnek megjelenítésre. Láthatjuk az ügyfél nevét, kódját, utolsó esemény időpontját, utolsó tesztesemény időpontját, valamint a kért napokat. A kért napoknál a fenti magyarázatban látható szimbólumok, vagy azok hiánya jelzi az adott napon történteket.
Természetesen itt is a táblázat minden oszlopa szerint növekvő vagy csökkenő sorrendbe rendezhetjük a táblázatunk adatait a fejlécre kattintással.
A TMS rendszerben azok a komponensek, amelyek működéséhez nem szükséges felhasználói beavatkozás, szövegállományba naplózzák működésük eseményeit. A TMS alaprendszerben egy ilyen komponens van: az automatikus mentést végző modul. (Ezzel kapcsolatos bővebb információkat a 2.6 pontban tárgyaljuk)
Az adminisztrációs programmal megjeleníthetjük ezt a naplóállományt, valamint törölhetjük azt. A Naplóállományok kezelését a „Rendszernapló” objektumon belüli komponensével tudjuk elvégezni.
Az „Backup Napló” választása esetén a jobb oldali panelen megtekinthetjük a naplóállományt és igény esetén törölhetjük is azt a „Töröl” gombbal.
A naplóállományok az operációs rendszer adta lehetőségekkel is kezelhetők, az adatok könyvtárában találhatóak.
A TMS adminisztrációs programja nem tartalmaz beépített riport készítési lehetőséget, csak keretet ad a riportokat generáló külső modulokhoz. Ilyen modul pedig utólag is viszonylag egyszerűen beilleszthető a rendszerbe az igényeknek megfelelően. Az alaprendszer három modult tartalmaz, de ezek száma igény szerint bővíthető.
A Riport objektum kiválasztása után a jobb oldali panelen választhatunk a legördülő listából a rendszerbe illesztett riport modulok közül.
A kiválasztásra kerülő riport feladatáról, szükség esetén használatáról rövid leírást olvashatunk a „Riport leírása” szekcióban.
A riport futtatását a „Riport indítása...” gombbal tehetjük meg. Ezt követően már a kiválasztott riport futtatásához szükséges információkat és feltételeket kell megadnunk, majd legenerálni a riportot.
A TMS rendszer moduláris felépítéséből következően lehetőség van az alaprendszer kiegészítésére úgy, hogy a kiegészítő funkciókat tartalmazó, végrehajtó modulokat utólag csatoljuk a rendszerhez. Az ilyen kiegészítő modulok működése nagyban hasonlít az interfész modulok működéséhez, de lényeges eltérés, hogy ezek nem egy külső rendszerrel való folyamatos kapcsolattartást valósítanak meg, hanem a rendszer üzemeltetői számára nyújtanak szolgáltatásokat. Ezeket a szolgáltatásokat menüpontokon keresztül lehet igénybe venni. Minden ilyen kiegészítő modul használatához szükséges menüpont az „Eszközök” menü almenüjeként jelenik meg a modul telepítése után.
A kiegészítő modulok többnyire valamilyen adatcsoport rendezett, táblázatos megjelenítésére és esetleg ezen adathalmaz exportálására szolgálnak. Az ilyen típusú adatmegjelenítés esetén az adatok megjelenítését végző ablakban lehet bizonyos beállításokkal szabályozni a megjelenített adatok körét.
Az alaprendszer tartalmaz egy speciális kiegészítő riport generáló modult is ami az ügyfelek eseménylistáinak készítését segíti. Ennek használatát tekintsük át részletesen.
Az alaprendszer részét képző eseménylista riport generálására szolgáló modul az „Eszközök” menü három menüpontján keresztül érhető el. A menük használatához először foglaljuk össze hogyan működik ez a riportgeneráló modul.
A riport készítése két lépésben történik:
Ezzel a módszerrel az elvárásainknak megfelelő formátumú, tartalmú riportokat generálhatunk úgy, hogy magát a definíciót csak egyszer kell megadni és később többször felhasználhatjuk. Természetesen szükség esetén a kész riportdefiníciós állományt a későbbiek folyamán módosítani is tudjuk.
A riport modul funkcióit három menüponton keresztül érhetjük el:
A riportdefiníciót a „Riport készítése” menüpont kiválasztása után egy úgynevezett varázsló segítségével tudjuk elkészíteni. Ez lépésről lépésre végigvezet minken hogy milyen feltételekkel akarjuk a riportot létrehozni. A varázsló tulajdonképpen adatbeviteli lapok sorozata, amelyek közt az „Előre” vagy „Vissza” gombokkal mozoghatunk, vagy ha meg akarjuk szakítani a riportdefiníció futtatását, azt a „Mégsem” gombbal tehetjük meg. Miután minden lapon megadtuk a szükséges információkat, a „Mentés” gombbal tudjuk elmenteni a riportdefiníciót.
Az eseménylista riportok ügyfelenként egy-egy html állományba kerülnek lementésbe, így a generált riport akár elektronikus formában is továbbítható, vagy bármely web böngésző programmal megjeleníthető, esetleg igény esetén kinyomtatható.
Nézzük részletesen, laponként milyen adatok megadására van szükség egy riportdefiníció létrehozásához.
Vizsgált időszak kijelölése
Meg kell adni, hogy mely időszak adatairól kívánunk riportot készíteni. Nény módszert is választhatunk az időszak megadására. Konkrétan megadhatjuk az elemezni kívánt időszakot, de kijelölhetjük, hogy a készítendő eseménylista mindig a készítést megelőző adott időszak adatait tartalmazza.
Események szűrése
Szűkíthetjük a listázásra kerülő események körét, azok tulajdonságai alapján.
SMS küldési riport készítésére is van lehetőségünk. Ilyenkor adott időszakra listázhatjuk a kijelölt ügyfeleknek kiküldött SMS üzeneteket, természetesen ha rendelkezünk SMS küldést lehetővé tevő kiegészítő modullal.
Ügyfelek
Megadhatjuk, hogy mely ügyfelek adatairól készüljön eseménylista.
Kijelölhetjük, hogy az összes ügyféladatáról kérünk listát, mi is megadhatjuk egyesével, hogy mely ügyfelek adatairól kérünk, vagy felhasználhatjuk azt az információt amit az ügyfelek definíciónál adtunk meg, vagyis hogy az ügyfél igényel-e riportot eseményeinek adatairól. Ennek beállításáról a 2.4.3.2.1 pontban már beszéltünk.
Megjelenítés
Itt adhatjuk meg hogy mely adatok megjelenítése szükséges a riportban.
Látható, hogy négy fő szekció létezik. Az első háromban az ügyfélre vonatkozó, valamint az összesített adatok megjelenítését engedélyezhetjük, vagy tilthatjuk le. A negyedik szekció maga a részletes eseménylista, amit ha meg szeretnénk jeleníteni, akkor megadhatjuk, hogy az események mely adatai kerüljenek a listába. A részletes eseménylistában két adat megjelenítése nem tiltható le, ezek az időpont és az esemény neve.
Riport megjelenítési jellemzői
Itt adhatjuk meg hogy az adatok milyen formai feltételek szerint kerüljenek megjelenítésre.
Mint látható a variációk száma kellően nagy, így a megjelenítést egyéni az elvárásokhoz lehet igazítani.
Lényeges kiemelni, hogy a szövegek betűméretét egy alapértékhez képest lehet módosítani. A „0” érték azt jelzi, hogy nem változtatunk, de szövegtípusonként csökkenthetjük vagy növelhetjük ezt a méretet.
Riport útvonala
Az elkészített riportot szétválogathatjuk az ügyfél címadatainál („Riport címadatok”) megadott riport küldési paraméterek szerint:
A riport alkönyvtárának neveiben helyettesítő karaktereket használhatunk, ahol az adott helyettesítő karaktersor a riport generálásakor az aktuális dátumra és időpontra fog módosulni. Ennek helyes használatáról példa is látható. Ezzel a módszerrel a riport generálásánál elkerülhető az előzőleg (például előző hónapban) képzett riportok felülírása.
„Mentés” gombbal tárolhatjuk az elkészített riportdefiníciót.
Figyelem: Ha egy adott riporttípus útvonalát üresen hagyjuk, akkor azok a riportok amelyeknek abba a könyvtárba kellene, hogy létrejöjjenek, nem generálódnak le még akkor sem ha egyébként előírtuk az adott riport szükségességét!
Riportdefiníció szerkesztése ugyanannak a varázslónak a segítségével történik amit már az előző pontban megismerhettünk. A „Riport szerkesztése” menüpont megadása után a megjelenő állomány nyitási dialógusablak segítségével meg kell adni, hogy mely riportdefiníciót szeretnénk szerkeszteni. A definíció megadása után a rendszer betölti az adatokat a varázslóba, ahol a már megismert módon szerkeszthetjük azokat.
A „Riport futtatása” menüpont kiválasztása után meg kell adni, hogy mely riportdefiníció alapján kívánjuk az eseménylistákat elkészíteni. Ezután a listák generálása elkezdődik. Az eseménylisták a definícióban megadott alkönyvtárban jönnek létre. Az eseménylista az ügyfélnevéből és ügyfélkódjából kerül kialakításra. Például: „Teszt ugyfel (1234;4321).html”. Az ügyfélnévben az ékezetes betűk lecserélésre kerülnek ékezet nélküli párjukra.
Az OrMEBackup program a TMS rendszer adatainak mentését végzi el. A program tipikus használata során a program automatikusan kerül indításra az operátori modul által, az adminisztrátori felületen beállított szabály(ok) szerint naponta egyszer (vagy akár többször is). A program felépítése támogatja, hogy az egyéni igények szerint, teljesen automatizáljuk a mentést, akár úgy is, hogy a mentett adatok több verzióját tároljuk. A program indítása után az előre definiált, valamint a paraméterekben átadott adatok alapján elvégzi a mentést. A mentés folyamán fellépő eseményekről log bejegyzés jön létre amit a már megismert módon (lásd: 2.4.14) tudunk megtekinteni vagy akár törölni.
A mentés problémamentes lefutásának előfeltétele, hogy a használt PostgreSQL adatbázis kliens programja telepítve legyen a futtató számítógépre és elérhetősége, továbbá a mentés célkönyvtára a „TMS paraméterek” programmal definiálásra kerüljön (lásd: 1.1.2) A mentés célkönyvtárát célszerű úgy kijelölni, hogy az (amennyiben erre lehetőség van) a számítógépes hálózaton, egy másik számítógépen lévő osztott hozzáférésű alkönyvtár legyen. Ha erre nincs mód, akkor a TMS-t futtató számítógépen kell megadni a mentés célkönyvtárát.
A mentés során az adatbázisban tárolt ügyfél és eseményadatokon túl konfigurációs adatok, valamint az adatok számára kijelölt alkönyvtárból a hangállományok és egyéb megjelenítési beállításokat tartalmazó segédállományok kerülnek még mentésre. A mentés célkönyvtárában a mentéshez szükséges átmeneti állományok kerülnek, és ebből a könyvtárból nyíló „BackupBase” könyvtárban jön létre egy tömörített fájl ami tartalmaz minden mentett adatot. Ez a tömörített állomány a nevében tartalmazza a létrehozás dátumát és egy sorszámot, így egy nap több mentés is készülhet. A létrejövő állomány neve a következő módon épül fel: „CSAutBackup<ééhhnn>_<sss>.csdmp”. Itt „ééhhnn” a létrehorás napját (év, hó nap) jelöli, az „sss” pedig egy sorszám ami 000-tól 999-ig változhat ha egy nap több mentést is végzünk.
Az OrMEBackup program paraméterezése nélkül a mentés a megadott báziskönyvtárba fog történni az ismertetett módon.
A programot paraméterezve is indíthatjuk. Ennek helyes szintaktikája a következő:
OrMEBackup [/T:<útvonal>][/FileDB:<állomány_szám>]
Az OrMEBackup program indítását célszerűen a SYSTEM ügyfél eseményeihez (pl. óraváltások, napváltások, hóváltások stb.) kapcsolt munkafolyamatban kell indítani, de igény esetén lehet az operációs rendszer időzített folyamataként is megadni. (lásd: Windows feladatütemező vagy “schtasks” parancs)
A DataCenter is egy önálló program, de míg az előzőekben tárgyalt OrMEBackup arra van felkészítve, hogy automatikusan végezze feladatát az indítás után, majd álljanak le, addig a DataCenterrel a rendszer adminisztrátora végezhet adatkezelési feladatokat. A program futtatásához a Windows rendszergazdai jogosultság szükséges.
A program indítása után itt is névvel és jelszóval kell azonosítani magunkat. Annak van joga a Datacentert indítani, aki az adminisztrátori modulba is be tud lépni. Viszont mivel ez a program például a rendszer összeomlása, az adatok megsemmisülése utáni helyreállításra is használható, így ha a DataCenter indításakor nem érhető el a felhasználói adatokat tartalmazó adattábla, akkor név és jelszó ellenőrzés nélkül fog elindulni, mivel feltételezi, hogy adatsérülés miatt nem érhető el a TMS adatbázis. Természetesen ez kockázatot is jelent, így használatát ennek megfelelően kell szabályozni.
A program funkcióit több lapon érhetjük el. Nézzük a DataCenterrel elvégezhető feladatokat!
A programmal lehetőségünk van a TMS rendszer adatainak mentésére a 2.6 pontban bemutatott OrMEBackup programtól függetlenül és legfőképpen részben eltérő jellemzőkkel. Valamint lehetőségünk van a már meglévő mentési állományok törlésére is.
A program indítása után a „Mentés” lap jelenik meg, itt végezhetjük el ezeket a funkciókat:
A programablak felső részén tudunk a három alapfunkciót megvalósító lap között választani. (A harmadik lap gyakorlatilag az előző két lapon végzett műveletek részletes naplóját tartalmazza).
A „Mentés” lapon beállítható a mentési útvonal, ami alapértelmezetten a rendszer mentési célkönyvtárából nyíló „BackupBase” alkönyvtár. (Ennek szerepét a 2.6 pontban már tárgyaltuk.) Ezt az útvonalat módosíthatjuk is a beviteli mező melletti választógomb segítségével. A megadott alkönyvtárban található mentési állományokat, és azok jellemzőit a képernyő középső részén láthatjuk. Mint már említettük az OrMeBackup program által generált állomány neve „CSAutBackup<ééhhnn>_<sss>.csdmp” formátumú. Viszont a Datacenter „CSManBackup<ééhhnn>_<sss>.csdmp”névkonvenciót használ. Így később is látható, hogy mely mentéseket milyen módszerrel készítettük. Az is lényeges, hogy az OrMeBackup csak a saját maga által generált állományokat törli a megismert módon, így a DataCenter segítségével manuálisan készült mentések automatikusan nem fognak törlődni. A DataCenterből viszont lehetőségünk van bármely mentési állomány törlésére.
Látható, hogy az állomány nevén kívül további három jellemző is megjelenítésre kerül. Ez a mentés kezdetének és végének ideje, valamint a mentési állomány állapota. Ezek a jellemzők magából a mentési állományból kerülnek kiolvasásra, illetve a fájl állapota a teljes átvizsgálás eredményét mutatja. Így adott esetben a mentési állomány sérülése, használhatatlansága nem csak akkor derül ki ha szükség lenne rá.
Ha kiválasztunk egy vagy több mentési állományt, akkor azokat a „Törlés” gombbal, szándékunk megerősítése után, törölhetjük.
Ha új mentési állományt akarunk készíteni, akkor ahhoz beállíthatjuk, hogy a készítendő állomány sűrített állomány legyen-e. Ha a sűrítést választom, az valamivel kisebb mentési állományt eredményez, de mivel a mentendő komponensek egy része eleve sűrített így a méretcsökkenés mértéke minimális.
A mentést a „Start” gomb lenyomásával kezdhetjük meg. Ilyenkor automatikusan a „Napló” lap jelenik meg ahol követhetjük a mentés folyamatát.
Mentett adatokból (függetlenül attól, hogy az DataCenter-el vagy OrMEBackup-al készült) az adatok visszaállítása a Datacenterrel lehetséges. Itt a második, „Visszaállítás” lapot kell kiválasztanunk.
Mint láthatjuk itt csak a mentési útvonal kiválasztására, és a megjelenő mentési állományok listájából egy állomány kiválasztására van módunk. További két paraméterrel befolyásolhatjuk a visszatöltés folyamatát:
„Start” gombbal indítható az adatok visszaállítása.
FIGYELEM: Adat visszaállítás csak akkor lehet sikeres ha természetesen a TMS rendszer telepítve és konfigurálva van a gépen, de a DataCenter kivételével egy modul sem fut a visszaállítás időpontjában! Valamint nagyon lényeges, hogy adat-visszaállítással végérvényesen elveszik a visszaállítást megelőző pillanatnyi állapot és a továbbiakban az adatbázis tartalma a mentési állomány készítésekor létező állapotra áll vissza!
Az adat-visszaállítás indítása után még egyszer meg kell erősítenünk szándékunkat. Ha itt is az adat-visszaállítás folytatása mellet döntünk, akkor a már tárgyalt módon a naplóadatokat tartalmazó lapon követhetjük nyomon a visszaállítás folyamatát.
Mint láthattuk minden műveletünk naplózásra kerül. Ezt a naplót nézhetjük meg vagy kezelhetjük a negyedik, „Napló” feliratú lapon.
Itt minden elindított művelet tevékenységét nyomon követhetjük. Az elkészült naplót állományba menthetjük a „Mentés (napló)” gombbal, vagy törölhetjük azt.
Az adminisztrátori modul mellett az operátori modul a rendszer másik nagy és összetett komponense. A modul használatának részletes bemutatása önálló dokumentumban történik. Adminisztrátori feladat az operátori modulban a kialakított TMS rendszerfelépítéshez igazodó, az adott céges elvárásoknak megfelelő beállítások elvégzése. Erre az operátori modul „File” → „Konfiguráció...” menüpont ad lehetőséget. Az elvégezhető beállításokat az operátori modul leírása tárgyalja.
További, tipikusan adminisztrátori feladat a vevő interfész modulok beállítása. Ennek lehetőségeit bővebben az A. függelékben tárgyaljuk.
A TMS DataShow program felületét tekintve kísértetiesen hasonló az operátori modulhoz, de tényleges operátori tevékenység nem végezhető vele. A program kizárólag a TMS rendszerben tárolt élő és statikus adatok megjelenítésére, elemzésére szolgál, de ott az eseményadatokhoz kapcsolódó adatmódosítást nem végezhetünk. Adatmódosítás csak az ügyfelekhez rendelt megjegyzések kezelésével végezhetünk a belépett felhasználó jogosultságainak megfelelően.
A TMS rendszer komponensei eltérő gépeken lehetnek, így könnyen előfordulhat, hogy az adatbázis és az operátori munkahely eltérő gépeken üzemel. Ez viszont magában hordotta annak lehetőségét, hogy ha a két gép között megszakad a folyamatos TCP/IP kapcsolat, az az operátori munkahely hibára futását jelenti, még akkor is ha a hiba átmeneti jellegű. Átmeneti hiba az adatbázis és az operátori modul között úgy is előfordulhat, ha az adatbázis duplikálásra kerül és a „mester” adatbázis meghibásodás miatt kiesik és a tartalék adatbázis veszi át a feladatait. Ilyenkor a TMS alapbeállításainak módosításával az új adatbázis elérést be kell állítani a hibamentes állapot visszaállítása érdekében.
Az ilyen jellegű feladatok elvégzéséhez olyan ismeretek szükségesek amelyeket az operátori tevékenységet végző kollégáktól nem várható el, viszont a hibaelhárítás mihamarabbi elvégzése létfontosságú lehet. Ezen probléma feloldására készült a TMS szerver ellenőr programja. A program az egyéb TMS komponensekhez hasonlóan indítható:
A program indításához alapértelmezett beállítás esetén nem szükséges bejelentkezési adatok megadása. A program hibamentes állapotban 30 másodpercenként (hibás állapot esetén 5 másodpercenként) ellenőrzi a TMS adatbázisszerver problémamentes elérését, valamint hogy az ellenőrzést végző gépen hibamentes módon fut-e az operátori modul. Ha az adatbázis szerver nem érhető el, akkor azt hanggal jelzi, valamint a futó (valószínűleg már hibaüzenettel várakozó) operátori modult leállítja.
Az ellenőrzések és hiba esetén végzendő tevékenységek pontos szabályozását a fogaskerekekkel jelölt gomb megnyomásával indíthatjuk el, de ehhez már TMS adminisztrátori jogosultság szükséges.
A gombnyomást, és azonosítást követően a következő felületen tudjuk a TMS szerver ellenőr beállítását elvégezni:
A konfigurációs felületen négy kategóriában a következő beállítások elvégzésére van módunk:
Általános beállítások:
Operátori modul ellenőrzési stratégia:
Operátori modul indítási stratégia:
TMS adatbázis ellenőrzése:
A TMS szerver ellenőrző az adatbázis eléréséhez szükséges adatokat a TMS alap konfigurációjából veszi. Ez a konfiguráció tartalmaz egy adott IP címet és egyéb az adatbázis kezelőbe való belépéshez és adateléréshez szükséges adatokat. Viszont tételezzük fel hogy ugyan egy adatbázis-kezelő számítógépünk van, de az egy távoli telephelyen működik és az üzembiztos adatkapcsolat miatt a távoli telephely két publikus IP címmel rendelkezik. Ha ilyenkor kiesik az egyik internet szolgáltató által nyújtott IP elérés, akkor a TMS tovább üzemeltetése csak a szerver kapcsolatnak a másik IP cím beállítása után van lehetőség.
Ilyen estben a szerver eléréshez használható két (vagy akár több) IP címet kell a szerver ellenőrző programban megadni, pontosvesszővel elválasztva. Ha a szerverellenőrző az első IP címen nem éri el az adatbázist, akkor megkísérli a következőn. Amelyik címen sikerül a kapcsolatfelépítés, azt az IP címet beállítja a TMS alap paraméternek és így indítja (vagy újraindítja) az operátori modult.
Ha adatbázis emelt rendelkezésre állása érdekében replikáljuk a „mester” adatbázist, akkor az elmondottakhoz hasonlóan kell minden adatbázis IP címét felsorolni, lehetőleg a mester adatbázis címével kezdve. Ilyen esetben lehetőségünk van a replikáció ellenőrzésének beállítására is. A replikáció megszakadása esetén hangjelzés mellet pár percenként figyelmeztető dialógusablak jelzi az operátor számára a problémát.
Szükséges lehet, hogy egy TMS munkahelyen kizárólag a vevők kezelését akarjuk megvalósítani. Ez operátori modul futtatásával is megoldható, de nem hatékony megoldás. Operátori modulba indítás után be kell jelentkezni, továbbá a modul a tényleges vevő kezelésen túl számos egyéb funkciót is elvégez ami jelen esetben teljesen felesleges, hisz operátori tevékenységet nem akarunk végeztetni ennél a gépnél.
Ilyen szituáció esetén hatékonyan alkalmazható a „TMS központi vevő kezelés” program rendszer, ami a TMS egyéb komponenseihez hasonlóan indítható. A központi vevő kezelés tulajdonképpen két programmodulból áll. Az „Esemény kezelő” felügyeleti szerepet tölt be és feladata, hogy ellenőrizze a folyamatos, hibamentes működést. A másik modul („Esemény feldolgozó”) több példányban futhat és az „Esemény kezelő” felügyeleti modul indítja és ellenőrzi működését. Minden elindított „Esemény feldolgozó” példány egy-egy vevőinterfészt kezel és így azon keresztül fogadja a vevők jelzéseit, majd feldolgozást követően letárolja azokat a TMS adatbázisban.
Az „Esemény kezelő” modul:
A modul a TMS konfigurációjának megfelelően (lásd: a 2.4.10.2 pont) indítja az „Esemény feldolgozó” modulokat.
Az esemény kezelőben lehetőségünk van a gépünk megnevezésére („Fájl” → „Név beállítása”). Ez a név a fogadott események sorában a „Vevő/Vonal” mezőben fog megjelenni.
Az „Esemény feldolgozó” modulokban az adott vevő interfész beállításait, konfigurálását tudjuk elvégezni a „Fájl” → „<Vevőinterfész neve>” menüpont alatti almenükben. A „Fájl” → „Interface DUMP” menüponttal beállíthatjuk, hogy diagnosztikai céllal logoljuk a vevővel való kommunikációt. Itt lehetőségünk van a log állomány alkönyvtárának megadására is.
A „Esemény feldolgozó” modulok működés közben információt adnak az utoljára fogadott esemény adatairól, valamint egy élő diagramban láthatjuk az elmúlt időszak eseményforgalmát: