Az élet mindig úgy hozza, hogy minden munka során olyan kérdések merülnek fel, amelyek miatt minidig valami újjal kell foglalkozni. A mostani CA USD munkáim egyikében ismét felmerült, hogy szükséges egyes eszközök esetén plusz adatokat kezelni.

Az alaplogika azt diktálná, hogy az eszköztábla rekordját kibővítem a szükséges mezőkkel. Ezt követően nincs más dolgom, mint kódszinten leprogramozni, hogy mely eszközöknél kezelje a rendszer ezen plusz mezőket. Jó gondolat, de már egy bővítendő eszközkategória során is jelentős macera, nem ha több ilyen van (jelen munkában több mint egy tucat!). Mit lehet tenni? Amennyiben az ember ismeri az USD előző verzióit automatikusan az EXTENSION TABLE lehetőségekkel kezdene operálni.

Az Extension Table lényege tömören, hogy egyes Configuration Item Family-hoz rendelve az egyes extension-ket, a rendszer automatikusan kibővíti az adott osztályokat az extension-ben definiált plusz mezőkkel. Ezen adatokat a rendszer ugyan külön-külön táblában tartja, de automatikusan bekapcsolja az NR objektumba. Fontos azonban, hogy nekünk kell ügyelnünk rá, hogy ezen adatok csak az adott eszközosztály esetén legyenek használva!

Az eddigi rendszerekben ezen funkció használatához kézzel kellett a szükséges feladatokat elvégeznünk (DB bővítés, Schema kialakítása – ráadásul ez több ponton is). Mostantól – hála az r12 újdonságainak – ezen dolgoknak hátat fordíthatunk és ebben is segítségünkre van a rendszer Schema Designer-e.

A folyamat nem is olyan ponyolult, csak tudnunk kell mit is akarunk csinálni! Az alábbiakban összefoglalom lépésről-lépésre mit kell tenni és azután megy minden mint a karikacsapás. Lássuk hát sorban.

1. Annak érdekében, hogy a séma kiterjesztését a számunkra szükséges elemekkel elvégezhessük, indítsuk el a Web Screen Designer-t, és azt követően abból a Schema Designer-t.
   
2. Ezt követően nyomjuk meg az Add Extension Table gombot. A rendszer megkérdezi a létrehozandó tábla nevét, majd felveszi a tábla objektumot (a rendszer ennek az objektumnak a nevét is kiegészíti egy ‘z’ előtaggal, amit – több hazai kollégám gyakorlatával ellentétben – tilos megváltoztatni, levenni. Ha ezt elkövetjük az esetleges upgrade során a scriptek simán “átléphetik”, kihagyhatják az így általunk felvett extra elemeket).
3. Ha a táblánk megvan, akkor vegyük fel a szokott módon a számunkra szükséges elemeket. Ezek felvétele során minden eddig általunk ismert és a séma által támogatott lehetőség rendelkezésünkre áll.
4. Ha készen vagyunk mentsük el a változtatásokat.
   Fontos! A változások mentése előtt az egyes mezők még átnevezhetőek a GUI-n keresztül, ezt követően a séma név direktben már nem megváltoztatható (természetesen kézzel a scriptekben módosíthatjuk a dolgot, de akkor a Schema Designer leíróit is módosítanunk kell!)
5. A File menü Publish menüpontjával publikáljuk az elkészült módosítást. A rendszer ekkor tájékoztat minket, hogy ezzel még nem vagyunk kész, szükséges a pdm_publish utasítás alkalmazása is.
6. Ellenőrizzük, hogy a rendszert senki nem használja, majd állítsuk le a CA Service Desk szolgáltatást!
7. Indítsuk el a konzol ablakot és adjuk ki a pdm_publish utasítást. A rendszer ellenőrzi, történt-e újabb módosítás amit fel kell dolgozni. Ha igen, akkor ellenőrzi, fut a service. Ha igen hibaüzenettel leáll a folyamat (ezért iktattuk be a 6. pontot!)
   Ha mindezen túljutottunk, akkor a rendszerbe bedolgozásra kerülnek az elkészített változtatásaink, kiegészítéseink.
8. Indítsuk el ismételten a CA Service Desk szolgáltatást, és várjuk ki a rendszer teljes elindulását.
9. Ismételten indítsuk el a Web Screen Painter alkalmazást és ellenőrizzük a séma bővítésének megtörténtét. Amennyiben ez sikeres, akkor az nr tábla egy plusz assoc_<objektumnév> bejegyzéssel gazdagodott (a példa képernyőn ez a assoc_pbx kapcsolat).
   
10. Hozzunk létre egy a detail_<objektum név>.htmpl állományt (javasolt a detail_nr.htmpl állományból kiindulni).
    
    Az itt megjelenő ablakot már eleve a számunkra szükséges módon “átszabhatjuk”, azaz eltérhetünk a megszokott eszköz adatlaptól.
11. Az objektumunk speciális adatait célszerű – de nem kötelező – egy saját adatlapon megjeleníteni a notebook control-on. Ennek érdekében ide vegyünk fel egy plusz sort, ahol a file mezőbe írjuk be a nr_rel_<objektum név>_tab.htmpl fájlnevet és kapcsoljuk ki a Deffered kapcsolót (a fájl nevének a következő lépésben létrehozandó fájl nevével kell meegyeznie!).
12. Hozzunk létre egy új állományt nr_rel_<objektum név>_tab.htmpl fájlnévvel.
    Megjegyzés: Az állomány nevének ekképp történő kialakítása nem szükséges, de ajánlott a CA belső névkonvencióinak követése, s így a fenti névlogikát kell alkalmazni.
13. A létrehozott form-on az eddig megszokott módon vehetjük fel a számunkra szükséges mezőket, definíciókat. A pluszban felvett – és csak ezen osztályhoz tartozó mezőket az nr.assoc_<objektum név> alatt találjuk meg és innen csatoljuk be! Annak érdekében, azonban, hogy a form véletlen más osztályhoz való meghívása esetén ne kapjunk hibát egy plusz ellenőrzést ajánlott beépíteni:
    
    A fenti form kódban látható az ellenőrzést végző sor:
    <PDM_IF “$Extension” == “<objektum név>”>
    A feltétel csak akkor lesz igaz, ha a számunkra szükséges osztállyal dolgozunk, és így a formon található mezők éppen elérhetőek. Javaslom az ellenőrzés használatát!
14. A létrehozott állományok mentését követően, válasszuk ki a File menü Publish menüpontját, és publikáljuk az elkészült módosításokat.
    Megjegyzés: Az én tapasztalataim szerint az r12 esetén ezt követően sok esetben szükséges a pdm_webcache utasítás konzol szinten való ismételt kiadása is, mert különben a form cache nem űrül ki (eddig ilyen problémával nem találkoztam).
15. Ellenőrizzük az elkészített formokat és használjuk egészséggel.

A fentiek alapján azt hiszem érezhető, hogy e megoldást is “emberközelivé tették”, és már nem a text fájlok hegyeinek bújása a feladat, hanem a tényszerű tervezés, és a pontos megvalósítás.