A hónap elején megjelent új Service Desk alapjaiban nem változott sokat, de a részletekben számos változást és fejlesztést fedezhetünk fel. A következőkben – egyenlőre még csak “szárazon” – összefoglalom a rendszer újdonságait. 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.
Aki használja a CA Service Desk rendszert az már biztosan találkozott azzal a helyzettel, hogy a rendszer amennyiben nem sikerült valamilyen oknál fogva az értesítéseket elküldenie, akkor az el nem küldött levelek egy könyvtárba kerülnek. Sajnos ezt követõen eléggé macerás ezek ismételt elküldése.
A héten egy ügyfelünk erre kért megoldást, s tekintettel arra, hogy a megoldás maga univerzálisan jelenleg még létezõ valamennyi verzióhoz jól használható közkincsé teszem.
Kérek mindenkit, hogy aki letölti dobjon egy emailt, mert e jelzések érdeklõdések függvényében publikálom esetleg további tool-jaimat amik e rendszerhez készültek.
A héten – szemben a múltheti IBM-el – talán épp azt ellensúlyozandó a CA által tartott Service Desk Integration tanfolyamon ülök. Ez a tanfolyam félig ismétlés számomra hisz az elmúlt 10-12 évben számos implementációval a hátam mögött, rengeteg interfészt készítettem már…
Jelenlegi megoldásaim teljes egészében .NET 2.0 alapon kidolgozott osztályrendszert alkalmaznak, és ezek segítségével gyakorlatilag pillanatok alatt tudok tetszõleges programokat készíteni az USD mellé.
A tanfolyamot követõen megpróbálom az itt hallottakat is feldolgozni és az utókornak, és külsõ érdeklõdõknek is elérhetõvé tenni.
A most kivitelezett CA Unicenter Service Desk projektben az az elvarázsolt ötletem támadt, hogy az egyik külsõ rendszer felé az adatáramlást és manipulációt a Notification által meghívott módon valósítom meg. Tehettem ezt minden különösebb probléma nélkül, hisz a megrendelõ elvárása az volt, hogy Service Desk egy-egy tikett állapotváltozását követõen végezzen el módosításokat egy másik rendszerben.
A megoldás eléggé hamar létrejött az USD szintjén, hisz a szükséges plusz adatokat a Schema Designer-el felvettem, majd a Web Screen Painter segítségével létrehoztam.
Érdekes ez a Web Screen Painter termék! Hiába van meg én a HTMPL és JS még mindig elsõsorban a régi öreg jól bevált TextPad alkalmazásomat használom. Még anno 2000 határában elkészítettem hozzá egy SYM fájlt, így a belsõ utasításokat a megszokott módon kiemeli, kezeli is a szerkesztõ.
Megvan a mezõ, kezeli is a rendszer de hiába nézem nem jön át a Notification felületen az infó. Mi a teendõ? Sokáig nem esett le a tantusz mit is kezdjek vele, majd bekattant az isteni szikra!
A rendszerben lehetõségünk van a maileater konfigurálása a (\Site\pdm_maileiter.cfg fájl módosításával), hátha az itt található fájlok valamelyike további segítséget jelenthet. És lõn csoda, CA-s barátaink eddigi hagyományaiknak megfelelõen az átadandó adatok halmazát is egy konfig fájlal szabályozzák. Ez a text_api.cfg fájl. E ponttól kezdve a megoldás szinte már adta magát, csak e fájlba fel kell venni a számunkra szükséges elemet és kész. Miként? Egyszerû!
Keressük meg a [KEYWORDS] szekciót és a számunkra szimpatikus pontra szúrjunk be egy új sort a következõ képpen:
REQUEST.<KIMENONEV>=<sajatelem>.<tipus>
pl.: REQUEST.TESTMEZO=testmezo.STRING
és a kimenet:
NX_NTF_KIMENONEV=<adott elemben felvett érték>
pl.: NX_NTF_TESTMEZO=ide kerul a beirt szövegünk
Nem is bonyolult nem? E megoldással már nem volt nehéz elérni, hogy az adott illesztõ alkalmazás minden fontos információt megkapjon és a továbbiakban könnyen befejezhessük az illesztést.
Lényeges még azt is leszögezni, hogy a fentiekben a REQUEST objektumra vonatkozó bõvítésrõl beszéltem, de ugyanilyen módon lehet a CHANGE, ISSUE, CONTACT és az ASSET elemekben lévõ információkat is bõvíteni.
