In-context launch wrapper (ICLW) module and method of automating integration of device management applications into existing enterprise management consoles6311321Abstract Embodiments of the present invention are directed to an In-Context Launch Wrapper (ICLW) module which provides a comprehensive generic interface for automating integration of device management applications (applets) into existing Enterprise management console(s) installed at a host system of a network for centralized remote device management of remote network devices on a network. The ICLW module comprises a set of extensible software components, including: an Install component which provides a file based interface to device management applications for installation specific to the existing enterprise management consoles; a MConsole Interface component which provides a comprehensive generic interface to existing enterprise management consoles for enabling integration of device management applications into the existing enterprise management consoles; a Discovery component which provides a discovery interface to the existing enterprise management consoles for identifying remote network devices on a network; and a Trap Extension component which provides an extension interface to the existing enterprise management consoles for handling Simple Network Management Protocol (SNMP) traps on a network. Claims What is claimed is: Description TECHNICAL FIELD
pwNumConsoles: Variable to hold number of consoles
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in
<iclwerr.h>, specific errors and function proto-
types are defined in other header files, and are
included in a source file
Remarks: Get the number of consoles installed.
The second instruction set stored in the Install Interface DLL 214 may be used to obtain detailed information of the Enterprise management consoles installed at the host system 12. Similarly, the instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWGetConsoleInstallInfo(LPCONSOLEINFO pConsoleInfo, WORD wNumConsoles);
pConsoleInfo: Array of Console information structures
wNumConsoles Number of elements
Return Values: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in
<iclwerr.h>, specific errors and function
prototypes are defined in other header flles,
and are included in a source file
Remarks: Get the information of consoles installed on the system.
The third instruction set stored in the Install Interface DLL 214 may be used to process install file for installation of an applet. Likewise, the instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWProcessInstallFile(LPCTSTR IpszFileName);
IpszFileName: Full path to the Install file
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific errors and function prototypes are defined in
other header files, and are induded in a source file
Remarks: Process the install file.
Again, it should be understood that practice of the present invention is not limited to the above or below discussed example instructions. FIG. 4 illustrates a functional diagram of an example MConsole Interface (MCI) module 220 of the In-Context Launch Wrapper (ICLW) application 200 according to the principles of the present invention. The MConsole Interface module 220 may be useful in abstracting different Enterprise management consoles from the applet by providing a comprehensive generic interface to existing Enterprise management consoles. As shown in FIG. 3, the MConsole Interface (MCI) 210 may comprise a dynamic link library (DLL) 222 and a plurality of interface COM objects 224, 226, 228 for automating integration of device management applications (applets) such as a SMM applet 100 and an ISC applet 110 into existing Enterprise management consoles such as HP OpenView, CA Unicenter via corresponding HP OpenView Libraries 302, and CA Unicenter Libraries 312 and MConsole Interface Libraries 322. The console libraries such as HP OpenView Libraries 302, CA Unicenter Libraries 304 and other MConsole #N Interface Libraries 322 may contain console information specific to different Enterprise management consoles, such as HP OpenView 300, the CA Unicenter 310, the Intel LDSM 320, and the IBM Tivoli 330 as shown in FIG. 2. Such console information may include installation directory, language, console version, etc. The individual interface COM objects such as the HP Interface COM object 224, the CA Interface COM object 226 and MConsole #N interface COM object 228 may act as translators for respective Enterprise management consoles which may translate instructions from the MConsole Interface DLLs 222 into console specific commands. The MConsole Interface DLL 222 may store generic instruction sets (i.e., interface programs written typically in C and C++ language, but not limited thereto) for providing a comprehensive generic interface to all applets such as SMM applet 100 and ISC applet 110 and generic mechanisms to obtain generic and instance specific properties from any console, such as to generate events and log message to the console. The properties can be properties of the console such as the language and version being run or device properties such as the card type of a SMM card, the server name, etc. Individual instruction sets (in bold print below) and textual comments may be written in the non-exhaustive list of C or C++ code language. For example, the first instruction set stored in the MConsole Interface DLL 222 may be initiated by the applet used to determine which Enterprise management console (software application) installed at a host system 12 may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWInitMCI(DWORD dwConsoleID, IUnknown **ppUnk);
dwConsoleID: The console identifier
ppUnk: Pointer to Iunknown pointer. If the Iunknown pointer
is not needed pass NULL
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific prototypes are defined in other header files and
are included in a source file
Remarks: Initialize the Mconsole interface DLL 222 and optionally
returns the IUnknown pointer. Release the
Iunknown pointer after finished.
The second instruction set stored in the MConsole Interface DLL 222 may be referred to as a get property procedure and may be used during a 2nd discovery application to get information of a network device, which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWGetProperty(LPDEVICEIDSTRUCT pDeviceId, LPCTSTR pszPropertyName, WORD *pwType, void**ppBuff, DWORD **pdwSize);
pDeviceId: The structure has three fields that are used to iden-
tify the device. The fields are: ObjectId (console
specific id passed in the command-line), AppletId,
and the network address (command-line)
pszProperty Name: The generic name of the property. This name is de-
fined in xxdevprp.ini
pwType: The data type of the property. The types are defined
in "Iclwtype.h". If the type passed is incorrect
the type will be changed, check the type on return
ppBuff: Pointer to buffer pointer. The buffer will be alloca-
ted using the `ICLWMemAlloc` function. The
caller should free the buffer using ICLWMemFree
function
PdwSize: Size of the buffer in bytes
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Get the property from the object defined in the
Mconsole. This function is used by the applet to get
properties of the device they are managing. The
properties are defined in xxdevprp.ini. They may
also need to be defined in the console if they are
special properties of the network device. The
device extensions can also use this function during
the 2.sup.nd level of discovery to get properties
directly from the console if they are available.
Since there is no guarantee that they are available
the device extension should have a alternate
mechanism to get the properties
Sample: //This function gets the server name(string) and
prints it Foo(LPTSTR szObjId, LPTSTR
szAppletId, LPTSTR szNetAddress)
{
void *pszServerName;
DWORD dwcardType;
DWORD dwSize;
WORD wType = ICLW_STRING;
DeviceId DevId;
SetUpDeviceId(&DevId,szObjId,szAppletId,
szNetAddress)
if(S_ICLW_OK==ICLWGetProperty(&DevId,
"SERVER_NAME"
&wType, &pszServerName, &dwSize)
printf("ServerName=%s",
(LPTSTR)pszServerName);
ICLWMemFree(pszServerName); }
The void ** is used to oveload the
ICLWGetProperty function to support multiple data
types.
The third instruction set stored in the MConsole Interface DLL 222 may be referred to as a set property procedure and may be used to set information of a network device, which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWSetProperty(LPDEVICEIDSTRUCT pDeviceId, LPCTSTR pszPropertyName, WORD wType, Void*pBuff, DWORD dwSize);
pDeviceId: The structure has three fields used to
identify the device. The fields are: ObjectId
(console specific id passed in the
command-line), AppletId, and the network address
(obtained from command-line)
PszPropertyName: The generic name of the property. This name is
defined in xxdevprp.ini
wType: The data type of the property. The types are defined
in "Iclwtype.h"
pBuff: Pointer to buffer. A pointer to appropriate data type
should be cast to a void* and passed
dwSize: Size of the buffer in bytes
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined
in other header files and are included in a source
file
Remarks: Set the property for the object defined in the
Mconsole. This function will be typically used
by device extension DLLs in the 2nd level
discovery.
The fourth instruction set stored in the MConsole Interface DLL 222 may be initiated by the applet used to get console information of a network device, which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWGetConsoleInfo(LPCONSOLEINFO *pConsoleInfo);
pConsoleInfo: Pointer to the console info structure pointer.
The structure will be allocated by ICLW, free the
structure after use with ICLWMemFree
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Get the console info.
The fifth instruction set stored in the MConsole Interface DLL 222 may be initiated by the applet used to get console trap information of a network device, which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWGetConsoleTrapInfo(LPTRAPINFO*pTrapInfo);
pTrapInfo: Pointer to the trap info structure pointer. The
structure will be allocated by ICLW, free the structure
after use with ICLWMemFree
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific prototypes are defined in other header files and
are included in a source
Remarks: Get the IP address of the console and the port its
listening for traps.
The sixth instruction set stored in the MConsole Interface DLL 222 may be initiated by the applet used to generate an event, which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWGenerateEvent(LPEVENTSTRUCT pEvent);
pEventInfo: Pointer to the event structure
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific prototypes are defined in other header files and
are included in a source file
Remarks: Generate an event on the console.
The seventh instruction set stored in the MConsole Interface DLL 222 may be initiated by the applet to log a message, which may be needed for the Enterprise management console. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWLogMessage(LPLOGENTRYSTRUCT pLogEntry);
pLogEntry: Pointer to the log entry structure
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific prototypes are defined in other header files and
are included in a source file
Remarks: Log a message to the console.
The eighth instruction set stored in the MConsole Interface DLL 222 may be used to exit the In-Context Launch Wrapper (ICLW) message. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWExitMCIO;
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr,h>,
specific prototypes are defined in other header files and
are included in a source file
Remarks: Release the resources of Mconsole Interface DLL.
The ninth instruction set stored in the MConsole Interface DLL 222 may be used to get a simple network management protocol (SNMP), which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWSNMPGet(LPSNMPGETSTRUCT IpSNMPGet, WORD *pwType, void**ppBuff, DWORD*pdwSize);
IpSNMPGet: Pointer to the SNMP get structure
pwType: The data type of the property. The types are defined in
"Iclwtype.h". If the type passed is incorrect
the type will be changed, check the type on return
ppBuff: Pointer to buffer pointer. The buffer will be allocated
using the `ICLWMemAlloc` function. The caller should
free the buffer using ICLWMemFree function
PdwSize: Size of the buffer in bytes
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Use SNMP to do a get on a MIB (Management
Information Base).
The tenth instruction set stored in the MConsole Interface DLL 222 may be used to set a simple network management protocol (SNMP), which may be needed for integration. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWSNMPSet(LPSNMPSETSTRUCT pSNMPSet, WORD wType, void*pBuff, DWORD dwsize);
pSNMPSet: Pointer to the SNMP set structure
wType: The data type of the property. The types are defined in
"Iclwtype.h"
pBuff: Pointer to buffer. A pointer to appropriate data type
should be cast to a void * and passed.
dwSize: Size of the buffer in bytes
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Use SNMP to set a value in a MIB (Management
Information Base).
The eleventh instruction set stored in the MConsole Interface DLL 222 may be used to set a symbol status of a network device. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWSetSymbolState(LPDEVICEIDSTRUCT pDeviceId, DWORD dwState);
pDeviceId: Pointer to the device id structure
dwState: The state can be ICLW_SYMBOL_ALERT,
ICLW_SYMBOL_WARNING, or
ICLW_SYMBOL_NORMAL
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Set the state of the symbol on the console.
The twelfth instruction set stored in the MConsole Interface DLL 222 may be used to perform memory allocation functions on the Enterprise management console. The instruction set may be written in C or C++ code language as provided as follows. LPVOID ICLWMemAlloc(DWORD dwsize);
dwSize: Size in bytes.
Return Value: Allocated memory block, Memory block allocated
successfully. NULL, insufficient memory available
Remarks: Allocate a block of memory. Use this function to
allocate memory for buffers passed to the MCI functions.
The thirteenth instruction set stored in the MConsole Interface DLL 222 may be used to perform memory reallocation functions on the Enterprise management console. The instruction set may be written in C or C++ code language as provided as follows. LPVOID ICLWMemReAlloc(LPVOID IpBuff, DWORD dwsize);
IpBuff: Pointer to the buffer to be reallocated
dwSize: Size in bytes
Return Value: Reallocated memory block, Memory block successfully
reallocated. NULL, insufficient memory or dwSize
is zero
Remarks: Allocate a block of memory. Use this function to
allocate memory for buffers passed to the MCI functions.
The fourteenth instruction set stored in the MConsole Interface DLL 222 may be used to free memory from the Enterprise management console. The instruction set may be written in C or C++ code language as provided as follows. HRESULT ICLWMemFree(LPVOID IpBuff);
lpBuff: Pointer to the buffer to be freed
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to indicate
failure: The error codes are defined in <iclwerr.h>,
specific prototypes are defined in other header
files and are included in a source file
Remarks: Allocate a block of memory. Use this function to allocate
memory for buffers passed to the MCI functions.
The fifteenth and sixteenth instruction sets stored in the MConsole Interface DLL 222 may relate to the use of the COM interface at the console interface COM objects such as HP OpenView interface COM object 224, CA Unicenter interface COM object 226, and MConsole #N interface COM object 228. When the COM interface may be used, the `ICLWInitMCI` function may be called to get the IUnknown pointer. Query interface for a IConsole pointer may be made by referring to console.h for the interface definition. The Iunknown and the IConsole pointer may be released before calling ICLWExitMCI. The IConsole pointer may provide almost exactly identical functions as the C interface. The only exceptions may be the `GetProperty` and `SetProperty` functions. These `GetProperty` and `SetProperty` functions may be written in C or C++ code language as provided as follows. HRESULT ICLWGetProperty(LPDEVICEIDSTRUCT pDeviceId, LPCTSTR pszPropertyName, variant*pvarg);
pDeviceId: The structure has three fields used to identify the
device. The fields are: ObjectId (console specific
id passed in the command-line), AppletId, and the
network address (command-line)
pszPropertyName: The generic name of the property. This name is
defined in xxdevprp.ini
pvarg: Pointer to a variant. Check the type on return
and use the appropriate union member
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined
in <iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: Same as for the ICLWGetProperty in the
MConsole interface.
HRESULT ICLWSetProperty(LPDEVICEIDSTRUCT pDeviceId, LPCTSTR pszPropertyName, variant*pvarg);
pDeviceId: The structure has three fields to identify the
device. The fields are: ObjectID (console specific
id passed in the command-line), AppletId, and the
network address (obtained from command-line)
PszPropertyName: The generic name of the property. This name
is defined in xxdevprp.ini
pvarg: Pointer to a variant
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used
to indicate failure: The error codes are defined
in <iclwerr.h>, specific prototypes
are defined in other header files and are
included in a source file
Remarks: Same as for the ICLWSetProperty in the
MConsole interface.
FIG. 5 illustrates a functional diagram of an example Discovery module 230 of the In-Context Launch Wrapper (ICLW) application 200 according to the principles of the present invention. The Discovery module 230 may be known as a 2.sup.nd level Discovery module, and may be provided for each Enterprise management console installed and/or which may potentially be installed at a host system 12 which may call into device specific extensions to do specific device discovery. The 2.sup.nd level Discovery module 230 may be required to identify the type of a network device, such as ISC server or SMM card, and to also get additional properties of such device. As shown in FIG. 5, the 2.sup.nd level Discovery module 230 may contain a 2.sup.nd level discovery.exe block 232, Devdisc.ini files 234A, xxDevprp.ini files 234B, and a plurality of device extensions such as device extension #1 236A and device extension #N 236B. The Devdisc.ini files 234A and the xxDevprp.ini files 234B may be configuration and initialization files. The device extension #1 236A and device extension #N 236B may be software components for representing different network devices 16, 18, 20 on a network 10. It should be understood that FIG. 5 is actually a diagram over time, wherein the left-hand portion of such figure is illustrative of a starting state where the MConsole interface 220 has an unidentified node, a middle portion of such FIGURE illustrates procedures, etc., used to gather additional information, and a right-hand portion is illustrative of an ending state where the MConsole interface 220 now contains an identified node as well as found properties. More particularly, the 2.sup.nd level discovery.exe block 232 may interact with MConsole Interface module 220 via MCI DLL 222 to obtain specific information of the network device and related properties. For example, at the end of the 1.sup.st (initial) level discovery which may be provided by most Enterprise management consoles, the MConsole Interface module 220 may contain unidentified node. The 2.sup.nd level Discovery module 230 may be initiated by the console in order to obtain an identification of such node of the network device and related properties. The 2.sup.nd level Discovery module 230 may also be used to gather further detailed information with respect to already known nodes. Device specific extensions such as device extension #1 236A and device extension #N 236B may be called to do specific device discovery. Instruction sets stored in the MConsole Interface DLL 222 may be used export a `DISC2CheckDeviceIdentity` function (given below) and may implement the `DISC2GetProperty` function (given below) during the 2.sup.nd level discovery. The instruction sets imported from MConsole Interface DLL 222 may be written in C or C++ code language as provided as follows. HRESULT DISC2CheckDeviceIdentity (LPDEVICEIDSTRUCT pDeviceId, BOOL *bNoGets);
pDeviceId: The structure has three fields that are used to
identify the device. The fields are: ObjectId (console
specific id), AppletId, and the network address
(IP/IPX). The ObjectId and the network address Will be
set in the structure when it is passed
to the function
BNoGets: Set this to 1 if GetProperty calls need not be made.
If set to 1, the assumption is that either properties
of device are not available or the SetProperty call
in the MCI dll is used to set the properties of device
Return Value: S_ICLW_OK indicates that the device at the network
address is correct
S_ICLW_FALSE indicates that the device is incorrect
Remarks: The 2.sup.nd level discovery exe will call this function
in device extension DLL to check if the device
at the given network address has been identified
as correct. The network address is passed in the
DeviceId structure. Set the AppletId field in the
structure before returning from the function.
HRESULT DISC2GetProperty(LPDEVICEIDSTRUCT pDeviceId, LPCTSTR bpszPropertyName, WORD wType, void **ppBuff, DWORD *pdwSize);
pDeviceId: The structure has three fields that are used to
identify the device. The fields are: ObjectId (console
specific id), AppletId, and the network address
(IP/IPX)
pszPropertyName: The generic name of the property. This name
is defined in xxdevprp.ini
wType: The data type of the property. The types are
defined in "Iclwtyp.h"
ppBuff: Pointer to buffer pointer. Allocate the buffer using
the `ICLWMemAlloc` function. The caller
will free the buffer
PdwSize: Size of the buffer in bytes
Return Value: S_ICLW_OK indicates success
Error codes defined as follows and are used to
indicate failure: The error codes are defined in
<iclwerr.h>, specific prototypes are defined in
other header files and are included in a source file
Remarks: The 2.sup.nd level discovery exe will call this function
in device extension DLL to get the properties of the
identified device. Depending on the type, a
pointer to a DWORD, or a string etc. may
be sent. The 2.sup.nd level discovery exe will use the
type information from xxDevprp.ini to cast to
the correct type. Set the AppletId field in the Device
id structure before returning from the function.
The Devdisc.ini files 234A of the 2.sup.nd level Discovery module 230 may list the device extension DLLs that the 2.sup.nd level Discovery module 230 may call. Every device extension that may need to be called may have an entry in the INI files. The format may be as follows. [DEVDISC] NumExtensions=2 DDE--DeviceName#1=ISC DDE DLLPath#1=%ISC PATH%lscdisc.dll The xxDevprp.ini files 234B of the 2.sup.nd level Discovery module 230 may list the properties of the device and the corresponding console specific names for the attributes. There may be a single file from the xxDevprp.ini files 234B for each Enterprise management console. The format may be as follows. [Generic] NumProperties=2 DP_GenericName#1=ServerName DP_ConsoleSpecificName#1=CA_SERVER_NAME DP_Type#1-ICLW_STRING [SMM] NumProperties=2 DP_GenericName#1=CardType DP_ConsoleSpecificName#1=CA_CARD_TYPE DP_Type#1=ICLW.sub.=13 STRING For every device extension (DLL) listed in the Devdisc.ini files 234A of the 2.sup.nd level Discovery module 230, the 2.sup.nd level discovery.exe block 232 of the 2.sup.nd level Discovery module 230 may call the Disc2CheckDeviceIdentify function first. If the device may be identified, an appropriate success value may be returned. There may be two ways of giving properties of the identified device to the 2.sup.nd level Discovery module 230. 1. The Device extension can use the ICLWSetProperty call provided by the MCI dll to set the properties on the object, while it is in the Disc2CheckDeviceIdentity call. It can assume that the MCI dil is initialized and therefore does not need to call the ICLWInitMCI and the ICLWExitMIC functions. If it uses the ICLWSetProperty function, it should set the bNoGets flag to 1 in the Disc2CheckDeviceIdentity call. If this flag is set, no more calls will be made into the device extension dll. To use the ICLWSetProperty the device extension DLL needs to link with MCI.lib. 2. The other way to return properties is to wait for the GetProperties call. If the device extension choose to wait for the Disc2GetProperty calls, it should set the bNoGets flag to 0. This may require a saving state between functions calls depending on implementation. FIG. 6 illustrates a functional diagram of an example Trap extension module 240 of the In-Context Launch Wrapper (ICLW) application 200 according to the principles of the present invention. The Trap extension module 240 may be used to extend the Enterprise management console's trap handling for purposes of automating integration of a specific applet into the existing Enterprise management console. The Trap extension mechanism may be very handy for special trap handling. For example, when a network device under management such as SMM server may send Simple Network Management Protocol (SNMP) traps and those SNMP traps are not acknowledged, the SMM server may not know if the SNMP traps were received. With the Trap extension application 240 in place, when a SNMP trap may be received from SMM server, the Enterprise management console may handle the SNMP trap, and then call the Trap extension which may acknowledge the SNMP trap. The SNMP Trap extension and acknowledgment may be described in greater detail with reference to FIG. 6. The Trap extension module 240 may contain a Trap extension block 242, and Traphdlr.ini files 244 which may handle trap extension. The Trap extension block 242 may use the SNMP management API with Windows NT, for example, so as not to depend on SNMP support on the Enterprise management console. When a network device 16, 18, or 20 may generate an event (SNMP trap) to the Enterprise management console, the MConsole Interface module 220 of the In-Context Launch Wrapper (ICLW) application 200 may access the Trap extension block 242 using Traphdlr.ini files 244 to handle the SNMP trap and to send a SNMP Trap acknowledgment to such a network device 16, 18, 20 (see FIG. 6 feedback loop) for integration with the Enterprise management console. This may be necessary because the SNMPv1 protocol may not provide a mechanism for acknowledging a SNMP trap. One common solution may be to set a flag in the network device Management Information Base (MIB) files which may be used to define SNMP traps and variables, when the SNMP trap may be sent from the network device 16, 18, 20. The flag may be reset by the receiver of the SNMP trap via SNMPSet function, which may be used to acknowledge SNMP trap receipt. If the flag may not be reset before a time-out, the network device 16, 18, 20 may take certain actions such as trying to send the SNMP trap again or use other alternate mechanisms to acknowledge such a receipt. Lastly, the FIG. 2 example Launch module 250 of the In-Context Launch Wrapper (ICLW) application 200 may be optional. Most Enterprise management consoles may provide a comprehensive mechanism for launching applications with command-lines. For example, a HP OpenView console may allow the user (network administrator) to launch specific device management application from the Enterprise management console toolbar icon, menu, or submap using a graphic user interface. Consequently, the launch procedure may not be needed unless the Enterprise management consoles may not contain mechanisms for launching operations. As described from the foregoing, the In-Context Launch Wrapper (ICLW) application according to the present invention has several advantages. First, ICLW application may provide an management solution to integration and interoperability between LAN management applications and Enterprise management applications. Second, the ICLW application may efficiently automate integration of device management software functionality into existing Enterprise management consoles which may allow the network administrator to easily manage all aspects of the enterprise from a single console, desktop and mobile PC systems. Third, the ICLW application may launch any device management software from the Enterprise management console toolbar icon, menu, or submap for viewing and remote management over a network. Fourth, the ICLW application may lower the cost of managing complex corporate computing environments. Lastly, the ICLW application may be extendable to accommodate integration of newly developed Enterprise management console software as well as newly developed device management applications. While there have been illustrated and described what are considered to be exemplary embodiments of the present invention, it will be understood by those skilled in the art and as technology develops that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the present invention. For example, additional device management application programs of different vendors may be provided to allow greater integration with different Enterprise management console framework. A network may include a local area network (LAN), a wide are network (WAN), a campus area network (CAN), a metropolitan area network (MAN), a global area network (GAN), and a system area network (SAN) for linking together computers, servers, workstations, peripherals, storage devices, and other types of communication devices for communications. Many modifications may be made to adapt a particular situation to the teachings of the present invention without departing from the central scope thereof. Therefore, it is intended that the present invention not be limited to the various exemplary embodiments disclosed, but that the present invention includes all embodiments falling within the scope of the appended claims.
|
Same subclass Same class Consider this |
||||||||||