Az SDM interfészek írása során van egy már kialakított és az elmúlt évek során folyamatosan csiszolt eljárás rendszerem, amit .NET alá készítettem. E rendszerben a kapcsolati szálat egy alap kezelőobjektumon keresztül lehet kezelni, melynek szolgáltatásai között szerepel a leíró mezők induláskor való beolvasása. E megoldás segítségével jelentősen gyorsítani lehet az egyes interfészek működését, hisz nem kell minden leíróadatért elrohanni a szerverhez, hanem az helyben a memóriából olvasható.

E megoldás szépen muzsikált már az elmúlt pár évben, de most beleütköztem egy problémába, nevezetesen, hogy a WebService doSelect utasítása max 250 elem átadását teszi lehetővé. Ez a korlát nem okozott eddig gondot, de a mostani implementációnál már nem volt elégséges. Kénytelen voltam utánanézni mi is az eljárási rend ilyen esetben.

A megoldás – annak ismeretében – frappáns és egyszerű (csak amíg rájössz, hogy mit csinálj másképp…):

  1. Kérdezzük le az adatokat a doQuery metódussal. Itt egy a WebService által definiált ListResult elem lesz a válasz, amiben két infó van a szerveren összeállított lekérdezés azonosítója és a lekérdezésben szereplő elemek száma
  2. Olvassuk ki a számunkra szükséges adatokat a getListValues metódussal, amelynek van egy StartIndex és egy EndIndex paramétere. Ezekkel szabályozhatjuk az egyszerre visszaküldött elemek számát.
    Fontos! Egy adatlekérésben a rendszer max. 250 elemet ad vissza, ennél nagyobb elemszám esetén a lekérdezést a szükséges mennyiségben ismételni kell.
  3. A lista végigolvasását követően a szerver oldalon szabadítsuk fel a listát (és a hozzá kapcsolódó erőforrásokat) a freeListHandles metódussal.

Ennyi az egész, ugye nem is bonyolult? Mosolygó arc

Van egy mondás, amely így szól: "A történelem ismétli önmagát”. Bár történelemről nem beszélhetünk, de én is így jártam, és 2 év kihagyással visszakeveredtem a CA Service Desk köré. A változatosság kedvéért, most akasztják a hóhért, azaz elsősorban cégünknél fogjuk várhatóan a terméket használni. E tényből és előéletemből adódóan az első körös implementációt magunk végezzük, de ezt követően a fő hangsúly a használatra fog vonatkozni (várhatóan). E tényből adódóan ismét nekiültem és végignéztem mi is változott az elmúlt két évben a termékben, annak bevezetésében és végül használatában.

Eddigi életemben – bár mindig is használtuk a terméket – soha nem a felhasználáson volt a hangsúly, hanem az implementáción és a betanításon. Ezt követően az ügyfeleket szép fokozatosan magukra hagytuk és már csak a kérdések a problémák esetében találkoztunk a termékkel. Nos ez most várhatóan nem így lesz, a mindennapok öröme és bánata is az életem része lesz.

A CA a Service Desk termékkel most az r12.5-nél jár, úgyhogy e termékhez nyúltam (régebbit nem sok értelme lenne nem ?). Két év kihagyás után az ember elsőre – CA esetén ez eddig is nagyon ajánlott volt – a RELASE NOTES-vel kezd. Nos ez mára önálló könyvé, 144 oldalas kis PDF-é nőtte ki magát. A leírás alapján rájöttem, hogy a termék számos ponton igencsak fejlődött, a kb 3 évvel ezelőtti fejlesztői egyeztetésen Londonban ígértek mentén ment tovább a gyár, illetve számos ott felvetett, vagy akkor már Wish List-en lévő kérés meghallgatásra talált. Nem mennék bele a 144 oldal részletes taglalásába, de röviden felsorolnám azokat a pontokat, amelyek már az olvasás pillanatában megérintettek, és rájuk ezt követően több figyelmet fordítottam:

  • Kiterjesztett Multi-tenancy megvalósítás
  • E-mail kezelés (küldés, fogadás) továbbfejlesztése
  • Állapot váltás szabályozása
  • Automatikus feladat lezárás
  • Felhasználói interfész és az adminisztrációs felület, szolgáltatások továbbfejlesztése
  • CA IT PAM
  • Tudásbázis Management változásai, további integrációja a termékkel
  • CMDB fejlődése

         

        Az eddigi ismereteim birtokában és a fentiek alapján már feltételeztem, hogy igencsak sokat fejlődött a termék, de azt amit a későbbiekben találtam azt ekkor még csak nem is feltételeztem.

        Az első telepítést és a Tenant szolgáltatás engedélyezését követően elkezdtem a termék részletes felderítését, de ezek mindegyike már egy-egy önálló post-ot érdemel.

        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.

        More »

        A cikksorozat a hónap elején megjelent Service Desk új változatát veszi górcső alá, jelenleg még szigorúan csak “szárazon”. Az összefoglaló megírása során feltételezem, hogy a kedves olvasó ismeri az ITL v3-t és a Service Desk rendszer előző változatainak valamelyikét. Lássuk hát a folytatást.

        More »